抓包这事，抓到常常只是开头，真正费劲的是看懂。你大概也遇到过这几种：
- 响应点开一看，body 是一坨压缩过的二进制，啥也认不出；
- 接口明明返回了 JSON，挤成一行不换行，找个字段得拉半天；
- 一条遥测上报，前面几个自定义头、后面跟一段压缩流，没有标准编码标识，普通工具直接给你摆一堆乱码；
- gRPC 接口没有
.proto在手，字节根本没法读。
抓包响应怎么看明白，说白了就是"把抓到的字节还原成人能读的样子"这一步。这篇就拿 TraceEagle 的数据查看来讲讲：一条数据能有哪几种看法、引擎替你自动做了哪些解码、碰上非 HTTP 的流量又怎么办。
为什么抓到的 body 常常看不懂？
根子在于，网络上传的字节本来就不是给人直接读的。服务端为了省流量会压缩（gzip、brotli 这些），内容类型五花八门（JSON、protobuf、图片、plist），有些自研上报还会套一层私有信封------自定义头加压缩流，连个标准的 Content-Encoding 都不给你标。
普通工具多半只解最外面一层编码，剩下的原样丢给你。于是你看到的就是乱码。想看明白，要么工具帮你一层层解开，要么你自己掏出各种解压、解码的小脚本挨个试------后者我干过，折腾小半天，真心累。
抓包看不懂，九成不是数据坏了，是没被正确地解压和解码。
一条数据能有哪几种看法？
TraceEagle 里请求和响应两侧各自独立切换查看方式，一共五种，按你当下想看什么挑：
- 结构化：默认视图，起始行加请求头表格，body 智能展示，日常看接口够用；
- 文本·美化：按内容类型自动缩进，JSON、XML、表单一键格式化，挤成一行的 JSON 瞬间就铺开了；
- 文本·原样：完整报文按文本原样摆出来，想看原始结构时用；
- 十六进制：hex 查看器，点一个字节 hex 和 ASCII 两边联动高亮，显示偏移，还能一键存成二进制文件------排查协议字节、定位某个魔数特别顺手，数据再大也不卡；
- 自动识别 ：交给引擎深度解码，渲染成能逐层展开的解码树，压缩里套压缩、帧里再套帧，都能一层层钻进去。
有个概念别绕混了：「查看为」切的是表示层（结构化 / 文本 / 十六进制 / 自动识别），而 JSON、XML、表单这些属于文本的格式化方式，归「文本·美化」自动处理，不单列成一种。想清楚这点，切起来就不晕了。
引擎替你自动做了哪些解码？
这块是省事的大头。抓到一条数据，引擎默认就把下面这些活儿干了，不用你动手：
- 多层自动解压 ：gzip、brotli、deflate、zstd 都认，而且支持多层叠加------像
gzip, br这种从外到内逐层解开，普通工具常常只解最外一层就停了； - 自动识别并美化：JSON、XML、表单、Apple plist（二进制、XML、连 NSKeyedArchiver 归档都能还原）、protobuf / gRPC；
- 二进制格式识别：内置的识别引擎能认出图片、字体、PDF、压缩包，压缩包还能列出里面的文件清单；
- 媒体内联预览：图片、视频、音频直接在详情里渲染或者播放，不用导出来再找个软件打开；
- 信封智能剥离：前面说的那种"自定义头 + 压缩流"的遥测信封，它能认出来、把信封头剥掉、还原出里面真实的数据------这一步是普通工具翻车最多的地方。
还有个细节我挺认可：碰上确实还原不了的私有加密数据，它会老老实实告诉你"这段解不开"，而不是硬塞一堆乱码让你误会是自己操作错了。诚实这点，调试的时候真的省心。
举个我前阵子碰到的例子：一条上报接口，响应头里压根没写 Content-Encoding，点开全是乱码。我切到「自动识别」，引擎先认出外层是 gzip 给解掉，发现里面又是一段 protobuf，直接展成了带字段号的树------我一行脚本都没写。搁以前，我得先猜它压没压、用的哪种压缩，curl 下来管道接 gunzip，再翻出 protoc 挨个解，一套走下来小半个钟头就没了（还不一定一次猜对）。这种"抓到即还原"省下的，其实就是来回试错那段时间。
gRPC / protobuf 不用你准备
.proto文件就能解出字段号、类型和值。没有 proto 定义时，字段名显示不出来是正常的------字段号和值都在，照样能对着接口猜出结构。
不是 HTTP 的流量怎么看？
抓包这事早就不只有 HTTP 了，TraceEagle 的查看器对这些也能使用：
- WebSocket：逐帧展示，文本帧、二进制帧、ping、pong 分得清，还标收发方向；
- SSE（Server-Sent Events）：事件流一个事件一个事件地列出来，看推送很直观；
- gRPC / protobuf ：前面说了，无需
.proto直接解； - 裸 TCP / UDP：没解密的、或者压根不是 HTTP 的原始收发字节，hex 和文本随你切。
要是碰上自研的私有二进制协议，很多私有帧引擎能自动试出边界、逐帧拆开，不用写一行脚本；复杂一点的，内置了长度前缀、Magic 签名、分隔符、定长这些分帧模板，改几个值就能拆；再刁钻的，写少量 JS 自定义分帧兜底。一条裸流能拆成一条条消息，这在排查私有协议时省了大功夫。
几个常见问题
抓到的图片能直接看吗？
能。引擎认出是图片后会在响应详情里直接渲染出来，还标类型和大小，不用另存再打开。
多层压缩的响应，它能全解开吗？
能。gzip 套 br 这种叠加编码会从外到内逐层解，不是只解最外一层。解不动的那层它会提示，不会假装成功。
十六进制视图能定位到具体字节吗？
能。点 hex 那边，ASCII 那边同步高亮，偏移也显示，想保存成二进制文件一键就行，分析协议格式时比纯文本直观。
没有 .proto，gRPC 还能看吗？
能看字段号、类型和值，就是字段名显示不出来。对着接口文档或者多抓几条对比，结构基本能还原。
和 Charles、Wireshark 比一比
几个工具在"看 body"这件事上各有侧重：
- Charles：JSON、XML 美化做得不错，日常 HTTP 调试顺手，但多层压缩、protobuf、私有信封这些遇上就有点吃力；
- Wireshark：看字节、看协议分层是它的强项，可 HTTP body 的解压和美化要自己配，媒体预览基本没有；
- 浏览器 DevTools：看自家网页的请求响应方便，但只能看过它这个浏览器的流量，手机和别的程序就够不着了；
- TraceEagle：强在"抓到就尽量帮你还原到能读"------多层解压、二进制识别、媒体预览、私有信封剥离连在一条链路上，HTTP 之外的 WebSocket、gRPC、裸流也统一在一个查看器里。
真要做底层协议的逐包精细分析，Wireshark 的专业度还是更深，该用它的时候用它。各看各的场景，组合着来效率最高。