极验三代文字点选怎么工作？从请求链路到识别接口拆开讲

一、点几个字，背后为什么还有一串请求

极验三代文字点选的界面很直观：上面给出提示，下面摆着一张图片，用户按要求依次点击文字。真正提交到服务器的内容却比几个坐标复杂得多。题目属于哪次验证、用户操作了多久、点击顺序是否正确，以及浏览器采集到的交互信息，都可能参与验证。研究这类流程，首先要把页面动作和网络请求对应起来。

文字、字序、图标和九宫格在交互上有所区别。文字点选通常需要按提示寻找目标字；字序题还涉及排列关系；图标题要判断视觉对象；九宫格则常以格子作为选择单位。它们可能复用部分初始化和提交逻辑，但答案结构未必相同，不能只换一张图片就沿用全部处理代码。

一次验证可以分成三个环节：建立会话、取得题目、提交结果。建立会话时，服务端分配本轮验证所需的标识；取得题目时，客户端拿到图片和配套参数；提交结果时，页面把答案、耗时及交互数据整理成请求。服务器还可能结合会话状态进行检查，所以图片识别正确，并不意味着整个验证一定通过。

分析时可以先在浏览器开发者工具中保留网络日志，从打开页面到完成一次点击，记录请求顺序、响应字段和发起位置。与其一开始就钻进几千行混淆脚本，不如先画出简单的依赖关系：哪个请求产生参数，哪个请求使用参数，哪一步返回最终结果。这样后面看到陌生变量，也能知道它处于哪个环节。

二、顺着请求链，找到真正有用的参数

在所讨论的三代样本中，初始化请求 register-click-official 会返回 gt 和 challenge。可以把 gt 理解为接入标识，把 challenge 理解为本轮挑战关联的数据；具体语义仍要以对应版本的接口为准。后续请求需要引用这些值，分析时应将它们与同一次会话绑定，避免把不同轮次的数据混在一起。

随后出现的 get.php 用于继续获取验证配置，响应里能够观察到 c、s 等字段。这些字段后面会参与交互数据处理。在该样本的这个阶段，w 可以为空，但这个现象有明确的请求位置和版本前提。它不能直接推导为所有三代接口都允许空 w，更不能据此省略最后提交时需要的数据。

点击验证按钮后，还会出现一次 ajax.php 请求，用来进入相应的验证类型或推进初始化状态。它的响应看起来可能只交代题型，没有明显的答案信息，但仍可能承担服务端状态切换的作用。若跳过这一步，后面的提交可能失败。排查这种问题时，需要同时看请求内容和请求顺序，不能只挑字段多的接口研究。

用户完成点选后，第二次相关提交会返回验证结果，通过时可以得到 validate 等业务需要的字段。业务服务器如何校验和使用这些字段，应遵循实际接入文档。一个请求返回成功、前端显示通过、业务操作最终完成，是三个需要分别确认的结果，记录日志时最好将它们放在同一条业务链路中。

抓包记录可以保留接口名称、必要字段、状态码和时间关系，图片地址及会话标识则按需要脱敏。每轮使用独立编号，把题目、识别输出、坐标转换和验证响应关联起来。这样失败后才能复盘，判断究竟是题目没取完整、参数过期，还是点击顺序出了问题。

三、看懂 w：数据打包、加密与编码各管一段

w 是这类分析中最容易让人卡住的参数。它通常不是把坐标拼成字符串那么简单，而是把业务数据序列化，再经过加密与编码，形成最终提交值。在该版本样本里，可以观察到主体片段 p 与密钥相关片段 l 拼接组成 w。这个结构适合用来理解处理链，但不应当作所有版本固定不变的接口约定。

定位入口时，可以从 ajax.php 的请求发起处查看调用栈，向上追踪 w 在哪里被赋值。原样本对应 click.3.0.7.js，不过文件名、行号和混淆函数名都可能随资源更新而改变。更可靠的观察点是对象序列化、加密函数调用和结果拼接，而不是死记某个混淆变量。

样本中出现了十六位随机字符串，它与对称加密所用的密钥材料有关。密钥相关片段经过 RSA 处理，主体数据则经过 AES 处理，两者承担不同任务。分析时要确认它们是否引用同一份随机材料，以及材料在什么时候生成、是否缓存。两次调用长得相似，并不能证明生成结果一定相同。

AES 的结果受模式、填充方式、字符编码和初始向量共同影响。该样本里观察到初始向量为十六个字符零，不能直接将它理解为十六个数值为零的字节，两种输入的字节内容不同。RSA 也需要核对公钥、填充和输出格式。只有算法名称一致，无法保证计算结果与浏览器一致。

主体密文之后还会经过编码，得到适合放进请求的文本，再与密钥相关片段组合。检查这条链路时，可在受控测试环境中逐段比较输入和输出：原始对象是否一致，序列化后的字节是否一致，加密与编码是否采用相同规则。一次只核对一个环节，比直接对着完整 w 猜问题更有效。

