iloveepub本機處理 — 檔案永不離開你的裝置
修復我的 EPUB
一本書的搶救全在一頁完成：拖入那本打不開、目錄壞掉、或在書架上沒有名字的書，先做健康檢查，結構損壞自動修復，封面和元資料的缺口由你補上——下載前還會自動複檢。全部在瀏覽器裡進行，檔案從不離開你的裝置。
01選擇你的 EPUB
如何修復一本壞掉的 EPUB
放入壞書
選擇任何 .epub 檔案——打不開的、目錄壞掉的、書架上沒名字的都行。不上傳任何內容。
查看健康報告
診斷列出每一項檢查——container、mimetype、引用、目錄、封面、元資料——標註健康、可修復或無法修復。
套用修復
結構問題自動修復。若封面或書名/作者元資料缺失，在同一步補上——兩項都是可選的。
下載驗證過的書
修復後的 EPUB 在下載前會自動複檢。你拿到的是修復報告和全綠結論，不是一句空泛的「成功」。
健康檢查都查什麼
EPUB 本質是一個對自身結構有嚴格規則的 ZIP 包，而幾乎所有「打不開」的案例都是結構問題，不是內文損壞。診斷逐層檢查這些結構：先看壓縮檔本身，再看 META-INF/container.xml——它是告訴閱讀器「書的內容清單在哪」的收件標籤；然後驗證 mimetype 條目：它必須是壓縮檔的第一筆記錄、以不壓縮方式儲存、內容一字不差。很多重新打包工具恰恰做錯這一點，不少閱讀器因此直接拒收。
再往深處，檢查會把 manifest 與包內實際檔案逐一對照：每個被引用的文件和圖片必須真實存在，spine 的每一條目必須指向 manifest 裡宣告過的條目，導覽文件（EPUB 3 的 nav 與 EPUB 2 的 NCX）必須存在且可解析。最後看兩樣決定書架顯示的東西：封面宣告，以及書名和作者元資料。每一項的結論都會標為：健康、可自動修復、或只有你能補。
EPUB 為什麼會壞
多數壞書是製作工具出廠就壞的：匯出器的 ZIP 寫入器有 bug，把 mimetype 放錯位置或錯誤壓縮；擷取器和自製轉換器引用了從未嵌入的檔案；有些寫作軟體產生的 manifest 在區分大小寫的閱讀器上路徑對不上。
其餘的壞在傳輸和存放途中：下載中途斷掉、雲端同步衝突把兩個副本合併成一個包、某個 zip 工具「好心」地用不同壓縮方式重新打包、或一次手滑的改名弄亂了 container。這些都不影響內文本身——這正是為什麼結構修復做得對，就能在不重新編碼任何一章的前提下把書救回來。
診斷 → 修復 → 複檢的閉環
無法驗證的修復只是猜測。桌面工具把修好的檔案丟給你，讓你自己去試；上傳式轉換器哪怕書仍然無法通過驗證，也會展示一個「成功」頁面。本工具把閉環閉上：結構修復套用之後、下載按鈕出現之前，同一套健康檢查會在瀏覽器裡對結果再跑一遍。如果仍有缺項——比如你跳過了可選的封面——報告會直說，而不是宣告大功告成。
複檢也讓工具對自己的能力邊界保持誠實。當一本書的損壞超出了瀏覽器端修復的能力，診斷會預先告知「無法修復」，而不是讓你在一個假進度條盡頭才碰壁。
能修什麼、不能修什麼（誠實清單）
可自動修復：缺失或損壞的 container.xml、位置不對或被壓縮的 mimetype 條目、manifest 裡指向不存在檔案的引用、spine 裡未宣告的條目、缺失的 EPUB 3 nav 文件或 EPUB 2 NCX、以及早期編輯留下的死連結。這些修復都是確定性的，本工具逐一套用並驗證。
由你來補、工具來寫：缺失的封面（上傳 JPG、PNG、WebP 或 GIF 皆可）、缺失的書名或作者元資料（填進去，工具寫入規範的 Dublin Core 元素）。
這裡修不了、且工具會如實告知的：整個檔案不是合法 ZIP、書內沒有可讀章節、以及帶 DRM 鎖的檔案。DRM 書無法處理——瀏覽器裡既解不開，多數地方也不合法，任何誠實的工具都不會聲稱自己能做到。
為什麼書架上顯示檔名或空白封面
書庫類應用程式在排書架時只讀兩樣東西：包元資料裡的封面宣告，和 dc:title / dc:creator 元素。缺了任何一樣，閱讀器就自己湊合——檔名頂替書名、灰色佔位圖頂替封面——而人們很自然地以為書壞了。其實多半只是發布時就不完整，或某個轉換器剝掉了元資料。
所以封面和元資料被納入本工具的診斷，而不是留給你單獨去查：健康檢查點出缺口，你補上缺失的那塊，複檢確認書架從此能正常渲染這本書。
為什麼堅持本機修復
一本你在意的 EPUB 是一件私人物品。它可能帶著你的劃記錨點、閱讀進度標記、購買識別碼，元資料裡還有前任擁有者或工具寫進去的任何內容。上傳式修復服務把整個檔案送到一個你無法稽核的伺服器上，它們的隱私權政策描述的是「保留多久」，不是「不可能發生」。
本頁面沒有任何上傳通道——沒有壓縮後的備援，沒有佇列，沒有暫存副本。檔案用與閱讀器相同的瀏覽器 API 開啟、在記憶體中修改、交還給你。工具運作時你可以盯著網路面板：唯一的請求就是頁面本身。
「修復我的 EPUB」與單點工具的關係
本站也提供每個修復的獨立版本——Repair EPUB、Fix EPUB TOC、Metadata Editor、Change Cover——它們繼續可用。差別在於意圖：那些頁面假設你已知問題所在；「修復我的 EPUB」假設你不知道——你手裡只有一本壞書和一個問號。它檢查一切、一次性套用所有自動修復、提示兩處需要人來補的缺口，最後交付一本經過複檢、書架就緒的書。
支援最大 120 MB 的書，超過 100 MB 會溫和提醒（修復在記憶體中進行）。產物是標準 EPUB，Calibre、Thorium、Kobo、Kindle（經 Send to Kindle）以及所有原本能開啟它的閱讀器都能正常開啟。
常見問題
我的 EPUB 完全打不開了，能修嗎？
多數可以——只要損壞在結構層。缺失的 container.xml、錯位的 mimetype 條目、失效的內部引用都會讓閱讀器拒收這本書，但內文毫髮無損。健康檢查幾秒內告訴你屬於哪種情況；如果壓縮檔本身不是合法 ZIP 或沒有任何可讀章節，它會如實相告，而不是假裝能修。
「修復我的 EPUB」和 Repair EPUB 有什麼區別？
Repair EPUB 只做結構修復然後交付檔案。「修復我的 EPUB」是完整任務：先對八個方面做健康檢查（含封面與元資料），套用結構修復，讓你補上只有人能補的缺口，然後在下載前自動複檢結果。
我的書會被上傳到哪裡嗎？
不會。診斷、修復和複檢全部在你的瀏覽器裡進行，用的是與桌面閱讀器相同的解析方式。這個頁面沒有任何上傳通道——工具運作時你可以開啟瀏覽器網路面板親自驗證。
能移除書上的 DRM 嗎？
不能，任何誠實的瀏覽器工具都做不到。帶 DRM 的檔案在設計上就是加密的，診斷會將其回報為無法處理。本工具只修復你有正當權限開啟和修改的書。
為什麼閱讀器顯示檔名而不是書名？
包元資料缺失 title 或 creator 元素，閱讀器只能退回顯示檔名。健康檢查會標記這一點，你可以在修復前填入正確的書名和作者——工具會寫入規範的 Dublin Core 元資料。
目錄壞了，這個工具會重建嗎？
會。目錄文件完全缺失時，會按書的實際章節清單重建；既有目錄裡指向已刪檔案的死連結會被清掉。如果你只是不滿意現有目錄的排法，Fix EPUB TOC 工具仍在。
最大支援多大的書？
接受最大 120 MB 的檔案，超過 100 MB 會有效能提示（一切在記憶體中進行）。典型小說的整個「診斷-修復-複檢」流程幾秒內完成。
修復會重新編碼或降低畫質嗎？
不會。章節、圖片和樣式表在包內原樣搬運，只有損壞的結構檔案被改寫，mimetype 條目恢復到要求的首位。
診斷說我的書無法修復，接下來怎麼辦？
這個結論出現在三種情況：檔案不是合法 ZIP、沒有可讀章節、或帶 DRM。下載截斷的書請回原始來源重新取得；DRM 書請使用購買管道的官方方案。無論哪種，得出這個結論的過程都沒有任何資料離開你的裝置。