简介：面向需要快速实现图片文字提取的开发者、办公人员与信息化建设者，一套聚焦开源工具和在线服务两条应用主线的OCR识别示例：提供简洁可运行的Python程序与配套测试样张，帮助读者绕过环境配置与接口调用的常见障碍，将OCR能力落地到档案数字化、金融票据录入、医疗信息提取、教育资料整理等实际场景中。资源包共3个文件，包含2个Python脚本（分别承担基础识别演示与可扩展测试入口的功能）及1张费用单据样图，压缩包仅2.03MB，体量轻巧、结构直观，尤其适合初次接触OCR的初学者快速上手验证。目前已有190人次浏览学习。通过研读代码，使用者可掌握Tesseract等开源OCR引擎的调用方法，理解图片预处理、识别参数调优、结果输出与异常处理等关键环节，还可利用随包样图直接检验识别效果，为更复杂的文档自动化处理打下扎实基础。

1. OCR 不是「把图变文字」：真正决定文档识别能否落地的三件事

很多人以为 OCR 就是把图片变成文字，其实真正决定一套文档识别系统能不能上线的，是引擎选型、图像预处理和出错后的人工兜底这三件事。从纸质合同扫描件到可检索的电子档案，中间隔着倾斜校正、降噪、语言包匹配、表格结构还原和置信度过滤五道坎。开源工具（Tesseract、PaddleOCR）能覆盖大多数批量识别需求，在线服务适合轻量、偶发且不涉敏感的场景。本文面向要做文档数字化、票据录入、批量归档的从业者，把原理、代码、参数和坑一次讲透，让你从「能跑」进到「好用」。

2. 选型定生死：开源引擎与在线服务的成本、质量、隐私差异

选型是整套 OCR 方案里成本最低、但返工代价最大的一步。引擎选错，后面所有预处理和参数调试都在错误的地基上打转。做选型时不要只盯着「识别率」一个指标，要把文档类型、日处理量、隐私约束这三件事摆到桌面上，再决定用本地开源引擎还是云端服务。

2.1 开源方案：Tesseract 与 PaddleOCR 的定位差异

Tesseract 是老牌开源 OCR 引擎，从 1980 年代一直迭代到现在，识别核心早已切换到 LSTM 神经网络。它的优势是轻、稳、依赖少：一个二进制程序加几个语言包就能跑，部署在 1G 内存的服务器上也不吃力，批量处理几百页普通文档吞吐很稳。不足也很明显：它的定位是「整页文本提取」，对表格、多栏、图文混排这类需要版面理解的任务，默认输出会把结构压平，中文字形识别和词语切分也只能算及格。

PaddleOCR 定位完全不同。它把检测、方向分类、识别拆成三段模型，内置文字区域检测网络，中文印刷体和常见手写体识别率在公开评测里普遍优于 Tesseract，对版面稍微复杂的图片也能先定位再识别。代价是环境重：Python 包多、模型文件大、加载后吃内存。我用 2 核 4G 的机器批量跑文档时，PaddleOCR 单张图延迟明显高于 Tesseract，并发一上来内存就报警；换到 8G 机器才跑得从容。

所以选型不要先问「哪个识别率高」，要先问「我的文档是什么形态」。纯英文、多语种混杂但以欧文字形为主、机器资源紧张，先试 Tesseract 足够；以中文为主、版式相对规整、没有硬件压力的，直接上 PaddleOCR 能省掉后面大量调参时间。我在实际项目里两套都维护着，对外统一封装同一个识别接口，内部按文档类型路由到具体引擎，这样换引擎不伤业务代码。

2.2 在线服务：什么场景才值得把文档送出去

在线 OCR 服务的优势，说白了就是「用钱买时间和质量」。云端通用文字识别、表格识别、票据识别、证件识别都经过海量真实样本训练，对印章、表格线、证照底纹的鲁棒性远不是本地开源模型能比的。调用方式也简单，传图拿 JSON，不需要自己管 DPI、阈值、语言包这些细节。适合三类场景：低频偶发的单张识别、识别质量要求极高的票据证件、以及手机随手拍且光照复杂的图片。

但把文档送出内网之前，必须先过三道审查：敏感信息出不出得去、单页费用能不能覆盖预算、批量任务有没有并发与总量限制。合同、简历、订单、银行回单这类数据，多数机构的合规要求不允许外传；就算允许，一天几万张的量走在线接口，按页计费非常可观，出问题后定位还难。另一个隐性坑是格式兼容：有的服务对 PDF 直接上传有页数限制，或者要求图片小于某个尺寸，批处理时要把大 PDF 切页成图再传，这一步反而成了新增的工程。

