Tesseract-OCR中文OCR实战：语言包、参数与置信度分流

简介：Tesseract-OCR 是面向开发者与文档数字化从业者的开源光学字符识别引擎安装资源，解决从图片中批量提取文字、并为中文识别补齐语言数据的问题。压缩包共 724 个文件，约 36.01MB，以 C/C++ 源码与头文件为主体，辅以 Java 接口示例、XML 配置、Shell 脚本、训练数据及少量演示图片和说明文档，既覆盖编译构建所需工程文件，也保留字符集训练、词典与参数配置等环节的原始素材。已有 289 人学习下载。目录保留完整工程结构，便于对照源码理解识别流程、调整语言模型与排查依赖问题，也可直接取用现成组件做快速验证。借助其中的安装向导、库文件与配置脚本，读者可完成 OCR 环境搭建，并调用多语言 API 接入自有程序；中文语言包可显著改善汉字文档的识别效果，适用于票据录入、扫描件归档与自动化文本处理等场景。

1.

上周有人甩给我一份两百多页的扫描版设备手册，PDF 里的字一个都选不中，复制出来全是乱码。这类活儿我一般直接扔给 Tesseract-OCR：一套开源的光学字符识别引擎，配上 chi_sim 中文语言包，就能把图片里的字抠成可编辑文本。它的定位很明确——不是那种点一下按钮就出结果的商业软件，而是一个能被脚本调用、参数可调、可以塞进批量流水线的命令行工具。手上有扫描件、截图、票据、老文档要转文字，又不想为每页付识别费用的人，这个安装包加语言包的组合是绕不开的起点。但也正因为它是个引擎而不是成品软件，装完直接跑，十有八九先给你一屏乱码，然后你开始怀疑是不是下错了包。

2. 识别链路与语言包：traineddata 里到底装了什么

在动手装之前，先把「一张图是怎么变成一行字」这条链路捋清楚，后面调参才不会瞎试。Tesseract 不是黑盒，它的每一步都有对应的可干预点，你改的每个参数其实都作用在链路的某一环上。这一章把链路拆开，顺便说清语言包到底是什么东西——很多人以为它是本词典，其实不是。

2.1 一张图进、一行字出：五步流水线

第一步是图像读取与预处理，由 Leptonica 这个图像处理库完成，包括解码、灰度化、二值化、去噪、旋转校正。第二步是页面版面分析，找出这一页里有几个文本块、每块是横排还是竖排、有没有表格线干扰。第三步是行切分，把文本块切成一行一行。第四步才是真正的识别，把整行图像送进 LSTM 网络做序列解码。第五步是后处理，用词典和字符集对结果做约束修正。

这里有个关键差异值得说清楚。Tesseract 3.x 时代靠连通域分析逐字切割，中文一旦出现粘连、断笔，切分就崩，崩了后面全错。4.x 之后改成 LSTM 整行识别，不再强依赖单字切割，对粘连和轻微倾斜的耐受度好了很多。这也解释了一个常见困惑：为什么网上老教程里那些「切字」技巧在新版本上基本没用，因为引擎换了一代。所以下载安装包时第一步要看版本号，4.x 和 5.x 的经验可以互通，3.x 的教程直接跳过。

链路清楚之后，干预点也就明确了：预处理决定输入质量，--psm影响版面分析和行切分，--oem决定用哪套引擎，-l决定加载哪个模型。识别率上不去，八成是这四环里的某一环出了问题，而不是引擎本身不行。

2.2 语言包是模型文件，不是词典

.traineddata这个后缀容易误导人。它内部打包了四类东西：LSTM 网络权重、字符集定义（unicharset）、词典（word dawg）、数字与标点规则（number dawg、punc dawg）。也就是说，中文语言包里既有「这个字形长什么样」的视觉模型，也有「哪些字组合起来才像词」的语言约束，两者是一起加载的。这就是为什么换了语言包，同一个 engines 的识别结果风格会明显不同。

体积上能看出区别：eng.traineddata只有几 MB，chi_sim.traineddata通常几十 MB，因为汉字字符集规模摆在那里。官方分发的训练数据一般有三档：fast 版体积小、速度快、精度略低；standard 版是默认折中；best 版体积最大、精度最高但明显慢。做批量离线处理、追求吞吐，我一般用 fast 或 standard；做票据、证照这类不能错的场景，才上 best。

