内容摘要：Burp Suite 抓到的 HTTP 响应里，中文变成了一堆问号或者乱码方块。这不是 Burp 的 bug，十有八九是你没告诉它该怎么解码。 HTTP 协议本身不强制规定字符集。服务端返回的 Con

Burp Suite 抓到的数据 HTTP 响应里，中文变成了一堆问号或者乱码方块。显示这不是中文 Burp 的 bug，十有八九是数据你没告诉它该怎么解码。

HTTP 协议本身不强制规定字符集。显示服务端返回的中文 Content-Type 头里如果写了 charset=GBK 或 charset=GB2312，浏览器能正确渲染，数据但 Burp 默认按它自己的显示逻辑去猜编码，猜错了就乱。中文更麻烦的数据是，很多服务端压根不在 header 里声明 charset，显示直接把 GBK 字节流扔过来，中文Burp 按 UTF-8 一解，数据全废。显示

我上周测一个老旧的中文政务系统就撞上这事。响应包里 Content-Type: text/html，没有 charset。Burp 的 Raw 视图里中文全是 锟斤拷。切到 Hex 视图看字节，D6 D0 对应的是 GBK 的“中”字，Burp 却拿 UTF-8 去拼，拼不出来就替换成 U+FFFD。

改哪里

打开 Burp，进 Settings → Display（旧版在 User options → Display）。有一栏叫 HTTP Message Display，里面有个字符集下拉框。默认是 “Automatic”。把它改成你目标系统实际用的编码，比如 GBK 或 GB18030。改完不用重启，切回 Proxy 的 HTTP history 就能看到中文了。

但这里有个坑。你改成 GBK 之后，那些确实是 UTF-8 的响应又会乱。所以别指望一个全局设置解决所有问题。

更精细的做法是用 Burp 的 Inspector 面板。选中某个请求或响应，在 Inspector 里找到 Response → Charset，单独给这个包指定编码。这个设置只影响当前查看的消息，不会污染其他请求。

如果是自己写插件

用 Burp Extender API 处理 IHttpListener 的时候，processHttpMessage 拿到的字节数组是原始字节。你在插件里 new String(bytes) 而不指定 charset，Java 会用平台默认编码——Windows 中文版是 GBK，Linux 服务器上可能是 UTF-8。同一个插件换个环境跑，输出就不一样。必须显式写 new String(bytes, "GBK") 或从 Content-Type 头里解析 charset。

Repeater 里发出去的请求也受影响

反过来，你在 Repeater 里手动构造一个包含中文参数的 POST 请求，Burp 会按当前显示编码把字符转成字节发出去。如果显示编码设的是 UTF-8，但服务端期望 GBK，参数就错了。这时候需要在 Repeater 的请求编辑区右键，选 Change body encoding，或者直接在 Hex 视图里手工改字节。

还有个容易忽略的点：Burp 的 Decoder 模块。你把一段 GBK 字节粘进去，选 “Decode as → GBK”，能看到正确中文。但如果你先按 UTF-8 解了一遍，得到的是乱码字符串，再用 GBK 去解那串乱码，救不回来。字节层面的编码转换必须在原始字节上做，不能先变成 String 再转。

说白了就一句话：Burp 不显示中文，是因为它不知道字节流对应哪张码表。告诉它就行了。全局设置管大多数情况，Inspector 管个别请求，写插件就自己指定 charset。三个层面各管各的，别混。