我一般的经验是：在线服务只放在「人工复核台」用。系统里识别失败、置信度低的页面，丢给云端接口二次识别，再由人工确认；全量批量任务永远走本地开源引擎。这样既保住了隐私和成本，又能在关键时刻借到在线模型的质量兜底。

2.3 一页纸拍板：按文档类型、单量、隐私三个维度定方案

选型结论可以用一张表收住。判断顺序是：先看文档能不能出网，不能出就直接本地；能出再看日单量，量大必须本地批处理，量小才考虑在线；最后看文档形态，表格票据类优先专用模型，整页文本类开源引擎足够。

3. 本地跑通最小方案：环境准备、图像预处理与三段式识别代码

选型定了之后，第一件事不是写业务代码，而是先在命令行里把引擎跑通。 OpenCV 负责图像预处理，pytesseract 负责调用 Tesseract，PIL 负责图像格式转换，这三者组合是开源 OCR 最常见的搭档。下面这套最小方案，能让你从一张图片走到可用的文本输出。

3.1 环境准备：两条命令装完依赖，先验证引擎能跑

Debian/Ubuntu 系的安装命令如下，macOS 用户把apt-get换成brew，Windows 用户直接下载安装包并把tesseract.exe所在目录加入 PATH。

# 安装引擎与简体中文语言包 sudo apt-get install -y tesseract-ocr tesseract-ocr-chi-sim # 安装 Python 调用库与图像处理库 pip install pytesseract opencv-python pillow # 验证引擎与语言包是否就绪 tesseract --version tesseract --list-langs

pytesseract 只是调用壳，真正干活的是 tesseract 二进制，所以tesseract命令必须在 PATH 里。--list-langs输出里能看到chi_sim，说明中文语言包装好了；看不到就重装语言包，最常见的启动报错就是语言包缺失，提示Failed loading language 'chi_sim'。Windows 用户还容易踩另一个坑：pytesseract 找不到 tesseract 的可执行路径，需要在代码里手动指定pytesseract.pytesseract.tesseract_cmd = r"C:\Program Files\Tesseract-OCR\tesseract.exe"。

提示：先跑通命令行再写代码，命令行都识别不出来的图，换到 Python 里一样识别不出来。

3.2 预处理三步：灰度、二值化、降噪，从糊图到清晰文本

预处理是 OCR 里最像玄学的环节，但有一套默认组合可以先兜底：灰度化去掉颜色干扰，中值滤波去掉椒盐噪声，OTSU 自动二值化把文字变成黑底白字。下面是完整代码。

import cv2 import numpy as np def preprocess(image_path: str): """读取图片，灰度化、去噪、二值化，返回处理后的图像。""" img = cv2.imread(image_path) if img is None: raise FileNotFoundError(f"读取失败: {image_path}") # OCR 基本不需要颜色信息，灰度化可以降计算量并降低噪声 gray = cv2.cvtColor(img, cv2.COLOR_BGR2GRAY) # 3x3 中值滤波，去除扫描产生的椒盐噪点，同时保留文字边缘 gray = cv2.medianBlur(gray, 3) # OTSU 自动计算阈值，让文字变黑、背景变白 _, thresh = cv2.threshold(gray, 0, 255, cv2.THRESH_BINARY + cv2.THRESH_OTSU) return thresh if __name__ == "__main__": thresh = preprocess("sample.jpg") cv2.imwrite("sample_pre.png", thresh)

灰度化是必须的第一步，颜色通道对字符特征没有帮助，反而把印章、彩色底纹等噪声带进识别流程。中值滤波窗口取 3 是经验值：窗口太小没效果，窗口太大容易把细笔画磨断。OTSU 是全局自适应阈值，适合光照均匀的扫描件，是默认首选；后面第四章会讲光照不均时怎么换成局部阈值。预处理结果sample_pre.png应该是一张黑白分明的图，如果背景还有大块灰斑，先调整这一步，不要急着调识别参数。

3.3 识别调用：最小识别代码与中文语言包加载

把预处理后的图像交给 pytesseract，就能拿到文本。注意 pytesseract 底层走 PIL，OpenCV 的图像是 numpy 数组，中间要转一次格式。

