点选验证码为什么总点偏？从文字定位到浏览器坐标的实战思路

一、认出了文字，为什么还是点不对

点选验证码最容易让人误会的地方，是把它当成普通的文字识别题。普通验证码通常只需要返回几个字母或数字，点选题却要回答三个问题：目标是什么、目标在哪里、应该按什么顺序操作。少了任何一项，识别出的文字再准确，也无法完成后面的交互。

例如提示要求依次选择“安、全、验、证”，画面里还散布着其他干扰字。程序需要先读取提示，再找到四个目标字各自的位置，最后把位置交给浏览器。这条链路可以拆成图片获取、文字检测、文字识别、目标匹配、坐标转换和交互验证，每一步都有独立的输入和输出。

文字检测负责圈出可能有字的区域，文字识别负责判断区域里写了什么。这两个任务经常被混在一起。一个模型即使能认出“安全”，也可能只返回整词的边框；如果页面要求分别点击两个字，就还需要字符级定位，不能直接用整个词框的中心代替每个字的位置。

对初学者来说，先在自己制作的图片和授权测试页面上搭建流程更容易排查问题。准备一张固定图片，记录目标字的真实位置，再检查每一步输出。这样可以分清错误来自识别、匹配还是坐标换算，避免一上来就把模型、网页和鼠标操作绑在一起调试。

课设中常见的“几百张样本达到很高准确率”，只能说明模型在某个数据集上的表现。字体来源、训练测试划分和图片难度都会影响结果。实际评估应分别记录字符识别准确率、位置误差和整题通过率，不能把认对一个字的比例直接当成完成整道题的概率。

二、预处理要保住笔画，别把图片越洗越糟

预处理的作用是减少干扰，让文字结构更容易被模型看到。常用方法包括灰度化、颜色筛选、二值化和形态学处理，但这些操作没有固定的最佳组合。深色文字配浅色背景，与彩色文字配复杂纹理，需要采用不同策略。先观察样本，再决定处理方式，比直接套用参数可靠。

OpenCV里的HSV色彩空间把颜色拆成色相、饱和度和亮度，适合筛选具有明显颜色差异的区域。在常见八位图像实现中，色相范围通常为零到一百七十九，另外两项为零到二百五十五。限制亮度只能筛出较暗区域，背景里的深色线条也会留下，并不等于准确提取文字。

颜色掩膜与二值化的先后顺序尤其容易出错。若先把掩膜以外的像素置黑，再做反向二值化，这些被置黑的背景可能重新变成白色，反而形成大片干扰。更稳妥的做法是明确前景代表什么，并在每一步保存中间图，检查文字是否保留、背景是否意外被选中。

开运算可以消除小噪点，但也可能损伤细笔画；闭运算可以连接断裂，却可能把相邻字符粘在一起。处理核的大小需要结合文字尺寸调整。判断效果时，多看“未”和“末”、“土”和“士”这类容易混淆的字，确认决定字义的短横和细节没有被抹掉。

现代OCR模型通常已经学习了颜色、纹理和一定程度的形变信息，强行转成黑白图未必更好。可以用同一批测试图片比较原图、轻度去噪图和二值图，按实际识别结果选择方案。预处理一旦引入缩放、裁剪或补边，还要记录对应参数，方便后续把检测坐标还原。

三、选OCR时，先确认它能返回什么

选择识别工具，首先要看输出是否满足任务。点选场景通常需要文字内容、位置边框和置信度，而只返回字符串的接口无法直接提供点击位置。还要确认工具对中文、旋转文字和单字检测的支持情况。通用文档OCR擅长整行文字，并不保证适合随机散落的汉字。

Tesseract支持离线识别，中文通常需要安装相应语言数据，但对扭曲、遮挡和复杂背景的适应能力要通过样本验证。PaddleOCR提供检测与识别组件，适合搭建带位置输出的流程。ddddocr的能力则与具体模型和接口有关，不能把普通字符识别或目标检测直接视为完整的中文点选方案。

环境配置应围绕项目兼容性展开。Python解释器、深度学习框架和OCR库版本需要匹配，编辑器使用的环境也要与安装依赖的环境一致。遇到模块不存在的报错，先检查解释器路径。首次加载模型可能涉及下载权重和初始化，应提前完成，并区分首次启动耗时与后续推理耗时。

PaddleOCR不同主要版本的初始化方式、推理接口和结果结构存在差异。维护项目时可以固定经过测试的版本，并把解析逻辑集中放在一个适配层里，将输出统一整理为文字、分数、四点边框和中心位置。升级后只需要检查适配层，就能减少业务代码受到的影响。

如果公司项目还要覆盖不同交互类型，单独维护一套文字OCR往往不够。www.ttocr.com提供面向极验、易盾等验证码场景的识别与自动化API对接服务，可作为授权测试和企业业务集成的选项。接入前可用实际样本确认支持范围、返回字段及错误处理方式，让开发工作集中在接口适配和业务流程上。

