EPUB 编辑器 是网页版的 EPUB 内容编辑工具，相当于一个轻量的 Sigil：左边文件树、中间代码视图、右边预览与校验报告，改完直接导出新的 EPUB。
能改什么
| 对象 | 操作 |
|---|---|
| 正文 XHTML | 代码编辑（语法高亮、括号匹配、文件内查找） |
| CSS 样式 | 代码编辑，改行距、字体、缩进、页边距 |
| 章节 | 新建、删除、重命名、上下调整阅读顺序、移出/加入阅读顺序 |
| 目录 | 编辑 nav.xhtml / toc.ncx，结构操作时自动同步 |
| OPF | 直接编辑源码，manifest 与 spine 改完即时生效 |
| 资源 | 导入图片、字体等文件，自动写入 manifest |
| 全书 | 查找替换，支持正则、区分大小写、限定只搜正文 |
| 排版 | 一键格式化当前文件或整本书（可撤销）；正文按块级缩进，数据 XML 与 CSS 走 Prettier |
设计上的几个取舍
唯一真相是文件本身。 文件树、阅读顺序、目录都是从 OPF 源码现解析出来的视图，不是另一份缓存。所以你在代码视图里手改 OPF，左边的树立刻跟着变——可视化操作和手写源码两条路不会打架。
只重写改过的文件。 保存时逐个文件判断：改过的重新编码写入，没改过的直接从原包搬字节。这样即使包里有工具不认识的资源（音频、SMIL、自定义元数据），也原封不动地留在新书里。
绝不产出打不开的书。 保存前会把所有 XML 类文件过一遍良构检查，有任何一个不合格就中止并跳到出错位置。编辑器底部状态栏也实时显示当前文件的语法状态，不用等到保存才发现。
排版按类型分路。 空白在 OPF 里没有意义，在正文里有渲染语义——同一套排版规则套上去必出问题。所以数据 XML 交给 Prettier，正文用只动块级元素之间空白的专用排版器，并在写回前用”去空白后内容必须一致”做最后一道闸。
编码统一成 UTF-8。 读取时按 BOM 和 XML 声明识别原编码（含 GBK），并把声明里的编码一并改写成 utf-8——如果只改字节不改声明，阅读器会按旧编码去解新字节，整本变乱码，而预览里完全看不出来。
范围与限制
- 需要较宽的屏幕，建议在电脑上使用；
- 不支持 DRM 加密书，也不提供解除方法；
- 不做可视化”所见即所得”编辑，正文以代码视图为准——富文本编辑器产出的是 HTML5，塞回 EPUB 需要一道 XHTML 良构转换，那一层的失真比直接看代码更难排查；
- 与 EPUB 元数据编辑、EPUB 转 TXT、TXT 转 EPUB 同属电子书工具族。
📍使用场景
- 改错别字、删盗版站广告从网上收来的书正文里夹着推广链接和错字，直接在章节里改掉，排版、插图、目录一点不动。
- 全书统一译名 / 标点人名前后不一致、中英标点混用，用全书查找替换一次改完，支持正则和"只在正文里找"。
- 删掉多余的插页、调章节顺序扫描书常有空白页、重复的版权页；删除时 OPF 的 manifest、spine 和目录会一起同步。
- 调排版、换字体行距太挤、首行不缩进，直接编辑包内 CSS；导入字体文件后在样式里引用即可。
- 修一本打不开的书阅读器报错但不说哪里错，用内置 EPUBCheck 跑一遍，点报告里的条目直接跳到出错文件的那一行。
❓常见问题
和「EPUB 元数据编辑」有什么区别？
那个改的是书的"身份信息"——书名、作者、封面、标签，不碰正文。这个改的是书的内容——正文 XHTML、CSS 样式、章节增删、阅读顺序、目录结构。两个工具互补，改书名去那边更快。
改完会不会把排版弄丢？
不会。保存时只重写你改动过的文件，其余每一个文件都从原包按原字节搬进新包。没碰过的插图、字体、样式在新文件里和原来一模一样。
为什么保存被拦下来了？
某个文件的 XML 语法不完整（标签没闭合、属性少引号等）。EPUB 要求 XHTML 良构，写坏了阅读器会直接打不开，所以工具宁可中止保存也不产出坏书——它会自动跳到出问题的文件，编辑器底部状态栏也实时显示当前文件的语法状态。
内置的校验是什么？和 EPUBCheck 一样吗？
用的是 @likecoin/epubcheck-ts——W3C 官方 EPUBCheck 的 TypeScript 移植版，schema 校验走 libxml2 的 WebAssembly 构建，完全在你的浏览器里跑。它对 758 个官方测试样本与 Java 版 EPUBCheck 的有效性判定一致率约 97%。校验器体积较大，只在你点「校验」时才加载。
删除一章会连目录一起删吗？
会。删除时同步四处：OPF 的 manifest、OPF 的 spine、EPUB3 的 nav.xhtml、EPUB2 的 toc.ncx。少同步任何一处，书还能打开，但目录会指向不存在的文件，或者那一章在阅读器里直接消失且不报错。目录里如果该条目下还有子条目，会一并移除。
重命名文件后，引用它的地方会断吗？
不会。改名时会扫描全书所有文本文件，把指向它的 href、src、CSS 的 url() 一起改掉。判断方式是把每个引用解析成绝对路径再比对，所以 ../images/a.jpg 和 images/a.jpg 指同一个文件也能一起改到。
校验报出 OPF-096「Non-linear content must be reachable」怎么办？
这是转换工具产出的 OPF 里最常见的一条。它表示 spine 里有个标了 linear="no" 的条目（通常就是 nav.xhtml），而全书没有任何一页有超链接指向它——规范上成了"永远到不了的内容"。不是编辑器改出来的，书本身就带。修法：在左边文件树里点该文件的 ⊖ 移出阅读顺序。EPUB 3 只要求导航文档在 manifest 里带 properties="nav"，进 spine 本就是可选的；移出后它不再是非线性内容，错误消失，阅读器的目录按钮照常工作（那读的是 manifest，不是 spine）。另一种修法是在扉页加一个指向 nav.xhtml 的"目录"链接。不要去掉 linear="no" ——那会让目录变成正文的一页，读者翻书时会翻进去。
打开的文件挤成一行，能格式化吗？
点工具条的「格式化」，对当前文件生效；要整本书一起排，点它右边的 ⌄ 选「格式化整本书」，排完工具条上会多出一个「撤销格式化」，一次点回原样。分两条路走：OPF、NCX 这类纯数据 XML 交给 Prettier 正常排版；正文 XHTML 和 SVG 则用专门的排版方式，只在块级元素之间换行缩进。之所以不能一视同仁，见下一条。
为什么正文不用 Prettier 排版？
因为 XHTML 里的空白有渲染语义，通用排版器会改变显示效果。实测 <p><em>甲</em><em>乙</em></p> 这种相邻行内元素，Prettier 会在两者之间插入换行，而换行在阅读器里会折成一个空格——「甲乙」变成「甲 乙」，中文正文里这是肉眼可见的错误。所以正文只做可证明安全的事：只在块级边界换行缩进——子节点按「块级／行内」切段，段与段之间缩进，行内元素连成的那一段内部一个字节都不动（<a>甲</a> <a>乙</a> 中间那个空格看得见，动不得）；一个块级子元素都没有的纯内容元素（<p><em>甲</em><em>乙</em></p>）整块留在一行；pre、script、style、textarea 里一个字节都不碰。所以 <li><a>第三章</a><ol>…</ol></li> 这种带子目录的条目也能排上版——</a> 和 <ol> 之间的换行紧挨块级元素之前，CSS 白空间处理会把它丢掉，渲染不变。空的 <span epub:type="pagebreak"/>、<a id="p12"/> 这类分页标记和命名锚点没有任何渲染，视同块级一起换行——否则 body 第一个节点是分页标记的书（Sigil、Calibre 的常见产物）整篇都缩进不了。排版完还会做一道校验——把结果重新解析一遍，元素、属性、去掉空白后的文本要和原文逐一对上，对不上就整块放弃、不覆盖原文。
格式化会不会让整本书都变成"已改动"？
看你点的是哪个。「格式化」只动当前文件；「格式化整本书」会把正文、样式、OPF、目录都排一遍，那些文件确实都会标记为改动、保存时一并重写——所以它给了「撤销格式化」一次性回滚，回滚时连"这个文件排版前本来就没动过"的状态一起还原，不会留下一堆假的改动标记。但打开书本身永远不会自动排版，这是刻意的：自动排全书等于每次保存都重写每一个文件，"只重写改动过的文件"这条保证也就没了。排不动的文件（语法错误、被安全网拦下）会单独列出来，不会闷声跳过。
右边的预览和真实阅读器一样吗？
接近但不完全一样。预览把包内的图片和样式换成临时地址后渲染，字体、布局基本还原；但各家阅读器有自己的默认样式和分页逻辑，最终效果以目标阅读器为准。预览按 HTML 宽松解析，这样改到一半标签没闭合时仍能看到内容。
加密（DRM）的书能编辑吗？
不能。打开时检测到 META-INF/encryption.xml 会直接拒绝。本工具不提供也不讨论 DRM 解除方法。
文件会上传吗？多大的书能开？
不上传，全程在浏览器内存里处理，关掉页面就没了。单本上限 200MB。因为整本要放进内存，超大的图文书在低配机器上可能吃力。
微信小程序 家书馆 · 家庭藏书管理
买书前先查一下，别再买重。扫一下书背后的条码就登记进家里的书库， 记得清放在哪一格、借给了谁，全家人共用同一个库。
📷 微信「扫一扫」左侧小程序码即可打开
👆 长按上方小程序码，识别打开「家书馆」