import pytesseract from PIL import Image def ocr_image(thresh, lang="chi_sim+eng", psm=6): """对预处理后的图像执行文字识别。""" return pytesseract.image_to_string( Image.fromarray(thresh), lang=lang, config=f"--psm {psm}" ) # 调用示例 text = ocr_image(thresh, lang="chi_sim+eng", psm=6) print(text)

lang="chi_sim+eng"表示简体中文和英文混排识别，顺序不影响结果；chi_sim是简体中文语言包，繁体中文用chi_tra。psm=6是页面分割模式，表示「假设图像是一个规整的文本块」，对整页文档最常用。如果图片里有表格、多栏、零散文字，这个参数要换，第四章细讲。Image.fromarray(thresh)这步少写了会直接报类型错误，是新手最常见的卡点。

注意：lang配错时引擎不会报错，只是识别结果变成一堆乱码。先tesseract --list-langs确认语言包存在，再设置lang参数。

3.4 结构化输出：把结果写回文件而不是只打控制台

识别结果不能只print，要落盘。纯文本适合阅读和检索，但要做版面还原、关键词定位、搜索高亮，纯文本丢掉了所有坐标信息。此时应该导出 hOCR 格式，它把每个词的包围盒（bbox）和置信度写进 XML，几乎不用额外加工就能对接下游。

# 纯文本保存：适合直接阅读和全文检索 with open("out.txt", "w", encoding="utf-8") as f: f.write(text) # hOCR 结构化保存：带文字坐标和置信度，便于二次加工 hocr = pytesseract.image_to_pdf_or_hocr( Image.fromarray(thresh), lang="chi_sim+eng", config="--psm 6" ) with open("out.hocr", "wb") as f: f.write(hocr)

这条经验是拿血泪换来的。早期我只存 txt，后来要做关键词定位和版面复现，发现 txt 里根本没有坐标信息，全部重新跑了一遍识别。如果你预判后续要做高亮、切块、比对，起步就直接存 hOCR。config里还能叠加白名单，比如纯数字场景用-c tessedit_char_whitelist=0123456789大幅缩小候选集，但要小心白名单对中文不友好，只建议在专用工单号、金额字段上用。

4. 把识别率从「能用」往「好用」拉：关键参数与工程调优

引擎装好、代码跑通，这时候识别率可能只有七八成，卡在「能用」的及格线上。往「好用」走，靠的是把参数吃透。Tesseract 的可调参数有上百个，但真正决定成败的只有三类：页面分割模式（psm）、识别引擎模式（oem）、以及图像输入的 DPI 与阈值策略。这三个调对了，识别率上九成不夸张。

4.1 psm 页面分割模式：选错分割，再好的引擎也白给

psm 全称 Page Segmentation Mode，告诉引擎「你怎么看待这张页面的布局」。Tesseract 默认自动推测，但自动推测经常出错。常用模式就这几个：

实际调试顺序我一般是这样的：默认先跑--psm 6，如果输出文字顺序错乱但内容都识别出来了，换成--psm 3或--psm 4；如果部分文字整段被吞，换成--psm 11试试，它不强制文本框排序，能捞回零散字符；纯标题、纯一行字，直接--psm 7，识别率和速度都会好很多。psm 是回报率最高的参数，选错再好的引擎也白给，选对识别率立涨。

4.2 语言包与 oem：什么时候该切换识别引擎模式

语言包影响字符集，oem 影响底层识别引擎。语言包按需安装，简体用chi_sim，繁体用chi_tra。注意不要把简繁同时开，混排时引擎会反复切换，准确率反而下降。中英混排设lang="chi_sim+eng"即可。oem 有四个取值：0 用传统引擎，适合模糊扫描件和旧字体；1 用 LSTM 引擎，适合清晰印刷体；2 两者结合；3 自动选择，默认值。一般来说--oem 3就可以，遇到低清老扫描件时改成--oem 0往往有惊喜，打印体清晰文档用--oem 1更稳。

4.3 DPI 与自适应阈值：工程里被忽略的两个隐性杀手

手机拍屏幕的图、低清扫描件，DPI 往往只有 72 到 96，文字笔画只有一两像素宽，LSTM 提取不到稳定特征。这时候放大再锐化是最高性价比的处理。

# 放大三倍并锐化，再做二值化 scale = 3 resized = cv2.resize(gray, None, fx=scale, fy=scale, interpolation=cv2.INTER_CUBIC) blur = cv2.GaussianBlur(resized, (0, 0), 1) sharp = cv2.addWeighted(resized, 1.6, blur, -0.6, 0) _, thresh = cv2.threshold(sharp, 0, 255, cv2.THRESH_BINARY + cv2.THRESH_OTSU)

