【科技前沿】pdf-inspector:先分型后提取

很多 PDF 处理流程一开始就进入 OCR，但 pdf-inspector 的顺序不同：先判断文档是原生文本、扫描件还是混合型，再决定后续走哪条提取路径。它要解决的，不是“如何把 OCR 再做一遍”，而是“哪些 PDF 原本就不该先进入 OCR”。

README 将它描述为本地 Rust 库，重点处理 text-based PDF 的分类、文本提取和 Markdown 转换，同时提供 Python、Node.js、Rust、CLI 和浏览器 WebAssembly 入口。下文主要看它的分型机制、提取链路、基准前提和接入方式。

处理流程

1先做分型

README 中的第一层能力是分类。项目会把 PDF 识别为 TextBased、Scanned、ImageBased 或 Mixed，并返回置信度以及逐页 OCR 路由信息。

这一步的作用，是把原生文本页和需要 OCR 的页先拆开，再决定后续走文本抽取还是 OCR 路径，而不是一开始就把所有文件都按同一种方式处理。按 README 的说明，分类阶段会先看内容流中的文本与图像操作，再据此判断文档是否属于可直接解析的范围。

2再做提取

在分型之后，提取阶段会继续处理版面顺序、表格、标题层级、列表、代码块和链接，再把结果转换成 Markdown。

README 还列出了 position-aware extraction、多栏阅读顺序、双路径表格检测和链接提取等能力，并强调检测与提取共享同一份解析结果，避免重复加载文档。这使它更像一条本地解析链路，而不是单点格式转换工具。

基准与接入

1基准前提

README 引用的是 opendataloader-bench 语料上的一组本地基准：覆盖 200 份 PDF，关闭 OCR，只比较非模型式 PDF parser。文档说明这组结果在 2026 年 7 月 31 日刷新，测试机器为 Apple M4 Pro。

在这个前提下，pdf-inspector 的整体得分、阅读顺序得分、表格得分以及完整处理速度都处在 README 列出的前列。但这组结果代表的是原生文本 PDF 的本地解析能力，不等于扫描件全流程效果。

2调用入口

项目提供 Python、Node.js、Rust、CLI 和浏览器 WebAssembly 入口。对命令行场景，README 重点给出 `pdf2md` 和 `detect-pdf` 两个命令，一个负责转换，一个负责检测与分析。

●●●Terminal

# 将 PDF 转成 Markdownpdf2md document.pdf --compact# 只做检测与版面分析detect-pdf document.pdf --analyze --json

`pdf2md` 面向直接转换，适合把原生文本 PDF 输出为 Markdown；`detect-pdf` 面向先检测、再决定后续处理路径，适合在进入提取前先判断文档类型和版面分析结果。README 还给出了 `--json`、`--items-json`、`--raw`、`--pages` 和 `--select-pages` 等参数，用于控制输出粒度。

结语

pdf-inspector 的核心不是把 OCR 做得更快，而是先把 text-based、scanned 和 mixed 文档分清，再把结构化提取建立在这一步之上。对原生文本 PDF 而言，更值得关注的是它把分型、提取、Markdown 转换和多端接入组织成同一条本地解析链路。

欢迎「长按」下方图片👇，关注我们在公众号上的专业知识分享。