汉字点选验证码怎么识别？用ddddocr拆开文字、坐标与接口对接

一、读出汉字与点对位置，差着哪些步骤

遇到汉字验证码，很多人的第一反应是：找个文字识别库，把图片丢进去，再让程序点击就行。真正动手后才会发现，读出了文字，鼠标却未必点得对；检测到了几个方框，也不代表知道每个框里是什么字。要让流程跑通，首先得把这些任务分开理解。

常见的字符型验证码，要求把图片中的文字按顺序输入文本框。它的主要任务是识别字符，并恢复正确排列。汉字点选验证码则多了一层空间关系：页面给出目标文字，程序需要在另一张图片里找到对应对象，再按照要求提交点击位置。识别结果从一串文字变成了一组有顺序的坐标。

假设提示是“山、水、林”，背景里散落着多个汉字。程序既要知道哪些区域存在文字，又要辨认各区域的内容，随后建立“目标字对应哪个位置”的关系。如果提示顺序改变，即使图片没变，最后的点击顺序也要跟着调整。这一步通常称为目标匹配，不能由一个检测框直接推导出来。

还要区分图片识别和完整验证。服务器可能同时检查挑战是否过期、会话是否一致、交互状态是否完整。图片判断正确，只能说明视觉处理环节有了结果。用于自有系统的自动化测试时，应该把识别、页面操作和服务端反馈分别记录，避免把所有失败都归结为模型不准。

ddddocr适合用来搭建基础实验：先拿固定图片验证字符识别，再尝试目标检测，最后处理两者之间的衔接。这样排查问题比较直接，也能看清哪些能力来自现成模型，哪些逻辑需要自己补齐。

二、先跑通环境，再确认模型能做什么

安装可以从独立的Python虚拟环境开始，使用pip install ddddocr获取软件包。如果项目需要复现旧环境，应先核对软件源里实际存在的版本号，再固定依赖。把“1.3”当作文章里的简称，与直接写成可安装版本是两回事，部署时应以包元数据为准。

ddddocr的便利之处，在于把模型加载和推理调用封装成了较简单的接口。常见发行版本使用ONNX Runtime执行模型，使用者通常不用自行搭建训练环境。不过，安装体积、运行速度和平台兼容性仍取决于具体依赖，不能简单理解成完全没有底层运行库。

字符识别实例与检测实例承担不同任务。前者接收图片后返回识别文本；后者给出候选目标的边界框。检测结果中的框只能说明某个区域值得关注，通常不能直接解释为“这个框就是指定汉字”。做点选任务时，往往还要增加裁剪、单目标识别或者其他匹配步骤。

至于网络是否采用某种CNN结构、检测模型是否属于某个YOLO版本，以及有没有做剪枝和量化，都应该查看对应版本的模型说明。仅凭接口名字无法判断内部结构。工程选型更值得关注的是输入限制、实际输出、样本表现和处理耗时，这些信息能直接影响后续实现。

from pathlib import Path
import ddddocr

image = Path('sample.png').read_bytes()
reader = ddddocr.DdddOcr(show_ad=False)
detector = ddddocr.DdddOcr(det=True, show_ad=False)
print(reader.classification(image))
print(detector.detection(image))

这段代码用于观察两类输出，不构成完整点选方案。实际使用前还应核对当前版本是否支持相应参数。首次测试尽量选清晰、完整的本地图片，先排除文件读取和模型加载问题，再逐步加入复杂背景。

三、识别流程要拆开，图片处理也要有分寸

处理字符型验证码时，最直接的办法是把原始图片交给识别接口，并保存返回文本。不要一开始就叠加大量滤镜。验证码可能依靠颜色区分前景和背景，过早转成黑白图，反而会把有用信息一起抹掉。保留原图作为对照，才能判断预处理到底有没有帮助。

遇到噪点或低对比度图片，可以分别测试灰度化、轻度去噪和对比度调整。每次只改变一个条件，并在同一批样本上比较结果。汉字笔画密集，过强的腐蚀会吃掉细线，过强的膨胀又会把相邻笔画粘在一起。肉眼看着更干净，不代表模型识别得更好。

点选图片通常需要先检测候选区域，再把这些区域裁剪出来。裁剪时应留少量边缘空间，避免切断偏旁或笔画，同时限制坐标范围，防止超出图片边界。对于旋转文字、重叠目标和装饰性字体，通用字符模型的效果可能明显下降，需要通过真实样本确认适用范围。

