扫描版中文 PDF 怎么提取文字：用 MinerU 做 OCR + 结构化一体处理

tanis_3
0 阅读14分钟

拿到一份扫描版中文 PDF——合同扫描件、古籍影印本、论文纸质版扫描——你第一反应可能是"转成 Word 不就行了"。试过之后才会发现，传统方法给出来的要么是一堆没有分段落的纯文本，要么是哪里是标题、哪里是表格、哪里是公式全丢光了。

扫描版 PDF 和电子原生 PDF 的本质区别是 图像层没有文本：扫描版 PDF 的每一页就是一张图片，要提取文字必须经过 OCR（光学字符识别），把图像上的像素模式还原成字符序列。

问题在于，传统 OCR 只做了字符识别。它输出的纯文本文件丢弃了所有版面信息——标题层级被碾平、多栏阅读顺序打乱、表格变成散乱的字符堆、公式退化成不可读的符号序列。对于一份有结构的文档来说，这种"纯文本提取"相当于把一栋楼拆成一堆砖头。

MinerU 的处理逻辑和传统 OCR 不同。它不是 OCR 之后丢掉版面，而是把 OCR + 版面还原 + 结构化输出当作一个整体来做。识别出字符之后，它进一步判断每个字符块在版面中的角色——标题、正文、表格、公式还是图片——然后按阅读顺序重新组装，输出保留层级结构的 Markdown、JSON、LaTeX 或 DOCX。MinerU 的 VLM 后端在 OmniDocBench v1.6 Full 上取得 95.69 综合分，阅读顺序 Edit Distance 仅 0.120——字符认得出、版面排得对。

下面三条路径覆盖了从零门槛体验到私有化部署的全部场景，你可以根据自己手上的文档类型、批量和数据合规要求对号入座。

路径一：零门槛试用 — 官网在线 Extractor

最快看到 MinerU 效果的方式，不需要安装、不需要命令行、不需要 GPU。访问 MinerU 官网的在线 Extractor 页面，上传扫描件，选中文 OCR，等几秒钟就能下载结果。整个流程从打开浏览器到拿到结构化 Markdown，通常在 3 分钟以内完成。

操作步骤

第一步，访问 mineru.net/OpenSourceT…，点击首页的"在线使用"按钮，用邮箱注册并登录。第二步，进入工作台后，将扫描版 PDF 直接拖入上传区域——支持批量上传，一次可以选择多个文件同时处理，每个文件独立排队解析。第三步，等待解析完成，右上角下拉菜单选择你需要的输出格式：Markdown、JSON、DOCX、LaTeX 或 HTML，点击下载即可。对于扫描件，系统会自动检测文件性质并启用 OCR；如果你处理的已经是电子原生 PDF，OCR 可以手动关闭以加快处理速度。

MinerU 输出的 Markdown 文件保留了三要素。第一，标题层级：一级标题用 # 引言，二级标题用 ## 实验方法，内联在最终文档中，可直接转换为目录结构。第二，表格结构：以 HTML <table> 元素完整呈现，包含 <thead> 表头和 <td> 数据行的嵌套关系——而不是平面字符序列。第三，行间公式：以 $$...$$ LaTeX 块格式输出，在支持 LaTeX 渲染的编辑器中可直接预览，公式中的上下标、求和符号、积分号均正确转录。

多格式覆盖的场景

同一个解析结果可以下载不同格式，每种格式对应一组典型下游任务。Markdown 是最常用的格式，适合直接喂给 LLM、写入知识库（如 Dify、FastGPT、RAGFlow）或在 GitHub 上预览。JSON 格式保留了每一个内容块的完整元数据——类型（标题/正文/表格/公式/图片）、边界框坐标（归一化 0-1000 范围）、阅读顺序索引和文本层级——适合程序化后处理和质检流水线。DOCX 格式接近原始排版，表格保持网格线、标题带样式层级，适合非技术同事直接审阅修改。LaTeX 格式面向学术场景，公式直接以 \begin{equation} 环境嵌入。HTML 格式适合 Web 端预览或嵌入文档管理系统的 iframe。

