Java调用第三方API时，若响应为GBK编码但未正确解码会导致中文乱码；关键在于实测确认真实编码，并显式用"GBK"解码字节数组，而非依赖响应头或默认UTF-8。
Java 调用第三方 API 时，如果响应内容是 GBK 编码但没正确声明或没按 GBK 解码，就会出现中文乱码（比如显示成 ??? 或方块）。核心不是“怎么接”，而是“怎么**正确解码**”——关键在识别并指定响应的真实字符集。
确认响应实际编码是 GBK
不能只看文档或接口名，要实测。常见方式：
- 用 Postman 或 curl 请求接口，看响应头中
Content-Type是否带charset=gbk（注意：有些接口不写，或写错） - 用浏览器开发者工具（Network → Response Headers）查看原始响应头
- 把响应体二进制数据保存为文件，用编辑器（如 Notepad++）以 GBK 打开，若中文正常，基本可确认是 GBK
HTTP 客户端手动指定 GBK 解码
多数 HTTP 客户端默认按 UTF-8 解码，需显式设置编码。例如：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- OkHttp：不依赖响应头，直接按 GBK 解析响应体
Response response = client.newCall(request).execute(); String body = new String(response.body().bytes(), "GBK"); // 关键：强制用 GBK 解码
-
Apache HttpClient：用
EntityUtils.toString(entity, "GBK") -
Spring RestTemplate：避免用
response.getBody()直接转字符串；改用response.getEntity().getBody()获取字节数组，再用new String(bytes, "GBK")
处理无 Content-Type 或 charset 错误的响应
有些接口返回 Content-Type: text/plain 或空 charset，甚至写成 charset=utf-8 但实际发的是 GBK。此时必须忽略响应头，以实测为准：
立即学习“Java免费学习笔记（深入）”；
- 先读取原始
byte[]，再尝试用"GBK"和"UTF-8"分别解码，检查哪个能解析出合理中文（可用正则[\u4e00-\u9fa5]判断） - 生产环境建议加 fallback 逻辑，比如：
String tryDecode(byte[] bytes) {
try {
return new String(bytes, "GBK");
} catch (UnsupportedEncodingException e) {
return new String(bytes, StandardCharsets.UTF_8);
}
}
注意 URL 参数和请求体的编码方向
乱码不止发生在响应，请求时也可能出问题：
- 若向第三方发送含中文的参数（如 GET 查询串、POST 表单），需确保按对方要求编码（常见是 UTF-8，少数老系统要 GBK）
- 用
URLEncoder.encode("中文", "GBK")编码参数，并确认 URL 整体被正确拼接 - POST 提交 JSON 时一般用 UTF-8；若对方明确要求 GBK 编码的 JSON 字符串，需先生成字符串，再用 GBK 转字节数组发送
