Postman响应乱码通常是服务端返回gzip/deflate压缩但未正确解压所致，需检查Content-Encoding头、禁用自动解压验证原始字节，而br压缩则Postman原生不支持。
Postman响应显示乱码像二进制压缩数据
这基本是服务端返回了 gzip 或 deflate 压缩的响应体，但 Postman 没能正确解压——不是解析错，而是压根没解。
典型表现：响应体里一堆不可读字符（如 \u001f 开头、夹杂 \x8b\x08 类字节），Raw 视图里能看到 Content-Encoding: gzip 头，但 Body 标签页却显示乱码而非 JSON/HTML 文本。
- Postman 默认开启自动解压，但某些边缘情况（如响应头缺失、压缩流不完整、代理篡改）会导致它跳过解压逻辑
- Mac 版和 Windows 版在解压策略上略有差异，尤其遇到
Content-Encoding: br（Brotli）时，Postman 原生不支持，会直接当原始字节处理 - 如果服务端用了自定义压缩中间件（比如 Nginx 的
gzip_static on配合预压缩 .gz 文件），而文件本身损坏或未校验 CRC，Postman 解压也会失败并静默回退到原始字节
检查并确认 Content-Encoding 是否真实存在
别只信“看起来像压缩”，必须看响应头。打开 Postman 的 Headers 标签页，找这三项：
-
Content-Encoding：值为gzip、deflate或br才算真压缩；若不存在，乱码大概率是编码问题，不是这个原因 -
Content-Type：必须与实际内容匹配（如application/json），否则 Postman 可能误判解压后该用什么方式渲染 -
Transfer-Encoding：若为chunked，要额外注意分块传输是否被截断——Postman 有时会在 chunk boundary 错位时放弃解压
如果 Content-Encoding 存在但 Body 仍是乱码，下一步不是调设置，而是先验证原始字节是否有效。
禁用自动解压，手动保存并验证原始响应
绕过 Postman 的自动解压逻辑，拿到原始字节流，用外部工具验证是否真能解压：
Postman Mac版
下载
Postman Mac版是一款专为macOS设计的API开发与测试工具，凭借简洁的界面和强大的功能，深受开发者喜爱。它支持发送各种HTTP请求（GET、POST、PUT等），轻松管理接口集合、环境变量和模拟服务器。Mac用户可享受原生性能、快捷键优化及与系统无缝集成的体验，适用于接口调试、自动化测试和文档生成。无论是个人项目还是团队协作，Postman for Mac都能提升API开发效率，是ma
- 在请求的 Settings → General 中，取消勾选
Automatically decode compressed responses - 重新发送请求，在响应 Body 标签页点击
Save Response→ 保存为response.bin - 终端执行：
file response.bin看类型；若提示gzip compressed data，再试gunzip -t response.bin测试完整性 - 若
gunzip -t报错（如invalid compressed data），说明服务端输出异常，不是 Postman 的锅
注意：保存前务必关闭自动解压，否则你存下来的已经是 Postman 尝试解压失败后的“残缺字节”，毫无验证价值。
服务端返回 br 压缩时 Postman 无解，必须换方案
Postman 目前（2026 年 11 月）仍不支持 Brotli（br）解压，这是硬限制。
- 看到
Content-Encoding: br且 Body 乱码，直接放弃在 Postman 里“看内容”——它就是不会解 - 临时方案：用
curl -H "Accept-Encoding: gzip" http://xxx强制协商回 gzip，或让服务端对 Postman UA 禁用 br - 长期方案：改用浏览器 DevTools 的 Network 面板（Chrome/Firefox 均原生支持 br 解压并格式化 JSON），或写个简单脚本用
requests+brotli库解压查看
最容易被忽略的一点：你以为在调 API，其实是在和压缩算法博弈。服务端开了 br，Postman 就是摆设，别浪费时间调它的设置。