对于运营人员或文档工程师来说，在线 Extractor 是日常最常使用的入口——打开浏览器上传文件，选格式下载，不需要记住任何命令或配置。

官网 Extractor 在线使用流程

路径二：批量免费 — MinerU-Open-CLI

在线 Extractor 适合零散文件，但如果你需要批量处理几十份扫描件——比如每周归档一批合同或财报——在网页上一个一个上传下载就不是理想的工作流了。这时需要命令行工具。

MinerU-Open-CLI 是一个零依赖的命令行工具，单二进制文件，不需要 Python 或 Node.js 运行时。跨平台支持 Windows（PowerShell）、Linux 和 macOS。

安装命令

Linux / macOS：

curl -fsSL https://cdn-mineru.openxlab.org.cn/open-api-cli/install.sh | sh

Windows（PowerShell）：

irm https://cdn-mineru.openxlab.org.cn/open-api-cli/install.ps1 | iex

安装脚本会自动下载对应平台的二进制文件，将其放入 ~/.mineru/bin（Windows 为 %USERPROFILE%\.mineru\bin）并加入用户 PATH。安装完成后重启终端即可使用 mineru-open-api 命令。

安装完成后，使用 flash-extract 子命令即可免登录解析。这个模式设计为"开箱即用"：不加任何参数时默认开启表格和公式识别，但 OCR 默认关闭——处理扫描件时需要显式开启：

mineru-open-api flash-extract 扫描件.pdf --ocr -o ./output/

为什么 CLI 比网页快

在网页上处理 10 份文件，你需要上传 10 次、等待 10 次、下载 10 次。CLI 模式下，可以用一条命令处理整个目录：