osd.traineddata是另一个容易被忽略的文件，它只负责方向和文字脚本检测，配合--psm 0使用。扫描件如果有一半是倒着扫的，没有这个文件就会直接报错退出。

还有一个常被问到的组合问题：中英混排该用-l chi_sim+eng还是只用chi_sim。我的经验是混排场景加上eng更稳，尤其是文档里有大量英文缩写、型号、数字的时候，eng的词典约束能救回不少被中文模型认错的拉丁字符。但语言不是加得越多越好，一次加载五六种语言，速度会掉得很明显，而且小语种模型的误判会污染主语言的输出。

2.3 装完先跑三条命令

装完别急着识别正文，先跑三条命令确认环境。这三条能把九成的安装问题挡在门外。

# 1. 确认引擎版本与依赖库版本 tesseract --version # 2. 列出当前可加载的全部语言 tesseract --list-langs # 3. 看关键参数是否齐全（输出较长，取前 20 行） tesseract --print-parameters | head -n 20

第一条输出里要关注两件事：Tesseract 主版本号，以及 Leptonica 版本。主版本决定你能用哪些参数，--oem的可选值在不同版本上行为不一样。第二条是最直接的判据——输出列表里没有chi_sim，说明语言包根本没被找到，后面所有识别都会退化成英文模型硬认，结果就是一堆莫名其妙的拉丁字母。第三条用来确认配置项没被裁剪，某些精简打包的版本会删掉部分参数。

三条都过了，再跑一个最小识别测试：

# stdout 表示结果直接打印到终端，不写文件 # --psm 6 假定整张图是一块连续的文本 tesseract test.png stdout -l chi_sim --psm 6

test.png自己截一张，最好是白底黑字、字号正常、横向排版的一小段中文，别拿手机拍的斜角照片当第一张测试图，那属于给自己加难度。这一步能出正常中文，说明链路是通的，剩下的都是调优问题。

3. 安装与中文语言包落地：把 TESSDATA_PREFIX 一次配对

装 Tesseract 本身不难，难的是语言包放对位置。几乎每个新手都会卡在「语言包明明下载了，--list-langs里就是没有」这一步，根因基本都出在数据目录的查找逻辑上。这一章把两条主流安装路线和路径规则讲透。

3.1 Windows 安装包路线

Windows 上用官方提供的 exe 安装包最省事。安装向导里有一个组件选择页，展开后能看到 Additional language data 一栏，里面可以勾选语言。这里有两个细节：一是默认只装eng和osd，中文必须手动勾；二是部分版本的安装器只提供chi_sim，繁体chi_tra和竖排chi_sim_vert需要事后手动补文件。

默认安装路径一般是C:\Program Files\Tesseract-OCR，语言包落在其下的tessdata子目录里。装完之后命令行里直接敲tesseract大概率提示找不到命令，因为安装器不会自动改 PATH。

# 当前 PowerShell 会话临时加入 PATH $env:Path += ";C:\Program Files\Tesseract-OCR" # 验证 tesseract --version tesseract --list-langs

这段是临时生效，关掉窗口就没了。要长期生效得去系统环境变量里加，或者干脆在脚本里写绝对路径调用。我自己的习惯是写绝对路径，因为部署到别的机器上时 PATH 往往是不可控的，脚本里硬编码路径反而更稳定，出了问题也一眼能看出是路径错了还是别的问题。

需要注意的是Program Files这个路径带空格，在脚本里调用时一定要加引号，否则参数会被拆开。这类问题报错信息往往很含糊，看起来像语言包的问题，实际是命令行解析错了。

3.2 Linux 包管理器路线与包名陷阱

Linux 上直接用发行版的包管理器，比手动放文件省心。

# Debian / Ubuntu 系 sudo apt-get update sudo apt-get install -y tesseract-ocr tesseract-ocr-chi-sim tesseract-ocr-osd # RHEL / Fedora 系 sudo dnf install -y tesseract tesseract-langpack-chi_sim

这段命令里最值得说的是包名。注意 apt 的包名是tesseract-ocr-chi-sim，中间是连字符；而语言代码、traineddata 文件名用的是下划线chi_sim。这两个不是一回事，写成apt install tesseract-ocr-chi_sim会直接报「无法定位软件包」。dnf 那边又反过来用下划线。这个坑我见过太多次，很多人卡在这里以为源里没有中文包。

装完之后要知道语言包落在哪。Debian 系常见路径是/usr/share/tesseract-ocr/5/tessdata，也可能是/usr/share/tessdata，取决于版本和打包方式。用--list-langs能列出语言就说明路径是对的，但如果你要手动补一个语言包进去，就得先确认这个目录在哪。

