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 把 PDF 和 Office 文档解析成大模型能直接读的结构化 Markdown 和 JSON。它的 OCR 引擎提供 12 个语言选项覆盖中文、西里尔文、天城文、阿拉伯文等语系。这篇文章讲清一件事--lang参数到底怎么选以及选错时会发生什么。先跑起来一份多语言文档变成什么先不谈原理看结果。装好之后跑一条命令git clone https://gitcode.com/GitHub_Trending/mi/MinerU cd MinerU pip install -e . mineru -p demo/pdfs/demo1.pdf -o output/解析完成后output/下按文件名建目录核心产物有两个full.md完整 Markdown 正文和content_list.json按块切分的结构化列表每块带类型和位置。文本、标题、表格、公式在 Markdown 里各归其位图片单独导出。目录结构细节可以查 docs/zh/reference/output_files.md。布局检测是整个流程的地基模型先把页面上的每个文本块、表格、公式框出来再逐块送去识别。下面是识别效果示例对 OCR 路径扫描件或强制-m ocr语言参数就是在这里生效的它决定用哪个识别模型去读框出来的文字。12个语言选项按文字体系选不是按国家选理解 MinerU 多语言 OCR 的关键点只有一个识别模型按文字体系划分而不是按语言一一对应。12 个选项里有 11 个是模型 key每个 key 背后挂一个识别模型各自负责一族文字。以cyrillic为例一个模型同时覆盖俄语、乌克兰语、保加利亚语、蒙古文等 30 多种西里尔文字语言。完整的选项与覆盖范围来自代码 mineru/utils/ocr_language.py逐字如下选项覆盖语言常见用途ch默认中文、英文、日文、繁体中文、拉丁文绝大多数中文文档中英混排直接用它ch_server同ch服务器级模型显存充足时精度更高korean韩文、英文韩文文档el希腊文、英文希腊语文档th泰文、英文泰语文档ta泰米尔文、英文印度泰米尔语文档te泰卢固文、英文印度泰卢固语文档ka卡纳达文印度卡纳达语文档arabic阿拉伯文、波斯文、维吾尔文、乌尔都文、普什图文、库尔德文、信德文、بلوچی文、英文阿拉伯语系文档east_slavic俄文、白俄文、乌克兰文、英文东斯拉夫三国文档cyrillic俄文、乌克兰文、塞尔维亚文西里尔、保加利亚文、蒙古文、哈萨克文等 30 多种西里尔文字俄语区之外的西里尔语系devanagari印地文、马拉地文、尼泊尔文、僧伽罗文、天城文等 14 种印度北语文档另外代码里有一层别名归一传en、japan、chinese_cht、latin都会被静重定向到ch模型传ru、be、uk会归到east_slavicar、fa、ur等归到arabic。也就是说这些短码不是独立模型只是别名。列表外的值比如fr则直接报错错误信息里会附全部合法值照着改就行。这里要诚实说明一点MinerU 没有自动识别语言的选项不存在langauto。选哪个选项是你的责任代码只负责校验和归一。怎么传语言参数命令行和 Python API命令行入口是mineru语言参数写作-l。注意帮助信息里那句仅用于 pipeline 后端这条后面会再踩一次坑mineru -p report_ru.pdf -o output/ \ -b pipeline \ -l cyrillic \ -m ocr四个参数各管一事-b pipeline指定走 OCR 流水线后端-l cyrillic指定西里尔文识别模型-m ocr强制走 OCR默认auto会优先抽文本层纯扫描件抽不到字时就靠它兜底。完整参数表在 docs/zh/usage/cli_tools.md。如果你在代码里集成 MinerU语言参数通过 API 表单传入仓库自带的 demo/demo.py 就是这个模式的完整示例核心几行from mineru.cli import api_client as ac form_data ac.build_parse_request_form_data( lang_list[cyrillic], # 仅对 pipeline 后端生效 backendpipeline, parse_methodauto, return_mdTrue, return_imagesTrue, response_format_zipTrue, )场景对选项一张表查完你的文档情况该怎么配中文、英文、中日英混排不传-l默认ch就是最优解韩文为主-l korean俄语、白俄语、乌克兰语-l east_slavic其他西里尔文保加利亚、蒙古、哈萨克等-l cyrillic覆盖面比east_slavic大得多阿拉伯文、波斯文、乌尔都文-l arabic印地文、尼泊尔文等天城文-l devanagari希腊文 / 泰文 / 泰米尔文 / 泰卢固文 / 卡纳达文分别-l el/th/ta/te/ka中文文档、GPU 显存充足、追求更高精度-l ch_server扫描版、无文本层的 PDF在上面配置基础上加-m ocr两个补充判断一是ch_server和ch覆盖语言完全相同区别只在模型档位没有 GPU 就别碰它二是语言选项只在pipeline后端有意义vlm-engine、hybrid-engine这类视觉模型后端不读这个参数写了等于没写。踩过的坑三个语言配置的真实问题第一个坑最隐蔽语言参数被静默忽略。mineru的默认后端是hybrid-engine而 demo 脚本源码注释里写得很直白——hybrid 和 VLM 后端忽略该语言值。于是有人对着俄文扫描件反复换语言码、重跑输出纹丝不动。解法只有一个把-b pipeline加上。排查时先看输出目录名后端名就写在路径里确认自己到底跑的是哪个后端。第二个坑是别名带来的误判。有人传-l en处理纯英文文档没报错但识别行为和中英文混排完全一样——因为en只是ch模型的别名并不存在独立的英文模型。反过来传一个真不在表里的值如fr会得到一个ValueError消息里列出全部 12 个合法值。所以遇到效果不对但没报错先查别名表遇到报错了错误信息本身就是配置清单照着抄即可。第三个坑是多语言混排文档。由于没有自动语言检测一份正文是俄语、引用里夹了法文的文档你只能选覆盖主语的选项——法文文字会走西里尔文模型的识别路径效果必然打折。实践口径是按正文主体语言选模型混排部分容忍降级。如果混排的两种语言恰好都在ch的覆盖集内中、英、日默认配置就是最优解不用动。执行前照做清单非中日英文档先在上面对照表里找到覆盖该文字体系的选项再动手凡是用了-l同一命令里必须带-b pipeline否则参数不生效拿不准语言体系时先跑一次默认配置翻full.md看是否大面积乱码再换选项重跑成本比猜测低扫描件加-m ocr有文本层的文档保持默认auto即可结果验证看两个文件full.md通读查乱码content_list.json抽查关键表格和公式块的结构是否完整。【免费下载链接】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），仅供参考