Rust 终于有能打的文档解析了？

做 RAG 应用的人都会撞上同一个问题。PDF、Word、扫描件要喂给 LLM，第一步就是把这些东西变成文本。我在选型的时候发现，Unstructured、Docling、MinerU 全是 Python 系，Rust 生态只有 pdf-extract、lopdf 这类单格式库，没有一站式方案。后来看到 xberg，Rust 核心、101 种格式、371 种语言的代码智能、15 种语言绑定，还自带 MCP server，就把它装下来实测了一周。

先把结论放前面，Rust 项目用它省心，Python 项目先别急着迁。

xberg 是什么

xberg 是一个 Rust 写的文档解析库。把 PDF、Word、图片、网页、代码文件丢给它，它给你吐干净的文本和结构化数据，表格、实体、embedding 都有，主要就是给 LLM 应用喂料的。crates.io 上的定位是 document intelligence，101 种格式、371 种语言的代码智能。

它解决的核心问题是多格式一个入口。以前一个 PDF 一个库，Office 又换一个，代码文件还得再找解析器，凑起来是一堆散件。xberg 把所有格式统一收进一套 API，用语言无关的插件体系按格式挑 extractor。这个设计比一个函数硬啃所有格式实在，也比自己拼五六家库省心。

架构一句话就能说清。核心是 Rust，其它都是绑定。

核心模块做 extract 编排，MIME 检测覆盖 115 种扩展名，按格式优先级挑 extractor。插件体系是语言无关的，PDF、图片、Office、邮件各走各的提取器。OCR 后端有 Tesseract、PaddleOCR 和 Candle 系的 VLM，按需切换。绑定层覆盖 Python、TS（NAPI-RS）、WASM、Java、Go、Elixir 等 15 种，WASM 性能约为原生 60%-80%，不是所有绑定体验一致。接入方式有库 API、CLI、REST API、MCP server。自带 MCP server 这一点，说明它是冲着 AI Agent 场景设计的。

这些数字我对照 crates.io 核对了一遍，101 种格式、115 种扩展名、371 种语言、15 种绑定，当前版本 1.0.14。

第一个坑，默认特性连 PDF 都打不开

建个项目，cargo add xberg，用默认特性直接跑这段探针代码

rust 复制代码

use xberg::{extract, ExtractInput, ExtractionConfig};

#[tokio::main]
async fn main() -> anyhow::Result<()> {
    let config = ExtractionConfig::default();
    let out = extract(ExtractInput::from_uri("document.pdf"), &config).await?;
    println!("{}", out.results[0].content);
    Ok(())
}

Markdown、CSV、JSON 开箱即用，中文和表格都提取得干净。换成 PDF 就报错，错误信息是这样

css 复制代码

ERROR: UnsupportedFormat("application/pdf")

101 种格式是特性开关，不是默认全开。PDF 和 HTML 都要手动开 feature，Cargo.toml 里这样写

toml 复制代码

xberg = { version = "1.0.14", features = ["pdf", "html"] }

第二个坑，pdf 特性编译断链

开 pdf 特性之后构建直接失败，报错信息长这样

vbnet 复制代码

error: failed to select a version for the requirement `fax = "^0.3"`
candidate versions found which didn't match: 0.2.7, 0.2.6, ...
required by package `pdf_oxide v0.3.77`

xberg 的 PDF 能力基于 pdf_oxide 0.3.77，它依赖 fax ^0.3，而 fax 0.3.0 是 2026 年 7 月 13 日才发布的，本地 cargo 索引缓存里只有 0.2.x。跑一次 cargo update 更新索引，编译就过了。整个编译约 6 分钟，产物 28.4MB。新项目第一次跑大概率踩这个，记一笔。

PDF 解析质量，内容完整，结构打平

PDF 提取质量我拿 arXiv 的 Attention Is All You Need 试的，5 页文本层论文。

耗时 0.302 秒，输出 39.6KB、809 行文本。内容完整性没得说，Multi-Head、positional encoding、BLEU、softmax 这些关键词全部命中，正文、公式叙述、表标题都在。结构保真一般。没有 Markdown 标题层级，表格没有还原成表格，Table 1 的标题和叙述在，表格数据被打平成文本流，数学符号的下标混在句子里。

