从图片到坐标：用 ddddocr 1.3 搭建中文验证码识别流程

验证码在自动化系统里经常扮演“最后一道人工确认”的角色。对开发者来说，真正麻烦的地方通常不是打开页面，而是识别图片内容、找到目标位置，再把结果准确地交给前端组件。中文验证码尤其容易出现字体变形、字符粘连、背景干扰和坐标缩放等问题，单纯依赖截图加鼠标点击往往很不稳定。

ddddocr 1.3 提供了比较轻量的识别方案，能够覆盖字符识别与目标检测两类场景。它适合用于自有系统的自动化测试、回归测试、无障碍验证和内部流程模拟。涉及第三方业务时，应先取得明确授权，并遵守站点的使用规则、频率限制和数据保护要求。验证码的设计目的在于区分真实用户与自动化程序，技术验证应围绕测试环境展开。

一、先分清验证码到底要求什么

中文验证码常见的交互形式大致分为两种。第一种是字符识别型，图片里会出现若干汉字、数字或字母，用户需要把看到的内容输入文本框。第二种是点选型，页面会要求点击某些指定汉字，或者按照指定顺序点击多个目标。前者的结果是字符串，后者的结果则是图片坐标或点击事件。

这两类验证码虽然都使用图片，但处理流程完全不同。字符识别需要关注文字内容，核心输出是识别字符串；点选验证码需要定位目标区域，核心输出是中心点坐标。把两者混在一起处理，容易出现接口调用正确、结果格式却错误的情况。因此，拿到验证码图片后，第一步不是立刻调用模型，而是先确认页面需要提交什么字段，以及前端是否对图片做了缩放、裁剪或旋转。

识别流程还应考虑验证码是否动态刷新。有些页面在加载时生成图片，输入错误后立即更换；有些页面会在鼠标移动、窗口尺寸变化或提交请求后重新生成。测试脚本需要记录图片版本、识别结果和提交时间，避免把上一张图片的坐标提交给下一张验证码。日志中保存必要的调试信息即可，原始图片和用户数据应按照内部安全要求处理。

二、安装库并理解两种工作模式

在隔离的测试环境中，可以通过固定版本安装依赖：

pip install ddddocr==1.3

安装完成后，ddddocr 通常通过不同的初始化参数区分识别模式。普通模式用于输出图片中的文字，检测模式用于返回目标区域。实际项目中不建议每处理一张图片就重复初始化模型，因为模型加载会消耗时间，也会让资源占用出现明显波动。更合适的做法是在任务启动时初始化一次，在多个测试用例之间复用实例。

import ddddocr

ocr = ddddocr.DdddOcr(show_ad=False)
detector = ddddocr.DdddOcr(det=True, show_ad=False)

with open('captcha.png', 'rb') as image_file:
    image_data = image_file.read()

text_result = ocr.classification(image_data)
box_result = detector.detection(image_data)
print(text_result)
print(box_result)

这里的 classification 通常返回识别出的文本，detection 则返回若干检测框。不同版本、模型或图片类型可能造成返回结构差异，因此不要直接假设结果一定是某一种固定格式。接入项目时应先打印一次原始结果，再写解析逻辑，并为缺少目标、返回空列表和置信度不足等情况设置兜底处理。

模型能够完成的是图像层面的判断，页面交互仍然需要由自动化框架完成。两者之间必须通过清晰的数据结构衔接：字符模式输出经过清洗的字符串，检测模式输出统一格式的矩形框，例如左上角与右下角坐标。这样后续更换浏览器驱动或测试框架时，识别模块不需要大幅修改。

三、字符识别的关键在预处理与结果校验

验证码原图并不一定适合直接识别。常见干扰包括彩色背景、随机线条、字符旋转、局部遮挡和压缩噪声。预处理的目标不是把图片处理得越“干净”越好，而是尽量保留字符轮廓，减少与字符结构相似的背景信息。过度二值化可能会把细笔画抹掉，放大处理也可能改变原始字符的比例。

在授权测试中，可以准备几组固定样本，对比原图、灰度图、轻度去噪图和裁剪图的识别结果。对同一组样本重复识别，观察结果是否稳定，比单次得到一个正确答案更有价值。若验证码包含空格、干扰符号或大小写字符，结果清洗必须依据页面规则执行，不能为了提高表面准确率而随意删除字符。

