3 分钟跑通 pdf-inspector:从安装到把 PDF 变成 Markdown【免费下载链接】pdf-inspectorFast Rust library for PDF inspection, classification, and text extraction. Intelligently detects scanned vs text-based PDFs to enable smart routing decisions.项目地址: https://gitcode.com/GitHub_Trending/pdf/pdf-inspector爬虫一次吐了两百个 PDF,哪些能直接抽文本、哪些得送 OCR,不该靠肉眼判断。pdf-inspector 是纯 Rust 编写的本地 PDF 处理库,一次加载文档就能完成类型分类、文本提取和 Markdown 转换,带 Python、Node.js 与浏览器三套绑定,给要把 PDF 预处理塞进数据 pipeline 的工程师用。 它解决什么,不解决什么pdf-inspector 的问题域很小:先回答这是文本件还是扫描件,再把能抽的内容抽成结构化 Markdown,让上游只对需要 OCR 的页付钱。它不内置 OCR 引擎,也不做 PDF 编辑、表单或渲染服务;文档只加载一次,检测与提取共享同一份解析结果,没有重复 I/O。量化参考来自仓库 README 的对比测试:opendataloader-bench 的 200 份 PDF,Apple M4 Pro,OCR 关闭,版本 0.2.6。pdf-inspector 综合分 0.875,阅读顺序 0.915,表格 TEDS 0.814,全库 0.470 秒跑完;类型判断靠采样内容流里的 Tj/TJ 文本算子,约 10–50ms,文本型 PDF 全流程通常 200ms 以内。适合:报告、论文、发票、法律文档等文本型 PDF 批量转 Markdownpipeline 里的 OCR 路由:结果带 pages_needing_ocr,按页送检而不是整份送需要 X/Y 坐标与字体信息的抽取,以及浏览器内本地处理不适合:纯扫描件的内容重建——它能指出哪些页该走 OCR,但 PDFium、ONNX Runtime 和模型文件都要自备逐字保真级别的校对:表格检测是矩形加对齐启发式,复杂版式仍需人工抽查 最短路径:Python 端装好并转出第一份 Markdown预编译 wheel 覆盖 CPython 3.8 的 Linux(x86_64/ARM64)、macOS(Intel 与 Apple Silicon)和 Windows x64,无需 Rust 工具链:pip install pdf-inspector最小可运行示例,跑完直接出结果:import pdf_inspector result pdf_inspector.process_pdf(document.pdf) print(result.pdf_type) # text_based / scanned / image_based / mixed print(result.markdown) # Markdown 文本,无可抽文本时为 None print(result.processing_time_ms)不想落盘就用 process_pdf_bytes 直接喂内存字节,行为一致;在仓库源码里开发则用 maturin develop --release 本地构建。Node.js 一行 npm install firecrawl/pdf-inspector,同步的 processPdf 传 Buffer 即得同样的结构;Rust 侧 cargo add pdf-inspector 后调 process_pdf,另有 pdf2md、detect-pdf 两个 CLI 可直接进 shell;浏览器用独立的 wasm 包。想一次看全所有入口的输出,跑examples/basic_usage.py 你的pdf最直观。核心能力按工作流拆解:分流、取坐标、补 OCR按真实流程排:先低成本分流,再深入取细节,最后把漏网的页交给 OCR。批量处理前先分流。只想知道类型、页数和哪些页要 OCR,用 classify_pdf,它比 process_pdf 轻,不做任何提取:d pdf_inspector.classify_pdf(document.pdf) print(d.pdf_type, d.confidence) # 类型与 0-1 置信度 print(d.pages_needing_ocr) # 需要 OCR 的页,0 索引下游需要坐标时,比如把文本贴回渲染图或做布局分析,换 extract_text_with_positions,每个条目带字体名、字号和加粗斜体标记:items pdf_inspector.extract_text_with_positions(document.pdf) print(items[0].text, items[0].x, items[0].y, items[0].font_size)分流出的扫描件页走本地 OCR。process_pdf_with_ocr 先做原生抽取,只对质量信号不可靠的页渲染识别,Python 端处理时释放 GIL:ocr pdf_inspector.process_pdf_with_ocr(scan.pdf) print(ocr.pages_routed_to_ocr) # 实际被 OCR 的页ocr.pages 里每页都带来源(native/ocr/fused)、置信度、各阶段耗时和警告,方便对账哪页结果来自哪条路径。另外留意结果里的 has_encoding_issues 字段:字体编码坏掉的文档会把它打成 True,提示你该回退 OCR。Markdown 转换本身还处理多栏阅读顺序、标题分级、列表与表格,这些在 result.markdown 里直接可见。⚠️ 新手先看的三个坑页码索引不统一。process_pdf 的 pages 参数、结果里的 pages_needing_ocr、process_pdf_with_ocr 的 page_numbers 都是 1 索引;而 classify_pdf 返回的 pages_needing_ocr、extract_pages_markdown 的 pages、区域提取的页号是 0 索引。跨 API 拼页码前先换算,拿不准就查包内类型桩的注释,以仓库最新代码为准。process_pdf 不做 OCR。纯扫描文档的 markdown 很可能为 None,这是设计而非故障——默认路径只做纯抽取。要 OCR 得显式调 process_pdf_with_ocr,它依赖外置的 PDFium 与 ONNX Runtime 动态库(wheel 不带),模型在第一个被路由的页下载并校验;离线部署要预置模型目录并传 offlineTrue。Node 的同步函数会卡事件循环。processPdf、classifyPdf 是同步调用,大文档能阻塞几十到几百毫秒;服务端改用 processPdfAsync 等 *Async 变体,解析跑在 libuv 线程池上,输入 Buffer 调用前会被复制,返回后即可复用。延伸路径docs/python.md — Python 完整 API 参考docs/rust-api.md — Rust 库 API 与 OCR 选项napi/README.md — Node.js 绑定与类型定义docs/ocr-runtime.md — OCR 运行时配置细节浏览器场景的 wasm 包与 Rust CLI 的细节,分别见对应目录的 README 与仓库文档;前文引用的性能对比有可复现的配套方法,想验证那些数字可以直接照跑。拿 pipeline 里最拿不准的那份 PDF 跑一遍 classify_pdf,看它给的路由和你现在人工的判断差多少。【免费下载链接】pdf-inspectorFast Rust library for PDF inspection, classification, and text extraction. Intelligently detects scanned vs text-based PDFs to enable smart routing decisions.项目地址: https://gitcode.com/GitHub_Trending/pdf/pdf-inspector创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考