一、問題概述
說下程序的架構。
有個后台管理系統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
這個可以多開，同時跟蹤多個網卡。
這里注意的一點是：
比如兩個服務部署在同一個服務器上，但是調用的時候，host用的是真實ip（192.168.19.88）而不是127.0.0.1的話，
抓包的時候，可以像下面這樣：
RawCap.exe 192.168.19.88 dumpfile.pcap
2、wireshark的使用
https://www.cnblogs.com/yuhuameng/p/5871443.html
3、utf-8編碼轉換
http://www.mytju.com/classcode/tools/encode_utf8.asp
