“你不能通过！” [drop_cap]A[/drop_cap] 现在的亚度并不是一个备受喜爱的公司。人们勉强使用他们的产品，因为创意套件是行业标准（读作：垄断），或者根本没有值得选择的替代品，而不是因为有人真的对这些工具感到兴奋。我很高兴地报告我（大多数情况下）现在可以没有亚度软件生活了（向Photopea致敬），然而，我对亚度的厌恶程度却达到了一个全新的高度。让我来解释一下。几个月前，我出版了一本新书。像往常一样，我给读者提供了无DRM的电子书EPUB文件，这些文件经过一系列流程，直到它们通过所有的epubcheck检查……呃……检查。如果你不熟悉epubcheck，它基本上是一本电子书的合规性金标准。一开始可能会非常烦人，因为它比复活节星期三的修女还要挑剔。如果你的清单没有仔细列出书中的每一个片段和图像，你的ebook就无法通过。如果你使用HTML元素的顺序不对，或者你的文档稍微偏离国际数字出版论坛所规定的神圣规则集，你也无法通过。所以，是的，让一个epub文件达到100%通过epubcheck对于初学者来说不是一件小事。当我刚开始的时候，我害怕在辛苦工作几个月后点击我完成的书的验证按钮，因为它总是会找到什么值得哭泣的东西。然而，如今我却成为了epubcheck的忠实粉丝。为什么？因为它是我们这种出版者所拥有的最接近“类型检查器”或正式测试套件的工具。换句话说，如果你的书通过了epubcheck，你就可以保障这本书可以在任何EPUB兼容的阅读器或应用程序上正常工作。或者至少，这就是想法。我最近收到一条信息，说我的新书，在epubcheck规则集3.3中表现优异，却是“损坏的”。或许是向后兼容性问题？所以我给他们提供了一个EPUB2版本，也完全符合规则。然而，仍然出现了同样的问题。他们告诉我这本书在他们各种代的Kobo设备上无法打开。那么，当epubcheck这个挑剔的金标准说你的书没问题，而它在亚马逊Kindle、Apple Books、Thorium和其他地方没有问题时，而Kobo却说它是“损坏的”，你该怎么办？我深入研究了这个问题，发现Kobo使用RMSDK，“Reader Mobile Software Development Kit”，这是亚度专有的电子书渲染引擎。也许你能够猜到接下来的事情……RMSDK是Adobe Digital Editions（那个庞大的软件的精华，80%关于DRM，20%关于阅读体验）的核心，运行在各种Kobo设备和旧款索尼/诺克设备上。它最初是在2010年左右构建的（！），为EPUB2设计，稍微更新了EPUB3，但从未现代化。虽然这一认识并没有为我解决问题（epubcheck仍然表示“通过”，而Kobo则表示“未通过”），但至少给我提供了调试的路径。于是我把我的书放进了Adobe Digital Editions中。结果如预期，无法加载。但怎么会这样！没有错误消息，没有一点点反应。书根本无法加载。唯一的迹象是，当我再次加载时，ADE告诉我：“你无法导入那本书，你已经添加过了。”同时显示一个白屏。经典的Adobe。所以我开始把我的书拆开，创建了十几种不同的变体，总是确保epubcheck仍然通过。我重新排列文件夹结构，剔除元数据，删除语言属性，用新的UUID生成epub，扁平化目录，重命名扩展名，重新从零构建压缩包好几次，并调整我的清单。但结果失败，失败，再失败。当我快要放弃时，想到要禁用样式表。突然，它居然加载了！一旦确认样式表是我困扰的来源，我终于可以深入找出究竟是哪一行导致了问题。经过使用样式表不同子集进行的十几种变体后，我最终找到了罪魁祸首。 这一行是：.copyright img { max-width: min(150px, 30vw); } 一旦我把它改成更传统的 max-width: 150px; ADE就可以顺利打开。然而问题出在哪里呢？上述代码完全是有效的CSS 4级，只是RMSDK不支持它，因为它的CSS解析器大约在2013年被冻结——没有弹性盒模型、没有网格布局、没有数学函数、没有自定义属性。只有好老的浮动布局，不佳的字体处理，以及当遇到任何它不识别的东西时，静默崩溃。那么，为什么epubcheck没有捕获到这个问题呢？当然，epubcheck会进行基本的CSS检查，但它无法根据一个根本是破损的渲染器来验证CSS！所以，你看，就是这样。已经是2026年了。由于Kobo选择将可怕的RMSDK作为所有书籍渲染的基础（可能是出于DRM原因），一行完全有效的CSS把一个完全合法的EPUB文件变成了Kobo上的“损坏文件”，并直接放弃了整本书。没有明确的错误信息，没有回退支持。就是这么一个巨大的、令人失望的