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 = Charset.defaultCharset().name();
而結果顯示出來就是：
所以，問題很明顯，就是因為本來是utf8的字節，用gbk來解碼，當然會亂碼。
2.6 解決辦法1
參考了：
https://blog.csdn.net/qq_21033663/article/details/53022797
1、通過System.out.println(System.getProperty("file.encoding"));可查看JVM運行時所使用的編碼
2、默認情況：
1）Windows下，file.encoding=”GBK”,
2）Linux下，file.encoding=”UTF-8”。
3、通過修改Tomcat配置來指定JVM運行時所使用的編碼
1）linux下，在catalina.sh配置：JAVA_OPTS="$JAVA_OPTS -Dfile.encoding=utf-8"
2）Windows下：在catalina.bat配置:set JAVA_OPTS=%JAVA_OPTS% -Dfile.encoding=UTF-8
2.7 解決辦法2
new String的時候，指定正確的解碼字符集就可以了。
如下：
三、參考資料
1、RawCap的使用
https://blog.csdn.net/lz_obj/article/details/53116432
這個可以多開，同時跟蹤多個網卡。
2、wireshark的使用
https://www.cnblogs.com/yuhuameng/p/5871443.html
wireshark和RawCap跟蹤並解決中文亂碼問題