从 PDF 提取文本

重排成阅读顺序的文字 —— 而在它上方,是别的提取工具会漏掉的部分:哪几页真的给出了文本、哪几页是扫描件、哪几页的文本层解码出来什么都读不出来。

🔒 你的文档不会离开浏览器。

📄

把一个 PDF 拖到这里

一次一个 PDF · 什么都不上传

一页空白和一页没读出来,长得一模一样

扫描页是没有文本层的。问任何提取工具要它的文字,你拿回的都是一个空字符串 —— 和一页真正空白的页面给出的答案一模一样。这正是值得专门设计来防的失败模式:输出没有错,它只是沉默——而下一个读它的环节会认定这一页本来就什么都没有。这里把这些页点名、计数,并指向 OCR 工具。

看着是文本,其实不是文本

还有第二种更安静的失败:字体带着自定义编码嵌入,又没有 ToUnicode 映射。字形画得没错,页面看着完美无缺,而字形背后的字符其实是毫无意义的私用区码位。把这段文字复制到任何地方,你拿到的都是乱码。本页会把它标出来,而不是当成正常文本原样交给你。

它刻意不做的事

不做表格重建,也不做版面分析。把一张表格连行列结构一起从 PDF 里还原出来,是另一个问题,有专门的工具去解;假装能顺手做到,只会产出一份看着像模像样的胡话。这里给你的是文字本身,按阅读顺序排好,并如实交代它来自哪些页。

本工具的全部检查项(共 4 条)

PDX-001 这一页没有文本层

这一页完全没有可提取的文本,几乎总是意味着它是扫描件 —— 一张页面的图片,而不是一个页面。提取结果是一个空字符串,而危险在于:一个空字符串读起来像「这页是空白的」,而不是「这页还没被读出来」。先给这些页跑一遍 OCR。

修复: 用 OCR 工具补一层文本,再重新提取。

yaktool 工程规则,不是引自规范的条文:依据的是 PDF 文字提取在实际中的表现。没有文字层的页面、没有 ToUnicode 映射的字体、被截断的结果,是提取「看上去成功、其实没用」的三种情形。

PDX-002 文本层提取出来是乱码

提取出了文字,但其中很大一部分是替换字符或私用区码位。这发生在字体带着自定义编码嵌入、又没有 ToUnicode 映射的时候:字形在屏幕上画得没错,但背后的字符毫无意义。这比一页空白更糟,因为输出看起来像文本,也会被当成文本来读。

修复: 对这一页做 OCR,而不是信任它的文本层 —— 渲染出来的字形是对的,编码却不对。

yaktool 工程规则,不是引自规范的条文:依据的是 PDF 文字提取在实际中的表现。没有文字层的页面、没有 ToUnicode 映射的字体、被截断的结果,是提取「看上去成功、其实没用」的三种情形。

PDX-003 输出被裁到符合字符预算

请求的预算在整份文档输出完之前就用完了。掉了多少字符、哪几页完全没有输出,两者都会报出来 —— 因为一次悄悄缩短的提取,和一份本来就短的文档,是没法分辨的。

修复: 调高预算,或者只要一段页码区间。

yaktool 工程规则,不是引自规范的条文:依据的是 PDF 文字提取在实际中的表现。没有文字层的页面、没有 ToUnicode 映射的字体、被截断的结果,是提取「看上去成功、其实没用」的三种情形。

PDX-004 请求的页不在文档里

被要求的页码超出了文档范围。这里选择报出来而不是忽略,这样一个多打了一位的区间就不会看着像刚好是空白的一页。

yaktool 工程规则,不是引自规范的条文:依据的是 PDF 文字提取在实际中的表现。没有文字层的页面、没有 ToUnicode 映射的字体、被截断的结果,是提取「看上去成功、其实没用」的三种情形。

关于这些规则。 每一条都有编号、严重级别和通俗解释。每个来源链接都已登记在案,并对线上页面实际复验过,而不是凭印象写上去的. 规则如何编写、测试与保持更新 →