请求载荷出现不可读字符的原因是什么？如何转为可读文本？

常见成因 #

• 传输层压缩：HTTP、WebSocket都支持传输压缩，常见压缩算法包括gzip、Brotli(br)、deflate，以及WebSocket专属的permessage-deflate压缩。直接读取未解压的原始二进制字节，必然会出现大量无意义不可读字符，这是占比最高的触发场景。
• 二进制序列化替代纯文本：不少站点为了降低传输体积、提升解析效率，不会直接传输JSON、form表单这类纯文本内容，会改用Protobuf、MessagePack、Thrift这类二进制序列化协议，这类格式本身就面向程序解析设计，原始字节没有可直接阅读的明文语义。
• 自定义加密/混淆：部分站点为了防爬、防抓包篡改，会对业务载荷做异或、AES、自定义编码变换，没有对应解密逻辑的情况下看到的就是无规律乱码。
• 解码配置不匹配：要么是抓包工具没有正确识别协议层封装（比如没解析WebSocket帧头、没处理WebSocket客户端帧的掩码位，把协议头二进制和业务载荷混在一起展示），要么是字符集匹配错误（比如载荷是GBK编码，工具默认按UTF-8解码）。

转可读文本的实操步骤 #

针对普通HTTP POST请求载荷 #

1. 先检查请求/响应头的Content-Encoding字段，如果存在压缩标识，直接开启抓包工具的自动解码功能即可：浏览器DevTools网络面板默认会自动解压，Charles/Fiddler右键对应请求选择「Decode」，Wireshark在HTTP协议配置中开启自动解压选项，不需要手动做解压处理。
2. 解压后仍有乱码的，核对Content-Type头中的charset参数，把抓包工具的展示字符集切换为对应值（比如GBK、GB2312）再查看。
3. 排除编码、压缩问题后还是不可读，先判断二进制序列化格式：MessagePack、Protobuf都有明确的字节特征，可以用对应格式的解码工具、或者对应编程语言的序列化库尝试反序列化——如果是Protobuf通常需要找到站点前端打包的.proto定义才能完整解析字段。
4. 序列化格式也匹配不上的，基本是自定义加密/混淆，需要在站点前端JS代码中定位到载荷加密、发送的逻辑，拿到算法和密钥后再解密还原。

针对WebSocket协议载荷 #

1. 先确认抓包工具开启了WebSocket协议解析：不要直接看原始TCP流，Wireshark需要配置对应端口为WebSocket端口，Charles/Fiddler、浏览器DevTools的WS面板默认会自动剥离WebSocket帧头、处理客户端发送帧的掩码位，直接看解析后的消息列表即可。
2. 检查WebSocket协商阶段的Sec-WebSocket-Extensions头，如果存在permessage-deflate说明开启了压缩，开启工具的WebSocket自动解压选项即可还原明文。
3. 后续序列化格式识别、加密逻辑排查的步骤和普通HTTP载荷完全一致。

相关示例参考：

内容的提问来源于stack exchange，提问作者javedb