Tesseract直接识别验证码失败率高，因其默认配置专为清晰印刷体设计，而验证码含干扰线、扭曲、噪点等反OCR特征；必须前置灰度化、自适应二值化、去噪、倾斜校正，并强制设置psm=7和LSTM引擎。
为什么直接用 Tesseract 识别验证码大概率失败
不是 Tesseract 不行，而是默认配置完全不适应验证码场景：它专为清晰、规整、高对比度的印刷体文本设计，而验证码通常带干扰线、扭曲字符、噪点、粘连、倾斜甚至动态背景。直接传入原始图片调用 Recognize()，返回空字符串或乱码是常态。
关键在于预处理必须前置——Tesseract 不做图像清洗，你得自己把图“擦干净”再喂给它。
- 先灰度化 + 二值化（
Threshold值需根据图片明暗动态调整） - 去除孤立噪点（小面积连通域过滤）
- 对细干扰线做形态学开运算（
cv2.morphologyEx在 OpenCvSharp 中对应MorphologyEx） - 字符粘连时尝试垂直投影切分，避免单个 ROI 包含多个字符
Tesseract 初始化必须指定 PageSegMode 和 OcrEngineMode
默认的 PageSegMode.Auto 会尝试检测段落、表格、标题结构，对单行验证码反而引入误判。必须强制设为单行模式；同时启用 LSTM 引擎（新版 Tesseract 默认仍用旧引擎）。
正确初始化示例：
using (var engine = new TesseractEngine(@"./tessdata", "eng", EngineMode.LstmOnly))
{
engine.SetVariable("tessedit_pageseg_mode", "7"); // 7 = Single line
using (var img = Pix.LoadFromFile("captcha.png"))
{
using (var page = engine.Process(img))
{
string text = page.GetText().Trim();
}
}
}
-
tessedit_pageseg_mode=7是硬性要求，=8（Single word）在字符间距不均时更差 -
EngineMode.LstmOnly比Default对扭曲字体识别率高 30%+，但需要 tessdata v4+ 数据包 - 语言包路径必须指向
tessdata文件夹，不是单个.traineddata文件
验证码太短时，Tesseract 会主动丢弃结果
Tesseract 内部有置信度阈值，对长度 ≤ 3 的识别结果常因“不可靠”直接返回空。这不是 bug，是设计行为——它默认假设用户要识别的是有意义的单词或句子。
绕过方式只有两个：
- 设置
engine.SetVariable("tessedit_char_blacklist", "[]")防止黑名单误杀（某些版本默认禁用数字 0/O） - 关键：调用
page.GetWords()获取每个字符的详细结果，手动拼接并忽略置信度检查 - 示例中取
word.Confidence> 30 的字符，比依赖GetText()稳定得多
训练自定义模型前，请确认你真需要它
90% 的简单验证码（如 4–6 位纯数字+大写字母、无旋转）靠预处理 + 参数调优就能达到 85%+ 正确率。训练 tesstrain 模型成本极高：需生成上万张带标注样本、编译工具链、调试 box 文件格式——且一旦网站换一套字体，全部重来。
更务实的做法：
- 用
ImageMagick.NET或SkiaSharp批量生成相似风格验证码，反向验证预处理流程 - 对固定来源的验证码，保存失败样本 + 人工标注，构建小规模验证集跑 A/B 测试
- 真正难啃的（如汉字、滑动拼图、极坐标扭曲），应优先考虑接口对接第三方服务，而非死磕 OCR
预处理逻辑和 Tesseract 参数组合的微小变化，对识别率影响远大于换模型。调参顺序比模型本身重要得多。
