字符型验证码识别：CRNN+CTC对齐、合成数据与避坑

简介：围绕字符型图片数字验证码识别，这份项目资料以深度学习与Python实现为主线，面向具备一定神经网络基础、希望把CNN/RNN知识落到实处的开发者与安全方向学习者，覆盖数据集准备、图像预处理与归一化、CNN特征提取、LSTM/GRU序列建模、交叉熵训练与模型保存推理的完整链路。包内共1210个文件，主体是978张png与202张jpg验证码样本，配合17个Python训练与推理脚本、txt说明、rst文档、svm_model_file模型文件及若干压缩包与网页文件，整体约9.58MB，样本、代码与说明分层存放，便于按阶段对照阅读。已有1542人学习下载，适合作为课程设计、毕业项目或安全对抗研究的起步案例。读者能跟随源码复现one-hot编码、数据增强、Adam优化、验证集监控与过拟合排错的完整流程，也能理解多模型集成与迁移学习在提升准确率上的取舍。

1. 字符型验证码识别：为什么它更像一个对齐问题，而非分类问题

基于深度学习的字符型图片数字验证码识别，常被当作一个 10 分类任务来理解：输入一张图，输出 4 个数字。但把模型真正推到线上后，麻烦基本都不在分类精度上，而在「哪一列像素对应哪个字符」这个对齐关系上。字符间距随机、笔画粘连、干扰线横穿，任何先切分再分类的流程都会在切分这步崩掉。Python 实现里最容易被低估的环节，是标签与时间步的对应关系，以及合成数据把这种对应关系写进参数的方式。搞懂这条链路，你才能判断手头的任务该用定长多分类头，还是必须上 CRNN 加 CTC 这种序列建模方案，也能看懂源码里每个参数为什么长那样。

2. 预处理链路：为什么验证码该做归一化，而不是做增强

拿到一张 100×40 的验证码图片，直觉反应是「先增强一下，让字符更清楚」。方向恰好反了。验证码的难点从来不是字符太淡，而是干扰信息太像字符：一条一像素宽的彩色斜线，经过锐化或直方图均衡之后，边缘梯度会被放大成类似笔画的结构，CNN 在前几层就会把这些伪边缘当成特征学进去。真实场景里更常见的做法是反着来——先决定扔掉哪些信息，再把剩下的信息压到网络习惯的分布上。

2.1 彩色干扰下，先决定扔掉哪些通道信息

字符型验证码的干扰元素普遍是高饱和纯色，比如红绿蓝的细线、噪点块，而字符本身往往是深灰或黑色。这时候直接用加权灰度公式0.299R + 0.587G + 0.114B未必是最优解，因为它会把一条纯蓝的干扰线压成中灰，和字符亮度撞在一起。一个在工程里更稳的选择是取三通道的最大值：

import cv2 import numpy as np def to_gray(img_bgr, mode="max"): if mode == "max": # 干扰线多是饱和色，单通道值很高；字符偏暗，三通道都低 # 取 max 相当于把彩色干扰"提亮"，后续阈值更容易把它和字符分开 return img_bgr.max(axis=2).astype(np.uint8) # 常规加权，适合字符与背景色差明显、干扰较少的样本 return cv2.cvtColor(img_bgr, cv2.COLOR_BGR2GRAY)

这个mode参数不是玄学，它取决于数据分布：如果线上样本的干扰线颜色与字符亮度接近，取最大值反而会让二值化更乱，那就要退回加权灰度，改用颜色饱和度通道（HSV 的 S 分量）来剥离干扰。判断依据很简单——把两种方式的结果各存 200 张，人工看哪一版字符更连续、干扰更碎。这一步不做，后面网络再深也只是在拟合噪声。

2.2 尺寸与数值归一化：CNN 对输入分布最敏感的两个点

