2026 年本地文档抽取 SDK 推荐：格式、OCR 与运行成本怎么选？

快速建议

需要多格式处理并希望在自己的代码中组合流程，可先试 Xberg；更重视文档内部结构和后续处理，可比较 Docling；主要想把文件转成便于模型阅读的 Markdown，可了解 MarkItDown。已有 Java 内容分析基础设施，可评估 Apache Tika；主要围绕 PDF 做细粒度提取与处理，可评估 PyMuPDF，并先确认许可证。

这五项都能参与本地文档处理，但部署方式、输入对象与输出结构不同。这里的 SDK 是开发接入方式的统称，也包含可通过服务或命令行接入的工具包。编号只是介绍顺序，没有五家共同的速度、OCR 或表格准确率排名。资料核对日期为 2026-10-23。

先确定交付物

文档抽取至少有三种目标：提取可搜索文本，保留表格和来源结构，或者把内容转换成业务字段。前两项成功不代表第三项正确。例如读到一份发票里的所有数字，仍需确认哪个是税额、总额、币种和到期日期。

选工具前，先收集文本 PDF、扫描件、Office、网页存档和损坏文件，标注关键证据。明确最终输出需要纯文本、Markdown、结构化对象，还是带坐标的来源记录。不要仅看官网支持的格式数量，因为同一格式中的文本、表格、图片和复杂版式并不等价。

工具	优先考虑	重点检查
Xberg	多格式开发组件与可选 OCR	版本、实际构建、后端和依赖
Docling	结构化文档表示与后续处理	模型资源、布局与导出结果
MarkItDown	为后续阅读或检索生成 Markdown	格式依赖与语义保留
Apache Tika	已有 Java 内容分析和元数据流程	运行服务、解析器与资源限制
PyMuPDF	PDF 提取与页面处理	坐标、表格、OCR 与许可条件

1. Xberg：多格式流程中的统一入口

Xberg 提供 Rust 核心与多语言接口。适合已有开发流程，希望在文件进入索引或业务系统之前，统一管理输入、内容、元数据与错误的团队。接入时先固定实际包版本，再检查相应 API，不能混用旧 Kreuzberg 和新 Xberg 示例。

本次 Python 1.3.9 示例实际处理了六份合成文件：文本型 PDF、DOCX、HTML、CSV、中文文本以及一张英文图片。两份其他输入分别以损坏文件和不支持扩展名的形式保留为失败。这说明有限流程可以运行，不证明所有格式、语言或复杂表格都达到业务标准。

在本地运行的价值是可控制环境与数据流，代价是依赖、资源、更新和错误处理需要自己维护。可选模型增强路径应单独核对下载和调用。实际步骤见 Xberg 教程。

2. Docling：重视结构化文档表示

Docling 的文档转换与结构化表示适合后续需要文档层级、表格和内容关联的流程。选择它时，不只检查导出的 Markdown，还要检查结构对象是否保留了业务需要的关系，是否便于追溯回原始页面。

布局、OCR 或其他模型路径可能带来资源准备和运行成本。能在本地执行，不代表首次运行无需网络或所有模型都已经随包装好。固定配置和模型来源，再用自己的文档观察结果，比套用厂商或社区基准更可靠。

如果已经使用结构化文档做分块和来源追踪，继续复用现有对象可能减少适配工作。若只要简单文本，也应评估新增模型和数据结构的维护成本是否值得。

3. MarkItDown：先把文件变成模型可读文本