# 找 traineddata 的实际落点 dpkg -L tesseract-ocr-chi-sim | grep traineddata # 或直接全盘找 find / -name "chi_sim.traineddata" 2>/dev/null

3.3 手动放语言包与 TESSDATA_PREFIX 的正确设置

需要手动补语言包的场景很常见：安装器里没有你要的语言、你想换成 best 版本、或者内网机器没法走包管理器。做法就是把.traineddata文件复制进tessdata目录，然后靠环境变量告诉引擎去哪找。

这里有个历史遗留的坑必须讲清楚：TESSDATA_PREFIX的语义在版本之间变过。3.x 时代它指向tessdata目录本身；4.x 之后改成指向tessdata的父目录，引擎会自己往下拼一层tessdata。如果你按老教程设成了.../tessdata，引擎拼出来的路径就会变成.../tessdata/tessdata/chi_sim.traineddata，然后报文件不存在。

# 4.x / 5.x 的写法：指到父目录 export TESSDATA_PREFIX=/usr/share/tesseract-ocr/5 # 验证是否生效 tesseract --list-langs

判断方法很简单：看报错信息里拼出来的完整路径。如果出现重复的tessdata段，把TESSDATA_PREFIX往上退一级就行。反过来，如果某些自行编译的构建仍然沿用老语义，那就得指到tessdata本身。所以别背结论，看报错路径，这是最可靠的判断依据。

提示：语言包文件放好后，先看文件大小。chi_sim.traineddata的 standard 版通常在几十 MB 量级，fast 版只有几 MB，best 版更大。如果下下来的文件只有几百 KB，多半是下载中断留下的残包，--list-langs里可能照样能显示语言名，但一识别就报损坏。

这里顺手给个校验清单，手动部署时按这个顺序过一遍，能省掉大量来回试的时间。

4. 命令行参数：--psm、--oem 与输出格式的组合

语言包装好之后，接下来决定成败的就是参数。同样一张图，参数搭配不同，结果可能从「勉强能读」跳到「基本不用改」。这一章把三个最常调的参数讲透，并给出可复现的对比方法。

4.1 --psm 的版面假设与选型

--psm的全称是页面分割模式，它告诉引擎「你面前这张图大概是什么结构」。默认值是 3，也就是全自动分页加方向检测。这个默认值在整页文档上表现尚可，但在截图、单行文字、票据这类非标准版面上经常翻车——因为引擎会强行找「多个文本块」，把一段完整的话切得七零八落。

选型的经验法则是：能确定结构就别让它自动判断。单行文字用 7，一整块截图用 6，整页排版规整用 3 或 4，零散文字用 11。判断依据不要靠猜，直接跑一轮对比。

# 同一张图跑不同 psm，各取前三行对比 for p in 3 4 6 7 11; do echo "===== psm $p =====" tesseract page.png stdout -l chi_sim --psm $p 2>/dev/null | head -n 3 done

这段循环的意义在于把「玄学」变成可比较的输出。看什么？看第一行是否完整、有没有把两行粘成一行、标点是不是变成了别的符号。如果 psm 3 出来一堆碎片而 psm 6 是完整段落，那这张图就该用 6。批量任务里我通常固定一个 psm，而不是逐图自适应，因为稳定性比个别图的最优更重要。

4.2 --oem 引擎模式与一个高频报错

--oem控制用哪套识别引擎：0 是旧版引擎，1 是 LSTM 加旧版混合，2 是纯 LSTM，3 是按可用性自动选择。很多人照着老教程写--oem 0，然后得到一个报错，大意是引擎请求了 legacy 组件但当前构建里没有。

原因很简单：5.x 的官方二进制包默认只编译 LSTM，旧引擎需要额外的编译开关才会带上。所以在多数现成安装包上，--oem 0和--oem 1都不可用，实际能用的只有 2 和 3，而这两个在纯 LSTM 构建里行为基本一致。与其纠结这个参数，不如把精力放在--psm和预处理上。

-c后面可以跟配置项，几个实用的：

# 保留词间原始空格，中文混排文档排版还原更准 tesseract page.png stdout -l chi_sim --psm 6 -c preserve_interword_spaces=1 # 关闭调试输出，避免日志污染结果 tesseract page.png stdout -l chi_sim --psm 6 -c debug_file=/dev/null

