EPUB 是什么？开放的电子书标准
基础知识：EPUB 到底是什么？
EPUB 是“Electronic Publication”（电子出版物）的缩写，但它真正的身份是数字图书的通用标准。这是一个开放格式，自 2017 年由国际数字出版论坛 (IDPF) 移交给万维网联盟 (W3C) 管理。从本质上讲，一个 .epub 文件就是一个 ZIP 压缩包。在里面，你会找到构成现代网页的基石：用于文本的 HTML、用于样式的 CSS、图片，以及一些用于协调所有内容如何在你的电子阅读器上显示的 XML 文件。 EPUB 与 PDF 这类格式的关键区别在于其“可重排布局”（reflowable layout）。这正是它的超能力所在。无论是小巧的 6 英寸 Kobo、宽敞的 iPad，还是巨大的桌面显示器，文本都会自动换行和调整大小以适应任何屏幕。作为读者，你可以掌控一切。你可以改变字体大小、字型、间距，甚至是背景颜色，而书籍内容会随之调整。因为它将文本存储为真正的文本——而不是像扫描版 PDF 那样存储为静态的文字图片——一本 400 页的小说文件大小可能只有区区 500 KB。 这个格式也随着时间不断演进。2007 年的 EPUB 2 奠定了基础。接着是 EPUB 3，它于 2011 年首次定稿，并持续更新，最近的版本是 2023 年的 3.3 版。这个现代版本引入了大量的 Web 技术：HTML5、CSS3、用于交互的 JavaScript、用于复杂方程式的 MathML，甚至还支持嵌入音频和视频。它还引入了强大的可访问性功能，如 ARIA landmark。虽然大多数现代设备和应用都能很好地处理 EPUB 3，但你仍然会发现一些较旧的电子阅读器在处理简单文本时会退回到 EPUB 2 的渲染方式。 首先要明确一点：EPUB 和 MOBI 或 AZW3 不是一回事。那些是亚马逊专有的 Kindle 格式。从亚马逊买书，你得到的是一个锁定在其生态系统内的文件。而从 Kobo、Google Play Books、Apple Books 或几乎任何独立书店购买，你得到的则是一个 EPUB 文件。
EPUB 文件内部：结构解析
这里有个小窍门：随便找一个 .epub 文件，把它的扩展名改成 .zip，然后解压缩。你会发现里面是一个组织得井井有条的文件夹结构。在顶层，你总会看到一个名为 `mimetype` 的文件。这个小文件只包含一行字——`application/epub+zip`——而且它必须是压缩包里的第一个文件，且不能被压缩。这样，软件就能在不深入探查文件内容的情况下，立即识别出这是一个 EPUB 文件。 接下来，看看 `META-INF` 文件夹。你会找到一个 `container.xml` 文件。它唯一的工作就是指向主包文档，通常名为 `content.opf` 或 `package.opf`。这个 OPF 文件是这本书的中枢神经系统。它是一份包含所有内容文件的主列表，定义了章节的阅读顺序，并保存了所有关键的元数据：书名、作者、语言、ISBN、出版日期和出版商。 书籍的实际内容——文本和图片——存放在一个通常叫做 `OEBPS` 或 `Content` 的文件夹里。在这里，你会找到每个章节的独立 XHTML 文件、控制书籍外观的 CSS 文件，以及一个存放图片的目录。你还会看到一个 `toc.ncx` 文件（用于较旧的 EPUB 2 阅读器）和一个 `nav.xhtml` 文件（用于现代的 EPUB 3）。这两个文件共同构成了你在电子阅读器上用来在章节间跳转的目录。 那么，为什么这个结构很重要呢？因为如果一个 EPUB 文件损坏了，你常常可以自己修复它。任何曾被一个有小毛病的文件搞得焦头烂额的人都懂那种挫败感。对于 EPUB，你可以打开“引擎盖”一探究竟。只需打开压缩包，找到有问题的 XHTML 文件，用文本编辑器修复代码，然后重新打包成 ZIP（记住，`mimetype` 文件必须是第一个，且不能压缩！），最后再把扩展名改回 .epub 就行了。这其中有一种实实在在的满足感。你甚至可以用 W3C 的 EPUBCheck 这样的免费工具来精确定位到导致问题的具体文件和行号。对于开发者来说，这种开放结构也使得 EPUB 如此灵活。想添加自定义字体？只需将一个 `.woff2` 文件放入压缩包，然后在你的 CSS 中用标准的 `@font-face` 规则调用它即可。
EPUB 与 PDF：如何选择合适的格式
EPUB 与 PDF 之争是一个老生常谈的话题，但它基于一个错误的前提。它们其实不是竞争对手，而是为完全不同的工作而设计的工具。没有哪个“更好”——它们只是在不同的场景下表现出色。 PDF 的核心在于保持固定的视觉布局。想象一下双栏的学术论文、排版精美的杂志跨页，或是需要填写的政府表格。这些*必须*是 PDF。页面尺寸是锁定的，字体是嵌入的，你在屏幕上看到的文档和打印出来的会一模一样。这种静态的可预测性正是 PDF 存在的全部意义。 而 EPUB 则优先考虑在任何屏幕上的可读性。小说、长篇报道，以及你需要在手机上阅读的手册，都非常适合使用 EPUB。它的可重排文本意味着读者可以将字体调大到 24pt 以获得更好的可见度，而文字会自行重排以适应屏幕。如果用 PDF 这么做，你就会陷入需要不停地双指缩放和水平滚动的噩梦，让阅读变得不可能。 有时，平台会替你做出选择。iOS 和 macOS 上的 Apple Books 就是为 EPUB 而生的；虽然它也*能*打开 PDF，但你会失去所有最佳的阅读功能，比如字体控制、夜间模式和跨设备同步。亚马逊的 Kindle 生态系统则恰恰相反。它已经完全放弃了对 EPUB 的原生支持。你要么必须将你的 EPUB 转换成 AZW3，要么使用“发送至 Kindle”服务，让亚马逊的服务器来完成转换。 在可访问性方面，一个制作精良的 EPUB 3 是无与伦比的。屏幕阅读器可以利用书籍的语义化 HTML 结构，按章节、标题或地标进行导航。虽然理论上“带标签的 PDF”也能做到这一点，但在现实世界中，这些标签常常是损坏或完全缺失的。EPUB Accessibility 1.1 规范为出版商提供了一个明确的标准。唯一的例外是固定布局的 EPUB。虽然存在这种格式，但阅读器的支持情况就像个雷区。我的建议是？如果你绝对需要像素级的精确布局，那就坚持使用 PDF，并尽你所能让它变得易于访问。不要试图强迫 EPUB 去扮演一个它并非为此而生的角色。
DRM、分发以及“开放”的真正含义
当我们说 EPUB 是一个“开放标准”时，意味着它的蓝图可供任何人免费使用。其规范是公开的，实现它无需任何成本，也没有任何一家公司拥有它。这就是为什么一个健康的 EPUB 应用生态系统得以蓬勃发展。你有很多选择，从像 Calibre 和 Thorium Reader 这样的高级用户工具，到苹果、谷歌和 Kobo 的内置应用，还有像 Foliate 这样适用于 Linux 的小众选择。 但“开放格式”并不意味着“没有 DRM”。这是一个至关重要的区别。出版商和零售商在销售 EPUB 文件前，常常会给它们加上一层数字版权管理 (DRM) 的保护。最常见的系统是 Adobe 的 ADEPT DRM，你在通过 OverDrive 或 Libby 从公共图书馆借阅的电子书上就会遇到它。Kobo 和苹果也有自己的专有 DRM。最终的文件底层仍然是 EPUB，但它是一个被锁定的文件，只能在授权的设备上用授权的应用打开。 对于文件转换来说，DRM 就是一堵无法逾越的墙。CocoConvert 可以轻松地将未受保护的 EPUB 与 PDF、DOCX、HTML 等格式相互转换。但它不能，也绝不会，处理受 DRM 保护的文件。根据美国《数字千年版权法》(DMCA) 和《欧盟版权指令》等法律，为了转换文件而剥离 DRM 是非法的。如果你拥有一本带 DRM 的书，并想在不同的设备上阅读，你唯一的合法选择是查看商店是否提供无 DRM 的下载版本，或者直接使用零售商指定的应用。 好消息是，无 DRM 的 EPUB 比你想象的更普遍。像 Tor Books 和 O'Reilly 这样的大型出版商就是靠销售无 DRM 文件建立起了声誉。大多数开放获取的学术出版商也是如此。你还可以在 Smashwords 和 Humble Bundle 这样的商店找到它们，或者直接从作者的网站购买。这些才是你真正拥有的文件——你可以备份它们，转换它们，并在你选择的任何应用中阅读它们，永久有效。
创建和编辑 EPUB 文件
从头开始创建一个 EPUB，可以随你心意，可简可繁，这取决于你使用的工具。对于熟悉基本 HTML 的人来说，免费开源的编辑器 Sigil 是经典的起点；它有一个可视化界面和内置的验证器来捕捉错误。macOS 上的独立出版作者通常对 Vellum 推崇备至，这是一款付费应用，能通过模板生成排版精美的书籍，不过价格高达 199.99 美元。许多作家已经在使用 Scrivener，它可以直接从 `文件 > 编译` 菜单将手稿编译成 EPUB 3。 开发者和技术文档撰写者则有他们自己的一套强大工具。Sphinx，作为许多 Python 文档背后的引擎，可以像生成 HTML 或 PDF 一样轻松地生成 EPUB 3 文件。还有 Pandoc，文档转换界的瑞士军刀。它几乎可以从任何格式创建 EPUB——Markdown、DOCX、LaTeX——只需一条简单的命令行指令，例如 `pandoc input.docx -o output.epub --epub-cover-image=cover.jpg`。 编辑现有的 EPUB 则更有趣。如果你手头的文件排版混乱或章节顺序错误，你可以用 Sigil 深入内部进行修改。它的“书籍浏览器”会向你展示整个文件结构，让你能直接进入特定的 XHTML 或 CSS 文件来解决问题。Calibre 也有一个强大的电子书编辑器，提供类似的功能。不过，如果只是调整元数据，没有什么比 Calibre 的主界面更好用了。修改作者名、添加系列标签或更正出版年份，只需右键点击即可完成。它甚至可以使用 ISBN 自动获取正确的元数据，这能节省大量时间。 但请注意：如果你试图编辑一个固定布局的 EPUB，比如儿童图画书或复杂的杂志版式，那你可就面临挑战了。这些文件通常使用复杂的 CSS 和 JavaScript，是无法用简单的可视化编辑器理清的。你需要对 EPUB 规范和 Web 开发有深入的理解，才能在不破坏一切的情况下进行修改。
转换 EPUB 文件：可行与不可行
转换 EPUB 文件是一项常见任务，但结果的质量完全取决于你的源格式和目标格式。这不是一个“一刀切”的过程。 从 EPUB 转换到 PDF 通常是稳妥的选择，尤其是对于以文本为主的书籍。像 CocoConvert 这样的工具会把 EPUB 的内容渲染成一个干净、分页的 PDF，非常适合打印或存档小说和报告。但当遇到更复杂的文件时，这个过程就会遇到麻烦。EPUB 3 文件中花哨的 CSS 布局、未嵌入的字体以及任何基于 JavaScript 的交互性，在转换成静态 PDF 的过程中都会丢失。布局甚至可能会被破坏，需要你手动清理。 将 EPUB 转换成 DOCX 文件是把文本导入 Microsoft Word 进行编辑的最佳方式。转换会保留基本结构——标题、段落、粗体和斜体、基本图片——但也就仅此而已了。别指望花哨的 CSS、首字下沉或自定义布局能在转换过程中幸存下来。最好把生成的 DOCX 文件看作是一份干净、可编辑的草稿，而不是一份排版完成的最终文档。 从 PDF 转换到 EPUB 是目前为止最难的转换，是真正的“因文件而异”的情况。如果 PDF 是从像 Word 这样的文本源导出的，像 CocoConvert 这样的转换器通常可以干净地提取文本并将其构造成一个可用的 EPUB。但如果你有一个扫描版的 PDF——它实际上只是一堆页面的图片——那你的体验会糟糕得多。这需要光学字符识别 (OCR) 技术将这些图片转回文本，而这个过程绝非完美。CocoConvert 的 OCR 功能很不错，但其准确性取决于扫描质量。即使是清晰的 300 DPI 扫描件，98% 的字符准确率仍然意味着一本 300 页的书里会有几十个错别字需要你去找出来并修正。 最后，从 HTML 转换到 EPUB 通常很简单，但有一个重要的前提：垃圾进，垃圾出。如果你的源文件是干净、语义化的 HTML——比如一个结构良好的网页文章——它会很漂亮地映射成 EPUB 的章节。但如果你给转换器喂了一堆混乱的、带有内联样式和用表格构建布局的 HTML，那么你最终得到的也只会是一个混乱、纠缠的 EPUB。
EPUB 的可访问性与标准现状
可访问性是 EPUB 3 真正大放异彩的地方，也可以说是该格式最重要的特性。通过基于 Web 标准构建，它支持语义化的 HTML5 元素（`nav`、`aside` 等）、为辅助技术准备的 ARIA 角色、为图片提供的适当的替代文本，以及定义逻辑阅读顺序的元数据。这确保了屏幕阅读器能按照作者的意图来导航书籍，而不仅仅是遵循页面上的视觉布局。 这不仅仅是一些零散的最佳实践的集合。官方的 EPUB Accessibility 1.1 规范（自 2023 年 5 月起成为 W3C 推荐标准）列出了具体的要求。一个可访问的 EPUB 必须有完整的目录、逻辑阅读顺序、替代文本和适当的颜色对比度。符合规范的出版商甚至可以在文件中嵌入元数据，以证明他们达到了特定的标准，如 WCAG 2.1 AA。 然而，在现实世界中，EPUB 可访问性的质量参差不齐。得益于《马拉喀什条约》和《欧洲无障碍法案》（于 2025 年 6 月全面生效）等法律和监管压力，大型学术和商业出版商已经做得好很多了。但是大量的书籍，特别是来自小型出版社和独立出版作者的书籍，仍然存在明显的无障碍设计缺陷：缺少替代文本、没有声明阅读顺序、导航不完整。标准的好坏取决于其执行情况。 对于需要这些功能的读者来说，应用的选择至关重要。在桌面上，免费的 Thorium Reader 是可访问性方面的黄金标准，它对文本转语音、句子高亮显示以及通过 ARIA 地标导航提供了出色的支持。在移动设备上，iOS 上的 Apple Books 与 VoiceOver 屏幕阅读器配合使用时，能很好地支持 EPUB 的可访问性功能。 但工作还远未结束。W3C 的 EPUB 工作组仍在积极地发展该标准。目前，他们正专注于改善对有声书的支持，为脚本的使用提供更清晰的指导，并着手解决固定布局可访问性这个棘手的问题。最后一个问题尤其是一个难啃的硬骨头，目前规范还没有完美的解决方案。