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/MinerUMinerU 的多语言 OCR 靠 CLI 的-l语言参数实现指定文档所属语言pipeline 就会切换到对应的识别模型与字典。非中英语种的扫描件默认参数下容易识别错乱指定语言后输出仍是带图片的结构化 markdown。快速上手三条命令解析一份阿拉伯语文档先安装并确认模型源可达国内网络切到 ModelScopepip install MinerU export MINERU_MODEL_SOURCEmodelscope # 仅国内网络需要然后默认语言跑一遍再指定语言对比# -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.pyen、japan、ru、ar等别名会先归一到基础值再进模型未知取值直接抛ValueError。语言参数只决定识别模型 字典的选型文本检测环节是共用的识别侧底座来自 PaddleOCR 系列模型。hybrid 与 vlm 后端不读取该参数所以换语言没变化通常不是语言的问题是后端选错了。能力全景哪份文档该用哪个 -l12 个取值按文字体系分组。统一输出输出目录下按文件生成 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 filesmanual.pdf \ -F backendpipeline \ -F lang_listarabic \ -F return_mdtruelang_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_SOURCEmodelscope后重跑。性能与能力口径MinerU 没有公布多语言 OCR 的官方精度或提速基准因此不引用具体提升数字。以下数值均直接取自源码统计项数值口径公开语言参数数量12ocr_language.py 中PUBLIC_OCR_LANGUAGES单参数最大覆盖34 种语言cyrillic描述逐条计数默认语言值chCLI-l的缺省值别名映射示例en/japan→ chru/be/uk→ east_slavicnormalize_ocr_model_lang需要自测精度时建议每种语系准备 20~50 页测试集对同页分别在ch与目标语言取值下跑一遍人工比对识别结果。延伸阅读多语言能力收敛在一个参数上先判断文档文字体系选对应的-l取值确认后端为pipeline识别结果就与输入匹配。mineru/utils/ocr_language.py语言白名单、别名与归一化逻辑的完整实现docs/zh/usage/cli_tools.mdCLI 全部参数的官方说明【免费下载链接】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），仅供参考
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/MinerUMinerU 的多语言 OCR 靠 CLI 的-l语言参数实现指定文档所属语言pipeline 就会切换到对应的识别模型与字典。非中英语种的扫描件默认参数下容易识别错乱指定语言后输出仍是带图片的结构化 markdown。快速上手三条命令解析一份阿拉伯语文档先安装并确认模型源可达国内网络切到 ModelScopepip install MinerU export MINERU_MODEL_SOURCEmodelscope # 仅国内网络需要然后默认语言跑一遍再指定语言对比# -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.pyen、japan、ru、ar等别名会先归一到基础值再进模型未知取值直接抛ValueError。语言参数只决定识别模型 字典的选型文本检测环节是共用的识别侧底座来自 PaddleOCR 系列模型。hybrid 与 vlm 后端不读取该参数所以换语言没变化通常不是语言的问题是后端选错了。能力全景哪份文档该用哪个 -l12 个取值按文字体系分组。统一输出输出目录下按文件生成 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 filesmanual.pdf \ -F backendpipeline \ -F lang_listarabic \ -F return_mdtruelang_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_SOURCEmodelscope后重跑。性能与能力口径MinerU 没有公布多语言 OCR 的官方精度或提速基准因此不引用具体提升数字。以下数值均直接取自源码统计项数值口径公开语言参数数量12ocr_language.py 中PUBLIC_OCR_LANGUAGES单参数最大覆盖34 种语言cyrillic描述逐条计数默认语言值chCLI-l的缺省值别名映射示例en/japan→ chru/be/uk→ east_slavicnormalize_ocr_model_lang需要自测精度时建议每种语系准备 20~50 页测试集对同页分别在ch与目标语言取值下跑一遍人工比对识别结果。延伸阅读多语言能力收敛在一个参数上先判断文档文字体系选对应的-l取值确认后端为pipeline识别结果就与输入匹配。mineru/utils/ocr_language.py语言白名单、别名与归一化逻辑的完整实现docs/zh/usage/cli_tools.mdCLI 全部参数的官方说明【免费下载链接】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），仅供参考
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