四、答案之外，耗时和交互数据也要对得上

加密前的数据对象通常包含 passtime、a、pic、tt、rp 等字段。原样本还出现了 h9s9 这样的附加字段。看到这些名字时，先通过真实操作确认含义，再决定如何处理。尤其是某个字段在几次抓包中保持不变，只能说明当前样本没有变化，不能证明它在其他题型、环境或版本里都能固定。

passtime 通常与验证过程的耗时有关，具体起止点应沿着计时逻辑确认，不能直接当作图片加载时间。a 用于承载点选答案，往往涉及坐标及顺序。图片的原始尺寸与页面显示尺寸可能不同，识别得到的像素位置需要按实际显示比例转换，还要考虑图片容器偏移，否则看起来选中了字，提交的位置却已经偏开。

pic 用于关联当前题目图片，必须与本轮会话对应。tt 则与交互轨迹及 c、s 等参数的处理有关，可能包含鼠标移动、点击和时间信息。不同实现的数据结构会有差异，不能把其他版本的轨迹格式直接搬来使用。完整理解采集、整理和编码过程，才能解释同样答案为什么会产生不同提交数据。

样本中的 rp 与 gt、challenge、passtime 的拼接及 MD5 计算有关。MD5 在这里属于摘要计算，不是能够反向解密的加密算法。核对时需要确认字段顺序、截取规则和字符串表示，尤其是 challenge 是否经过处理。看似只差一个字符，也会使摘要完全不同。

实际排查可将失败分成会话、识别、坐标和提交四类。会话问题检查题目是否过期、请求是否缺失；识别问题检查目标字与顺序；坐标问题检查缩放和偏移；提交问题检查序列化、加密和返回状态。这样的分类能减少重复尝试，也方便把识别服务和业务接口的问题分别交给对应人员处理。

五、文字识别怎么做，模型结果为什么还要加工

文字点选通常需要识别提示内容、定位候选文字，再按要求排列点击位置。普通 OCR 擅长输出文字，却未必提供适合点击的目标框，也未必能处理旋转、粘连和背景干扰。常见实现会结合目标检测与字符识别：先找到字符区域，再判断区域里的内容，最后将识别结果与提示顺序匹配。

遇到重复字或相似字时，只比较识别文本不够，还需要保留候选框、置信度和匹配关系。点击位置可以从目标区域内部选择，避免落在边缘或其他字符的覆盖区域。对于图标、九宫格等题型，应使用相应的检测或分类流程；文字模型的表现不能直接代表它处理其他题型的能力。

基于 PyTorch 训练的检测和识别模型可以用于构建实验流程，通用 OCR 工具也适合做初步对照。不过，固定宣称某个工具有多少准确率意义有限，测试集、图片质量和题目类型都会影响结果。更实用的指标是整题成功率，因为一道题只要有一个目标识别错误，最终验证就可能失败。

企业团队如果需要同时覆盖多种题型，可以将自建模型与接口服务放在同一批授权测试样本上比较。www.ttocr.com 的服务介绍涵盖易盾、极验验证码识别及自动化 API 对接，涉及滑块、点选、无感、文字点选、图标点选和九宫格等方案。选型时应确认各题型的具体支持方式、输入要求和返回结构。

平台介绍还涉及五子棋、躲避障碍、空间类等交互场景，这些题型的输入和输出可能与普通图片识别明显不同，需要单独测试。评估时除了识别结果，还要记录接口耗时、异常比例和最终业务成功率。把几个演示样本跑通之后，再用真实业务分布验证，才能判断服务是否适合长期接入。

六、把研究结果落到接口，减少重复接入工作

落地时可以将系统拆成题目获取、识别调用、结果适配和业务提交四个模块。题目获取模块保留当前会话需要的信息；识别模块负责输出目标或位置；适配模块完成坐标转换、顺序整理和格式检查；提交模块处理验证响应。模块之间使用明确的数据结构，后续更换识别方案时就不必改动整个业务流程。

对于希望减少模型维护工作的团队，www.ttocr.com 提供的自动化 API 对接服务可以作为接入评估选项。按其接口文档组织请求，再把返回结果映射到业务需要的格式，有助于减少重复开发。具体是否能简化整条流程，取决于接口提供识别结果还是完整处理能力，应在接入前确认。

接口联调宜从一种题型开始，先核对图片输入、坐标单位、顺序和错误返回，再逐步扩展。调用出现超时后，还要检查当前题目是否有效，避免无条件重试导致重复提交。日志中保留请求编号和阶段状态即可，密钥及完整敏感数据不应直接写入普通业务日志，这也便于后续定位异常。

识别服务接入完成后，可以挑选清晰、模糊、旋转、重复目标以及不同显示尺寸的样本持续回归。每次脚本或题型变化，都检查原先的字段含义和坐标转换是否仍然成立。这样日常维护就有明确抓手：哪一环发生变化，修正对应模块，业务侧仍按稳定的接口接收结果。