INTER_CUBIC是三次插值，放大后边缘比默认的线性插值更平滑；锐化系数 1.6 和 -0.6 是经验值，边缘增强过大反而会出现白边干扰识别。如果源文件是 PDF 里嵌的低清图，直接用工具把 PDF 按 300 DPI 重新渲染成图片，效果比任何后处理都好。

光照不均、复印件发灰时，OTSU 的全局阈值会把暗部文字切碎，这时候换成自适应阈值，按局部窗口计算阈值：

thresh = cv2.adaptiveThreshold( gray, 255, cv2.ADAPTIVE_THRESH_GAUSSIAN_C, cv2.THRESH_BINARY, 41, 15 )

blockSize=41是局部窗口大小，必须是奇数，一般 31 到 51 之间；窗口太小会把笔画误判为背景，太大又退化成全局阈值。C=15是常量偏差，相当于阈值再减 15，C 越大背景越容易干净。打印件 C 取 15，扫描底灰重的取 20 以上。这一组参数对不同扫描仪差异很大，值得做个小实验集多试几个组合。

5. OCR 落地避坑：五个让你翻车的问题与排查路径

跑通容易，上线难。这里整理了我踩过的五个高频坑，每个都按「现象 → 原因 → 解决」写清楚，复制到自己的项目里对照排查，能省下至少一周的调试时间。

5.1 中英文混排识别乱码

现象：中文段落正常，但夹在中间的英文单词被拆成乱码或者整段丢失。原因：Tesseract 按语言字典切词，中英混排时断词错位；英文笔画较细，二值化阈值稍微激进就会断线。解决：lang设成chi_sim+eng是第一步，但更稳定的是把图片按文字区域切块，英文区域单独用eng识别，中文区域用chi_sim识别，最后按坐标合并。

# 对检测出的文字区域分别识别 for x, y, w, h in text_regions: roi = thresh[y:y+h, x:x+w] # 判断区域以英文为主（通过字符像素密度等简单特征） if is_latin_dominant(roi): text = pytesseract.image_to_string(roi, lang='eng', config='--psm 7') else: text = pytesseract.image_to_string(roi, lang='chi_sim', config='--psm 7')

切块识别比整页识别多一道区域检测的工程，但效果立竿见影。如果你的文档中英文混排比例高，这一步不能省。

5.2 表格识别全部串行

现象：识别结果像从左上角到右下角读了一条长字符串，单元格的列位置完全丢失。原因：Tesseract 本身没有表格结构模型，默认把整个表格当成文本流读取。解决：先提取表格横竖线，算出单元格坐标，逐格识别；或者直接换 PaddleOCR 的表格结构模型，输出 HTML 表格。坚持用 Tesseract 的话，用形态学操作提取直线：

# 提取水平线和竖直线 kernel_h = cv2.getStructuringElement(cv2.MORPH_RECT, (80, 1)) kernel_v = cv2.getStructuringElement(cv2.MORPH_RECT, (1, 80)) horiz = cv2.morphologyEx(thresh, cv2.MORPH_OPEN, kernel_h) vert = cv2.morphologyEx(thresh, cv2.MORPH_OPEN, kernel_v) lines = cv2.bitwise_or(horiz, vert)

kernel 长度要和表格线宽度匹配，80 不是固定值，按图片宽度调整。提取出lines后找轮廓，每个闭合轮廓就是一个单元格 bbox，再逐格送入识别。这条路径能跑，但工程量不小；如果表格是项目主场景，建议直接上 PaddleOCR，别在 Tesseract 上死磕。

5.3 红色印章遮挡文字，识别结果全是乱码

现象：合同扫描件里印章盖住了几个字，识别结果在印章位置冒出一串乱码。原因：灰度化后红色印章和黑色文字混在一起，LSTM 把印章笔画误认成字符。解决：在 HSV 空间把红色像素置白后再识别。

hsv = cv2.cvtColor(img, cv2.COLOR_BGR2HSV) # 红色在 H 通道两个区间：0-10 和 156-180 mask1 = cv2.inRange(hsv, (0, 50, 50), (10, 255, 255)) mask2 = cv2.inRange(hsv, (156, 50, 50), (180, 255, 255)) red_mask = cv2.bitwise_or(mask1, mask2) gray = cv2.cvtColor(img, cv2.COLOR_BGR2GRAY) gray[red_mask > 0] = 255 # 印章区域变白