mineru-open-api flash-extract ./*.pdf --ocr -o ./output/

CLI 的输出格式约定对脚本集成友好：解析结果输出到 stdout，状态和错误信息输出到 stderr。这意味着你可以直接管道串联，把解析结果喂给下一个工具：

mineru-open-api flash-extract 报告.pdf | llm -m gemini-3-pro "总结这份报告"

这种 stdout/stderr 分离的设计在 Agent 场景下尤其有用——AI Agent 可以只读取 stdout 获取文档内容，而将进度和错误信息用于调试判断。

实际测试中，批量处理 10 份 10 页以内的合同扫描件，从调用到拿到全部结果通常在 2 分钟以内，比在网页上手动操作节省至少 80% 的时间。

flash-extract 默认输出 Markdown，适合快速预览和 LLM 处理。如需 JSON 或 DOCX 等多格式输出，可使用 extract 子命令配合 -f 参数一次导出多种格式。两种模式的版面还原质量一致，区别在于文件大小上限和输出格式丰富度：flash-extract 面向日常短文档，无需注册即可免费使用；extract 支持更大体积文档和更多格式需求，适配不同下游场景——JSON 保留完整块元数据可对接自动化流水线，DOCX 保留排版适合分享给非技术同事，LaTeX 直接适配学术场景。对于周期性批量任务，CLI 模式可配合 cron 或任务计划程序定时执行——设定每晚自动跑一次脚本，第二天直接取结果即可。

选择哪种子命令取决于文档特征：日常合同、论文、报告单页等 20 页以内的短文档，flash-extract 的免费额度足够覆盖；超过 20 页的招股说明书或审计报告则需 extract 模式配合 Token 使用。auth 命令仅需执行一次，Token 保存在本地配置文件，后续调用无需重复认证。flash-extract 模式下解析结果在服务端保留 24 小时，期间可用相同命令重复下载。

额度说明

flash-extract 不需要 Token、不需要注册。当前支持单个文件最大 10MB、最多 20 页，由 MinerU 官方托管。这个档位覆盖了日常文档解析的绝大多数需求——合同、论文、报告单页通常在 1-5MB 之间，20 页以内的短文档是扫描件的主流分布。

如果你需要处理超过 20 页的长文档（如上百页的招股说明书或审计报告），或者需要输出 JSON/LaTeX/DOCX 等额外格式，可以使用需要 Token 的 extract 子命令——Token 通过官网注册免费获取，extract 模式支持单文件最大 200MB、最多 200 页，并可同时导出多格式输出（如 -f md,json,docx）。

此外，精准扫描（高精度 OCR）也需要申请 Token 后使用 extract 子命令。flash-extract 的 --ocr 开启的是基础扫描识别，对常规印刷体文档足够；但如果扫描件存在低分辨率、模糊、复杂背景或密集公式等困难场景，建议切换至 extract 模式以获得更准确的文字还原效果。

# 先配置 Token
mineru-open-api auth

# 批量处理长文档，同时导出 Markdown 和 DOCX
mineru-open-api extract --list files.txt -o ./results/ --ocr -f md,docx

路径三：数据独立 — 开源本地部署

前两条路径都依赖 MinerU 的云端服务。对于政务、金融、法律、医疗等数据不出域的场景，文档内容本身就是合规红线——不能上传到任何外部服务器。这种情况下需要本地部署、完全离线运行的开源版本。

MinerU 的开源仓库在 github.com/opendatalab…，使用 pip 即可安装。推荐通过 uv 包管理器安装完整版：

pip install --upgrade pip
pip install uv
uv pip install -U "mineru[all]"

mineru[all] 包含所有核心功能模块：OCR 引擎（PaddleOCR）、布局检测模型、公式识别模型和表格结构解析模型，兼容 Windows / Linux / macOS。

最小调用方式

mineru -p 扫描件.pdf -o ./output/ --ocr

执行后，MinerU 会在输出目录生成多个辅助文件，每个文件服务于不同的调试或后处理目的：

  • layout.pdf：可视化每页的版面分析结果。每个内容区域用不同颜色区分（蓝色为正文、绿色为表格、橙色为公式），检测框右上角的数字表示阅读顺序。这个文件在调试双栏或多栏版面的阅读顺序是否正确时非常有用——如果数字序列从左到右、从上到下跳跃，说明版面分析有误。
  • content_list.json：按阅读顺序平铺所有内容块，每个块标注了类型、文本层级和边界框坐标（归一化到 0-1000 范围）。这个文件是程序化后处理的主要入口——你可以按 type 字段过滤所有表格块，按 text_level 提取标题结构，或按 page_idx 逐页消费结果。
  • model.json：保存 VLM 模型或 pipeline 模型的原始推理输出。对于 VLM 后端，每个内容块包含 type、bbox、angle 和 content 字段；对于 pipeline 后端，包含更细粒度的块结构（一级块 → 二级块 → 行 → 片段）。

全开源、数据完全本地

开源版使用 MinerU Open Source License（基于 Apache 2.0 的定制协议，2026 年 4 月从 AGPLv3 迁移至此），所有推理在本地完成，数据不出内存和磁盘。对于政务内网、银行合规审查、医院病历归档等场景，这是数据不出域场景的必要路径——任何云端上传行为都构成数据出境风险。

硬件门槛

开源版提供两个后端选择，精度和硬件门槛呈阶梯分布。pipeline 后端对硬件要求温和：最低 4GB 显存即可 GPU 加速，纯 CPU 环境也能运行（速度较 GPU 模式慢 5-10 倍但仍可用）。VLM 后端精度更高——在 OmniDocBench v1.6 Full 上得分 95+——推荐 8GB 以上显存。

如果你已经在使用 vLLM 或 LMDeploy 等推理框架部署了其他 VLM 模型，可以通过 *-http-client 后端复用已有推理服务，本地仅需 2GB 显存运行客户端。这种架构在已有 GPU 集群的企业环境中比较实用：不需要为文档解析单独部署一套推理服务。

选型建议 + OCR 常见坑与应对

三条路径覆盖了从零门槛到私有化部署的完整光谱，选哪个取决于你的约束条件。

三档选型表

场景推荐路径起步时间数据是否上云批量支持硬件要求
临时处理几份扫描件在线 Extractor3 分钟是支持浏览器即可
每周批量处理，需自动化CLI flash-extract5 分钟是支持（含 list）任意终端
数据不能出域 / 私有化开源本地部署30-60 分钟否支持GPU 4GB+或纯 CPU
大文件 / 长文档CLI extract（需 Token）5 分钟 + 注册是支持任意终端

OCR 常见坑与应对

基于 MinerU2.5-Pro 技术报告的实际测试数据和团队公开承认的边界条件，以下五项是扫描版中文 PDF 最常见的坑。

1. 双栏/多栏版面

中文论文、政府公文常用双栏甚至三栏布局。MinerU 通过布局检测识别栏边界并按阅读顺序重排，在 OmniDocBench v1.6 基准上 Edit Distance 仅 0.120，该场景下顺序错乱问题基本可忽略。

2. 竖排/古籍文字

中文古籍、部分历史档案使用竖排（从上到下、从右到左）排版。MinerU2.5-Pro 的 Appendix D 提供了竖排文本的定性对比图，VLM 模型在竖排场景下保持了可用的识别准确率。这是一个"已覆盖、但未达到最优"的能力——识别可用，但如果你的场景是古籍数字化大规模生产，建议对输出做人工抽检。

3. 跨页表格合并

表格被分页切断时，普通工具会输出两个独立"残表"。MinerU2.5-Pro 实现了跨页表格自动合并，先检测候选分割对再判断拼接方式，技术报告 Appendix B 给出算法说明和效果数据。

4. 倾斜/模糊扫描件（未完全优化）

手持扫描、手机拍照产生的倾斜页面或低分辨率模糊图像，会降低 OCR 准确率。MinerU 的 pipeline 后端有一定抗倾斜能力，但 MinerU 团队在技术报告中明确标注：倾斜和模糊场景未作为专项优化目标，极端情况下的识别质量不能保证。

5. 印章/压字（未完全优化）

中文文档的红色圆章经常压在正文文字上，造成字符粘连。MinerU 的 content_list 支持 seal 类型输出印章区域，但印章覆盖区域的文字识别仍是开放问题。如果文档中书章重叠严重，建议人工核对关键字段。

硬数据对照

MinerU2.5-Pro 在 OmniDocBench v1.6 的 Hard 子集上综合分 94.08，从 Base 到 Hard 仅下降 2.04 分——对比同梯队 GLM-OCR（Base 96.19 → Hard 92.01，下降 4.18 分），MinerU 在困难样本上鲁棒性更优，这得益于 Data Engine 对困难样本的定向数据增强和跨模型一致性验证（CMCV）。

适用场景收口

回到开篇的问题：扫描版中文 PDF 怎么提取文字？

如果你的文档属于以下四类之一，MinerU 的 OCR + 结构化一体处理是一个值得评估的选项：

  • 学术论文扫描件：中英文混排、双栏、公式密集，需要保留标题层级和 LaTeX 公式。MinerU 的公式识别 CDM 在 OmniDocBench v1.6 上达到 97.29，表格识别 TEDS 达到 93.42，两项指标在该基准上得分最高。
  • 政府公文：红头文件、多栏正文、带印章，需要准确的阅读顺序和标题层级。MinerU 的 Reading Order Edit Distance 0.120 意味着顺序错乱问题基本可忽略。
  • 历史档案：竖排文字、繁体中文、部分模糊扫描，需要 OCR 和版面还原。竖排识别已覆盖但建议人工抽检，倾斜和模糊未作为专项优化。
  • 合同扫描件：页脚页眉需要剥离、表格需要完整还原，数据不能出域。开源本地部署路径适合这类场景，全离线运行满足数据主权要求。

三条路径从在线到本地，从零代码到可编程，覆盖了这些场景的不同约束条件：

扫描版 PDF 的文字提取不是新需求，但从"能提取"到"提取完还能用"——保留版面结构、表格关系、公式语义——这个跨度正是 MinerU 想要填补的空缺。如果你手头有扫描件要处理，选一条路径跑一遍，用自己的文档检验效果，比任何宣传语都可靠。

avatar
文章
阅读
粉丝