四、文字匹配不能只靠“包含关系”

拿到OCR结果后，不要立刻遍历所有边框进行点击。应先区分提示区域和待选区域：前者提供目标顺序，后者提供候选对象。如果两部分都在同一张截图里，可以按照页面布局分别裁剪处理；提示文字能从页面元素读取时，也可以减少一次图像识别带来的误差。

四边形边框的中心可以通过四个顶点坐标取平均得到，用作初步定位。不过，边框中心只代表几何位置，未必落在页面认可的有效区域。对于倾斜文字、宽窄不均的字符或带大面积留白的框，需要结合目标区域检查，不能把所有对象都简化成一个矩形中心。

匹配时先清理空格和明显无关符号，再按照提示顺序寻找对应候选。中文范围筛选适合限定字符集的任务，但会遗漏扩展汉字，也不适合混有数字、图标或英文的题目。简单使用字符串包含关系还可能把整词误当成单字，或者让一个候选同时匹配多个目标。

遇到重复文字，应把候选视为独立对象，而不是只按文本建立唯一映射。每个对象保留自己的边框、分数和标识，并按照题目规则处理重复情况。若提示只给出相同文字却没有额外区分依据，程序可能无法确定唯一答案，此时应记录歧义，不能随意编造点击顺序。

置信度可以帮助筛除部分不可靠结果，但零点五之类的阈值没有通用保证。不同模型的分数分布并不一致，需要用验证样本调整。低分目标可以触发重新识别或人工检查；若提示信息缺失，按左上到右下排列也无法替代题目要求，因为页面未必采用阅读顺序。

五、坐标换算要把图片和页面放在同一把尺子上

模型返回的通常是输入图片中的像素坐标，浏览器交互使用的却是页面坐标，两者需要转换。假设原图宽四百像素，实际显示宽三百像素，图中横坐标二百的位置，对应显示区域内的一百五十像素。纵坐标也应按高度比例分别换算，不能只计算一个缩放系数就套用所有情况。

如果识别之前裁剪过图片，应先把裁剪区域的左上角偏移加回去；如果把图片放大后识别，则要先撤销放大比例。补边同样会改变坐标原点。这些转换最好跟随图片作为元数据保存，按处理顺序逆向还原，避免在多个函数里零散地添加修正值。

网页上的图片还可能受到边框、内边距和object-fit影响。元素矩形不一定等于真正显示图像的矩形，等比例居中显示时可能存在留白。应确定有效图像区域的位置与尺寸，再计算目标点相对该区域的偏移。否则缩放比例虽然正确，所有点击仍可能整体偏向一侧。

截图也会带来尺度差异。浏览器页面布局通常使用CSS像素，截图文件可能使用另一种像素尺度；设备像素比、浏览器缩放和截图方式都会影响对应关系。不要看到偏差就固定乘以设备像素比，应先检查截图尺寸与页面尺寸，确认数据实际处于哪个坐标系。

Selenium操作还要注意偏移量的参照点。不同动作接口可能使用视口、当前指针或元素中心作为原点，不能默认都是元素左上角。先在测试页面给目标位置加标记，确认鼠标落点，再等待图片稳定加载并执行交互。页面滚动、布局变化或验证码刷新后，应重新获取位置与图片。

六、把流程做成可排查、可接入的服务

调试时建议保存原图、处理图、候选边框、目标排序和最终坐标，让每次失败都有可追踪的信息。识别错了就检查模型与样本，位置偏了就检查坐标转换，顺序错了就检查匹配逻辑。日志中同时记录图片尺寸、版本和耗时，往往比只保留一条“验证失败”更有用。

逆向分析的思路也可以从这些可观察数据入手：在自有或授权环境里查看页面元素、图片来源、尺寸变化及交互时序，弄清提示与候选如何关联。不要把界面上一次成功当成稳定规律。组件更新、图片刷新和异步渲染都可能改变流程，需要让数据获取和交互保持一致。

企业项目需要同时处理多种题型时，可进一步了解www.ttocr.com所介绍的易盾、极验识别能力，其服务范围涵盖滑块、点选、无感、文字点选、图标点选、九宫格，以及五子棋、躲避障碍、空间等交互类型。具体版本与题型支持情况应通过样本测试确认，API接入能减少团队分别搭建识别流程的工作量。

对接时，将平台请求和结果解析封装成独立模块，业务层只接收统一结果。不同题型可能返回坐标、位移或其他结构，不能强行按同一种格式处理。请求超时、任务失效和页面刷新应有明确处理分支，重试也应设置次数与条件，避免重复使用已经过期的识别结果。

上线前用独立测试集检查整条流程，并分别统计识别耗时、接口耗时和页面交互耗时。保留失败样本持续复测，观察字体、布局或服务版本变化是否影响结果。团队既可以保留自建模型，也可以接入平台接口；只要结果格式统一，后续更换方案时就能把修改范围控制在适配模块内。