注意 H 通道的上下限要按真实印章颜色微调，暗红色印章把 S 和 V 的下限降到 30 更保险。这个处理在合同扫描件里几乎是必选项，不加的话识别率直接掉两个档次。红色完全盖住文字的情况，去掉印章后文字也丢了，只能靠人工补录，后处理救不回来。

5.4 低分辨率扫描件识别率惨淡

现象：扫描件 DPI 不足，汉字缺笔少画，英文单词串字母。原因：笔画只有 1 到 2 像素，中值滤波加二值化后笔画断裂，LSTM 无稳定特征可提取。解决：放大加锐化（第四章的代码直接可用），但要注意「拍屏幕」这类重噪声图，放大只会放大噪声，应先做去噪再放大。如果 PDF 里嵌入的图本身就是低清，最佳方案是用工具把 PDF 按 300 DPI 重新渲染，比任何后处理都有效。

5.5 艺术字体、花体字整段识别失败

现象：海报、宣传单上的艺术字识别成一批完全无关的字符。原因：开源引擎训练数据以常规印刷体为主，艺术字字形变形大，超出模型泛化能力。解决：不硬扛。先用检测判断文本区域，如果是弯曲排列的文字，尝试透视校正拉直；再不行就用在线 OCR 的通用模型兜底，本地引擎在这种页面上调参的增量收益很低，不值得花时间。

6. 更进一步：批量文档管道与置信度后验技巧

单张识别跑通后，离实际生产还差两步：批量处理和自动质检。批量处理的难点不在识别本身，在于并发控制、内存管理和断点恢复。自动质检更关键，让程序自己把「可能需要人看的页面」挑出来，而不是靠肉眼翻一遍。

6.1 批量管道：用并发把几百份 PDF 的处理时间降下来

from pathlib import Path from concurrent.futures import ThreadPoolExecutor, as_completed def process_pdf(path: Path) -> Path: # 将 PDF 按 300 DPI 转成图片，逐页预处理、识别、落盘 out_txt = path.with_suffix(".txt") # 此处省略 PDF 转图与 ocr_image 调用细节 return out_txt paths = list(Path("inbox").glob("*.pdf")) with ThreadPoolExecutor(max_workers=4) as pool: futures = {pool.submit(process_pdf, p): p for p in paths} for fut in as_completed(futures): try: out = fut.result() print(f"完成: {out}") except Exception as e: print(f"失败: {e}")

OCR 底层是 C/C++ 库，受 Python GIL 影响小，线程池 4 到 8 个 worker 就能把 CPU 跑满，再多反而线程切换开销变大。转图片时务必固定dpi=300，不固定的话同一批 PDF 的识别质量会忽高忽低。另外要按页处理而不是整份 PDF 一次性载入内存，识别完一页就释放一页的引用，避免几百页的大文件把内存打爆。更稳妥的做法是边处理边把结果写进 SQLite，记录每页的状态，进程崩了还能断点续跑，不用从头再来。

6.2 置信度回传：让程序自动标记需要人工复核的页面

识别结果不能全信，但也不能靠人眼一页页看。pytesseract 的image_to_data能返回每个词的置信度，可以据此算出坏词占比，超过阈值就把该页丢进人工复核队列。

data = pytesseract.image_to_data( thresh, lang="chi_sim+eng", config="--psm 6", output_type=pytesseract.Output.DICT ) # 只统计有实际内容的词 words = [w for w in data["text"] if w.strip()] # conf 为 -1 表示无识别结果，需要过滤掉 confs = [int(c) for c in data["conf"] if str(c).isdigit()] bad_ratio = sum(1 for c in confs if c < 60) / len(confs) if confs else 1.0 if bad_ratio > 0.2: # 该页进入人工复核队列 review_queue.put(path)

bad_ratio阈值取 0.2 是经验值，合同、法律文书这类严谨场景建议收紧到 0.1，内部检索场景可以放宽到 0.3。置信度回流这事，一开始被我当成了「额外工作」跳过，结果上线第一周人工返工量翻了近一倍。后来把低置信度页面单独导出、逐页复核，整体效率反而提升明显。我现在养成的习惯是：任何 OCR 管道上线第一天就接上置信度回流，把坏样本留着当下一轮调优的原料。参数不是拍脑袋定死的，是一周一迭代改出来的。希望帮到你。

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