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 书请使用购买渠道的官方方案。无论哪种，得出这个结论的过程都没有任何数据离开你的设备。