PDF 要不要 OCR,先判断再处理

一份 PDF 里面，可能既有原生文字，也有扫描页、图片页和混合页。

如果文件一进来就全量 OCR，纯文字页也得跟着绕路。firecrawl/pdf-inspector 的处理顺序相反：先判断，再提取，只把需要的页面送去 OCR。

先判断文件类型

这是一个 Rust 库，默认会将 PDF 分为四类：

• TextBased：文字型

• Scanned：扫描型

• ImageBased：图片型

• Mixed：混合型

分类通过采样内容流完成，并返回 0.0–1.0 的置信度。README 给出的分类耗时约为 10–50ms，同时还会生成逐页 OCR 路由。

这样一来，不必把整份文件当成同一种输入。哪些页面可以直接读取，哪些页面需要 OCR，可以逐页安排。

让 OCR 只处理该处理的页面

Firecrawl 构建这个库，是为了在本地处理文字型 PDF。项目 README 给出的目标耗时低于 200ms，并希望跳过其估计约 54% 本来不需要 OCR 的文件。

这组数字来自项目说明，反映的正是它的设计思路：纯文字页直接提取，需要识别的页面再进入 OCR 流程，而不是让 OCR 覆盖所有输入。

提取时保留版面线索

提取结果不只是无顺序的一串文字，还会带上位置信息，包括字体、X/Y 坐标和自动整理的多栏阅读顺序。

遇到侧边盖章、图表轴标题等旋转文字时，结果会保留轴对齐框，同时报告 rotation 角，不会因为旋转而把文字宽度压成零。后续如果还要整理表格、还原阅读顺序或定位原文，这些信息都更实用。

提取后的内容还能转换成 Markdown。根据字体大小比例识别 H1–H4，并处理以下内容：

• 项目符号和编号列表

• 等宽字体代码块

• 表格

• 粗体、斜体和链接

• 分页符

对于需要把 PDF 统一整理成 Markdown 的流程，这比直接拿一段无结构文本更省事。

接入前先确认接口

如果需求是识别扫描件后再选择性调用 OCR，这个库会比较对路。原生 Rust 和 CLI 调用方可以主动启用 selective OCR；项目同时提供 Python、Node.js 和浏览器 WebAssembly bindings。

仓库 README 可以先作为入口，各语言文档分别在：

• Python：docs/python.md

• Node.js：napi/README.md

• WebAssembly：wasm/README.md

README 还列出了 Crates.io、npm 和 PyPI 等发布入口。项目主页在这里：PDF Inspector。

正式接入前，不妨拿自己的 PDF 样本测一轮，重点确认分类结果、默认提取范围，以及 selective OCR 的触发边界。

开源项目：firecrawl/pdf-inspector

免责声明：本文内容仅供学习与交流参考，不构成任何专业建议。文中观点及资料仅代表原作者；如涉及版权或内容问题，请联系处理。完整原文请点击文末「阅读原文」。