亚马逊中国电子书店关停之后，很多人硬盘里躺着一堆 .azw3 和 .mobi，换了阅读器才发现打不开。这些文件不是坏了——它们是亚马逊的私有格式，除了 Kindle 生态之外几乎没人认。
搬到 EPUB 是唯一的出路。但”转格式”这件事说起来一句话，实际做起来会遇到三类问题：有的书根本转不了（DRM）、有的书转完丢东西（目录、插图、跳转）、有的书转完不对劲（体积暴涨、阅读器不显示书名）。这篇把这三类问题各自的成因讲清楚。
三种扩展名，其实是三种东西
.mobi、.azw3、.azw、.prc 长得像一家人，外层确实也是同一种 PDB 容器（Palm Database，掌上电脑时代留下的遗产）。但容器里装的东西可以完全不同：
| 扩展名 | 内部格式 | 正文组织方式 | 排版能力 |
|---|---|---|---|
.prc | MOBI6 | 一整块 HTML | 极简，<font> 级别 |
.mobi | MOBI6 或合体包 | 一整块 HTML（+ 可能另有一份 KF8） | 取决于内部是哪份 |
.azw3 | KF8 | 骨架表 + 碎片表，需重新拼装 | 真正的 CSS + 内嵌字体 |
.azw | MOBI6 或 KF8 | 不定 | 商店下载扩展名，多数带 DRM |
MOBI6 是十几年前的格式：正文是一整块 HTML，章节跳转靠 filepos= 这种字节偏移——“跳到第 128394 个字节处”。这套设计在纯文本时代够用，但它意味着任何插入或删除都会让所有偏移失效，也没法表达嵌套的样式。
KF8（Kindle Format 8，即 .azw3）是完全重做的：正文被切成**骨架（skeleton）和碎片（fragment）**两张表，骨架是文档外壳，碎片按记录的插入位置填进去，拼装完才是完整的 XHTML。代价是解析复杂，收益是真正支持 CSS 排版、内嵌字体、图文混排。
合体包是过渡期的产物：一个 .mobi 文件里前半段是 MOBI6、后半段是 KF8，老设备读前半段，新设备读后半段。文件头里有一条 KF8 boundary 记录指明分界点。这类文件转换时应该取 KF8 那一份——排版信息完整得多。
DRM：为什么浏览器端一定解不了
这是转换失败最常见的原因，也是最容易被误解的一条。
带 DRM 的文件在 EXTH 头里有加密标记（encryption type 为 1 或 2）。关键在于解密密钥根本不在文件里——它绑定在你的亚马逊账号和具体设备的序列号上，由 Kindle 客户端在本地保管。浏览器拿不到这个密钥，任何声称能在网页里解 DRM 的工具，本质上是在破解版权保护。
判断手里的书带不带 DRM，看来源比看文件更快：
| 来源 | DRM 情况 |
|---|---|
| Kindle 商店购买 → App / 设备下载 | ✅ 基本都有 |
| Kindle 商店购买 → 网页版”下载并通过 USB 传输” | ✅ 有（绑定设备序列号） |
| 自己用 calibre 从 EPUB 转出的 MOBI | ❌ 无 |
| Project Gutenberg 等公版书站 | ❌ 无 |
| 别人用 kindlegen / KindlePreviewer 打包的 | ❌ 无 |
| 通过 Send to Kindle 发给自己的个人文档 | ❌ 无 |
工具在你拖入文件的瞬间就读头判断，有 DRM 立刻告诉你，不会转到一半吐出一本乱码书。
转换过程实际做了什么
理解这六步，出问题时就知道该怀疑哪一环：
1. 体检 读 PDB 头 + EXTH → 判断格式 / 压缩方式 / DRM / 文件完整性
2. 解压正文 无压缩 / PalmDOC(LZ77 变体) / HUFF-CDIC 三选一
3. 拆文档 MOBI6 按分页标记切段；KF8 按骨架表 + 碎片表重新拼装
4. 提资源 图片、封面、CSS、内嵌字体逐个提取成独立文件
5. 重建链接 filepos 字节偏移 / kindle:pos: → EPUB 的 文件名#锚点
6. 打包 清洗 XHTML → 生成 opf / ncx / nav → ZIP 成 EPUB 3第 5 步是最容易被低估的一环。MOBI 的目录跳转和脚注回跳都是字节偏移，而 EPUB 里正文被切成了多个 XHTML 文件——必须建立一张**“原字节位置 → 哪个文件的哪个锚点”**的映射表，把所有 filepos 翻译过去。这张表没建对，转出来的书目录能显示但点了不跳，或者脚注点进去跳到隔壁章节。
第 6 步的”清洗”是为了合规：MOBI 里满是 <font>、filepos=、recindex= 这类在 EPUB 里非法的东西。留着它们，宽松的阅读器能读，但 EPUBCheck 会报一堆错，苹果 Books 这类严格的实现可能直接拒绝导入。
什么会保留，什么必然丢
| 内容 | 转换结果 | 说明 |
|---|---|---|
| 正文文字 | ✅ 完整 | 三种压缩方式都能解 |
| 章节目录 | ✅ 保留 | 优先用 NCX 重建，无 NCX 时按标题生成 |
| 插图 / 封面 | ✅ 保留 | 按原样提取，不二次压缩 |
| CSS 排版 | ✅ KF8 保留 | MOBI6 本来就几乎没有 |
| 内嵌字体 | ✅ 可选保留 | 建议中文书丢弃，见下节 |
| 内部跳转 / 脚注 | ✅ 重建 | filepos → 锚点映射 |
| 书名 / 作者 | ⚠️ 取决于原文件 | EXTH 里没写就是没有 |
| 生词提示（Vocabulary Builder） | ❌ 丢失 | Kindle 私有，EPUB 无对应物 |
| X-Ray | ❌ 丢失 | 同上 |
| 阅读位置 / 笔记同步 | ❌ 丢失 | 存在亚马逊账号里，不在文件中 |
| 页码（Real Page Numbers） | ❌ 丢失 | 依赖亚马逊的印刷版对照数据 |
结论：内容层面的东西基本都能带走，丢的全是依附于亚马逊服务的功能性数据——这部分不是转换工具的能力问题，是它们本来就不在文件里。
内嵌字体：中文书的体积大头
一本 300 KB 正文的中文小说，转出来 18 MB，多半就是内嵌字体干的。
中文字体一套动辄十几到几十 MB（常用字就有三千多个，加上标点和异体字，字形数据量远超拉丁字体）。制作电子书的人为了保证在任何设备上字形一致，习惯把整套字体塞进去。
绝大多数情况下应该丢掉：
- 手机、平板、电纸书都自带中文字体，且多数阅读器允许用户自选字体，内嵌字体经常被直接忽略
- 丢掉之后体积能砍掉一多半，同步到设备、备份到网盘都更省事
只有这几种情况值得保留：古籍中的异体字、需要注音排版的教材、字形本身是内容一部分的书法类书籍。
一个技术细节：丢弃字体时必须同时删掉 CSS 里的 @font-face 规则。只删文件不删规则，EPUB 里就会有一条指向不存在文件的引用——宽松的阅读器忽略它，严格的会直接报错拒绝打开。
目录不对的三种表现和对策
| 表现 | 成因 | 对策 |
|---|---|---|
| 一条目录都没有 | 原文件无 NCX，正文标题也不规整 | 转 TXT 后用 TXT 转 EPUB 按正则切章 |
| 目录条数远少于实际章节 | 原书就只做了卷级目录 | 同上，按正文标题重切 |
| 目录能显示但点了不跳 | filepos 映射未正确重建 | 换转换路径重试；也可能原文件本身偏移就是坏的 |
| 目录层级全平了 | MOBI6 的 NCX 本来就只有一层 | 无解，MOBI6 不表达多级层次 |
顺带说明：MOBI6 的目录天然是扁平的。想要”卷 - 章 - 节”三级目录，只有 KF8 和 EPUB 支持。一本老 .mobi 转出来目录没层次，不是转换缩水了。
转完之后的三件收尾
1. 补元数据。 MOBI 里书名作者常常是空的或者写着文件名。用 EPUB 元数据编辑 补上书名、作者、系列名、系列序号——尤其是系列信息，多数阅读器靠它把同一套书排在一起。
2. 验收三项。 导入目标阅读器后，点一次目录、翻一次插图、点一次脚注。这三项通过基本就没问题了。
3. 需要纯文本时另转一次。 想做全文检索、灌进 AI 工具做摘要、或者在极简阅读器里看，用 EPUB 转 TXT 从刚转好的 EPUB 再转一次，比从 MOBI 直接转文本更干净——因为 EPUB 的文档结构已经理顺了。相关坑见 EPUB 转 TXT：spine 顺序、标题与编码。
常见报错对照
| 提示 | 真实含义 | 怎么办 |
|---|---|---|
| 这本书有 DRM 保护 | 文件头有加密标记 | 换无 DRM 的来源，浏览器端无解 |
| 文件不完整 | 记录表偏移超出文件长度 | 重新完整下载一次 |
| 不是有效的 MOBI 文件 | PDB 头的 type/creator 不是 BOOKMOBI | 确认扩展名没被改过（可能实际是 EPUB 或 PDF） |
| 标签页崩溃 / 内存不足 | 峰值内存约为文件体积的三到四倍 | 换电脑转，或一本一本转、转完刷新页面 |
总结
.mobi和.azw3不是同一种格式——前者是整块 HTML 加字节偏移，后者是骨架加碎片加 CSS，排版能力差一个时代- DRM 在浏览器端一定解不了，密钥不在文件里；看来源比看文件更快判断
- 内容能完整带走，丢的是生词提示、X-Ray、阅读进度这些依附亚马逊服务的东西
- 中文书优先丢弃内嵌字体，体积经常能砍掉一多半，阅读体验无差别
- 转完必做三件事：查目录、补元数据、在目标阅读器上验收跳转和插图
搬家一次，之后的书就都在开放格式里了——这才是这次转换真正的价值。