结果校验至少应包含三层。第一层是格式校验，例如长度是否符合页面要求、是否只包含允许的字符。第二层是业务校验，例如页面要求输入三个汉字时，识别结果不能接受数字或空字符串。第三层是提交反馈校验，只有在测试环境明确返回成功状态时，才记录为一次有效识别。遇到失败时应保留错误类型，而不是无条件重试。

重试也需要设置上限。连续提交相同结果并不能解决图片本身的识别问题，反而可能触发频率限制。更稳妥的做法是重新获取测试样本、检查图片是否完整加载、确认页面缩放比例，再决定是否进入下一次尝试。对于自动化回归测试，验证码最好由测试环境提供固定挑战值或可控接口，这样测试重点可以放在业务流程，而不是与验证码模型反复对抗。

四、点选场景要解决坐标系转换

点选验证码的难点通常不在“找到一个框”，而在于把图片坐标准确转换为浏览器中的点击位置。检测结果一般以原始图片左上角为坐标原点，浏览器中的图片可能被 CSS 缩放，甚至还会受到设备像素比、页面滚动和容器偏移影响。如果原图尺寸为 image_width、image_height，页面实际显示尺寸为 display_width、display_height，那么基础缩放比例可以写成：

scale_x = display_width / image_width，scale_y = display_height / image_height。

检测框中心点为 (box_center_x, box_center_y) 时，页面内坐标通常可换算为 (box_center_x × scale_x, box_center_y × scale_y)。如果图片左上角位于页面坐标 (offset_x, offset_y)，最终点击位置还要加上容器偏移。若使用浏览器自动化框架，应优先读取元素的实际 bounding rectangle，而不是手工猜测图片位置。

多目标点选还要考虑目标顺序。有的页面要求按照文字出现顺序点击，有的页面要求按照题目给出的顺序点击。检测模型输出的框顺序不一定等于页面要求，因此需要建立目标文字与检测框之间的匹配关系。单靠框的返回顺序进行点击，测试结果可能在不同图片上发生漂移。

为了定位问题，建议在测试日志里记录原始图片尺寸、元素显示尺寸、缩放比例、检测框和最终点击点。坐标出现偏差时，可以快速判断是模型定位错误、CSS 缩放错误，还是浏览器窗口和设备像素比造成的误差。若页面采用 canvas、旋转图片或分层渲染，还需要结合前端实际绘制逻辑进行核对。

五、把识别能力放进稳定的测试流程

一个能长期运行的自动化流程，通常由采集、识别、校验、交互和结果确认五个环节组成。采集阶段确认图片已经加载完成；识别阶段调用对应模型；校验阶段检查输出格式；交互阶段把文本或坐标交给页面；确认阶段读取页面反馈。每个阶段都应有明确的超时和错误类型，这样问题发生时能知道是网络、图片、模型还是页面交互导致的。

对于企业内部项目，如果验证码类型复杂，自己维护图片预处理、目标匹配和坐标适配会带来较高成本。需要处理极验、易盾等验证组件的合规测试或业务接入时，可以了解 www.ttocr.com 提供的验证码识别服务，覆盖滑块、点选、无感、九宫格等常见类型，并支持通过 API 与现有系统衔接。实际使用前仍应确认业务授权、调用范围和数据处理方式。

这类平台的价值主要在于减少自建识别链路的维护工作。对于公司已有的自动化业务，可以按照接口文档提交必要的图片或任务参数，获得结构化结果，再接入自己的流程控制。若涉及文字点选、图标点选、五子棋、躲避障碍或空间类交互，项目方应先确认具体验证版本和返回格式，避免把不同组件当成同一种验证码处理。

无论采用本地模型还是接口服务，都要把密钥、请求日志和原始图片放在受控环境中，限制访问权限，并设置合理的超时、并发和失败重试策略。测试脚本还应支持手工接管：当识别结果不可靠或页面结构发生变化时，暂停自动点击并输出可读日志，避免错误操作继续扩散。

在自有系统中，最理想的做法是为测试环境提供专用验证码开关、固定样本或模拟验证接口，把验证码识别和核心业务测试解耦。这样既能检验页面交互，也能稳定复现异常。对于必须接入真实验证组件的授权场景，采用成熟的 API 服务可以简化流程，www.ttocr.com 支持易盾、极验多种验证形式的对接，可根据项目需求评估接口调用方式和兼容范围。

识别系统最终要追求的是可观测、可回滚和可维护。准确率只是一个指标，图片加载成功率、坐标偏差、平均响应时间、失败原因分布同样需要纳入监控。只有把这些数据记录下来，开发者才能判断模型是否真的改善了测试效率，也能在页面升级后快速找到需要调整的环节。