2023年7月3日发(作者：)

wireshark和RawCap跟踪并解决中⽂乱码问题⼀、问题概述说下程序的架构。有个后台管理系统A，在页⾯修改数据后，会⽤httpClient发http请求给系统B；系统B做了异步机制，收到A发的请求后，将数据封装为Mq消息发给RabbitMq，然后结束该请求；然后系统B⾃⼰也是消费者，去对应的Rabbitmq拉取消息后，封装⼀个httpClient通知系统C。系统C会将该数据放到Redis⾥⾯。然后我们发现，Redis⾥⾯的value出现了中⽂乱码问题。⼤概的流程如下：

我采取的办法是，因为我们的所有系统，都默认是要采⽤“utf-8”来编码，那么我只要⼀路跟踪请求的链路，看看到底是在哪⼀步乱码的，就知道问题所在了。我准备利⽤wireshark和rawcap来跟踪链路。本来不需要RawCap，主要是wireshark⽆法跟踪localhost链路上的⽹络请求。（上图，系统A、B、Mq在同⼀台机器上）

⼆、链路跟踪2.1 A到B的链路跟踪上⾯提到，A是后台管理系统。下⾯是其界⾯。

注意到，上图中，有⼀个“中”字。⽽“中”在utf8中被编码为：

这边先不讲，怎么利⽤wireshark和rawcap来抓包。先看我们跟踪的结果：

经过寻找，我们页⾯上提交的“11中11236ckl111”就在上图红框标出的地⽅。这有个⼩技巧，我提交的字符串中，“中”字前后有两个1，主要就是⽅便寻找。上图，红框前后各有两个31，（对应数字1），那中间的“e4 b8 ad”就是中字的编码。可以看到，这个编码没问题，因为和我们查到的“中”的utf8编码是⼀致的。

2.2 B到Mq的链路跟踪 注意上图，就是系统B发到Mq的消息（上图中红框标识了其协议为AMQP，后⾯的Basic Publish表⽰这是⼀条⽣产者发送的消息）。这⾥的编码也是没问题的。 2.3 系统B消费Mq的消息的链路跟踪

和上⼀节类似，该消息就是系统B作为消费者从Mq拉到的。这⾥的编码也没问题。

2.4 系统B消费消息后，发送给系统C的消息的链路跟踪

注意了，上图这⾥，我们发现，这次“中”所在的编码，不再是utf-8，⽽是变成了什么“e6 b6 93 ef bf bd”之类的内容。我猜想了半天，实在难以理解为什么编码会变成这样。哪怕utf32也不会⽤6字节来编码这么⼀个简单的汉⼦吧。出问题的节点是找到了，那么剩下的就是查看代码。

2.5 代码问题定位

上图，第⼀个红框的位置，是获取消息体的字节数组；第⼆个位置，就是将字节数组解码为String。我猜测就是第⼆步出了问题。让我们看看该⽅法的说明：

这⾥是说，将会按照系统的默认字符集来解码。我在192.168.19.88上写了个java测试类，打印了下列变量：String csn = tCharset().name();⽽结果显⽰出来就是：

所以，问题很明显，就是因为本来是utf8的字节，⽤gbk来解码，当然会乱码。

2.6 解决办法1参考了：

1、通过n(perty("ng"));可查看JVM运⾏时所使⽤的编码2、默认情况：1）Windows下，ng=”GBK”,

2）Linux下，ng=”UTF-8”。3、通过修改Tomcat配置来指定JVM运⾏时所使⽤的编码1）linux下，在配置：JAVA_OPTS="$JAVA_OPTS -ng=utf-8"2）Windows下：在配置:set JAVA_OPTS=%JAVA_OPTS% -ng=UTF-8 2.7 解决办法2new String的时候，指定正确的解码字符集就可以了。如下：

三、参考资料1、RawCap的使⽤这个可以多开，同时跟踪多个⽹卡。这⾥注意的⼀点是：⽐如两个服务部署在同⼀个服务器上，但是调⽤的时候，host⽤的是真实ip（192.168.19.88）⽽不是127.0.0.1的话，抓包的时候，可以像下⾯这样： 192.168.19.88

2、wireshark的使⽤

3、utf-8编码转换

4、gbk编码转换

5、vim打开gbk编码的⽂件，乱码怎么办我们这边服务⽤gbk编码写⽇志⽂件。直接⽤vim打开后，直接就乱码了。此时可以：

然后执⾏：:e 刷新⼀下 这个⽅法可以永久解决，需要退出shell重登⽣效：