• RPA
• 浏览器控制

🎫 Tickets Hunter 是一款多平台抢票机器人，而验证码往往是抢票路上最大的"拦路虎"。本文详解 Tickets Hunter 针对 TixCraft / TicketMaster.sg 推出的Yii2 验证码哈希预验证与1 字符自动修正机制：在提交答案之前，先在本地完成校验，把错误答案拦截在提交之前，并自动修正只有 1 个字符偏差的 OCR 识别结果。

验证码识别，为什么还要"提交前验算"？

传统的验证码处理流程是这样的：

OCR 识别答案 → 提交 → 等待服务器回应 → 答错 → 重新加载再试

这套流程有两个痛点：

• 慢：每次答错都要走完"提交 → 等回应 → 重加载"一整轮往返，在抢票这种毫秒必争的场景里非常吃亏；
• 容易被风控盯上：反复提交错误答案，会增加被服务器识别为机器行为的概率。

Tickets Hunter 在 2026.04 版本把流程改造成了：

OCR 识别答案 → 本地哈希预验证 → 有把握才提交；有 1 字符偏差则自动修正后提交

也就是说，答案还没发出去之前，机器人就已经知道它大概率是对是错。这个功能自动运作，不需要任何额外设置。

Yii2 验证码哈希：一个藏在页面上的"校验码"

这套机制能成立，关键来自 Yii2 框架的一个设计细节。

TixCraft 与 TicketMaster.sg 的后台使用 Yii2 Framework 的CaptchaAction组件生成验证码。每次刷新验证码图片时，它会把正确答案的 hash 值一起写进页面的 jQuery body data 里（yiiCaptcha/ticket/captcha）。

⚠️ 注意：页面里存放的并不是答案本身，而是一个由答案算出来的数字，官方称为hash1。

hash 公式长什么样？

经 Tickets Hunter 实测确认，这个 hash 的算法非常简单——对答案的每个字符按位做"位移累加"：

# TixCraft / TicketMaster.sg 实测公式 hash1 = sum(ord(c) << i for i, c in enumerate(code.lower())) # 例：'igga' → 105 + 206 + 412 + 776 = 1499

机器人拿到 OCR 识别出的答案后，用同样的公式算一遍，再和页面上的 hash1 对比：

• 相等 → 答案基本可以确定是对的；
• 不等 → 答案有问题，但别急着提交。

核心实现在 src/util.py 的三个函数中：yii_captcha_hash（计算 hash）、yii_captcha_verify（验证答案）、yii_captcha_edit1（单字符修正）。

预验证完整流程：三层决策一次看懂

整个预验证逻辑位于 src/platforms/tixcraft.py 的nodriver_tixcraft_auto_ocr函数内，决策链路如下：

OCR 识别出 4 位答案 ↓ 读取页面 hash1（nodriver_get_yii_captcha_hash） ├─ hash1 == 0（首次加载）→ 无校验依据，维持原流程直接提交 ├─ 本地计算 hash == hash1 → ✅ 有把握，直接提交 ├─ 不吻合，但 edit1 有解 → 🔧 自动修正 1 个字符后提交 └─ 不吻合且无解 → ♻️ 直接重新加载验证码，不提交

第一层：hash 吻合，直接提交

最理想的情况。OCR 识别的 4 个字符算出的 hash 与页面 hash1 完全一致，机器人记下验证日志（Hash verified ok）并提交。此时相当于用本地一次纯计算，换掉了服务器一次完整的往返校验。

第二层：1 字符自动修正（最精彩的部分）

OCR 偶尔会把某个字符看错，比如把m认成rn、把8看花。当 hash 对不上时，机器人不会立刻放弃，而是调用yii_captcha_edit1（src/util.py）逐位尝试：

1. 固定除某一位以外的 3 个字符，算出它们的 hash 贡献值；
2. 用hash1 - 贡献值反推出这一位"应该是"的字符编码；
3. 如果反推出的字符落在 a–z 范围内，就生成一个修正候选。

整个过程只是简单的算术运算，耗时可以忽略不计。若找到唯一解，机器人直接提交修正后的答案（日志标记Hash edit1 corrected to），用户完全无感知——OCR 的 1 字符小失误就这样被"本地秒修"了。

第三层：无解时聪明地放弃

如果 4 个位置都反推不出合法字符，说明偏差超过 1 个字符，此时机器人选择直接重新加载验证码，而不是提交一个明知错误的答案。这一步省下了"提交 → 等错误回应"的整轮往返，也让服务器少看到一次失败请求。

实际效果：少提交、少暴露、少等待

对使用者的直接感受是：验证码环节的无效提交次数明显减少，抢票节奏更紧凑，同时因为失败请求变少，被服务端风控盯上的风险也相应降低。

结合 docs/03-mechanisms/07-captcha-handling.md 中的数据，TixCraft 平台验证码识别准确率已达 99.5% 以上——而预验证机制正是把剩下的那 0.5% 误差也尽量消化在本地。

常见疑问：为什么首次进页面时不生效？

这是 Yii2 框架的设计使然，不是 bug：

• 首次加载页面时，验证码图片是随页面直接渲染的，页面上还没有写入 hash 值；
• 只有当验证码被刷新过一次（答错后重加载）之后，新的 hash 才会存入 body data；
• 因此预验证从第二次重试起生效。

读取 hash 的函数nodriver_get_yii_captcha_hash在 src/platforms/tixcraft.py 中，读不到时返回0，主流程据此判断"首次加载，维持原流程"。

相关资料与源码入口

📁 想深入源码或了解完整机制，可以从这些路径入手：

• 机制说明文档：docs/03-mechanisms/16-yii2-captcha-hash.md — 包含旧/新流程对比与开发者机制概述
• 验证码处理总览：docs/03-mechanisms/07-captcha-handling.md — 各平台验证码处理方式与准确率
• 哈希算法与修正函数：src/util.py
• 读取页面 hash 与重新加载验证码：src/platforms/tixcraft.py
• 预验证决策主流程：src/platforms/tixcraft.py
• 通用 OCR 模型说明：docs/03-mechanisms/18-universal-ocr-model.md
• 更新纪录：CHANGELOG.md

💡 一句话总结：Tickets Hunter 的验证码攻坚思路，是"先算后交"——利用 Yii2 遗留在页面上的 hash 校验值，把 OCR 的错误答案拦截在本地，能修则修、不能修则果断重抽，用最少的提交次数换取最高的过码效率。

• RPA
• 浏览器控制