同一批样本文档里，Markdown 输入的结构保真度高很多，标题、表格、代码块全部保留。HTML 输入内容正确，结构也简化成了文本流。

对 RAG 场景，文本层 PDF 提取到这个程度够用，LLM 吃的是文本，不是版面。你要表格结构还原、版面分析，那还不是 xberg 现在的强项。

和 Python 系三件套比

下面这张表，xberg 一侧是我的实测，Python 系三件套是公开资料，官方 benchmark 单独标注。六行六列，先看整体再逐列说

维度	xberg 1.0.14	Docling	Unstructured	MinerU
安装与依赖体积	单二进制约 28MB（实测）	pip 安装，torch 级依赖，几百 MB	pip 安装，torch 和 tesseract 等	pip 安装，torch 和 PaddleOCR 等
解析质量（文本层 PDF）	内容完整，结构打平（实测）	版面分析强，输出 Markdown 和 JSON	分区提取，元素级输出	版面还原强，公式表格识别好
性能与速度	0.302s 提取 5 页论文（实测）	官方宣称领先，自报数据打折扣看	官方宣称领先，自报数据打折扣看	官方宣称领先，自报数据打折扣看
中文支持	中文文本提取正确（实测），OCR 依赖后端	中文 OCR 可用	中文支持一般	中文 OCR 强（PaddleOCR）
接入方式	库、CLI、REST、MCP	库、CLI、REST	库、CLI、API	库、CLI
许可证与商业背景	MIT，xberg-io 有 Enterprise SDK	MIT（IBM）	Apache 2.0，有商业版	Apache 2.0

每个维度单独说。

安装与依赖体积。xberg 是 Rust crate，编译完一个二进制。Python 系三件套动辄 torch 级依赖，几百 MB 起步，还要管 Python 环境和版本兼容。这是 xberg 最大的实际优势。

解析质量。xberg 对文本层 PDF 的内容提取没得说，表格和版面还原目前是短板，这是我实测出来的。Docling 和 MinerU 的版面分析是它们的老本行，输出结构化程度更高。

性能。我自测 0.302 秒一篇 5 页论文，没有三方案同机对比。三家官方都宣称自己最快，这种自报数据我一律打折扣看，你也一样。

中文。我的中文样本文档提取全部正确。OCR 的中文识别质量取决于后端，PaddleOCR 系在这一块有积累。

接入方式。只有 xberg 同时提供 MCP server，对 Agent 集成是实打实省事。

许可证。xberg 是 MIT，背后是商业公司 xberg-io，提供 Enterprise SDK，开源是获客入口。Docling 是 IBM 的，Unstructured 有商业版，MinerU 是 Apache 2.0。选型时把开源可用和长期依赖分开评估。

商业背景，说人话

xberg-io 提供 Enterprise SDK，仓库是 MIT。这件事带来两个直接后果。社区版免费可用，但 roadmap 大概率服务于商业目标，核心格式的解析质量会优先保，冷门格式的维护优先级要你自己盯。任何商业开源项目都这样，不用当成黑点，只是评估时要独立，解析质量和许可证风险分开算，别因为 MIT 就默认纯社区驱动，也别因为商业公司就一票否决。

什么场景用谁

用 xberg 的场景有四类。Rust 项目，因为和你的技术栈同构，不引入第二门运行时。想省 Python 运行时，省去专门维护一个 Python 服务。要 MCP 接入，因为 Agent 直接调，省掉中间层。性能敏感，因为原生编译产物，启动和吞吐都有优势。

留 Python 系的场景有三类。全 Python 团队，别为解析器引入 Rust 工具链。要深度学习文档理解，提取之外还要版面、语义结构。要 Docling 级别的版面分析精度，xberg 现在给不了。

中文 OCR 深度定制也算一类，Python 系后端选择更多，这个看需求再定。

总结

这一期把 Rust 生态有没有能打的文档解析这个问题的答案给出来了。xberg 能用，它占的是 Rust 原生、文本提取、Agent 集成这个位置，表格结构还原和版面分析还差一截，OCR 依赖链要自己评估。

下一期我用 xberg 搭一条完整的 PDF→Markdown→Embedding 的 RAG 管线，把提取、清洗、分块、检索跑通。