MinerU 多语言OCR完整指南：12个语言组覆盖60+种文字的识别路径-平芜编程栈

MinerU 多语言OCR完整指南：12个语言组覆盖60+种文字的识别路径

【免费下载链接】MinerUTransforms complex documents like PDFs and Office docs into LLM-ready markdown/JSON for your Agentic workflows.项目地址: https://gitcode.com/GitHub_Trending/mi/MinerU

一批扫描版 PDF 里混着俄文、阿拉伯文、泰文时，你过去的做法大概率是：拿默认中文 OCR 模型先跑一遍，结果错字连片，再按语种换工具、逐页重跑。MinerU 的多语言OCR能力就是解决这个断点的：它把 PP-OCR 系列的语言识别模型接进了文档解析管线，你只需要在解析时指定一个语言组，识别结果就能直接进入结构化输出，不用再为每种文字单独搭流程。

MinerU 3.4.4 版本里，这条能力集中在--lang参数背后：12 个可选语言组，合计覆盖60+ 种语言文字，且除个别语种外共用同一个文本检测模型，换语言组不用重新下载检测权重。

📋 能力盘点：12个语言组各管什么

MinerU 的--lang参数接受 12 个取值，每个取值对应一组「检测模型 + 识别模型 + 字符字典」的组合：

语言组	覆盖语言	识别模型	字典
`ch`（默认）	中文、英文、日文、繁体中文、拉丁语系	ch_PP-OCRv6_small_rec	ppocrv6_dict.txt
`ch_server`	同`ch`（medium 模型，精度更高）	ch_PP-OCRv6_medium_rec	ppocrv6_dict.txt
`korean`	韩文、英文	korean_PP-OCRv5_rec	ppocrv5_korean_dict.txt
`ta`	泰米尔文、英文	ta_PP-OCRv5_rec	ppocrv5_ta_dict.txt
`te`	泰卢固文、英文	te_PP-OCRv5_rec	ppocrv5_te_dict.txt
`ka`	卡纳达文	ka_PP-OCRv3_rec	ka_dict.txt
`th`	泰文、英文	th_PP-OCRv5_rec	ppocrv5_th_dict.txt
`el`	希腊文、英文	el_PP-OCRv5_rec	ppocrv5_el_dict.txt
`arabic`	阿拉伯文、波斯文、维吾尔文、乌尔都文、普什图文、库尔德文、信德文、俾路支文、英文	arabic_PP-OCRv5_rec	ppocrv5_arabic_dict.txt
`east_slavic`	俄文、白俄文、乌克兰文、英文	eslav_PP-OCRv5_rec	ppocrv5_eslav_dict.txt
`cyrillic`	西里尔文字体系 30+ 种：俄文、哈萨克文、蒙古文、鞑靼文、巴什基尔文等	cyrillic_PP-OCRv5_rec	ppocrv5_cyrillic_dict.txt
`devanagari`	天城文字体系 13+ 种：印地文、马拉地文、尼泊尔文、梵文等	devanagari_PP-OCRv5_rec	ppocrv5_devanagari_dict.txt

两个值得注意的点：第一，cyrillic和devanagari是「文字体系级」分组，一个参数覆盖几十种语言，代价是对单一语言的针对性不如east_slavic这类「语种级」分组；第二，绝大多数语言组共用ch_PP-OCRv6_small_det这个统一的检测模型，只有ka仍走 v3 世代的多语言检测模型。

🔍 原理速览：检测和识别如何分工

多语言识别的核心思路是「检测与识别解耦」：

检测负责「框出哪里有字」，识别负责「读出字是什么」，换语言组只动识别侧，检测模型基本不动。
语言参数支持别名自动归一：ru会映射到east_slavic，hi映射到devanagari，en、japan、latin统一归到ch组。
--lang仅对pipeline 后端生效，其他后端不受该参数影响。

🚀 上手路径：从安装到拿到多语言结果

第 1 步：安装 MinerU

# 安装 MinerU 及全部解析依赖 uv pip install -U "mineru[all]"

第 2 步：指定语言组解析文档

# 用阿拉伯语组解析 PDF，指定 pipeline 后端，结果输出到 output/ mineru -p doc.pdf -o output --backend pipeline -l arabic

首次运行会自动下载所需模型权重；国内网络可用环境变量MINERU_MODEL_SOURCE=modelscope切换模型源。解析完成后，output/目录下会生成 Markdown、content list JSON 和图片文件。

第 3 步：验证结果

打开生成的.md文件，重点抽查非拉丁文字段落和数字、标点。若个别语种效果不佳，再回到语言组选择上调整（见下文取舍部分）。

⚙️ 关键参数：真正影响识别效果的 4 个选项

参数	作用	建议值
`-l / --lang`	决定加载哪个识别模型和字典，直接决定识别精度	默认`ch`；确认文档语种后显式指定
`ch`vs`ch_server`	覆盖语言相同，`ch_server`用 medium 模型，精度更高但更慢	GPU 环境且对精度敏感时用`ch_server`
`-b / --backend`	解析后端；`--lang`只在`pipeline`下生效	多语言OCR场景用`pipeline`
`-m / --method`	`auto`会优先利用 PDF 自带文字层，`ocr`强制走 OCR	扫描版/图片文档显式用`ocr`

⚖️ 边界与取舍：什么场景好用，什么场景别用

单语种或主语种明确的文档是多语言OCR效果最好的场景：显式指定语言组后，识别模型和字典聚焦在该文字体系上，比让默认模型「猜」要稳定得多。而中英混排的文档其实不用额外配置——默认的ch组本身就覆盖中文、英文、日文、繁体和拉丁语系。

反过来的取舍也要心里有数。俄文文档用east_slavic比用覆盖面更广的cyrillic更准；阿拉伯语系 8 种语言共享一个模型组，其中弱势语种（如俾路支文）的识别率会明显低于阿拉伯文本身。含大量复杂公式或跨页表格的扫描件，pipeline 后端的整体质量不如 hybrid / VLM 后端，而这两个后端又不接受--lang参数——这是目前要接受的权衡。另外，ka（卡纳达文）仍是 v3 世代的模型，同组里其他语言已升级到 v5，遇到该语种可以预期效果相对弱一档。最后，如果你的 PDF 本身带文字层（非扫描件），直接走auto方法利用文字层即可，完全不需要经过 OCR。