网络的第一层是卷积，它对输入的空间尺寸和数值范围都敏感。尺寸上，验证码常见做法是统一到 32×100 或 32×256，高度固定为 32 是为了配合后面的下采样倍率——高度 32 经过 5 次 2 倍池化后变成 1，宽度方向只做 4 倍下采样，剩下的宽度就变成 CTC 的时间步。如果直接把任意比例的图拉伸到目标尺寸，字符会被横向压扁，同一个「8」在拉伸前后是两种形状，模型要多花很多容量去学这种形变。

数值上更隐蔽的问题是均值和方差。很多人写完x = img / 255.0就结束了，结果训练时 BatchNorm 在第一批就吃掉大部分动态范围，收敛变慢。稳妥的写法是用训练集统计出的固定常量和方差，在推理阶段复用同一组数字：

def normalize(gray, size=(100, 32), mean=0.588, std=0.193): h, w = gray.shape # 保持宽高比缩放，避免字符被横向拉伸变形 scale = min(size[0] / w, size[1] / h) nw, nh = max(1, int(round(w * scale))), max(1, int(round(h * scale))) resized = cv2.resize(gray, (nw, nh), interpolation=cv2.INTER_AREA) canvas = np.zeros((size[1], size[0]), dtype=np.uint8) top = (size[1] - nh) // 2 # 垂直居中 canvas[top:top + nh, :nw] = resized # 右侧补 0，留白不参与字符区域 x = canvas.astype(np.float32) / 255.0 return (x - mean) / std

INTER_AREA而不是默认的双线性，是因为缩小操作下 area 插值相当于对区域求平均，能把细干扰线「平均」掉一部分，而双线性会保留更多高频。mean和std这两个常量必须来自训练集，不能每张图现算——现算等于把每张图的对比度都拉平，反而抹掉了「某些样本本来就很淡」这个真实分布特征，线上遇到淡样本时模型没有见过同类的输入。

2.3 哪些增强能做，哪些会反噬

旋转 ±10 度、轻微透视、随机亮度偏移，这些属于形态层面的扰动，能提升对字体和渲染差异的鲁棒性。但有三类增强在验证码任务上要慎用：锐化、直方图均衡、强对比度拉伸。它们共同的问题是放大了高频细节，而验证码的高频细节绝大部分是干扰线和噪点。用血泪经验讲，一个团队曾把 CLAHE 加进预处理，离线验证集准确率涨了 2 个点，上线后掉 15 个点，原因是真实样本的压缩噪声被 CLAHE 放大成了块状伪影，模型把这些块当成了字符的一部分。

正确的位置是：形态增强放在合成阶段做（见第 4 章），预处理阶段只做确定性的归一化。二者混在一起，你会很难判断指标变化到底来自哪一环。

3. CRNN 加 CTC：不切分字符，网络怎么知道哪一帧对应哪个字

把所有字符先切开再逐个分类，是最符合直觉的方案，也是最早翻车的方案。字符粘连时切点落在笔画内部，切出来的半边「6」和半边「8」在像素上几乎一样；字符间距过大时又会切出空白块。端到端的思路是绕开切分：让卷积网络沿宽度方向输出一串特征列，每一列都带着「当前位置可能是什么字符」的判断，再由序列层把上下文揉进去，最后用一个允许「多输出、可重复、可留空」的损失函数去对齐标签。这个损失函数就是 CTC，它解决的核心问题正是第 1 章提到的对齐。

3.1 特征图怎么被压成一列时间步

输入 32×100 的灰度图，经过若干次卷积和池化，高度被压到 1 或 2，宽度保持相对大。关键在于池化核的设计：高度方向用 2×2 大步下采样，宽度方向用 (2,1) 这种只压高度、不动宽度的核。这样宽度 100 经过 4 倍下采样得到 25 个时间步，每一步对应原图约 4 个像素宽的一条竖直切片。

