最近帮朋友处理一批扫描版PDF的时候被OCR这事儿折腾得不轻。倒不是说现成的在线工具不能用而是文件量大、涉及隐私内容实在不方便一张张往云端传。后来我干脆在Linux上自己搭了一套文字识别流程前后花了一个晚上跑出来的效果比想象中好太多。这里把整个思路、核心代码和踩坑过程完整分享一下给同样需要批量识别、又不方便用在线服务的同学一个可以直接抄作业的参考。这套方案的核心只有三件事用Tesseract做识别引擎用OpenCV做图像预处理用Python把它们串成一条流水线。听起来很基础但恰恰是这套组合最稳、最容易调试也最符合“超简单”这个定位。下面我会从方案选型开始讲把每一步的“为什么”也说清楚而不是单纯给一段能跑的命令。1. 整体思路与方案选型1.1 为什么不自建OCR还要“自制”先说个实际的场景。我那朋友手里是几十本扫描版的技术手册PDF里全是图片没法直接复制文字。如果要全文检索或者摘录段落就必须做OCR。我一上来就考虑过在线API注册、申请密钥、传文件、等回调流程倒是不复杂但问题很明显一是隐私手册里有些内部标注不想经过第三方服务器二是批量识别有配额限制超出就要付费三是网络传输几十GB文件的时间成本也不低。所以在Linux上搭一套本地OCR是更合理的路线。数据不出本机脚本跑多久都不心疼而且识别参数完全可控什么时候觉得效果不满意随时可以调。所谓“自制”并不是要自己从零训练一个神经网络而是把成熟的开源工具按自己的需求组装起来。这就像做饭不要求你从种菜开始买来新鲜食材自己配比炒制照样叫“自己做”。1.2 主流方案的横向对比开源OCR引擎这几年可选的不少我实际用过或调研过的有这么几类Tesseract老牌引擎活跃度高支持语言多中文包也成熟。优点是轻量、命令行友好、社区资料多缺点是对于复杂版面、艺术字、低质量照片需要配合预处理才能有理想效果。PaddleOCR百度开源的那套识别精度在新版本上确实不错尤其对中文排版支持好。但依赖较重安装PaddlePaddle框架动辄几百MB模型加载也吃内存做“超简单”入门有些重。EasyOCR基于深度学习上手简单效果也还行但同样有模型体积和推理速度的问题而且对老机器的CPU推理不太友好。OCRmyPDF严格说它是PDF工具不是引擎它在Tesseract外面包了一层可以生成可检索PDF。这个我很推荐后面扩展章节会专门讲。我用一张表把这些方案的关键差异列出来方便你按自己的情况选方案安装复杂度中文识别CPU推理速度适合场景Tesseract低良好快批量文档、截图、印刷体PaddleOCR中高优秀中复杂版面、高精度需求EasyOCR中良好较慢小批量、模型效果尝鲜OCRmyPDF低看底层引擎快把PDF变成可检索文档1.3 我的选型结论最终选了Tesseract 4.x加中文语言包配合Python的pytesseract和OpenCV。选择理由有三个第一依赖简单。一条apt命令就能把引擎和中文包装好不需要担心框架版本冲突。第二调试方便。Tesseract有独立的命令行工具出了问题时可以先在终端里用一条命令定位是引擎问题还是预处理问题这比打开Python堆栈去猜要快得多。第三社区答案多。不管遇到什么识别率问题搜一下基本都能找到对应的参数配置对新手非常友好。至于训练自己的模型那是进阶路线。Tesseract 4以后支持基于LSTM的微调但需要准备大量标注样本和专用训练工具普通使用场景根本不必走到这一步。先把现成模型用利索已经能覆盖绝大多数文字识别需求了。2. 环境准备与工具安装2.1 安装Tesseract引擎与语言包我用的系统是Ubuntu/Debian系的直接走apt最省事。先更新索引再安装引擎sudo apt update sudo apt install tesseract-ocr tesseract-ocr-chi-sim第一条命令是装引擎本体第二条装简体中文语言包。这里提醒大家留意Tesseract默认只带英文识别能力不装语言包的话你给它一张中文图片它只会输出一堆乱码甚至什么都识别不出来。我最初没注意这点还以为是预处理的问题排查了半天才发现语言包没装。装好以后验证一下版本和可用语言tesseract --version tesseract --list-langs--list-langs这个命令很实用它会列出当前已安装的所有语言包代码。看到chi_sim就说明中文简体包已经就位了。如果你需要繁体加装tesseract-ocr-chi-tra就行。2.2 安装Python依赖接下来是Python这一层。我建议新建一个虚拟环境避免污染系统的全局Pythonpython3 -m venv ocr_env source ocr_env/bin/activate pip install pytesseract opencv-python pillow三个包的分工很明确pytesseract是Tesseract的Python封装负责把命令行能力暴露给代码调用opencv-python是图像预处理主力做灰度化、二值化、降噪这些操作pillow则是用来做基本的图片读写和格式转换虽然OpenCV也能读写图片但Pillow在某些编码格式上更省心。装完之后记得确认pytesseract能找到Tesseract的可执行文件。大多数情况下它会在/usr/bin/tesseract自动找到但如果你用源码编译方式安装过其他版本可能需要手动指定from PIL import Image import pytesseract # 正常情况下可以不用下面这行找不到时报错再手动指定 pytesseract.pytesseract.tesseract_cmd r/usr/bin/tesseract2.3 环境验证写个最小测试确认整个链路是通的。先用PIL生成一张带文字的图片再用pytesseract识别from PIL import Image, ImageDraw import pytesseract img Image.new(RGB, (400, 80), colorwhite) draw ImageDraw.Draw(img) draw.text((20, 20), Hello Linux OCR, fillblack) result pytesseract.image_to_string(img, langeng) print(result.strip())如果能正确输出Hello Linux OCR说明引擎、语言包、Python绑定全都正常。这一步虽然简单但能把安装问题跟后面的逻辑问题分隔开我每次在新机器上搭环境都会先跑一遍这个最小用例。3. 核心实现与代码解读3.1 为什么预处理是识别率的关键很多人在这一步容易栽跟头把图片直接丢给Tesseract发现识别结果一塌糊涂就以为是引擎不行。实际上相当一部分识别问题根源在于图片质量没有达到引擎的预期。Tesseract的识别逻辑是建立在“图片经过良好二值化”这个前提上的。扫描件常常带灰底、噪声、倾斜如果不处理引擎会被这些干扰信息带偏。打个比方你让一个阅读速度极快的人去读一张复印了三次、字迹模糊还歪斜的纸他再厉害也会读错。OCR引擎也一样给它的图越干净它发挥越稳定。所以我的核心思路是在调用识别引擎之前先对图片做一套标准化的预处理流程包括灰度化、去噪、增强对比度、二值化和倾斜校正。这一套做下来识别率往往能提升好几个档次。3.2 图像预处理管线下面这段就是用OpenCV实现的预处理函数也是整条流水线的第一个关键环节import cv2 import numpy as np def preprocess_image(image_path): # 读取原始图片 img cv2.imread(image_path) # 转为灰度图去掉颜色信息 gray cv2.cvtColor(img, cv2.COLOR_BGR2GRAY) # 中值滤波去噪去除扫描产生的椒盐噪声 denoised cv2.medianBlur(gray, 3) # 自适应阈值二值化把文字变成黑字白底 binary cv2.adaptiveThreshold( denoised, 255, cv2.ADAPTIVE_THRESH_GAUSSIAN_C, cv2.THRESH_BINARY, 15, 8 ) return binary每个步骤的作用我拆开说一下。灰度化是必须的因为识别只关心文字的明暗轮廓颜色信息不但没用还会干扰处理速度。中值滤波用3x3的窗口去除细小噪点这个核大小是我实测下来比较平衡的值太小了去不干净太大了会伤文字笔画。自适应阈值二值化跟固定阈值不一样它会在图像不同区域分别计算阈值这样即使扫描件存在局部阴影或打光不均也能尽量保留文字轮廓。还有一个经常被忽略的问题图像尺寸。如果扫描的DPI很低文字边缘是发虚的引擎自然认不准。遇到这种情况我一般会先把图像放大两倍再做二值化def upscale_image(img, scale2): width int(img.shape[1] * scale) height int(img.shape[0] * scale) return cv2.resize(img, (width, height), interpolationcv2.INTER_CUBIC)3.3 倾斜校正的补充处理扫描件里经常有页面本身没放正的情况文字是歪的识别率会直线下降。Tesseract对轻微倾斜有一定的容忍度但超过三五度的倾斜还是会有影响。我自己会加一个简单的倾角校正def deskew(image): coords np.column_stack(np.where(image 0)) angle cv2.minAreaRect(coords)[-1] if angle -45: angle 90 angle if angle ! 0.0 and abs(angle) 0.5: h, w image.shape[:2] center (w // 2, h // 2) matrix cv2.getRotationMatrix2D(center, angle, 1.0) image cv2.warpAffine(image, matrix, (w, h), flagscv2.INTER_CUBIC, borderModecv2.BORDER_REPLICATE) return image原理是找出所有非零像素点计算它们的最小外接矩形再根据矩形的倾斜角度反向旋转图片。这里有个细节OpenCV的minAreaRect返回的角度区间是[-90, 0]所以要做一次角度换算否则方向会搞反。borderMode用BORDER_REPLICATE而不是默认值是为了避免旋转后边缘出现大面积黑边干扰识别。3.4 调用识别引擎与参数说明预处理做完接下来就是调Tesseract。核心就一行代码但参数很讲究def ocr_image(image_path, langchi_simeng): processed preprocess_image(image_path) config --psm 6 --oem 1 text pytesseract.image_to_string(processed, langlang, configconfig) return text.strip()先看lang参数。我用的chi_simeng表示中英文混合识别Tesseract会同时在两种语言模型里匹配。如果你的文档里只有英文直接用eng速度会更快精度也更高因为不需要在中英文之间做权衡。再看--psm全称是Page Segmentation Mode决定引擎怎么理解页面的版面结构。我常用这几个值PSM值含义适用场景3全自动版面分析复杂多栏页面6把整张图当做一个文本块单栏正文、整页扫描文字7把图片当一行文字截图里的单行文本11稀疏文本识别发票、模板、不规则排版13原始行识别不做额外处理已经切分好的行--oem是引擎模式0是传统引擎1是LSTM神经网络引擎2两者结合3是让引擎自己选。我基本固定用1因为4.x版本里LSTM的精度明显更高。但有一种情况例外如果你处理的是印刷体的等宽字或者特殊符号表传统引擎偶尔会表现更好这个需要通过A/B对比来确定而不是凭感觉。3.5 后处理修掉常见的识别错误Tesseract不是万能的输出里常常混着一些低级错误比如中文里混进英文字母、标点半角全角混乱、空格位置不对。我会在后面加一道轻量后处理import re def clean_text(text): # 去掉只含空白的行 lines [line.strip() for line in text.splitlines()] lines [line for line in lines if line] # 统一常见的错误字符替换 replacements { O: 0, l: 1, I: 1, } # 注意这个替换只能用在纯数字场景中文文本别乱用 cleaned_paragraph .join(lines) return cleaned_paragraph这里要提醒一句字符替换这步非常危险不能无脑全局替换。比如把字母O替换成数字0在识别英文单词时会把“Open”变成“0pen”反而弄巧成拙。我的经验是只对特定场景启用比如识别验证码、识别纯数字编号时这种替换才有意义。普通段落文本我最多做空白整理和行过滤。3.6 完整脚本组装把前面几个函数串起来就是一个能用的命令行工具import sys import cv2 import pytesseract def preprocess_image(image_path): img cv2.imread(image_path) gray cv2.cvtColor(img, cv2.COLOR_BGR2GRAY) denoised cv2.medianBlur(gray, 3) binary cv2.adaptiveThreshold( denoised, 255, cv2.ADAPTIVE_THRESH_GAUSSIAN_C, cv2.THRESH_BINARY, 15, 8 ) return binary def ocr_image(image_path): processed preprocess_image(image_path) config --psm 6 --oem 1 text pytesseract.image_to_string(processed, langchi_simeng, configconfig) return text.strip() if __name__ __main__: if len(sys.argv) 2: print(用法: python ocr.py 图片路径) sys.exit(1) result ocr_image(sys.argv[1]) print(result)运行方式很简单python ocr.py sample.png4. 实操过程与效果测试4.1 准备三类测试样本光有脚本还不够得用真实样本验证。我分别准备了三种典型图片第一类是电脑截图字体清晰、排版规整第二类是手机拍的书籍页面有透视变形和阴影第三类是扫描仪的灰度扫描件有轻微噪点和倾斜。这三种基本覆盖了日常用到的场景。测试环境我记录一下方便大家对照Ubuntu 22.04Tesseract 4.1.1OpenCV 4.5.4Python 3.10CPU是普通的四核处理器。识别单张A4扫描件的速度大约在2到5秒之间具体取决于文字密度。4.2 有无预处理的对比为了验证预处理的价值我对同一张手机拍摄的页面分别跑了“直接识别”和“预处理后识别”两组测试。直接识别的结果惨不忍睹整段文字里能正确认出的不到一半很多笔画被阴影干扰连成了黑块。而经过灰度、去噪、二值化处理之后虽然仍有个别字误判但整体段落已经能顺畅阅读。测试样本直接识别正确率预处理后正确率耗时电脑截图约95%约98%1秒内手机拍摄页约50%约85%3秒左右扫描件约80%约95%2秒左右手机拍摄那组提升最明显原因就是原图里有大量阴影和反光预处理把这些问题大幅缓解了。这也印证了我前面的观点识别率瓶颈往往在图像质量而不在引擎本身。4.3 PSM参数的实战调优我在测试中特别对比了不同的PSM参数。对于整页扫描件--psm 3全自动版面分析有时候会把栏目标题和正文分开处理输出顺序会比较乱而--psm 6把整页当一个文本块按从上到下、从左到右的顺序输出对于单栏文档更稳定。但如果是多栏的杂志页面--psm 6反而会把两栏文字混读成一整段这时就必须用--psm 3让引擎自动识别栏位。我的实操经验是先看一眼你的页面版面结构再决定PSM值别指望一个参数通吃所有场景。正是因为这个原因我在脚本里把PSM做成了可选参数而不是写死。def ocr_image(image_path, psm6, langchi_simeng): processed preprocess_image(image_path) config f--psm {psm} --oem 1 text pytesseract.image_to_string(processed, langlang, configconfig) return text.strip()4.4 中英文混合场景的表现技术手册里有很多中英文混排的情况比如“在Linux终端中执行make命令”这种句子。我测试下来Tesseract的chi_simeng混合模式大体能用但偶尔会把中文句子里的英文单词拆错。比如把“make”识别成“m ake”或者把“API”认成“AP1”。遇到这种情况我的对策不是改引擎而是在后处理阶段加规则。比如对单词级别做一次小写/大写的模式检查如果一串大写字母中间夹着数字就把它标出来让人工确认。OCR本来就不可能做到百分之百准确关键是让机器把高置信度的内容自动处理掉把低置信度的内容暴露出来。5. 常见问题与排查实录5.1 识别结果全是乱码这是被问得最多的问题。先检查两件事语言包有没有装以及lang参数有没有传对。很多人在代码里写了langchi但Tesseract的语言代码是chi_sim一个拼写错误就会让引擎退回默认英文模式。在终端里跑tesseract --list-langs确认当前有哪些语言然后再对照代码里的参数基本能定位问题。另外乱码也可能是图片本身的问题比如彩色背景上的反白文字二值化之后文字和背景被反转了。遇到这种情况可以在二值化后加一步判断如果前景像素占比过高说明黑白色可能对调要用cv2.bitwise_not反转过来。5.2 某一行总是识别错如果你发现图片整体识别不错但特定行反复出错多半是那行的图片质量有问题比如字体过小、笔画连在一起、或者有下划线干扰。一个实用技巧是先把那一行裁出来单独测试用cv2把坐标范围切出来再用--psm 7按单行识别往往比整页识别的成功率更高。我专门写过一个调试模式把中间步骤的图像保存下来方便肉眼检查def debug_preprocess(image_path, output_prefix): img cv2.imread(image_path) gray cv2.cvtColor(img, cv2.COLOR_BGR2GRAY) cv2.imwrite(f{output_prefix}_1_gray.png, gray) denoised cv2.medianBlur(gray, 3) cv2.imwrite(f{output_prefix}_2_denoised.png, denoised) binary cv2.adaptiveThreshold( denoised, 255, cv2.ADAPTIVE_THRESH_GAUSSIAN_C, cv2.THRESH_BINARY, 15, 8 ) cv2.imwrite(f{output_prefix}_3_binary.png, binary) return binary把每一步的图存下来你会发现问题出在哪一步非常直观。有一次我发现中值滤波的核设成了5把笔画的细线都抹掉了文字看起来发虚就是靠这种调试方式发现的。5.3 同一个字反复被认错像“已”和“己”、“日”和“曰”这类形近字任何OCR引擎都会犯迷糊。Tesseract有一个黑名单机制但形近字不是靠黑名单能解决的因为它们在字形上确实接近。我的经验是对于专业术语库提前做一次术语替换是最高性价比方案。比如你的文档里反复出现特定产品名先跑一遍OCR再用关键词替换把识别成错别字的术语批量修正比逐字校对快得多。Tesseract也支持设置字符白名单如果你确定文档只包含数字和某些符号可以这样限制text pytesseract.image_to_string( processed, langeng, config--psm 7 -c tessedit_char_whitelist0123456789-. )这个功能在处理验证码、序列号这类确定性内容时非常有用能直接排除掉字母被误判成数字之类的问题。5.4 速度慢到无法接受如果批量处理大量图片单张两三秒累积起来也很可观。先检查是不是每一张图都在做同样的大图缩放如果原图分辨率很高前面提到的放大操作反而会增加无谓的计算量。另一个提速思路是降低图像尺寸到合适的范围一般宽度在2000像素左右足够Tesseract识别了太高的分辨率并不会带来精度提升只会拖慢速度。如果能接受并行处理可以考虑用多个子进程同时跑不同文件。Tesseract的引擎是单线程的但多开几个进程就能吃满多核CPU。我在批量脚本里用了concurrent.futures的进程池四核机器上处理时间基本缩短到原来的三分之一。6. 扩展从单张图片到批量流水线6.1 批量识别目录下所有图片单张识别只是为了验证逻辑真实使用场景一定是批量。下面这个脚本会把某个目录下所有常见格式的图片识别成同名文本文件import os import glob from concurrent.futures import ProcessPoolExecutor def batch_ocr(folder): images glob.glob(os.path.join(folder, *.png)) \ glob.glob(os.path.join(folder, *.jpg)) \ glob.glob(os.path.join(folder, *.jpeg)) with ProcessPoolExecutor() as executor: results executor.map(ocr_image, images) for image, text in zip(images, results): output os.path.splitext(image)[0] .txt with open(output, w, encodingutf-8) as f: f.write(text) print(f完成: {image} - {output})用进程池而不直接用循环是因为OCR是典型的计算密集型任务多核并行收益非常明显。但要注意进程池同时跑的进程数不要超过CPU核心数太多否则上下文切换的开销会抵消并行收益。我在四核机器上设的默认最大进程数就是4。6.2 把PDF变成可检索文档如果原始文件是扫描版PDF你还需要先将PDF拆成图片。这里可以用pdftoppm它是Poppler工具集里的命令专门把PDF页面转成图片pdftoppm -png -r 300 input.pdf page-r 300指定输出分辨率为300 DPI这个数值对印刷体文字来说已经非常充裕。转换后对每一张图片跑OCR最后再按顺序把识别文本合并成一个txt文件整个流程相当顺畅。另一种更省事的选择是直接用之前提过的OCRmyPDF它能把扫描版PDF转成带文本层的可检索PDF。简单来说就是给每一页“贴”一层透明的识别文字这样PDF既能看扫描原图又能搜索和复制文字ocrmypdf -l chi_simeng --deskew input.pdf output.pdf我个人的体会是OCRmyPDF适合“只要结果、不想折腾”的场景而自己写脚本适合需要对接后续处理的场景比如识别结果还想进数据库做检索那肯定还是自己控制流程更灵活。6.3 和截图工具配合使用日常使用中最频繁的场景其实是截图OCR。我习惯用一个最简单的办法先在桌面截图再把截图文件丢给上面的脚本。如果你有自动化的需求可以找一个支持“截图后执行命令”的工具或者自己写一个热键脚本用内置的截图命令截取区域、保存到固定路径、再自动调用OCR脚本。这样从截图到看到识别文本的整个过程只需一两秒钟体验已经和商用截图OCR工具差不多了。效率提升的关键是把识别结果直接复制到剪贴板而不是手动选中再复制。在命令行里可以用管道把结果接到系统的剪贴板工具不同发行版命令不一样自己查一下就行脚本逻辑完全一致。最后说一个我踩过几次坑之后的体会OCR项目里最花时间的往往不是模型而是把图片处理成模型预期的样子。很多人一开始就纠结要不要训练自己的模型其实先把手头这批图片的预处理调好、PSM参数选对、后处理规则补齐识别率已经从“不可用”变成“堪用”了。真到某类特定字体反复出错、规则修不掉的时候再考虑进阶的模型微调也不迟。我对这套方案的另一个建议是把每次调参的对比结果记下来比如哪类文档适合哪个PSM值、什么格式的图片需要先放大这些经验积累起来之后你的OCR流水线会越用越顺手遇到新样本时也能更快找到合适的处理路径。 
长河君 · 2026/10/24 3:32:02 · 阅读 1.2k Linux下搭建Tesseract+OpenCV+Python批量OCR识别流水线
最近帮朋友处理一批扫描版PDF的时候被OCR这事儿折腾得不轻。倒不是说现成的在线工具不能用而是文件量大、涉及隐私内容实在不方便一张张往云端传。后来我干脆在Linux上自己搭了一套文字识别流程前后花了一个晚上跑出来的效果比想象中好太多。这里把整个思路、核心代码和踩坑过程完整分享一下给同样需要批量识别、又不方便用在线服务的同学一个可以直接抄作业的参考。这套方案的核心只有三件事用Tesseract做识别引擎用OpenCV做图像预处理用Python把它们串成一条流水线。听起来很基础但恰恰是这套组合最稳、最容易调试也最符合“超简单”这个定位。下面我会从方案选型开始讲把每一步的“为什么”也说清楚而不是单纯给一段能跑的命令。1. 整体思路与方案选型1.1 为什么不自建OCR还要“自制”先说个实际的场景。我那朋友手里是几十本扫描版的技术手册PDF里全是图片没法直接复制文字。如果要全文检索或者摘录段落就必须做OCR。我一上来就考虑过在线API注册、申请密钥、传文件、等回调流程倒是不复杂但问题很明显一是隐私手册里有些内部标注不想经过第三方服务器二是批量识别有配额限制超出就要付费三是网络传输几十GB文件的时间成本也不低。所以在Linux上搭一套本地OCR是更合理的路线。数据不出本机脚本跑多久都不心疼而且识别参数完全可控什么时候觉得效果不满意随时可以调。所谓“自制”并不是要自己从零训练一个神经网络而是把成熟的开源工具按自己的需求组装起来。这就像做饭不要求你从种菜开始买来新鲜食材自己配比炒制照样叫“自己做”。1.2 主流方案的横向对比开源OCR引擎这几年可选的不少我实际用过或调研过的有这么几类Tesseract老牌引擎活跃度高支持语言多中文包也成熟。优点是轻量、命令行友好、社区资料多缺点是对于复杂版面、艺术字、低质量照片需要配合预处理才能有理想效果。PaddleOCR百度开源的那套识别精度在新版本上确实不错尤其对中文排版支持好。但依赖较重安装PaddlePaddle框架动辄几百MB模型加载也吃内存做“超简单”入门有些重。EasyOCR基于深度学习上手简单效果也还行但同样有模型体积和推理速度的问题而且对老机器的CPU推理不太友好。OCRmyPDF严格说它是PDF工具不是引擎它在Tesseract外面包了一层可以生成可检索PDF。这个我很推荐后面扩展章节会专门讲。我用一张表把这些方案的关键差异列出来方便你按自己的情况选方案安装复杂度中文识别CPU推理速度适合场景Tesseract低良好快批量文档、截图、印刷体PaddleOCR中高优秀中复杂版面、高精度需求EasyOCR中良好较慢小批量、模型效果尝鲜OCRmyPDF低看底层引擎快把PDF变成可检索文档1.3 我的选型结论最终选了Tesseract 4.x加中文语言包配合Python的pytesseract和OpenCV。选择理由有三个第一依赖简单。一条apt命令就能把引擎和中文包装好不需要担心框架版本冲突。第二调试方便。Tesseract有独立的命令行工具出了问题时可以先在终端里用一条命令定位是引擎问题还是预处理问题这比打开Python堆栈去猜要快得多。第三社区答案多。不管遇到什么识别率问题搜一下基本都能找到对应的参数配置对新手非常友好。至于训练自己的模型那是进阶路线。Tesseract 4以后支持基于LSTM的微调但需要准备大量标注样本和专用训练工具普通使用场景根本不必走到这一步。先把现成模型用利索已经能覆盖绝大多数文字识别需求了。2. 环境准备与工具安装2.1 安装Tesseract引擎与语言包我用的系统是Ubuntu/Debian系的直接走apt最省事。先更新索引再安装引擎sudo apt update sudo apt install tesseract-ocr tesseract-ocr-chi-sim第一条命令是装引擎本体第二条装简体中文语言包。这里提醒大家留意Tesseract默认只带英文识别能力不装语言包的话你给它一张中文图片它只会输出一堆乱码甚至什么都识别不出来。我最初没注意这点还以为是预处理的问题排查了半天才发现语言包没装。装好以后验证一下版本和可用语言tesseract --version tesseract --list-langs--list-langs这个命令很实用它会列出当前已安装的所有语言包代码。看到chi_sim就说明中文简体包已经就位了。如果你需要繁体加装tesseract-ocr-chi-tra就行。2.2 安装Python依赖接下来是Python这一层。我建议新建一个虚拟环境避免污染系统的全局Pythonpython3 -m venv ocr_env source ocr_env/bin/activate pip install pytesseract opencv-python pillow三个包的分工很明确pytesseract是Tesseract的Python封装负责把命令行能力暴露给代码调用opencv-python是图像预处理主力做灰度化、二值化、降噪这些操作pillow则是用来做基本的图片读写和格式转换虽然OpenCV也能读写图片但Pillow在某些编码格式上更省心。装完之后记得确认pytesseract能找到Tesseract的可执行文件。大多数情况下它会在/usr/bin/tesseract自动找到但如果你用源码编译方式安装过其他版本可能需要手动指定from PIL import Image import pytesseract # 正常情况下可以不用下面这行找不到时报错再手动指定 pytesseract.pytesseract.tesseract_cmd r/usr/bin/tesseract2.3 环境验证写个最小测试确认整个链路是通的。先用PIL生成一张带文字的图片再用pytesseract识别from PIL import Image, ImageDraw import pytesseract img Image.new(RGB, (400, 80), colorwhite) draw ImageDraw.Draw(img) draw.text((20, 20), Hello Linux OCR, fillblack) result pytesseract.image_to_string(img, langeng) print(result.strip())如果能正确输出Hello Linux OCR说明引擎、语言包、Python绑定全都正常。这一步虽然简单但能把安装问题跟后面的逻辑问题分隔开我每次在新机器上搭环境都会先跑一遍这个最小用例。3. 核心实现与代码解读3.1 为什么预处理是识别率的关键很多人在这一步容易栽跟头把图片直接丢给Tesseract发现识别结果一塌糊涂就以为是引擎不行。实际上相当一部分识别问题根源在于图片质量没有达到引擎的预期。Tesseract的识别逻辑是建立在“图片经过良好二值化”这个前提上的。扫描件常常带灰底、噪声、倾斜如果不处理引擎会被这些干扰信息带偏。打个比方你让一个阅读速度极快的人去读一张复印了三次、字迹模糊还歪斜的纸他再厉害也会读错。OCR引擎也一样给它的图越干净它发挥越稳定。所以我的核心思路是在调用识别引擎之前先对图片做一套标准化的预处理流程包括灰度化、去噪、增强对比度、二值化和倾斜校正。这一套做下来识别率往往能提升好几个档次。3.2 图像预处理管线下面这段就是用OpenCV实现的预处理函数也是整条流水线的第一个关键环节import cv2 import numpy as np def preprocess_image(image_path): # 读取原始图片 img cv2.imread(image_path) # 转为灰度图去掉颜色信息 gray cv2.cvtColor(img, cv2.COLOR_BGR2GRAY) # 中值滤波去噪去除扫描产生的椒盐噪声 denoised cv2.medianBlur(gray, 3) # 自适应阈值二值化把文字变成黑字白底 binary cv2.adaptiveThreshold( denoised, 255, cv2.ADAPTIVE_THRESH_GAUSSIAN_C, cv2.THRESH_BINARY, 15, 8 ) return binary每个步骤的作用我拆开说一下。灰度化是必须的因为识别只关心文字的明暗轮廓颜色信息不但没用还会干扰处理速度。中值滤波用3x3的窗口去除细小噪点这个核大小是我实测下来比较平衡的值太小了去不干净太大了会伤文字笔画。自适应阈值二值化跟固定阈值不一样它会在图像不同区域分别计算阈值这样即使扫描件存在局部阴影或打光不均也能尽量保留文字轮廓。还有一个经常被忽略的问题图像尺寸。如果扫描的DPI很低文字边缘是发虚的引擎自然认不准。遇到这种情况我一般会先把图像放大两倍再做二值化def upscale_image(img, scale2): width int(img.shape[1] * scale) height int(img.shape[0] * scale) return cv2.resize(img, (width, height), interpolationcv2.INTER_CUBIC)3.3 倾斜校正的补充处理扫描件里经常有页面本身没放正的情况文字是歪的识别率会直线下降。Tesseract对轻微倾斜有一定的容忍度但超过三五度的倾斜还是会有影响。我自己会加一个简单的倾角校正def deskew(image): coords np.column_stack(np.where(image 0)) angle cv2.minAreaRect(coords)[-1] if angle -45: angle 90 angle if angle ! 0.0 and abs(angle) 0.5: h, w image.shape[:2] center (w // 2, h // 2) matrix cv2.getRotationMatrix2D(center, angle, 1.0) image cv2.warpAffine(image, matrix, (w, h), flagscv2.INTER_CUBIC, borderModecv2.BORDER_REPLICATE) return image原理是找出所有非零像素点计算它们的最小外接矩形再根据矩形的倾斜角度反向旋转图片。这里有个细节OpenCV的minAreaRect返回的角度区间是[-90, 0]所以要做一次角度换算否则方向会搞反。borderMode用BORDER_REPLICATE而不是默认值是为了避免旋转后边缘出现大面积黑边干扰识别。3.4 调用识别引擎与参数说明预处理做完接下来就是调Tesseract。核心就一行代码但参数很讲究def ocr_image(image_path, langchi_simeng): processed preprocess_image(image_path) config --psm 6 --oem 1 text pytesseract.image_to_string(processed, langlang, configconfig) return text.strip()先看lang参数。我用的chi_simeng表示中英文混合识别Tesseract会同时在两种语言模型里匹配。如果你的文档里只有英文直接用eng速度会更快精度也更高因为不需要在中英文之间做权衡。再看--psm全称是Page Segmentation Mode决定引擎怎么理解页面的版面结构。我常用这几个值PSM值含义适用场景3全自动版面分析复杂多栏页面6把整张图当做一个文本块单栏正文、整页扫描文字7把图片当一行文字截图里的单行文本11稀疏文本识别发票、模板、不规则排版13原始行识别不做额外处理已经切分好的行--oem是引擎模式0是传统引擎1是LSTM神经网络引擎2两者结合3是让引擎自己选。我基本固定用1因为4.x版本里LSTM的精度明显更高。但有一种情况例外如果你处理的是印刷体的等宽字或者特殊符号表传统引擎偶尔会表现更好这个需要通过A/B对比来确定而不是凭感觉。3.5 后处理修掉常见的识别错误Tesseract不是万能的输出里常常混着一些低级错误比如中文里混进英文字母、标点半角全角混乱、空格位置不对。我会在后面加一道轻量后处理import re def clean_text(text): # 去掉只含空白的行 lines [line.strip() for line in text.splitlines()] lines [line for line in lines if line] # 统一常见的错误字符替换 replacements { O: 0, l: 1, I: 1, } # 注意这个替换只能用在纯数字场景中文文本别乱用 cleaned_paragraph .join(lines) return cleaned_paragraph这里要提醒一句字符替换这步非常危险不能无脑全局替换。比如把字母O替换成数字0在识别英文单词时会把“Open”变成“0pen”反而弄巧成拙。我的经验是只对特定场景启用比如识别验证码、识别纯数字编号时这种替换才有意义。普通段落文本我最多做空白整理和行过滤。3.6 完整脚本组装把前面几个函数串起来就是一个能用的命令行工具import sys import cv2 import pytesseract def preprocess_image(image_path): img cv2.imread(image_path) gray cv2.cvtColor(img, cv2.COLOR_BGR2GRAY) denoised cv2.medianBlur(gray, 3) binary cv2.adaptiveThreshold( denoised, 255, cv2.ADAPTIVE_THRESH_GAUSSIAN_C, cv2.THRESH_BINARY, 15, 8 ) return binary def ocr_image(image_path): processed preprocess_image(image_path) config --psm 6 --oem 1 text pytesseract.image_to_string(processed, langchi_simeng, configconfig) return text.strip() if __name__ __main__: if len(sys.argv) 2: print(用法: python ocr.py 图片路径) sys.exit(1) result ocr_image(sys.argv[1]) print(result)运行方式很简单python ocr.py sample.png4. 实操过程与效果测试4.1 准备三类测试样本光有脚本还不够得用真实样本验证。我分别准备了三种典型图片第一类是电脑截图字体清晰、排版规整第二类是手机拍的书籍页面有透视变形和阴影第三类是扫描仪的灰度扫描件有轻微噪点和倾斜。这三种基本覆盖了日常用到的场景。测试环境我记录一下方便大家对照Ubuntu 22.04Tesseract 4.1.1OpenCV 4.5.4Python 3.10CPU是普通的四核处理器。识别单张A4扫描件的速度大约在2到5秒之间具体取决于文字密度。4.2 有无预处理的对比为了验证预处理的价值我对同一张手机拍摄的页面分别跑了“直接识别”和“预处理后识别”两组测试。直接识别的结果惨不忍睹整段文字里能正确认出的不到一半很多笔画被阴影干扰连成了黑块。而经过灰度、去噪、二值化处理之后虽然仍有个别字误判但整体段落已经能顺畅阅读。测试样本直接识别正确率预处理后正确率耗时电脑截图约95%约98%1秒内手机拍摄页约50%约85%3秒左右扫描件约80%约95%2秒左右手机拍摄那组提升最明显原因就是原图里有大量阴影和反光预处理把这些问题大幅缓解了。这也印证了我前面的观点识别率瓶颈往往在图像质量而不在引擎本身。4.3 PSM参数的实战调优我在测试中特别对比了不同的PSM参数。对于整页扫描件--psm 3全自动版面分析有时候会把栏目标题和正文分开处理输出顺序会比较乱而--psm 6把整页当一个文本块按从上到下、从左到右的顺序输出对于单栏文档更稳定。但如果是多栏的杂志页面--psm 6反而会把两栏文字混读成一整段这时就必须用--psm 3让引擎自动识别栏位。我的实操经验是先看一眼你的页面版面结构再决定PSM值别指望一个参数通吃所有场景。正是因为这个原因我在脚本里把PSM做成了可选参数而不是写死。def ocr_image(image_path, psm6, langchi_simeng): processed preprocess_image(image_path) config f--psm {psm} --oem 1 text pytesseract.image_to_string(processed, langlang, configconfig) return text.strip()4.4 中英文混合场景的表现技术手册里有很多中英文混排的情况比如“在Linux终端中执行make命令”这种句子。我测试下来Tesseract的chi_simeng混合模式大体能用但偶尔会把中文句子里的英文单词拆错。比如把“make”识别成“m ake”或者把“API”认成“AP1”。遇到这种情况我的对策不是改引擎而是在后处理阶段加规则。比如对单词级别做一次小写/大写的模式检查如果一串大写字母中间夹着数字就把它标出来让人工确认。OCR本来就不可能做到百分之百准确关键是让机器把高置信度的内容自动处理掉把低置信度的内容暴露出来。5. 常见问题与排查实录5.1 识别结果全是乱码这是被问得最多的问题。先检查两件事语言包有没有装以及lang参数有没有传对。很多人在代码里写了langchi但Tesseract的语言代码是chi_sim一个拼写错误就会让引擎退回默认英文模式。在终端里跑tesseract --list-langs确认当前有哪些语言然后再对照代码里的参数基本能定位问题。另外乱码也可能是图片本身的问题比如彩色背景上的反白文字二值化之后文字和背景被反转了。遇到这种情况可以在二值化后加一步判断如果前景像素占比过高说明黑白色可能对调要用cv2.bitwise_not反转过来。5.2 某一行总是识别错如果你发现图片整体识别不错但特定行反复出错多半是那行的图片质量有问题比如字体过小、笔画连在一起、或者有下划线干扰。一个实用技巧是先把那一行裁出来单独测试用cv2把坐标范围切出来再用--psm 7按单行识别往往比整页识别的成功率更高。我专门写过一个调试模式把中间步骤的图像保存下来方便肉眼检查def debug_preprocess(image_path, output_prefix): img cv2.imread(image_path) gray cv2.cvtColor(img, cv2.COLOR_BGR2GRAY) cv2.imwrite(f{output_prefix}_1_gray.png, gray) denoised cv2.medianBlur(gray, 3) cv2.imwrite(f{output_prefix}_2_denoised.png, denoised) binary cv2.adaptiveThreshold( denoised, 255, cv2.ADAPTIVE_THRESH_GAUSSIAN_C, cv2.THRESH_BINARY, 15, 8 ) cv2.imwrite(f{output_prefix}_3_binary.png, binary) return binary把每一步的图存下来你会发现问题出在哪一步非常直观。有一次我发现中值滤波的核设成了5把笔画的细线都抹掉了文字看起来发虚就是靠这种调试方式发现的。5.3 同一个字反复被认错像“已”和“己”、“日”和“曰”这类形近字任何OCR引擎都会犯迷糊。Tesseract有一个黑名单机制但形近字不是靠黑名单能解决的因为它们在字形上确实接近。我的经验是对于专业术语库提前做一次术语替换是最高性价比方案。比如你的文档里反复出现特定产品名先跑一遍OCR再用关键词替换把识别成错别字的术语批量修正比逐字校对快得多。Tesseract也支持设置字符白名单如果你确定文档只包含数字和某些符号可以这样限制text pytesseract.image_to_string( processed, langeng, config--psm 7 -c tessedit_char_whitelist0123456789-. )这个功能在处理验证码、序列号这类确定性内容时非常有用能直接排除掉字母被误判成数字之类的问题。5.4 速度慢到无法接受如果批量处理大量图片单张两三秒累积起来也很可观。先检查是不是每一张图都在做同样的大图缩放如果原图分辨率很高前面提到的放大操作反而会增加无谓的计算量。另一个提速思路是降低图像尺寸到合适的范围一般宽度在2000像素左右足够Tesseract识别了太高的分辨率并不会带来精度提升只会拖慢速度。如果能接受并行处理可以考虑用多个子进程同时跑不同文件。Tesseract的引擎是单线程的但多开几个进程就能吃满多核CPU。我在批量脚本里用了concurrent.futures的进程池四核机器上处理时间基本缩短到原来的三分之一。6. 扩展从单张图片到批量流水线6.1 批量识别目录下所有图片单张识别只是为了验证逻辑真实使用场景一定是批量。下面这个脚本会把某个目录下所有常见格式的图片识别成同名文本文件import os import glob from concurrent.futures import ProcessPoolExecutor def batch_ocr(folder): images glob.glob(os.path.join(folder, *.png)) \ glob.glob(os.path.join(folder, *.jpg)) \ glob.glob(os.path.join(folder, *.jpeg)) with ProcessPoolExecutor() as executor: results executor.map(ocr_image, images) for image, text in zip(images, results): output os.path.splitext(image)[0] .txt with open(output, w, encodingutf-8) as f: f.write(text) print(f完成: {image} - {output})用进程池而不直接用循环是因为OCR是典型的计算密集型任务多核并行收益非常明显。但要注意进程池同时跑的进程数不要超过CPU核心数太多否则上下文切换的开销会抵消并行收益。我在四核机器上设的默认最大进程数就是4。6.2 把PDF变成可检索文档如果原始文件是扫描版PDF你还需要先将PDF拆成图片。这里可以用pdftoppm它是Poppler工具集里的命令专门把PDF页面转成图片pdftoppm -png -r 300 input.pdf page-r 300指定输出分辨率为300 DPI这个数值对印刷体文字来说已经非常充裕。转换后对每一张图片跑OCR最后再按顺序把识别文本合并成一个txt文件整个流程相当顺畅。另一种更省事的选择是直接用之前提过的OCRmyPDF它能把扫描版PDF转成带文本层的可检索PDF。简单来说就是给每一页“贴”一层透明的识别文字这样PDF既能看扫描原图又能搜索和复制文字ocrmypdf -l chi_simeng --deskew input.pdf output.pdf我个人的体会是OCRmyPDF适合“只要结果、不想折腾”的场景而自己写脚本适合需要对接后续处理的场景比如识别结果还想进数据库做检索那肯定还是自己控制流程更灵活。6.3 和截图工具配合使用日常使用中最频繁的场景其实是截图OCR。我习惯用一个最简单的办法先在桌面截图再把截图文件丢给上面的脚本。如果你有自动化的需求可以找一个支持“截图后执行命令”的工具或者自己写一个热键脚本用内置的截图命令截取区域、保存到固定路径、再自动调用OCR脚本。这样从截图到看到识别文本的整个过程只需一两秒钟体验已经和商用截图OCR工具差不多了。效率提升的关键是把识别结果直接复制到剪贴板而不是手动选中再复制。在命令行里可以用管道把结果接到系统的剪贴板工具不同发行版命令不一样自己查一下就行脚本逻辑完全一致。最后说一个我踩过几次坑之后的体会OCR项目里最花时间的往往不是模型而是把图片处理成模型预期的样子。很多人一开始就纠结要不要训练自己的模型其实先把手头这批图片的预处理调好、PSM参数选对、后处理规则补齐识别率已经从“不可用”变成“堪用”了。真到某类特定字体反复出错、规则修不掉的时候再考虑进阶的模型微调也不迟。我对这套方案的另一个建议是把每次调参的对比结果记下来比如哪类文档适合哪个PSM值、什么格式的图片需要先放大这些经验积累起来之后你的OCR流水线会越用越顺手遇到新样本时也能更快找到合适的处理路径。