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：先把文件变成模型可读文本

MarkItDown 面向将文件与 Office 文档转换为 Markdown 的开发流程。它适合需要给检索、摘要或阅读工具准备文本的场景。具体可用转换器和依赖随文件类型不同，不能只装一个包就假定所有输入都支持。

Markdown 便于阅读，但不是原文的无损复制。表格、注释、复杂排版或附加内容是否保留，需要按任务验收。若目标是核对财务数字或合同证据，应保存原文件和来源，不能把转换后的文字当成唯一依据。

开始时先比较结果中的关键文字、表格关系与缺失内容，再决定是否需要更复杂的结构输出。不要为了输出统一成 .md 而忽视内容本身是否完整。

4. Apache Tika：已有内容分析基础设施

Tika 用于内容类型检测、文本与元数据抽取，适合已有 Java 服务或搜索索引管线的团队。它与直接调用 Python 函数的运维方式不同：需要考虑运行时、服务封装、解析器配置和资源隔离。

文件解析器会面对损坏、超大或异常输入。为服务设置文件大小、时间、内存、嵌套资源和失败重试策略，保留原文件标识及错误。不要因为解析接口统一，就把未知文件直接交给无限制的后台进程。

当前主版本与维护版本的配置可能不同，接入时查对应版本的迁移说明。对于既有系统，评估升级和回归成本；对于新项目，不要只因为格式覆盖广就忽略部署复杂度。

5. PyMuPDF：PDF 为主的细粒度处理

PyMuPDF 可用于 PDF 内容提取、页面操作和相关分析。需要坐标、页面或更细的 PDF 数据时，可以把它纳入候选。OCR 和其他增强能力仍需分别确认依赖与适用范围，不应把简单文本 PDF 的结果直接推广到扫描件。

这里特别需要看许可：官方将 PyMuPDF 和 MuPDF 列为 AGPL 与商业许可双路径。不能把它与 MIT 组件一起笼统写成“无条件免费商用”。应按实际部署和分发方式核对条款，需要商业许可时向权利方确认，不在这里提供法律结论。

如果主要输入不是 PDF，或希望一次处理多类 Office 文件，先比较相应版本的格式支持及额外产品范围，不要假定所有功能都属于同一个开源包。

OCR 和表格怎么验收

把文本层解析与图像 OCR 分成两组。OCR 测试至少包含不同分辨率、旋转、低对比度和目标语言；重要数字再用人工标注核对。能识别一行英文不代表支持中文扫描件，能读取中文 DOCX 也不代表中文 OCR 成功。

表格要检查行列关系、空单元格、合并单元格、单位、负数和跨页续表。返回一个 table 对象只说明发现了结构，不能证明金额对应正确。需要业务字段时再做字段级校验和来源复核。

本篇没有五家共同基准。Xberg 的配套检查仅覆盖合成输入和应用拒绝规则，其他工具根据官方功能与运行方式介绍，不宣称谁在真实业务里更准确。

成本、隐私与上线安排

计算总成本时，分开列软件许可、OCR 与模型资源、主机、存储、日志、重试和维护。某条路径不调用模型，不代表同一工具的摘要、结构化提取或其他可选功能也没有外部费用。开源代码与托管或商业支持套餐也应分开。

上传托管解析服务前检查数据处理范围；选择本地库时检查日志、监控、临时文件和资源下载。来自文档的文字是不可信输入，不能直接变成 Agent 的操作授权。需要修改订单、发信或付款时，保留独立业务审批。

先用小批文件跑完整流程，保留失败与不适用项，核对总数再扩大。中国大陆网络、平台安装包和资源可达性，需要在部署环境验证。想比较托管路径，可读 Xberg vs LlamaParse 与 Xberg vs Parseur。

官方资料

• Xberg
• Docling
• MarkItDown
• Apache Tika
• PyMuPDF 与许可说明