import torch import torch.nn as nn class CRNN(nn.Module): def __init__(self, num_classes, hidden=256): super().__init__() self.cnn = nn.Sequential( nn.Conv2d(1, 64, 3, 1, 1), nn.BatchNorm2d(64), nn.ReLU(True), nn.MaxPool2d(2, 2), # 32x100 -> 16x50 nn.Conv2d(64, 128, 3, 1, 1), nn.BatchNorm2d(128), nn.ReLU(True), nn.MaxPool2d(2, 2), # -> 8x25 nn.Conv2d(128, 256, 3, 1, 1), nn.BatchNorm2d(256), nn.ReLU(True), nn.Conv2d(256, 256, 3, 1, 1), nn.BatchNorm2d(256), nn.ReLU(True), # 只压高度不压宽度，宽度方向的下采样倍率决定时间步数量 nn.MaxPool2d((2, 1), (2, 1)), # -> 4x25 nn.Conv2d(256, 512, 3, 1, 1), nn.BatchNorm2d(512), nn.ReLU(True), nn.MaxPool2d((2, 1), (2, 1)), # -> 2x25 ) self.rnn = nn.LSTM(512, hidden, 2, bidirectional=True) self.fc = nn.Linear(hidden * 2, num_classes) def forward(self, x): f = self.cnn(x) # (B, 512, 2, 25) b, c, h, w = f.shape # 剩余高度上的所有位置拼进通道维，宽度方向成为时间轴 f = f.permute(3, 0, 1, 2).reshape(w, b, c * h) # (25, B, 1024) f, _ = self.rnn(f) return self.fc(f) # (25, B, num_classes)

num_classes等于字符表大小加 1，那个 1 是 CTC 的 blank 类。时间步 25 意味着网络最多能输出 25 个符号（含重复与 blank），四位验证码绰绰有余；但如果你把宽度压到只剩 8 个时间步，五位以上的字符就基本没戏了——这是长度上限的硬约束，调网络结构时先算清楚这个数。

3.2 blank 与折叠规则：为什么允许输出比标签长

CTC 的设计动机可以用一句话概括：标签是「a b」，但网络输出的是 25 帧，中间隔着大量「没有字符」的位置。blank 就是用来占位的。解码规则是两步：先把连续重复的符号合并成一个，再删掉所有 blank。于是a a blank a折叠后是a a，a blank a折叠后也是a a，这就是为什么会重复的字符必须靠 blank 隔开，否则模型无法区分「一个 a」和「两个 a」。

损失函数不枚举所有路径，而是用动态规划对「所有能折叠成目标标签的路径」的概率求和，再取负对数。路径数随长度指数增长，动态规划把它压到 O(T·L)。工程上直接调用框架实现即可，但有两个参数经常被填错：

import torch.nn as nn ctc = nn.CTCLoss(blank=0, zero_infinity=True) # blank 必须与字符表约定一致 log_probs = logits.log_softmax(2) # (T, B, C)，必须先取 log input_lengths = torch.full((batch,), logits.size(0), dtype=torch.long) target_lengths = torch.tensor([len(t) for t in targets], dtype=torch.long) loss = ctc(log_probs, targets_concat, input_lengths, target_lengths)

input_lengths填的是每个样本实际经过 CNN 后的时间步数，不是原图宽度。如果一批样本做了 padding，短样本后面补的是无效帧，必须按真实宽度折算后的步数填，否则这些空白帧会参与路径计算，把 loss 拉偏。zero_infinity=True是防御性设置：当某个样本的时间步数少于标签长度时，CTC 的概率为 0，log 后是无穷大，这一个样本就能把整批梯度炸掉。

3.3 手写解码时最容易错的一行

推理阶段很多人手写 greedy 解码，然后在一个符号顺序上出错：

def greedy_decode(logits, blank=0): idx = logits.argmax(dim=2).transpose(0, 1) # (B, T) results = [] for seq in idx.tolist(): out, prev = [], None for k in seq: # 先判「和上一个原始输出不同」再判「不是 blank」 if k != prev and k != blank: out.append(k) prev = k # 关键：prev 要无条件更新，包括 blank results.append(out) return results

prev的更新必须放在判断之外，且要包含 blank。写成「不同就更新，否则跳过」的话，a blank a这种序列在处理第二个 a 时看到的 prev 还是 a，会被误判成连续重复而丢掉。这个 bug 的特点是 loss 正常下降、训练一切看起来健康，只有推理结果里偶尔少字符，而且频率随字符间距变化——非常难从指标上发现。

3.4 序列层的上下文到底值多少

双向 LSTM 的作用是让每一帧在看到自身切片的同时，也知道左右邻域在发生什么。对验证码来说，这个上下文主要用来消歧：「0」和「O」、「1」和「l」、「5」和「S」这类字形冲突，单帧特征几乎无法区分，但左右字符的组合能提供强约束。把 BiLSTM 去掉、直接用 CNN 特征接全连接加 CTC，在四位数字上也许能跑到相近准确率，因为数字字形差异本来就大；一旦字符表扩展到字母和大小写混合，差距立刻显现。这也是后面章节讨论取舍时的分界线之一。

4. 合成数据引擎：泛化上限在训练开始前就被定死了

真实验证码样本的采集成本高、标注成本更高，而且几乎拿不到覆盖全字符表的均衡数据。主流做法是用真实样本统计出风格参数，再写一个合成引擎批量生成带标签的图片。这个引擎的设计质量，直接决定了模型的天花板——训练策略调得再细，也补不回合成分布里缺失的那部分。

4.1 把真实分布翻译成参数

拆开看，一张验证码图片由这些因素决定：背景色、字符颜色、字体、字号、字符数与间距、旋转与透视、干扰线、噪点、压缩伪影。前六项决定形态，后三项决定噪声。合成引擎要做的不是随机乱撒，而是让每个因素的取值范围贴近线上采样统计。

最容易拉开差距的参数是字符间距。让它取负值，字符就会自然粘连，而粘连正是 CTC 存在的理由。如果合成数据里字符永远整整齐齐互不接触，训出来的模型遇到一点点粘连就掉点，你会误以为是模型容量不够。

import random from PIL import Image, ImageDraw, ImageFont def random_sample(char_pool, fonts, count=None): # count 为空时随机长度，模拟线上位数不固定的情况 n = count if count else random.choice([4, 5, 6]) text = ''.join(random.choice(char_pool) for _ in range(n)) bg = tuple(random.randint(200, 255) for _ in range(3)) img = Image.new('RGB', (160, 48), bg) draw = ImageDraw.Draw(img) x = random.randint(2, 6) for ch in text: font = ImageFont.truetype(random.choice(fonts), random.randint(26, 34)) step = random.randint(-4, 10) # 负值制造粘连，CTC 才能学到边界 color = tuple(random.randint(0, 120) for _ in range(3)) draw.text((x, random.randint(-3, 5)), ch, font=font, fill=color) # 用字符实际包围盒宽度推进，避免固定宽度导致的字距失真 bbox = font.getbbox(ch) x += (bbox[2] - bbox[0]) + step img = img.rotate(random.uniform(-12, 12), resample=Image.BICUBIC, expand=False) return img, text

char_pool是字符表，必须和推理时的标签映射严格一致，顺序都不能变——后面排查章节会专门讲这个坑。step的取值范围要靠线上样本的字符间距分布来定，取-4到10只是个起点，真实样本如果普遍偏紧凑，上限就该往下压。字体池至少要覆盖几种常见字重和衬线/无衬线两类，单一字体会让模型对字形变化的泛化能力极差。

4.2 干扰项要「像噪声」而不是「像字符」

干扰线、噪点、背景纹理这三项，很容易在实现时不自觉地往「更像字符」的方向设计。比如画一条有粗细变化的曲线，网络会试图把它解释成某个笔画；更好的做法是画固定宽度、角度随机的直线，或者用低不透明度的色块，让它们在特征层面明显区别于字符。

背景纹理同理。纯白背景合成的模型，一遇到带噪底的样本就崩，但如果你把背景做成复杂的棋盘格，模型又要花大量容量去忽略背景。折中的做法是从线上样本里裁出小块背景做底图，粘贴再叠加字符，这样背景分布天然对齐。

4.3 训练闭环里的三个判断线

结构定好、数据管道通了之后，训练过程里真正需要盯的只有三件事。

第一是学习率和 warmup。CTC 在早期非常脆弱：如果一开始学习率就设成 1e-3，模型倾向于把大部分时间步都预测成 blank（因为这样 loss 下降最快），一旦塌陷到「全 blank」，梯度就再也不会把它拉回来，现象是 loss 卡在某个值附近几乎不动。常见的做法是前 500 到 1000 步线性 warmup，从 1e-5 到 3e-4，再看曲线决定是否加余弦退火。

第二是验证集的构成。如果验证集也是合成器产的，指标会虚高得离谱，因为训练集和验证集共享同一套参数分布。一定要留一部分真实样本作为「难验证集」，哪怕只有两三百张，它的趋势比大合成验证集的绝对值更有参考价值。判断早停时看整串准确率，不要看单字符准确率——后者会给你虚假的安全感，四个字符各 97% 的准确率，整串就只有 88%。

第三是梯度裁剪。序列模型加 CTC 在某些样本上会突然产生尖峰梯度，裁剪阈值设 5 左右能救回不少批次。配合混合精度训练时注意 CTC loss 的数值稳定性，log_softmax要在大数值范围下算，必要时对 logits 做 clamp。

4.4 训练规模的现实估算

按经验给个量级：四位数字、字符表 10 类、字体 5 种，合成 20 万张能训到合成验证集 99% 以上，真实样本 90% 上下；想把真实样本推过 97%，通常需要在 20 万张的基础上补几千张真实样本做微调，并且把学习率降到 1e-4 以下。五位混合字母数字的任务，字符表扩到 36 类以上，合成量级要翻一到两倍。这个数字不是绝对的，但它反映一个事实：字符表和长度的增长，对数据量的需求是超线性的。

5. 避坑排查：五类把准确率吃掉的典型翻车

5.1 现象：loss 卡住不动，解码结果全是空

原因几乎总是 CTC 早期塌陷。学习率偏大、warmup 缺失，或者 batch 里短样本的时间步被错误地按 padding 后的长度填进input_lengths，都会让模型在头几百步就学会「全输出 blank」这个局部最优。

排查顺序是先打印前 100 步每个 batch 的input_lengths和target_lengths，确认没有任何样本的标签长度超过时间步数；再确认CTCLoss的blank索引和网络输出的类别顺序一致；最后把学习率降到 1e-4 重跑。如果还是不动，把模型输出在初始阶段的可视化一次——正常情况下第一个 epoch 里非 blank 类的概率应该缓慢抬升。

5.2 现象：离线验证集 99%，线上只有 60%

这是最常见也最伤的情况，根源是合成分布和真实分布错位。差异点往往不在字体，而在渲染链路：真实图片经过 JPEG 压缩、缩放、抗锯齿，字符边缘是渐变的；合成图用 Pillow 直接绘制，边缘是硬切的。模型在硬边缘上训出来的特征，遇到渐变边缘就失效。

解决办法是逆着链路补：合成完之后随机做一次质量 60 到 90 的 JPEG 压缩再解开，随机缩放到 0.7 到 1.2 倍再缩回目标尺寸。这两个操作成本极低，但对线上准确率的影响经常在两位数百分点。做完之后再用两三百张真实样本微调，效果比单纯调网络结构明显得多。

5.3 现象：位数一变，整个模型失效

定长多分类头的模型，训练时假设全是 4 位，遇到 5 位图时，四个输出头会各自抢字符，结果面目全非。即使换了 CTC，如果训练数据全是 4 位，模型在推理时遇到 6 位也极不稳定，因为它在训练中从未见过时间步被「用满」的情况。

处理方式是合成阶段就把长度做成随机分布，并且让最短和最长都出现在每个 epoch 里。另外要检查input_lengths的计算是否随宽度动态变化——固定填时间步总数而不按实际宽度折算，长度短的样本会被 padding 帧干扰，表现出的症状和这个坑很像。

5.4 现象：解码结果字符重复、顺序错乱，但 loss 正常

这是解码逻辑的 bug，不是训练问题。两个高频错误：一是prev未在 blank 时更新，导致a blank a被折叠成一个 a；二是标签映射表的顺序在训练脚本和推理脚本里不一致，训练时把字符表按字典序排，推理时按出现顺序排，模型输出的索引全部错位。

排查很直接：拿一张训练集里的图，先用训练脚本里的映射解码，再用推理脚本里的映射解码，两边结果应该完全一致。不一致就说明映射表有问题。同时写一个单元测试，输入构造好的[a, a, blank, a]序列，断言解码结果是[a, a]，这个测试能在后续任何重构里挡住回归。

5.5 现象：整体准确率尚可，但混淆矩阵集中错在某几个字符

个别字符的准确率长期偏低，通常是三类原因叠加。字形冲突（0/O、1/l/I）需要靠增加字符表内的区分样本，或者在损失上对那些类加权；训练样本分布不均，某些字符在字符表里被采样到的次数偏少，检查合成器的random.choice是否均匀，有没有因为某种字体缺少该字符而静默跳过；预处理把特定颜色字符吃掉了，比如深蓝字符在取通道最大值后和背景撞在一起。

定位方法是按字符维度统计真实验证集的错误分布，再按字体、颜色、长度分组看准确率。分组指标一旦做出来，问题基本自己浮出水面；只盯一个总体数字，永远只能靠猜。

6. 取舍与验证：什么时候该放弃 CTC 回到简单分类

把整条链路走完，最后一个问题其实是架构选型：到底要不要上 CRNN 加 CTC。

如果任务是固定 4 位纯数字、线上不做对抗升级、推理侧对延迟极敏感（比如要在毫秒级完成），那么一个纯 CNN 加四个独立的分类头是更划算的方案。它训练快、推理快、实现简单，四位数字的字形差异足够大，序列层的上下文带来的增益有限。反过来，一旦出现字符粘连、位数浮动、字符表含字母，CTC 的优势立刻体现，因为定长多分类头在粘连图上会稳定地把两个粘连字符判成一个。

验证方法上，我更看重分组统计而不是总体准确率。按字符长度分组、按字体分组、按是否有干扰线分组，三张表能告诉你模型在哪一类样本上是真的学会了，哪一类是碰巧蒙对。再配一个混淆矩阵，把 Top 5 的混淆对列出来，基本就能判断下一步该补数据还是改预处理。上线前还要做一次「反向验证」：把验证集的图做一次 JPEG 压缩再测，如果准确率下跌超过几个点，说明模型对渲染链路过于敏感，线上的波动会远大于验证集。

这套思路是我踩过几次坑之后才定下来的。早期我总盯着验证集的最高分，觉得模型没问题，线上数据一接进来就傻眼，回头才发现合成器和真实样本差了一整个压缩链路。从那以后我每次开新任务，都强制先跑一遍「真实样本小验证集」，哪怕只有五十张，也必须在训练开始前就把这个指标建起来，不然之后所有的调参都建立在虚高的数字上。这份完整实现把合成、预处理、CRNN、CTC 解码和真实样本微调串成了一条能跑通的链路，源码里每一环的参数都留了注释，按自己的数据分布改一改就能用，值得拿来对着走一遍。希望帮到你。

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