Raw视图显示乱码常见于：响应为二进制却未下载、服务端返回gzip压缩但Postman已自动解压、响应头缺失或编码声明错误；其本质是Postman用UTF-8直接解码原始字节流，失败则显示，而Pretty依赖Content-Type做格式化，二者内容长度一致但解释方式不同。
Postman 默认用 Pretty 模式美化 JSON/XML，但你想看原始字节流、确认是否被 gzip 压缩、检查 BOM 头或验证编码问题，必须切到 Raw 视图——它不解析、不转义、不补全，就是服务器发来的那一坨字节原样呈现。
为什么 Raw 视图显示的是乱码或一堆不可读字符
常见于以下几种情况：
- 响应体实际是二进制（如 PDF、图片、ZIP），而你没选
Send and download，Postman 会尝试用 UTF-8 解码二进制流，结果就是乱码 - 服务端返回了
Content-Encoding: gzip，但 Postman 自动解压后仍把解压后的内容当文本渲染；此时Raw显示的其实是解压后的原始文本（如果编码正确），不是传输层原始字节 - 响应头缺失
Content-Type或声明为text/plain，但实际含 UTF-16 或带 BOM 的 UTF-8，Raw不做编码推断，直接按系统默认编码渲染
Raw 和 Pretty 对同一响应的差异在哪
关键区别不在“内容”，而在“解释方式”：
Postman 12.27.7
下载
Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。
-
Pretty：依赖Content-Type响应头（如application/json）触发语法高亮+自动缩进+折叠+链接可点击；若头不匹配，可能完全不格式化 -
Raw：无视所有响应头，只做一件事——把响应 body 字节流原样转成字符串显示（底层用 UTF-8 解码，失败则显示 符号） - 两者看到的 body 内容长度一致，但
Raw能暴露空格、换行、BOM、控制字符等被Pretty过滤或隐藏的细节
怎么确认响应是否真的被压缩了
单靠 Raw 视图无法 100% 判断，需交叉验证：
- 先看响应头：找
Content-Encoding: gzip或br；没有这个头，基本没压缩 - 再看
Raw内容开头：gzip 压缩流固定以1f 8b两个字节开头（十六进制），可用浏览器 DevTools 的 Network 面板 → Response → Right-click → “Open in new tab” 后查看源码，或复制Raw内容粘贴到十六进制查看器里验证 - 对比大小：
Response size标签旁显示的 “Body: X B” 是解压后大小；若响应头有Content-Length且明显小于该值，说明 Postman 已解压（Postman 总是自动解压 gzip/br）
真正需要原始字节时，别信 Raw 视图——它只是解码后的文本快照。要验签、调试编码、分析协议层问题，得用抓包工具（如 Wireshark）或服务端日志。Postman 的 Raw 是开发阶段快速排查的辅助手段，不是字节级真相。
