EPUB 使用指南

EPUB 其實就是 ZIP——一部特殊的 ZIP 檔案

EPUB 的副檔名雖然是 .epub，但打開任何一個 EPUB 檔案，內部實際上就是一個 ZIP 封存。只是這個 ZIP 必須遵守比一般 ZIP 更嚴格的規則，否則閱讀器不會承認它是合法的 EPUB。

ZIP 做為 EPUB 的容器

W3C 的 EPUB 規格書中，OCF 章節明確規定 EPUB 必須使用 ZIP 做為實體容器格式。這不是一個可選的設計，而是 EPUB 標準的核心要求。選擇 ZIP 的原因很實際：ZIP 是幾乎所有作業系統都內建支援的壓縮格式，不需要額外的軟體就能讀取內容。但 EPUB 在 ZIP 之上加了三個關鍵限制。

mimetype 必須是第一個 entry

第一個限制是 ZIP 檔案中的第一個 entry 必須是 mimetype，且這個 entry 必須使用 Stored（不壓縮）的儲存方式。mimetype 的內容必須精確為 application/epub+zip，不包含 BOM、不包含換行字元、不包含前後空格。這個設計的目的是讓閱讀器可以在不掃描整個 ZIP 的情況下，直接讀取第一個 entry 就判斷檔案是否為 EPUB。如果 mimetype 使用 Deflate 壓縮，或位置不在第一個，某些閱讀器會直接顯示「格式不支援」的錯誤。

舉例來說，假設一個 ZIP 的 entry 順序是 META-INF/container.xml 在前，mimetype 在後，這個檔案在 Windows 的檔案總管可能可以開啟，但匯入到 Kobo 或 Kindle（透過轉換）時就會失敗。EPUB Tools 在修復時會重新排列 entry 順序，確保 mimetype 永遠是第一個，並且使用 Stored 方式儲存。

ZIP 中的壓縮方式

除了 mimetype 必須使用 Stored 之外，EPUB 內的其他檔案可以使用 Deflate 壓縮，這是一般 ZIP 最常見的壓縮方式。但有一個例外：如果 EPUB 使用了 ZIP 64 延伸格式（檔案大小超過 4GB 或 entry 數量超過 65535 個），部分瀏覽器或舊版閱讀器的 ZIP 處理程式可能無法正確讀取。EPUB Tools 在這種情況下會發出警告，但不會自動降級為 ZIP 32，因為這可能改變 ZIP 的內部結構。

另一個需要注意的是加密的 ZIP。EPUB 標準不允許使用 ZIP 層級的加密，但允許使用 EPUB 標準定義的 DRM 機制（如 Adobe ADEPT 或 LCP）。如果 EPUB 使用了 ZIP 的密碼保護或 AES 加密，EPUB Tools 無法讀取其內容，因為瀏覽器端的 ZIP 函式庫不支援處理加密的 ZIP 封存。

為什麼有些工具會破壞 EPUB 的 ZIP 結構

macOS 的 Archive Utility 在解壓縮 EPUB 時，會自動產生 __MACOSX 資料夾，並且在每個檔案旁產生 ._* 的 Apple Double 檔案。這些檔案在重新壓縮時會變成 ZIP 中的 entry，破壞 EPUB 的容器結構。Windows 的「傳送到壓縮資料夾」功能雖然不會產生 Apple 雙檔案，但重新壓縮時不一定會保留 mimetype 的 Stored 屬性，而且可能改變 entry 的順序。

Linux 的 zip 指令在預設情況下會按照新增檔案的順序來排列 entry，如果使用者先加入 META-INF/ 再加入 mimetype，產生出來的 ZIP 就不符合 EPUB 規範。這就是為什麼 EPUB 的封裝工具通常會先寫入 mimetype，再寫入其他檔案。

如何驗證 ZIP 是否符合 EPUB 規範

最簡單的方式是使用 unzip -l 指令來列出 ZIP 的 entry，檢查第一個 entry 是否為 mimetype。然後使用 unzip -Z 查看每個 entry 的壓縮方式，確認 mimetype 的壓縮方法為 stored。也可以用 hexdump 直接讀取 ZIP 檔案的前幾個位元組，確認 ZIP local file header 的檔名為 mimetype。EPUB Tools 在瀏覽器內自動完成這些檢查，並在結果中顯示每個 EPUB 的容器狀態。

ZIP 檔案的內部結構由三個主要部分組成：local file headers（每個 entry 一個，位於檔案前端）、Central Directory（位於檔案尾端，匯總所有 entry 的索引資訊）以及 End of Central Directory Record（EOCD，標記 ZIP 的結束位置，並記錄 Central Directory 的起始偏移量）。EPUB 閱讀器通常先讀取檔案尾端的 EOCD 來定位 Central Directory 的位置，再從 Central Directory 取得所有 entry 的清單與偏移量。但對於 mimetype 的檢查，有些閱讀器會直接讀取第一個 local file header，而不依賴 Central Directory 的索引，這是 mimetype 必須是第一個 entry 的重要原因。

Central Directory 中的每個 entry 都包含一個「相對偏移量」（relative offset），指向對應的 local file header 在 ZIP 檔案中的位元組起始位置。如果 EPUB 在傳輸過程中發生位元組損毀，導致 Central Directory 中記錄的偏移量與實際 local file header 的位置不一致，閱讀器可能無法正確解析 EPUB 的內容，甚至完全無法開啟檔案。EPUB Tools 在檢查容器時，會逐一比對 Central Directory 與 local file header 的資訊是否一致——包括檔案名稱、壓縮方式與 CRC-32 校驗碼——並在發現不一致時提出警告，讓使用者知道 EPUB 的 ZIP 結構可能已經受損。

開始檢查 EPUB