opendataloader-project/opendataloader-pdf

如果你手上的 PDF 一到提取环节就乱，这个项目值得花半小时试：本地模式确定性输出，难页面再交给混合模式。但要先接受两点：AI 相关的大多数能力需要额外安装后端，而无障碍这边只有自动打标签在开源版里，PDF/UA 导出属于付费插件。

解决什么问题

你有一批 PDF——报告、论文、银行流水、扫描件——想喂进 RAG 索引或做内容迁移。复制粘贴会把分栏和表格弄乱，普通提取器对多栏排版束手无策，坏页面只能人工逐页修。用这个工具，你把文件或目录传给 convert()，直接得到 Markdown、JSON 或 HTML，每个元素带坐标，还能重建标题、列表和表格结构。无障碍场景则不同：改造前是一份没有标签的 PDF，读屏软件只能按文档顺序念；改造后是一份带结构树的 Tagged PDF，后续修复工作有了基础。

有什么不同

核心是本地版面分析，用 XY-Cut++ 判断阅读顺序，输出确定、每个元素带 bounding box，也可以选择尊重 PDF 已有的结构标签。输出确定对数据管道很重要：同一份输入得到同一份结果，回归测试和 diff 才有意义。启发式搞不定的部分——复杂无边框表格、需要 OCR 的扫描页、公式、图表描述——混合模式会把这类页面转给 AI 后端，通过 [hybrid] 额外安装。代价也很典型：本地模式快且可预测，但恰恰在难页面上吃力；混合模式改善难页面，却多了一个服务、一步安装，输出也不再那么确定。

Tagged PDF 的处理是另一个有区分度的行为：文件本身有标签且你打开 use_struct_tree 时，解析器采用作者留下的结构，而不是猜。README 明确说标签质量差时会适得其反，而且 use_struct_tree 会覆盖混合模式，所以得先了解自己的语料。无障碍方向上，开源版止步于自动打标签生成 Tagged PDF；PDF/UA 导出和无障碍工作室是企业版功能，完整合规输出不在开源核心里。

谁值得试

适合：正在搭文档摄取管道的数据或 ML 工程师，能接受 Java 依赖，想要带坐标的 JSON 以及 Python/Node 封装；或者已经有修复流程的无障碍团队，需要给未打标签的 PDF 生成第一版结构树。不适合：只需要导出纯文本的人（安装成本换不回来），以及需要进程内 C++ 库的项目——HN 上有评论者明确说要找能在 C++ 里调用的表格提取库，Java/Python 技术栈对他就是障碍。如果你要求 PDF/UA 输出完整落在宽松许可证下，也不适合。

一条实际使用反馈：2025-09-23 有评论者在同一讨论串里说，拿银行流水试过，JSON 结果一次就能用，比自己试过的其他工具好，但仍需更深入检查。这只是单一文档类型、单一版本的经验，不是基准测试。

使用条件与边界

pip 路径需要 Java 11+ 和 Python 3.10+；另有 Node.js 和 Java 的快速上手路径。因为每次 convert() 都会启动一个 JVM，README 提醒反复单文件调用会慢——把输入批量放进一次调用。混合模式、OCR、公式和图表功能需要安装额外组件并启动后端；OCR 质量随引擎和语言不同而变化。

README 里的基准数字（整体 0.907、表格 0.928、本地模式 0.015 秒/页）是项目自报的，本文没有独立验证，只能当作针对你自己文档的起点假设。许可证在 2.0 版从 MPL 2.0 改为 Apache 2.0，2.0 之前的版本仍属 MPL。依赖结构标签前，先读 Tagged PDF 说明。

HotRepo 点评

HotRepo 记录到该项目 2026-10-24 为 29,983 星、2026-10-25 为 29,988 星，这两天样本里两次登上日榜。这只是快照，不是趋势：两天的记录不足以判断热度能否持续。真正该先验证的是：在你的实际 tagged PDF 语料上，use_struct_tree 和混合模式哪个效果更好。