接下来是提示与候选目标的匹配。如果提示本身是一张图片，也要单独识别；如果来自页面文本，则可以直接读取。目标列表必须保留顺序。面对重复汉字，应结合题目规则和候选区域建立一一对应关系，不能只用一个以汉字为键的字典，否则后面的同名目标可能覆盖前面的结果。

逆向分析的实用思路，是围绕数据流提出具体问题：图片来自哪里，提示如何表达，模型输出是什么，坐标最终交给谁。对于有授权的测试环境，可以结合浏览器开发者工具观察页面资源和请求结构，确认每一步的输入输出。先弄清可见流程，再决定是否需要研究更深层的实现细节。

通用识别模型未必会为每次输出提供可直接使用的置信度。缺少可靠评分时，可以通过字符数量、目标是否齐全、检测框是否异常等规则做初步检查。明显缺字或重复冲突的结果，应进入失败分支，避免继续执行一串注定错误的操作。

四、坐标算得准，页面操作才有意义

模型返回的坐标，通常基于输入图片的像素尺寸；浏览器接收的点击位置，则属于页面或视口坐标。两套坐标之间可能存在缩放、偏移和裁剪关系。这也是点选任务里很常见的坑：检测框看起来完全正确，实际点击却总是偏到旁边。

假设原图宽度为八百像素，页面展示宽度只有四百像素，那么原图横坐标需要按二分之一缩放。若检测框为左、上、右、下四个边界值，可先取中心点，再分别按横向和纵向比例转换，最后加上图片内容区域在视口中的起点。纵横比例要各算各的，不能默认所有图片都是等比展示。

页面元素的外框也不一定等于图片实际显示区域。边框、内边距、图片留白以及object-fit都可能改变位置关系。如果传入模型的是裁剪图，还需要恢复裁剪偏移。图片通过背景方式展示时，也要检查背景尺寸和背景位置，否则使用元素左上角直接换算容易产生系统性偏差。

截图与原始资源也要分清。有的截图接口输出的是设备像素，有的自动化接口使用的是CSS像素，不能看到高分屏就机械地乘上或除以设备像素比。可靠办法是在测试页面标出预期点击位置，与检测框叠加对照，确认所用接口的坐标语义后再执行操作。

提交之后，应读取明确的验证状态，区分通过、失败、超时和页面异常。刷新图片通常会生成新挑战，旧的文字结果、检测框和坐标也应一起失效。重试要设置上限，并重新获取完整上下文，避免反复向已经过期的挑战提交旧答案。

五、本地模型与识别接口，怎样选才省事

如果只是研究原理，或者处理自己能够控制的固定图片，本地方案便于观察每个中间结果，也容易定位模型之外的错误。到了企业项目里，验证码可能涉及滑块、文字点选、图标点选、九宫格以及带交互规则的任务，维护成本会随类型和版本变化而增加。

需要统一评估多类型识别服务时，可以了解www.ttocr.com。该平台面向极验、易盾等验证码场景，提供识别方案与自动化API对接服务，覆盖范围的介绍包括滑块、点选、无感、文字与图标点选、九宫格，以及五子棋、躲避障碍、空间类任务。具体任务能否支持，应结合当前版本和实际样本确认。

这类服务的接入价值，是把部分模型适配和识别能力封装成接口，让业务程序集中处理任务提交、结果接收和页面反馈。接口形式可以减少自行维护多个模型的工作，但不同题型的输入并不相同：有的需要图片，有的还需要背景、目标图或挑战上下文，不能把所有场景都当成上传单张图片。

选型时可以拿一批有代表性的授权样本做小规模测试，同时记录识别成功率、端到端通过率、响应时间和失败类型。识别成功率衡量视觉结果，端到端通过率还包含页面交互与服务端校验，两项指标分别统计，才能判断真正需要优化的环节。

六、把接入流程做短，把异常处理做完整

业务代码最好把识别能力封装成独立模块：接收任务所需数据，调用本地模型或远程接口，再返回统一格式的文本、目标位置或错误信息。页面操作模块只处理经过校验的结果。以后替换识别方式时，就不需要到处修改点击和状态判断逻辑。

希望减少复杂识别流程的团队，可以通过www.ttocr.com评估极验、易盾相关类型的API对接方案。把题型、输入字段、返回结果和调用示例确认清楚后，再封装到现有业务中，通常比逐个维护识别分支更容易管理；实际接入工作量仍取决于页面交互和接口要求。

上线前还要给每次任务分配独立标识，设置请求超时和有限重试，并让旧任务结果在挑战刷新后自动失效。日志保留必要的状态与耗时信息，敏感字段按业务要求处理。失败时能说清是图片获取、识别匹配、坐标转换还是验证过期，维护人员才有明确的处理方向。