同一个 sitekey，日本站点弹出日语 reCAPTCHA，欧美站点却是英语——脚本是不是要按地区单独适配？结论：大多数情况下不需要。token 类验证码的语言只影响界面文案，不影响 token 本身；真正需要手动配置的，只有图片/OCR 验证码的 language 参数。
对 CaptchaAI 解题到底有没有影响
先看结论，再看细节——本地化改的是界面，还是 token 本身：
| 验证码类型 | 本地化会改变什么 | 本地化不会改变什么 |
|---|---|---|
| reCAPTCHA | 界面文案、图片标签、语音验证的语言 | sitekey、验证流程、token 格式 |
| Turnstile | 小组件文案和错误提示 | sitekey、token 格式、解题机制 |
| hCaptcha | 挑战说明、分类标签 | sitekey、token 格式 |
| 图片/OCR | 字符集、图片中的文字语言 | 图片格式、提交/轮询流程 |
token 类验证码：语言不影响解题
reCAPTCHA、Turnstile 这类验证码，语言只作用于界面层，不作用于 token 层：
- 提交 sitekey 和页面 URL
- CaptchaAI 返回有效 token，无论小组件当时显示哪种语言，token 都同样有效
- 不需要传任何语言参数
（hCaptcha 本地化机制相同，但 CaptchaAI 目前不支持 hCaptcha 解题。）
图片/OCR 验证码：language 参数要匹配字符集
图片验证码是唯一语言会直接影响识别结果的类型——语言变化改变的是图片里的字符本身：
| 网站语言 | 验证码图片内容 | CaptchaAI language 参数 |
|---|---|---|
| 英语 | "Enter the text: XKCD42" | 0（默认/拉丁字符） |
| 俄语 | "Введите текст: ШКАФ" | 1（西里尔字母）或 2 |
| 中文 | "请输入验证码：汉字" | 2（非拉丁字符） |
| 阿拉伯语 | "أدخل النص: عربي" | 2（非拉丁字符） |
| 日语 | "文字を入力：ひらがな" | 2（非拉丁字符） |
language 参数填错，识别出来的字符就是错的——不是识别能力问题，而是参数没告诉它该按哪种字符集读图。
音频验证码
reCAPTCHA 语音验证按 hl 参数或 Accept-Language 头对应的语言播报，CaptchaAI 走标准 reCAPTCHA 流程处理，不依赖音频语言。
中国大陆开发者最容易踩的本地化坑
Accept-Language 和目标站点语言不一致
若抓取工具发送 Accept-Language: en-US，却访问日语站点，验证码界面可能以英语呈现——对 token 类验证码没有影响，但若站点校验语言一致性，就可能触发风控。稳妥做法是让 Accept-Language 头跟目标站点主语言保持一致。
不同地区的验证码服务商不一样
| 地区 | 常见验证码服务商 |
|---|---|
| 欧美市场 | reCAPTCHA、Turnstile、hCaptcha |
| 中国大陆 | GeeTest（极验）、腾讯防水墙、自定义图片验证码 |
| 俄罗斯/独联体 | 自定义图片验证码、reCAPTCHA |
| 韩国 | 自定义滑块验证码、图片验证码 |
CaptchaAI 目前只支持 GeeTest v3（v4 官方状态“即将支持”），不支持腾讯防水墙、阿里云验证码——抓取国内站点前先确认对方用的是哪一种。
验证码怎么判断用哪种语言
常见的语言判断信号：
1. Accept-Language 请求头
Accept-Language: ja-JP,ja;q=0.9,en-US;q=0.8,en;q=0.7
优先日语，其次美式英语，最后通用英语——reCAPTCHA 和 Turnstile 都读这个头选界面语言。
2. HTML 里的 hl 参数
reCAPTCHA 加载时可显式传语言参数，优先级高于 Accept-Language：
<!-- Force English reCAPTCHA -->
<script src="https://www.google.com/recaptcha/api.js?hl=en"></script>
<!-- Force Japanese -->
<script src="https://www.google.com/recaptcha/api.js?hl=ja"></script>
解题时不用匹配 hl 参数——无论界面显示什么语言，CaptchaAI 都会正常返回可用 token。
3. 地理 IP 定位
部分验证码配置按地区变化：
| 信号 | 影响 |
|---|---|
| IP 来自中国大陆 | 可能拿到 GeeTest（极验）而非 reCAPTCHA（Google 脚本在国内网络下常加载不稳定） |
| IP 来自欧盟 | 可能先看到 GDPR 同意弹窗，再出现验证码 |
| IP 来自高风险地区 | 可能面临更严格的挑战难度 |
4. 浏览器 navigator.language
JavaScript 验证码会读取浏览器语言：
navigator.language // "en-US"
navigator.languages // ["en-US", "en", "ja"]
无头浏览器默认使用系统 locale，容易和目标站点不匹配，抓取前应显式设置：
// Playwright
const context = await browser.newContext({
locale: 'ja-JP',
});
// Puppeteer
const page = await browser.newPage();
await page.setExtraHTTPHeaders({
'Accept-Language': 'ja-JP,ja;q=0.9',
});
排查清单
| 问题 | 原因 | 处理方式 |
|---|---|---|
| reCAPTCHA 显示的语言和预期不符 | hl 参数与 Accept-Language 头不一致 |
token 与语言无关，不影响解题 |
| 图片验证码识别出错误字符 | language 参数与图片字符集不匹配 |
非拉丁字符集设置 language=2 |
| 站点按地区提供不同验证码类型 | 服务商按地理 IP 做了差异化配置 | 用匹配目标地区的代理，配合正确 Accept-Language |
| 无头浏览器显示的 locale 不对 | 使用了系统默认 locale | 在浏览器上下文里显式设置 |
| 音频验证码用了意料之外的语言 | hl 参数覆盖了 Accept-Language 头 |
不影响基于 token 的解题 |
常见问题
CaptchaAI 需要知道验证码显示的是什么语言吗？
对 CaptchaAI 支持的 reCAPTCHA、Turnstile 不需要，解题流程与语言无关（hCaptcha 目前不在 CaptchaAI 支持范围内）。图片/OCR 验证码需要——把 language 参数设置成与图片字符集匹配的值即可。
图片验证码的 language 参数到底该填 0、1 还是 2？
拉丁字符填 0；西里尔字母可以填 1 或 2；中文、日语、阿拉伯语等非拉丁字符集统一填 2。参数填错不会报错，但识别结果会是错的，排查“答案总不对”时先检查这个参数。
从中国大陆的服务器请求 reCAPTCHA 页面，会不会因为访问不到 Google 而报错？
有可能。reCAPTCHA 脚本托管在 Google，国内网络下加载常不稳定，导致的是页面超时而非解题失败——这是网络连通性问题，与 CaptchaAI 解题能力无关。
Accept-Language 设置和目标站点不一致，会导致解题失败吗？
不会，但可能让验证码界面用错误语言呈现，若目标站点交叉校验请求头一致性，也可能增加被判定异常流量的概率。稳妥起见，让 Accept-Language 与目标站点主语言保持一致。
同一个 sitekey，为什么日本站点和欧美站点弹出的验证码类型不一样？
不少站点按地理 IP 做验证码服务商的差异化配置，不只是换语言那么简单——同一套系统，不同地区流量可能被路由到不同提供商。这是站点自己的风控策略，CaptchaAI 支持的类型都能处理，只需脚本先识别当前页面加载的是哪一种。
下一步
在任意语言环境下稳定处理验证码——获取你的 CaptchaAI API Key，配置好 Accept-Language 与 language 参数即可开始。
相关指南：
- 多语言图片验证码字符集对照
- 解决中文网站上的验证码
- 解决日语和韩语网站上的验证码
