上游API返回不同编码格式，中转统一输出UTF‑8处理

当你的中转服务同时调用多个第三方API时，最头疼的就是明明返回了中文，却变成乱码。
核心原因通常是上游返回的编码格式不统一，有的接口给GBK，有的给GB2312，有的才是UTF-8。
本文会从检测、转码、验证三个环节讲清楚，让中转接口最终统一输出UTF-8。

第一步：确认上游API实际使用了哪种编码

先用 curl 查看响应头：

curl -I "http://api.example.com/get_data"

重点看 Content-Type 里有没有 charset=...，没有的话就保存响应体再判断：

curl -s "http://api.example.com/get_data" -o response.bin
file response.bin

file 命令能根据字节特征识别编码，这是最直接的判断依据。
如果显示 GNU gettext 或 Non-ISO extended-ASCII，基本可以确定非UTF-8。

第二步：在中转代码里做统一转码

以 PHP 为例，如果上游返回的 body 是 GBK，可以使用 mb_convert_encoding：

$content = file_get_contents($apiUrl);
$utf8 = mb_convert_encoding($content, 'UTF-8', 'GBK,GB2312,UTF-8');

注意第三个参数可以传一个编码列表，函数会按顺序尝试识别，但最好还是按第一步的检测结果指定来源编码，避免误判。

Python 中使用 requests 和 chardet 更自动：

import requests
import chardet

resp = requests.get(api_url)
raw = resp.content
encoding = chardet.detect(raw)['encoding']
text = raw.decode(encoding, errors='ignore').encode('utf-8')

这段代码先检测编码，再转成UTF-8，适合上游编码经常变动的场景。

第三步：Nginx 反向代理场景下的处理

如果中转节点是 Nginx，可以在 location 里借助 sub_filter 做字符替换，但 Nginx 本身不负责解码，通常需要搭配 lua-nginx-module 或 ngx_http_substitutions_filter_module，操作成本较高。
常规做法仍是把统一转码放在后端服务里，让 Nginx 只做透传，这样逻辑更简单，也方便后期排查。

避坑：这几个问题最容易被忽视

• 不要直接 iconv 乱转。源编码判断错时，转换后会变成“锟斤拷”，而且不可逆。
• 响应头里的 charset 不一定可信。有些老接口声明UTF-8，实际内容是GBK，要以字节检测结果为准。
• 转码后要重新设置响应头。代码里输出前记得加上 Content-Type: application/json; charset=utf-8，否则客户端还会按默认编码解析。
• HTTP 头的 Content-Encoding 和字符编码是两回事。如果上游返回 gzip 压缩内容，要先解压再处理编码转换。

验证输出结果

转码完成后，把接口返回保存到文件再确认：

curl -s 你的中转接口地址 -o result.txt
file result.txt

看到 UTF-8 Unicode text 代表成功。
也可以直接用浏览器打开中转接口地址，检查中文是否正常显示。

如果你正在处理上游API返回不同编码格式、中转统一输出UTF-8的问题，建议先按第一步确认上游编码，再根据自己使用的语言选择转码方案，最后用 file 命令或浏览器完成验证。
之后再遇到类似接口，按照这个流程走，基本都能解决乱码。