MinerU 多语言 OCR 实战指南:12 个语言参数完整对照
【免费下载链接】MinerUTransforms complex documents like PDFs and Office docs into LLM-ready markdown/JSON for your Agentic workflows.项目地址: https://gitcode.com/GitHub_Trending/mi/MinerU
MinerU 的多语言 OCR 靠 CLI 的-l语言参数实现:指定文档所属语言,pipeline 就会切换到对应的识别模型与字典。非中英语种的扫描件默认参数下容易识别错乱,指定语言后输出仍是带图片的结构化 markdown。
快速上手:三条命令解析一份阿拉伯语文档
先安装并确认模型源可达(国内网络切到 ModelScope):
pip install MinerU export MINERU_MODEL_SOURCE=modelscope # 仅国内网络需要然后默认语言跑一遍,再指定语言对比:
# -l 缺省为 ch,覆盖中文/英文/日文/繁体/拉丁 mineru -p your.pdf -o output/ -b pipeline # 阿拉伯语系文档,只多一个参数 mineru -p your.pdf -o output/ -b pipeline -l arabic两点说明:-l只对pipeline后端生效,默认的hybrid-engine或vlm-engine会忽略它;该参数没有"自动检测"取值,不传时按ch处理。
工作原理:-l 参数走到哪一步
语言参数的链路很短,从参数入口到模型选择一条直线:
- 12 个公开语言值与别名定义在 mineru/utils/ocr_language.py:
en、japan、ru、ar等别名会先归一到基础值再进模型,未知取值直接抛ValueError。 - 语言参数只决定"识别模型 + 字典"的选型,文本检测环节是共用的;识别侧底座来自 PaddleOCR 系列模型。
- hybrid 与 vlm 后端不读取该参数,所以"换语言没变化"通常不是语言的问题,是后端选错了。
能力全景:哪份文档该用哪个 -l
12 个取值按文字体系分组。统一输出:输出目录下按文件生成 markdown、裁剪图片与中间 JSON。
| 解析场景 | -l 输入 | 可识别范围 | 备注 |
|---|---|---|---|
| 中/英/日/繁混排 | ch(默认) | 中文、英文、日文、繁体中文、拉丁 | ch_server为中文模型的服务端变体 |
| 韩文 | korean | 韩文、英文 | |
| 泰文 | th | 泰文、英文 | |
| 希腊文 | el | 希腊文、英文 | |
| 阿拉伯语系 | arabic | 阿拉伯、波斯、维吾尔、乌尔都、普什图、库尔德、信德、平衡奇、英文 | 8 种文字共用一个模型 |
| 东斯拉夫 | east_slavic | 俄、白俄、乌克兰、英文 | |
| 西里尔(宽) | cyrillic | 俄、保加利亚、蒙古、哈萨克等 34 种 | 覆盖东斯拉夫三语之外的西里尔文字 |
| 天城文 | devanagari | 印地、马拉地、尼泊尔等 14 种 | |
| 南亚单语 | ta/te/ka | 泰米尔 / 泰卢固 / 卡纳达 | ka不含英文 |
实战场景:两类日常工作
批量解析俄文合同
mineru -p contracts/ -o output/ -b pipeline -l east_slavic目录输入受支持:contracts/下每个 PDF 各自生成一个子目录,markdown 文件名与原文件对应。预期效果:俄文正文完整,西里尔字母与数字混排(如 "1 200 000 руб.")不丢字;若合同含较多保加利亚语内容,改用cyrillic。
阿拉伯语手册走 API 提交
curl -X POST http://127.0.0.1:8000/file_parse \ -F "files=@manual.pdf" \ -F "backend=pipeline" \ -F "lang_list=arabic" \ -F "return_md=true"lang_list表单字段与 CLI 的-l对应;列表长度小于文件数时,首值会复用到剩余文件。接口同步返回解析结果,markdown 直接在响应里取出。
参数调优与避坑:5 条自查项
- 现象:加了 -l 没有任何变化。原因:后端不是
pipeline(默认hybrid-engine会忽略该参数)。解法:追加-b pipeline。 - 现象:报
Language xxx not supported。原因:取值不在 12 个白名单内,常见误写是fr、de、vi。解法:除希腊文外没有独立的欧洲语言参数,回退到ch,其拉丁范围可覆盖。 - 现象:传
auto报错。原因:该参数没有自动检测取值,缺省就是ch。解法:按文档主导语言手工指定。 - 现象:西里尔文文档识别不全。原因:用了
east_slavic,它只覆盖俄/白俄/乌三语。解法:保加利亚、蒙古、哈萨克等改用cyrillic。 - 现象:模型下载失败。原因:网络到不了默认模型源。解法:
export MINERU_MODEL_SOURCE=modelscope后重跑。
性能与能力口径
MinerU 没有公布多语言 OCR 的官方精度或提速基准,因此不引用具体提升数字。以下数值均直接取自源码:
| 统计项 | 数值 | 口径 |
|---|---|---|
| 公开语言参数数量 | 12 | ocr_language.py 中PUBLIC_OCR_LANGUAGES |
| 单参数最大覆盖 | 34 种语言 | cyrillic描述逐条计数 |
| 默认语言值 | ch | CLI-l的缺省值 |
| 别名映射示例 | en/japan→ ch,ru/be/uk→ east_slavic | normalize_ocr_model_lang |
需要自测精度时,建议每种语系准备 20~50 页测试集,对同页分别在ch与目标语言取值下跑一遍,人工比对识别结果。
延伸阅读
多语言能力收敛在一个参数上:先判断文档文字体系,选对应的-l取值,确认后端为pipeline,识别结果就与输入匹配。
- mineru/utils/ocr_language.py:语言白名单、别名与归一化逻辑的完整实现
- docs/zh/usage/cli_tools.md:CLI 全部参数的官方说明
【免费下载链接】MinerUTransforms complex documents like PDFs and Office docs into LLM-ready markdown/JSON for your Agentic workflows.项目地址: https://gitcode.com/GitHub_Trending/mi/MinerU
创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考