EPUB 转文本：把一书架的书变成可以计算的东西
书是我们手头编辑得最好的长篇散文。职业作者写、职业编辑校，几万字口吻统一，中间没有导航菜单、 Cookie 弹窗和评论区。作为一切语言类工作的原料——embedding、文风分析、检索、训练一个识别语气 的分类器——很难找到比它更好的。
问题在于，这些文字装在一个打包了一堆 XHTML 文件的 zip 里。EPUB 转文本转换器把 它们取出来：一条连续的散文流，没有标签，没有标记字符，没有任何需要教会分词器忽略的东西。传到 上方，几秒钟就拿回来。免费、免注册、上限 50 MB，什么都不存。
为什么扁平文本正适合这类活儿
纯文本在这里绝不是将就的选项。对绝大多数需要批量处理书籍的场景，它才是工具链真正期待的格式：
- embedding 与语义检索。把散文切块，逐块向量化，按相似度召回。Markdown 的 井号和星号占着 token 的位置，对语义毫无贡献——纯粹稀释向量。干净的段落召回得更准，而且 地球上每个切块库默认吃的都是文本。
- 可读性与文体计量。Flesch-Kincaid、平均句长、型例比、词汇丰富度、标点节奏。 这些都是词级和句级的度量，任何排版 token 都会把它们全部污染。
- 给整个书库建搜索索引。Postgres 的
tsvector、SQLite FTS5、 Elasticsearch，或者一个直接grep的普通文件夹。它们要的都是字段里的裸文本。 五十本转好的书就是一台真正快的私人搜索引擎。 - 语料库语言学与 NLP 流水线。语境索引、搭配分析、命名实体抽取、主题建模。 spaCy 和 NLTK 吃的是字符串，不是标记。
- 语音合成与无障碍。把 Markdown 递给 TTS 引擎，它会兴高采烈地念出"井号 井号 第四章"。
- 比对版本。同一本书的两个印次都提取成文本，跑一次词级 diff——第二版到底 改了什么，就是这么查出来的。
压平之后你失去了什么
章节边界。这才是真正的代价，而且对书来说比对多数文档类型更要命，因为书长到"我现在读到哪儿了" 本身就是个问题。
在源 EPUB 里，每一章是一个独立的 XHTML 文件，带标题标签，在导航文档里有一条对应记录。压平之后， 章节标题就成了一行短文字，压在一大段长文字上头，没有任何东西标明它的不同。让模型"总结第七章"， 它只能靠措辞去猜第七章从哪儿开始。多数时候它猜得出来。偶尔它会晚一个段落起步，悄悄总结了 不该总结的内容。
引文块也不再和正文叙述有视觉区分，这对非虚构类很要紧——引用的原始材料和作者自己的论证肩并肩 坐着。如果这些对你要做的事是承重的，改用 EPUB 转 Markdown—— 标题树在那边活得好好的，你可以按章节干净地切分文件。本页顶部的格式切换按钮可以在两者之间切换， 并带着你已选好的文件，两种都转一遍再对比，不用上传第二次。
值得清理一下的排版残留
出版社的排版是认真的，读起来舒服，算起来就有点烦。有几样东西铁定会出现在提取出的书籍文本里， 跑一遍查找替换就能解决大半：
- 弯引号。正式出版物用的是排版引号，不是
"和'。分词器一般扛得住，但简单的正则和字符串匹配扛不住——在书里搜"好了"可能一无所获，而页面里满是“好了”。 - 破折号与连接号。西文里常常不带空格，分句器偶尔会因此把两句话粘成一句， 或者在错误的位置断开。
- 软连字符和不换行空格。屏幕上看不见，字节流里存在，正是它们让字数统计 对不上任何数字。
- 连字。"fi"和"fl"有时是单个字形。通常能正常提取，但少见的内嵌字体可能 让个别单词冒出怪字符。
- 前言后记类内容。扉页、版权声明、题献、致谢、"关于作者"、索引残片。每本 转出来的书都有这套样板，做语料统计时它们会成为虚假的高频词汇。做词频工作前请剪掉。
这些都不是转换器偷懒。文件里真真切切就是这些东西，而知道要去找它们，仗就赢了大半。
DRM，以及能转的书从哪来
从大型商店买的书通常是加密的。容器里的 XHTML 被打乱，旁边一个 encryption.xml
文件昭告此事，所以任何转换器——包括这一个——一个字也读不出来。传上来只会得到报错或空输出。
先知道这一点，能省下十分钟对着结果发懵。
好在无 DRM 的来源很多。Project Gutenberg 的公版书目录规模庞大，非常适合语料工作。Standard Ebooks 做的公版书排印讲究，标记异常干净。多数技术出版社、学术圈周边的出版机构、知识共享授权 的书，以及你自己导出的任何文件，都能顺利转换。转换自己拥有的书用于学习是正常使用；把有版权 的书提取出来的文本拿去传播就是另一回事了。点到为止。
对整个书库批量来一遍
转一本书是两秒钟的事。有意思的玩法是转四十本，然后把结果当数据集用。几条让这事顺畅的经验：
- 打包成 zip。ZIP 转文本 接一个归档，一趟转完里面所有支持的文件，比四十次单独上传强多了。留意 50 MB 上限——EPUB 本身很小，但带插图的不小。
- 先归一化，再切块。拉直引号、剥掉软连字符、合并连续空行。入库时做一次， 下游每一步都简单。
- 按段落边界切块，别按固定字符数。书有真正的段落，段落就是天然的语义单元。 无脑每 1000 字符一刀会把句子劈成两半，给碎片做 embedding。
- 把文件名当元数据留住。一旦全变成一条文本流，书名和作者就是你仅剩的出处 信息。把它们和每个块存在一起，否则你会检索到一段绝妙的文字，却不知道出自哪本书。
- 看一眼 token 数。输出下方的计数器给出每本书的真实数字，这是"规划流水线" 和"瞎猜流水线"的分界线。
同一本书，EPUB 比 PDF 版更好用
同一本书两种格式都有的话，EPUB 给你的文本更干净、活儿更少。PDF 是固定版式：每个视觉行都是 一串独立的字形，段落到手就是断成短行的，跨行断开的单词保持断开，页眉和页码每隔几百个词就 插进你的正文一次。 PDF 转文本这些都能处理， 但之后你得刷洗一遍。
EPUB 是可重排的。没有页面，所以没有页眉页脚可剥，段落在标记里就是真正的段落——出来的是 连续的长行，正则搜索能跨着匹配。凡是涉及短语检索、分句或 embedding 的活儿，光这一点差别 就值得换。
常见问题
怎么把 EPUB 转成文本？
把 .epub 拖进上方的转换器，书的正文就会以纯文本返回，可下载为 .txt。免费、免注册、单文件 50 MB——对任何可重排电子书都绰绰有余，因为 EPUB 是压缩过的 HTML，长篇也很少超过几兆。
从 Kindle 或 Apple Books 买的书能转吗？
只有无 DRM 的才行。买来的书通常是加密的，绑定在购买账号上，加密文件里没有任何转换器能触及的可读文本。Project Gutenberg 和 Standard Ebooks 的公版书、卖未加密文件的技术出版社的书，以及你自己的导出文件都能正常转换。
输出里章节还分得开吗？
章节边界会以文本流中的断行形式留下来，但章节标题就是普通的一行字，没有任何东西标明它是标题——压平成文本的本性如此。如果之后还要按章节导航或切块，EPUB 转 Markdown 保留的标题层级正是干这个的。
脚注和尾注呢？
会保留，一般集中在它们所属小节的末尾，而不是留在注号原来的位置。对学术著作来说，这意味着章与章之间会出现一串注释正文。读的时候跳过去不难；但如果你在给 embedding 切块、纳闷为什么某一块全是引文出处，原因就在这里。
能用这种方式把一整本书喂给 LLM 吗？
一次就能转完，但贴之前先看 token 数。一本 300 页的小说大约 12 万 token——放得进 200K 的上下文窗口，却远超聊天界面单条消息能接受的量。输出下方的计数器让你在吃亏之前就知道数字。
工具箱的其余部分
EPUB 是支持的十三种格式之一。 File2Txt 一次上传就能全部 处理。手稿有 Word 转文本，老式富文本 文档有 RTF 转文本，存下来 的文章有 HTML 转文本。 自己的结构化数据走 CSV 转文本或 JSON 转文本。
文档之外：转 GitHub 仓库为文本、 GitLab 项目或 本地文件夹，用 Web2Txt 把在线网页抓成文本。 想看全景的话，还有一篇更长的 为 LLM 准备文档的指南。
Repo2Txt 由 v12hero 开发和维护，那是一位独立开发者，专做隐私优先的原生应用和 Web 应用。