PDF 转文本：当排版本身就是麻烦的时候
试着对两个 PDF 跑一次 diff。跑不了——它们是二进制的，而且哪怕是同一份源文件重新导出的
"同一份"文档，也会因为时间戳和对象顺序而逐字节不同。现在把两份的文字都提取出来再 diff，两秒钟你就
知道合同的第 11 版和第 14 版之间究竟改了哪三句话。
PDF 转纯文本的理由，一句话就说完了。它不是"缩水版 Markdown"，而是另一件工具、另一种
用途。文本是你喂给分类器、灌进搜索引擎索引、切块存入向量库、丢给 grep 过滤、拿来统计字数
的东西，也是交给任何一个把 # 和 | 当成待解析字符而不是可忽略符号的程序的东西。
把文件拖进上方的转换器，几秒钟就有结果。免费、免注册、单文件上限 50 MB，我们这边不留任何东西。
扔掉标记之后，你得到了什么
纯文本提取的结果，就是按阅读顺序排列的文字，别无其他。没有语法字符，没有转义规则，也不用纠结一个星号 到底是强调还是就是个星号。对于数量惊人的一批处理流程来说，这不是妥协，而是硬性要求：
- 向量化与语义检索。把文档切块，逐块生成 embedding，再按相似度召回。Markdown 的竖线 和井号对语义毫无贡献，却实实在在占了向量里的位置——纯属稀释。干净的散文块召回得更准。
- 分类器与主题模型。凡是做词袋、TF-IDF 或 n-gram 分析的东西，只要你不提前剥掉，都会
老老实实把
###当成一个 token。与其事后清理，不如一开始就别引入。 - 全文索引。Elasticsearch、SQLite FTS、Postgres 的
tsvector——它们要的都是 一列裸文本。上 Markdown 就等于多一道清洗。 - 版本比对。按行 diff 对散文好用，对表格很糟：Markdown 表格改动一个单元格，整行都会 重排重写。
- token 成本。把长文档贴进上下文窗口本就吃紧的模型时，每一根竖线都是你花钱买来、却 什么也没换到的 token。
以及你会失去什么——先说清楚为好
扁平化是有损的，而且是故意的。其中两项损失比其余都重要。
表格会塌掉。一张财务表会变成一串用空白隔开的数字。数值一个不少，但每个数原本属于哪一列 没了，再怎么调提示词也捞不回来。如果表格恰恰是这份文档的重点，那就改用 PDF 转 Markdown，竖线表格能把 行列关系完整保下来。
层级会消失。一个小节标题和它下面那句话，会变成毫无区别的相邻两行。你让模型"总结第 4 节"， 它只能靠措辞去猜第 4 节从哪里开始。面对规格书、标准、带编号条款的合同这类又长又有结构的文档，答案出错 往往就出在这一步猜测上。
页面顶部的格式切换按钮会在文本和 Markdown 之间来回切，并且保留你已经选好的文件——两种格式各转一遍做 对比，只需一次点击，不用重新上传。
PDF 转文本时会冒出来的那些怪毛病
PDF 是一种页面描述语言。它把字形摆在坐标上，所谓提取，就是从这堆坐标里把句子重新拼回来。由此衍生出 几种产物，事先知道能替你省下一个摸不着头脑的半小时：
- 句子中间硬换行。PDF 里压根没有"会自动重排的段落"这个概念——每一个视觉上的行都是
一段独立文本。于是一个段落到你手里就是六个短行。这是
grep和正则最大的坑：你要搜的词组 正好跨了一次换行，明明白纸黑字就在那儿，结果零匹配。 - 断词连字符不会自动合并。西文 PDF 里跨行断开的"manage-"/"ment"通常还是断的，做词频 统计或关键词提取前值得先跑一遍查找替换。中文 PDF 不断词，但换行照样能把一个词组劈成两半，坑是同一个。
- 页眉和页码夹进正文。公司名和"第 14 页，共 88 页"每隔两三千字就插进你的正文一次。 读着无伤大雅，切块时有点碍事，看出规律后一行正则就能清掉。
- 分栏顺序可能错乱。学术论文的双栏排版通常能正确线性化，但浮动边栏、引文框和脚注块 有时会落到段落中间。
- 连字与怪字形。专业排版的 PDF 里，"fi"和"fl"常常是单个字形，多数都能正常提取。但 如果 PDF 用的是子集化字体、又没带正确的 Unicode 映射表，提取出来就是一堆乱码——这种情况少见，一旦 出现，问题在文件本身，不在转换器。
扫描版 PDF 里根本没有文字可提取
扫描版 PDF 就是纸张的照片套了个 PDF 外壳。里面除了像素什么都没有，而文字识别不会钻进 PDF 内部去跑—— 纯图像的文件转出来就是空的。（把同一页存成 JPG 或 PNG 再传，反而能正常识别，见 图片转文字。碍事的正是那层 PDF 外壳。）判断只要两秒：打开文件，用鼠标去选一句话。文字被高亮，那就没问题；整页盖上一个方框，那就是 扫描件。
扫描件请先跑 OCR——Acrobat、macOS 的"预览"以及大多数现代 PDF 阅读器都带"识别文本"这类命令——识别完 再回来转换。输出质量的差距一点都不细微。
它真正解决的活儿
- 搭建 RAG 语料库。几百份制度类 PDF 转成文本，按段落边界切块，再做向量化。文本是所有 切块库默认预期的格式。
- 核对合同改动。把两个版本都提取出来，跑一次词级 diff，直接读真实改动，而不是去信一封 总结邮件。
- 合规排查与关键词扫描。在一整个文件夹的提取结果里 grep 某个约定术语、某个供应商名字， 或者某句本不该出现的话。即时、离线，除了 shell 不需要别的工具。
- 可读性与文风分析。句长分布、术语密度、阅读难度评分——这些都要求文本流里干干净净， 不掺任何排版标记。
- 喂给语音合成。你要是把 Markdown 丢给屏幕阅读器或 TTS 引擎，它会一本正经地念出"井号 井号 引言"。
- 快速估算 token 数。输出下方的计数器会告诉你这份文档要花多少 token，这比贴进去之后 靠截断报错才发现有用得多。
常见问题
怎么免费把 PDF 文件转成文本？
把文件拖进本页顶部的转换器，提取出的文本就会显示在它下方。不用注册账号，不用留邮箱，输出也不带水印。单文件上限 50 MB，你拿到文本之后什么都不会留下。可以直接复制走，也可以下载成 .txt。
为什么我的 PDF 转出来的文本是乱码？
几乎总是字体的问题，不是转换器。用子集化字体制作、又没有附带 Unicode 映射表的 PDF，只存了字形索引，却没说明这些索引对应哪些字符，于是提取出来就是一串莫名其妙的字母。如果这段文字在你的 PDF 阅读器里同样选不中，那就确实是文件本身的毛病——请从源文档重新导出一次。
扫描版 PDF 能转成文本吗？
不能直接转。扫描件是包在 PDF 里的照片，内部没有任何字符可取，所以结果是空的。两条绕路：先在 Acrobat 或 macOS 的"预览"里执行"识别文本"，再回来转换；或者把该页导出为 PNG，走 图片转文字，那条路确实会对像素跑 OCR。
为什么提取出来的文本在句子中间就断行了？
PDF 没有可重排的段落——每一个视觉行都作为独立的文本块存储，所以一个段落会变成六个短行。这一点在用 grep 和正则时最难受：跨行的词组一律零匹配。检索之前，先把不以句末标点结尾的行拼回去。
PDF 该转成 txt 还是转成 Markdown？
如果下游解析的是裸词——向量化、搜索索引、分类器、diff——就转文本。如果文档的形态本身携带信息，就转 Markdown，因为竖线表格能活下来、标题仍旧带着标记。表格是决定性因素：把财务表压成纯文本，每个数字原本属于哪一列就永远找不回来了。
我的 PDF 会被上传到服务器吗？
文件会发送到转换服务，处理完即丢弃——不存储、不记日志、不建索引，响应返回之后什么都不保留。如果你需要文件真正一步都不离开本机，可以用本地文件夹转换器，它直接在浏览器里读取文件。
工具箱里的其他家伙
PDF 只是支持的十三种格式之一。File2Txt 一次上传就能全部处理，也可以直接去 Word 转文本处理 DOCX、 HTML 转文本处理存下来的网页、 EPUB 转文本处理电子书，或者 图片转文字处理截图。 手上是代码？那就转 GitHub 仓库、 GitLab 项目，或者 本地文件夹。要抓在线网页的话， Web2Txt 直接从网址抓。 为 LLM 准备文档的完整指南 讲的是这一整套东西的通用版本。
Repo2Txt 由 v12hero 开发和维护，那是一位独立开发者，专做隐私优先的原生应用和 Web 应用。