PHP调用外部API乱码的核心是响应体真实编码与处理方式不匹配，须通过bin2hex等实测字节模式确认编码，再用mb_convert_encoding显式转换，而非依赖header或mb_internal_encoding。
PHP 调用外部 API 返回乱码，核心问题几乎总是字符编码不一致，而不是“没加编码”——关键在于明确响应体的真实编码，并用对应方式解码或转换，而非盲目设置 header() 或修改 mb_internal_encoding()。
怎么判断 API 响应的真实编码
不能只看 HTTP Header 的 Content-Type，更不能凭感觉猜。必须实测：
- 用
file_get_contents()或cURL获取原始响应体（二进制），先不作任何mb_convert_encoding()处理 - 检查响应头：
var_dump($http_response_header);，找Content-Type: ...; charset=xxx，但注意有些 API 会写错（比如标utf-8实际发 GBK） - 用
mb_detect_encoding($raw_body, ['UTF-8', 'GBK', 'GB2312', 'BIG5'], true)辅助探测（仅作参考，不可全信） - 最可靠：用十六进制查看器（如
bin2hex(substr($raw_body, 0, 10))）比对中文字符的字节模式 —— UTF-8 中文是 3 字节（如e4b8ad），GBK 是 2 字节（如d6d0）
curl 默认不自动转码，必须手动处理响应体
cURL 只负责收字节流，不会帮你识别或转换编码。常见错误是以为设了 CURLOPT_ENCODING => 'UTF-8' 就能解码 —— 这个选项只影响请求头的 Accept-Encoding（用于 gzip 等压缩），和字符编码完全无关。
- 获取响应后，先确认真实编码（见上一条），再用
mb_convert_encoding($raw_body, 'UTF-8', 'GBK')转成你项目需要的编码 - 如果 API 返回 JSON，且含中文乱码，
json_decode()会失败或返回null—— 必须在json_decode()前完成编码转换 - 避免用
iconv('GBK', 'UTF-8//IGNORE', $raw_body)，//IGNORE会静默丢字，不如用mb_convert_encoding()配合mb_substitute_character('none')
为什么 setlocale()、mb_internal_encoding() 基本没用
这两个函数影响的是 PHP 内部字符串函数（如 mb_strlen）的默认行为，和 HTTP 响应的编码解析毫无关系。
立即学习“PHP免费学习笔记（深入）”；
-
mb_internal_encoding('UTF-8')不会让file_get_contents()自动把 GBK 响应转成 UTF-8 -
setlocale(LC_ALL, 'zh_CN.UTF-8')主要影响strftime()、strcoll()等本地化函数，对 API 响应解码无效 - 真正起作用的只有：读取原始字节 → 判定源编码 → 显式转为目标编码 → 后续使用
JSON 接口乱码的典型修复流程
这是最常踩坑的场景：API 返回的是 UTF-8 JSON，但响应头漏写 charset，或你误判为 GBK 导致双重转码。
- 用
$json = file_get_contents('https://api.example.com/data');拿到原始内容 - 检查：
echo bin2hex(substr($json, 0, 6));—— 若输出类似7b22e4b8ad（7b是{，e4b8ad是“中”的 UTF-8），说明就是 UTF-8，无需转换 - 直接
$data = json_decode($json, true);；若仍乱码，大概率是前端 HTML 没声明<meta charset="UTF-8">或输出时被其他环节二次编码 - 若确认是 GBK JSON（如
7b22d6d0），则必须：$json_utf8 = mb_convert_encoding($json, 'UTF-8', 'GBK');，再json_decode()
实际中最容易被忽略的点：你以为 API 返回的是 UTF-8，结果它用的是 GBK；或者你以为自己转对了，其实用了错误的源编码参数导致越转越乱。务必从原始字节出发验证，别依赖文档或响应头。
