Bing搜索翻译接口分析
Bing 网页版翻译（cn.bing.com/translator）背后是一个叫
ttranslatev3的接口。它没有签名算法、没有加密参数，防滥用完全依赖页面里下发的一对token + key，有效期 1 小时。换句话说：只要能把 token 拿出来，二十几行 Python 就能调通。
本文所有参数、字段、错误码均来自 2026-09-23 的实测，代码可直接运行。
一、接口全貌
一次翻译请求拆成两步：先访问翻译页拿令牌，再调接口。
第一步：访问页面取令牌
GET https://www.bing.com/translator注意这个地址会 302 跳转到 cn.bing.com/translator，跟随后拿到约 650 KB 的 HTML，令牌就藏在里面。
第二步：调用翻译接口
POST https://cn.bing.com/ttranslatev3?isVertical=1&IG=<32位十六进制>&IID=translator.5023
Content-Type: application/x-www-form-urlencodedURL 上挂三个参数：
请求体（表单）里挂五个：
二、token 到底从哪来
不需要逆向 JS，也不需要还原签名。令牌是页面 HTML 里的一段全局变量，直接用正则抠出来就行：
params_AbusePreventionHelper = [1788995349630, "3YwdKK5ea9-7...", 3600000]
// └─ key：签发时间戳 └─ token └─ 有效期（毫秒）三个元素依次是：key、token、有效期。3600000 毫秒 = 1 小时。
IG 在同一份 HTML 里，格式是 IG:"XXXXXXXX..."（32 位大写十六进制）。
也就是说，整个鉴权机制就是"从页面取一对有时效的口令"，没有任何需要计算或加密的东西。
三、完整可运行代码
依赖只有一个库：
pip install "httpx[http2]"# -*- coding: utf-8 -*-
import re
import httpx
PAGE_URL = "https://www.bing.com/translator" # 会 302 到 cn.bing.com/translator
API_URL = "https://cn.bing.com/ttranslatev3"
UA = ("Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 "
"(KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36 Edg/131.0.0.0")
def fetch_token(client):
"""访问翻译页，一次性抠出 IG / IID / token / key。"""
html = client.get(PAGE_URL).text
helper = re.search(
r'params_AbusePreventionHelper\s*=\s*\[(\d+),"([^"]+)",(\d+)\]', html)
return {
"IG": re.search(r'IG[:=]"([A-Z0-9]{32})"', html).group(1),
"IID": re.search(r'data-iid="([^"]+)"', html).group(1),
"key": helper.group(1),
"token": helper.group(2),
}
def translate(text, to_lang="zh-Hans", from_lang="auto-detect"):
# http2=True 是硬性要求，少它必失败（见第五节）
with httpx.Client(http2=True, follow_redirects=True, timeout=15,
headers={"User-Agent": UA}) as client:
cfg = fetch_token(client)
resp = client.post(
f"{API_URL}?isVertical=1&IG={cfg['IG']}&IID={cfg['IID']}",
data={
"fromLang": from_lang,
"text": text,
"to": to_lang,
"token": cfg["token"],
"key": cfg["key"],
},
)
return resp.json()[0]["translations"][0]["text"]
if __name__ == "__main__":
print(translate("The quick brown fox jumps over the lazy dog."))实测输出：
敏捷的棕色狐狸跳过懒狗。四、响应结构
响应是标准 JSON（Content-Type: application/json），顶层是一个数组，翻译结果在第一项里：
[
{
"translations": [
{
"text": "你好，世界。",
"to": "zh-Hans",
"transliteration": { "text": "Nǐ hǎo, shìjiè.", "script": "Latn" }
}
],
"usedLLM": true,
"detectedLanguage": { "language": "en" }
}
]几个值得注意的字段：
usedLLM: true—— 后端已经切换到 LLM 翻译引擎
detectedLanguage—— 只有源语言传auto-detect时才有意义，返回检测到的语种
transliteration—— 译文的音译（中文、日文等场景常返回）
五、哪些参数是必需的
把参数逐个删掉重跑，结果如下（2026-09-23 实测）：
这里有两个反直觉的点：
第一，Referer 和浏览器 UA 都不校验。 网上很多实现把它们当必需项，其实是多余的。
第二，失败时 HTTP 状态码依然是 200。 错误信息藏在响应体的 statusCode 字段里 —— 所以判断调用是否成功，不能看 HTTP 状态码，要看返回的是不是数组、有没有 translations 字段。这一点如果不注意，调试时会很痛苦：请求"成功"了，却永远拿不到译文。
六、语言代码怎么填
fromLang / to 用的是 BCP-47 风格的语言代码，常用取值：
七、注意事项
这是 Bing 网页前端使用的内部接口，不是微软对外承诺的公开 API。它的参数、页面结构、令牌机制随时可能变更，也没有任何服务等级保证。
它适合用来学习接口分析与逆向调试的思路。如果要做生产环境或商业项目，请使用微软 Azure 提供的 Translator 官方接口 —— 有正式的鉴权体系、配额说明和技术支持，稳定性与合规性都不是网页内部接口能比的。
同时，无论用哪种方式，请控制请求频率，不要对目标服务造成压力。
本文仅供参考