📌 项目地址：firecrawl/pdf-inspector | ⭐ 7,606 颗星 | 🔧 Rust | 📜 未标注
为什么需要这个项目
PDF 处理有个老问题：不是所有 PDF 都是“可复制文字”的。扫描件、纯图片、混合排版，甚至编码损坏的字体，都会让标准提取流程输出一堆乱码或空白。传统的解决思路是“无脑上 OCR”，但 OCR 又慢又贵。Firecrawl 在自家管线里统计过，大约 54% 的 PDF 根本不需要 OCR——它们是纯文本 PDF。pdf-inspector 就是用来在本地快速区分这些情况，并完成高质量提取的 Rust 库。
它的核心能力不是“另一个 PDF 解析器”，而是智能分流：先用约 10-50 毫秒抽样内容流，判断一个 PDF 是 TextBased（文本型）、Scanned（扫描型）、ImageBased（图片型）还是 Mixed（混合型），并给出置信度和按页的 OCR 路由建议。这样你可以在业务流程中做出决定：哪些文档值得送 OCR，哪些直接在本地用几百毫秒处理完。
它到底做了什么
- 分类：返回
TextBased/Scanned/ImageBased/Mixed和 0.0-1.0 的置信度，支持按页判断。 - 提取：位置感知提取——保留字体信息、X/Y 坐标，还能自动处理多栏阅读顺序。
- 转 Markdown：识别标题层级（通过字号比例）、列表、代码块（等宽字体）、表格、粗斜体、URL 链接和分页符。
- 表格检测：双模式，既能从 PDF 绘图指令识别矩形边界，也能从文字对齐方式推断，适合财务表格、脚注、跨页表格。
- 多栏与 RTL：支持报纸式多栏布局和从右到左文字。
- 编码问题探测：如果字体编码损坏，会主动标记，让调用方及时回退到 OCR。
- 单次文档加载：同一个解析结果在分类和提取之间共享，避免重复 I/O。
- 浏览器 WebAssembly：相同 Rust 解析器可直接在浏览器和 Web Worker 中运行，CMap 内置，无需服务器往返。
性能上，项目在 opendataloader-bench（200 个 PDF）上的测试结果非常亮眼：总分 0.875，阅读顺序 0.915，表格 0.814，处理 200 份文档仅用 0.470 秒。对比 pymupdf4llm 的 17 秒和 markitdown 的 16 秒，差距是两个数量级。
实际用法
项目提供 Rust crate、Python 包、Node.js 绑定和 WASM。安装命令和具体 API 请直接参考官方文档：
- Rust: crates.io/crates/pdf-inspector
- Node.js: npm 包
- Python: PyPI 包
- 详细文档: docs/python.md、napi/README.md、wasm/README.md
README 没有展示具体函数签名，但围绕它的典型逻辑是：先调用分类接口拿到一个 PDF 的“类型和置信度”，如果置信度表明是纯文本，就调用 Markdown 转换；如果检测到扫描痕迹或编码异常，才将其发送到 OCR 服务。
和同类工具的区别
注意，pdf-inspector 不是 OCR 引擎，而是 OCR 的前置判断器 + 本地文本处理器。它解决了“何时用 OCR”这个决策问题。同类工具如 PyMuPDF4LLM、MarkItDown 也能提取文本，但缺乏分类和路由能力，也没这么快。在基准测试中，pdf-inspector 在总分、阅读顺序、表格准确率和速度上都明显领先，只有在标题识别（MHS）上略低于 liteparse。
另一个关键区别是轻量：纯 Rust 实现，没有 ML 模型，不依赖外部服务，唯一的解析依赖是 lopdf。这意味着它可以嵌入到各种运行时中，甚至通过 WASM 在浏览器内跑。
需要注意的事项
- 不做 OCR：如果 PDF 是真正的扫描图片，它不会帮你识别文字；它会告诉你“这份 PDF 需要 OCR”，并给你路由建议。
- 许可证：README 里有 LICENSE 链接，使用前请确认是否满足你的商业项目要求。
- 版本和基准：基准数字来自特定版本（pdf-inspector 0.2.6），你的实际数据可能不同，建议用自己的 PDF 样本做压测。
- 依赖面：虽然只依赖
lopdf，但 PDF 格式极其复杂，遇到极端排版或自定义编码时仍可能失败。好在它会主动标记编码问题，而不是静默输出垃圾。
如果你的系统正在被海量 PDF 的 OCR 成本拖垮，或者你在构建 RAG 流水线、文档解析服务，这个项目值得认真评估——它可能会让你省掉一半以上的 OCR 调用。