preserve_interword_spaces=1这个参数值得单独提一句。中文本身不用空格分词，但文档里往往有表格对齐、编号缩进，默认行为会把连续空格压缩掉，还原出来的文本排版全乱。打开它能保住原始间距，代价是可能多出一些无意义的空格，需要后处理时清一下。

另外提醒一句关于字符白名单。网上流传用tessedit_char_whitelist=0123456789限定只出数字，这个技巧在旧引擎上有效，在 LSTM 引擎上基本不起作用，设了照样出字母。这是个高频误导，后面避坑章节会展开说。

4.3 输出格式的取舍

Tesseract 支持多种输出格式，选错了会白白丢掉有用的信息。

# 纯文本，最常用 tesseract page.png out -l chi_sim --psm 3 # TSV，带每个词的坐标和置信度 tesseract page.png out -l chi_sim --psm 3 tsv # 带文本层的 PDF，适合归档和检索 tesseract page.png out -l chi_sim pdf # hOCR，结构化 HTML，适合接前端展示 tesseract page.png out -l chi_sim hocr

只说一点最关键的：TSV 里的conf列是置信度，范围大致 0 到 100，-1表示这一行不是识别出的文字（比如图片行）。坐标四列left / top / width / height加上层级列block_num / par_num / line_num / word_num，足够你重建出段落结构。做质量校验、做版面还原、做人工复核排序，全都靠这份 TSV。纯文本输出看起来干净，但信息全丢了，出了问题没法定位是哪一行哪一段错了。

PDF 输出生成的文本层是可搜索的，扫描件归档场景很实用，但注意它内部也是靠识别结果生成的，识别错了 PDF 里的文本层一样是错的，别以为转成 PDF 就万事大吉。

5. 批量落地与踩坑排查：五条血泪记录

单张图调通了，真正的考验才刚开始：几百上千张图要跑，跑完还得知道哪些结果能信、哪些必须人工看。这一章先给批量封装的写法，再讲表格和竖排这两个特殊版式，最后把踩过的坑逐条列清楚。

5.1 用 pytesseract 做批量封装与置信度过滤

Python 侧最常用的是 pytesseract，它本质上是调外部命令并把结果解析成结构化的字典，所以性能瓶颈在进程启动和图像解码，不在 Python 本身。

import os # 必须在导入 pytesseract 之前设置：限制每个 tesseract 进程只用单线程 # 多进程并发时，每个子进程内部再开多线程会把 CPU 打满且互相拖慢 os.environ["OMP_THREAD_LIMIT"] = "1" from concurrent.futures import ProcessPoolExecutor import pytesseract from PIL import Image def ocr_one(path, lang="chi_sim", psm=6, min_conf=60): img = Image.open(path) data = pytesseract.image_to_data( img, lang=lang, config=f"--psm {psm} --dpi 300", # dpi 显式给，避免引擎按 70 估算 output_type=pytesseract.Output.DICT, ) kept = [] for text, conf in zip(data["text"], data["conf"]): text = text.strip() if not text: continue conf = float(conf) if conf >= min_conf: # 低于阈值直接丢弃，交给人工复核 kept.append(text) return {"file": path, "text": "".join(kept), "kept_words": len(kept)} if __name__ == "__main__": files = [f"pages/{n}" for n in os.listdir("pages")] with ProcessPoolExecutor(max_workers=4) as pool: results = list(pool.map(ocr_one, files)) for r in results[:3]: print(r["file"], r["kept_words"])

几个参数值得解释。OMP_THREAD_LIMIT=1是必须的，因为 Tesseract 内部依赖的数学库默认会按 CPU 核数开线程，你在外层再开四个进程，实际就是四乘 N 个线程在抢核，速度反而比单进程还慢，机器还会卡死。--dpi 300显式声明分辨率，是因为 PNG 和截图往往没有 DPI 元数据，引擎会按 70 这种离谱值估算，导致字符高度算小了，识别率断崖下跌。

置信度阈值怎么定，别照抄。中文正文一般 60 起步，票据上的数字、金额这类关键字段我提到 80 以上，宁可漏检也不要错检——错检比漏检更难发现。低于阈值的结果不要直接扔掉，打上标记走人工复核队列，这才是工程上能落地的做法。

5.2 表格与竖排文本的处理思路

