你的ePub没问题。但Kobo说不。都怪Adobe。

# 你的 EPUB 没问题，Kobo 说有。都怪 Adobe — André Klein 的个人博客 来源：https://andreklein.net/your-epub-is-fine-kobo-disagrees-blame-adobe/ [](https://andreklein.net/wp-content/uploads/2026/06/gandalf.jpg) “你不许通过！” [drop\_cap]A[/drop\_cap]dobe 如今还算不上讨人喜欢的公司。大家勉强用着他们的产品，只是因为 Creative Suite 是行业标准（读作：垄断），或者根本找不到像样的替代品——没人真心对这些工具感到兴奋。 我很高兴地报告，我现在（大部分情况下）已经不用 Adobe 系软件了（向 Photopea 致敬）。然而，我对 Adobe 的厌恶又达到了一个全新的高度。 让我来解释。 不久前我出版了一本新书。像往常一样，我向读者提供了无 DRM 的 `EPUB` 文件，这些文件经过层层检验，直到它们通过所有 `epubcheck`……呃……检查。 如果你不熟悉 `epubcheck`，它基本上是衡量电子书格式正确性的黄金标准。一开始它会非常烦人，因为它比圣灰星期三的修女还要吹毛求疵。如果你的 `manifest` 没有精确地列出书中每一段文字和每一张图片，你的 epub 通不过。如果你使用了顺序错误的 HTML 元素，如果你的文档与国际数字出版论坛制定的神圣规则集有丝毫偏差，都通不过。 没错，对于新手来说，让一个 `epub` 100% 通过 `epubcheck` 可不是件容易的事。我刚开始时，最害怕的就是在几个月的工作后，点击成品书的“验证”按钮——因为它*总会*找出点什么来抱怨一番。 不过如今，我自己却是 `epubcheck` 的忠实粉丝。为什么？它是我们这些出版人最接近“类型校验器”或正式测试套件的东西。换句话说，如果你的书通过了 `epubcheck`，你就可以保证这本书在任何兼容 EPUB 的阅读器或应用上都能正常运行。 至少，理论上是这样。 我最近收到一位读者的消息，说我那本完美通过 `epubcheck` 3.3 规则集的新书，在他们的设备上显示为“损坏”。 也许是向后兼容的问题？于是我给了他们一个也完全符合规则的 EPUB2 版本，但同样的问题又出现了。他们告诉我，这本书在他们不同世代的多台 Kobo 设备上都无法打开。 那么，当吹毛求疵的黄金标准 `epubcheck` 说你的书没问题，当它在 Amazon Kindle、Apple Books、Thorium 以及其他任何地方都运行无阻，但 Kobo 却说“已损坏”时，你该怎么办？ 我深入调查了这个问题，发现 Kobo 使用的是 RMSDK（Reader Mobile Software Development Kit），也就是 Adobe 专有的电子书渲染引擎。 也许你已经猜到结局了…… RMSDK 是 **Adobe Digital Editions**（那个臃肿的软件巅峰之作，80% 是 DRM，20% 是阅读体验）的内核，也是各种 Kobo 设备以及老款 Sony / Nook 设备的引擎。它最初大约在 2010 年为 EPUB2 构建，后来为了 EPUB3 做过轻微更新，但从未现代化。 虽然这个发现并没有直接解决我的问题（`epubcheck` 仍然说“好”，而 Kobo 说“坏”），但至少给了我一条调试的路径。 于是我把我的书丢进 Adobe Digital Editions。不出所料，它加载失败了。但怎么失败的呢？没有任何错误信息，甚至连一声叹息都没有。这本书就是加载不出来。唯一表明它尝试过的迹象是，再次加载时 ADE 告诉我：“你无法导入这本书，你已经添加过了。” 同时显示一个白屏。 典型的 Adobe 作风。 于是我把我这本书拆开，做了十几个不同的变种，每次都确保 `epubcheck` 仍然能通过。我调整了文件夹结构，删除了元数据，清除了语言属性，生成了带有全新 UUID 的 epub，展平了目录，重命名了扩展名，从头重建了 zip 文件十几次，还打乱了 manifest。 结果，一次次失败，再失败，还是失败。 就在我几乎要放弃的时候，我想到禁用样式表。结果豁然开朗——它突然就能加载了！ 一旦确定了样式表是罪魁祸首，我终于可以深入排查具体是哪一行代码导致了问题。我又创建了十几个包含样式表不同子集的变种，最终找到了元凶。就是这一行： ```css .copyright img { max-width: min(150px, 30vw); } ``` 一旦我将它改为更老派的 `max-width: 150px;`，ADE 就正常打开了。 但问题出在哪里呢？上面的代码是完全有效的 CSS Level 4，只是 RMSDK 不支持它，因为它的 CSS 解析器卡在了大约 2013 年——没有 flexbox，没有 grid，没有数学函数，没有自定义属性。只有老旧的 float、糟糕的字体处理，以及遇到不认识的东西时静默崩溃。 那么，为什么 epubcheck 没有发现这个问题呢？ epubcheck 当然会做基本的 CSS 检查，但它无法针对一个从根本上就有问题的渲染引擎来验证 CSS 啊！ 所以，事情就是这么回事。 现在是 2026 年。多亏了那个恐怖的 RMSDK——Kobo 决定用它作为所有书籍渲染的支柱（很可能出于 DRM 原因）——一行完全有效的 CSS 就把一个完全有效的 EPUB 文件在 Kobo 上变成了“损坏文件”，整本书就此报废。没有清晰的错误信息，没有降级处理。只有巨大的失败。 我后来发布了新版本，这样我的读者就不用再碰这个问题了。 在理想世界中，RMSDK 要么别再活在那个 CSS 石器时代，要么至少提供*某种*错误处理机制，而不是直接扔掉整本书——但我可没抱太大希望。 数字出版界更痴迷于*限制*访问，而不是给用户最佳的阅读体验。 而在这一点改变之前（它不会改变的），如果你想确保自己的书与 Kobo 兼容，仅仅依赖 `epubcheck` 是不够的。还得先把它扔进 Adobe 的碎木机里试试。 要么它能用，要么它静默失败。如果是后者，那你很可能用了某种被禁止的新潮 CSS。 反正我写这些就是为了事后总结，万一有人也碰上同样的问题呢。 EPUB 是一个极好的开放电子书标准，然而众多实现方式从根本上就有缺陷，这一切都是为了安抚知识产权律师。