表格是 Tesseract 的短板，它没有表格结构的概念，只会按文本块切。TSV 的坐标能帮你把词还原成行，但合并单元格、跨行跨列这类结构它完全理解不了。常见的补救做法是先用 OpenCV 检测横竖线，把表格切成一个个单元格图片，再逐格识别，最后按坐标拼回二维结构。这套流程代码量不小，如果表格占比高，值得单独写一个处理模块；如果只是零星几张，人工校对更快。

竖排文本相对简单，前提是加载了chi_sim_vert语言包，并且把--psm设成 5（假定为垂直对齐的单一文本块）。注意竖排模型和横排模型不能混着用，-l chi_sim+chi_sim_vert这种写法不会让引擎自动判断方向，只会让两套模型的输出互相干扰。

5.3 五条踩坑记录

其一，中文识别出来全是方块或空串。现象是跑完命令终端什么都没输出，或者出来一串问号。原因是只装了eng，中文被英文模型硬认，认不出就丢弃。解决方法是先跑--list-langs确认chi_sim在列，不在就按第 3 章的路径规则补语言包，别急着调参数。

其二，报错信息里出现两个 tessdata。现象是Error opening data file .../tessdata/tessdata/chi_sim.traineddata。原因是TESSDATA_PREFIX按老版本语义指到了tessdata目录本身，新版本又往下拼了一层。解决方法是看报错里的完整路径，把它往上退一级，改完立刻用--list-langs验证。

其三，截图或单行文字识别成一堆碎片。现象是完整的一句话被切成几段，中间还插入了无关符号。原因是默认--psm 3会强行做多块版面分析，把一行字当成了好几个文本块。解决方法是单行用--psm 7，整块段落用--psm 6，我一般先用 6 试，不对再降到 7。

其四，小字识别率极低且伴随分辨率告警。现象是日志里出现按 70 dpi 估算的提示，中文的偏旁部首糊成一片。原因是图片没有 DPI 元数据，引擎按默认值估算，字符高度远低于可用阈值。解决方法是显式加--dpi 300，或者先把短边放大到 1500 像素以上再喂进去。中文对小字比英文更敏感，字符高度低于 20 像素时基本没救。

其五，字符白名单设了不生效。现象是配了tessedit_char_whitelist只许出数字，结果还是冒出字母。原因是这个配置项对 LSTM 引擎基本无效，属于旧引擎时代的遗留技巧。解决方法是改用后处理正则清洗，或者把目标区域单独裁出来识别，再不行就走模型微调，别在这条路上耗时间。

注意：还有一类不是报错但很折磨人的问题——批量跑的时候内存缓慢上涨最后被系统杀掉。多半是图片没及时释放，Image.open之后没有 close，进程池跑几千张就撑不住了。养成用with Image.open(path) as img的习惯。

6. 进阶：用置信度做自校验，以及什么时候该停止调参

调参调到一定程度会遇到瓶颈：同一个 psm、同样的预处理，某些页面的结果就是不稳。这时候与其继续试参数组合，不如让程序自己判断结果可不可信。最省事的做法是按页聚合置信度。

import pytesseract from PIL import Image def page_confidence(path, lang="chi_sim", psm=6): with Image.open(path) as img: data = pytesseract.image_to_data( img, lang=lang, config=f"--psm {psm} --dpi 300", output_type=pytesseract.Output.DICT, ) # conf 为 -1 的是版面行，不是识别结果，必须排除 scores = [float(c) for t, c in zip(data["text"], data["conf"]) if t.strip() and float(c) >= 0] return sum(scores) / len(scores) if scores else 0.0

这个函数返回整页的平均置信度，配合阈值就能做分流：高于 85 直接入库，70 到 85 之间抽查，低于 70 自动回退到加强预处理的版本重跑一次，还不行就进人工队列。比起逐张肉眼看，这套分流能把复核工作量压掉一大半。实际用下来，平均置信度低于 65 的页面，肉眼几乎一定能找出错字，这个判断相当准。

最后说一句什么时候该放弃调参。如果满足这三个条件：文档字体高度单一、专业术语或生僻字频繁出错、版式长期固定，那问题不在参数而在模型本身，该考虑用少量样本做 LSTM 微调了。微调不是玄学，但样本标注的成本不低，几百行起步才有意义。反过来，如果文档来源杂、字体五花八门，微调收益很有限，不如把预处理和置信度分流做扎实。从那以后我每次上新的一批扫描件，都会先抽二十页跑一遍置信度分布，看清这批数据的底子再决定是调参还是上模型，这个习惯帮我省掉了大量无效折腾。希望帮到你。

本文还有配套的精品资源，点击获取