(原)一次揪心的乱码排查过程

序）不少时候其实问题很简单，问题在于本身懂得过于肤浅

　　项目中须要用到一个功能，机器人模拟和人类聊天，玩家说出一句话以后，机器人本能的和他开始聊天，这破B玩意儿我以为只要有强大的词库和拆分算法，就那么点东西，可是要本身作还真是压力满满的。因而果断的在网上搜索，轻松的找到了这个东西：

　　

 

　　这玩意儿给个人第一感受就是实在，能够，彻底可以知足需求，不过貌似它没有提供接口，这不是事儿，果断的翻网页源码，找到post的地方，是一个ajax的post请求，带了一个参数，很简单，因而果断的来个java模拟HTTP，分分钟搞定，写了个junit测试下：

　　

 

　　10分钟就搞定了一个智能聊天机器人，原本觉得问题就解决了，因而轻松的部署到jetty去，鄙人对jetty绯闻挺多了，websocket中的EOF曾经就搞了好久，部署上去以后，果断开始使用安卓端测试下，客户端发了一个：你好，另外一个客户端收到：骞茶帿瀛�

　　明显是乱码了，感受debug一下：

　　

 

　　能够看到接受到http的返回值的时候已经乱码了，在此过程当中经历过以下步骤：

　　发出http请求 ---> 第三方接口http返回值 --> 本地jetty容器接受二进制流 --> jetty根据容器编码从新编码二进制数据 --> Java InputStream接受jetty编码以后的流 --> java将其转换成String

 

　　因而咱们看到了一个String的返回值，而这个返回值乱码，通常在汉字乱码中分为两种状况：

　　1：骞茶帿瀛�  这样的乱码其实不叫乱码，而是数据不是咱们想要的，由于咱们要的是A却显示成了B，这样的缘由主要是由于编码格式不正确致使

　　2：?????  全是问号的乱码应该不少人都碰见过，这样的东西应该才是算乱码，为何会出现?。由于字节内的东西没法用一个汉字展现出来，也就是找不到汉字对应这个内容，因而这样的东西会以？的形式展现出来，官方的称呼就是编码黑洞，对应的二进制数据为63，转换后就是一个?

 

　　根据状况来看本身遇到的是第一种，因而有点疑惑，管他的，来个强转：

　　

   ChangeCharset changeCharset = new ChangeCharset();
        try {
            result = changeCharset.toUTF_8(URLDecoder.decode(result, "UTF-8"));
        } catch (UnsupportedEncodingException e) {
            e.printStackTrace();
        }
        return result;

　　管你什么编码，哥给你来个统一，因而美滋滋的再次打开客户端测试，又出现了另一种状况：

 

　　

机器人说:你好爱你哦亲??

　　妈了个巴子，竟然有部分乱码，因而继续测试想找出规律，后来果真发现规律，只要过来的数据是偶数个，则不会乱码，如果奇数个，则最后一个汉字乱码，乱码的形式是固定的?，来了一个?，我靠，今天两种状况都遇到了，本觉得很简单的东西竟然卡在了编码的地方，苦思冥想，很明显是容器编码问题，很SB的解决方法也很简单，判断下是否是奇偶，不是偶数加个东西就好了。

 

　　可是想搞明白为何是最后一个字乱码，忽然想到一个东西，UTF-8中，一个汉字3个字节，GBK中一个汉字2个字节，我好像明白了什么。。

 

　　由于jetty容器默认是按照系统编码来决定容器编码，前提是没有本身修改启动编码，而公司里我台PC是windows的，好像默认GBK的，反正我对windows绯闻也挺多的，因而这里有一个问题，好比jetty接受到了一串通过UTF-8编码的汉字：

　　我很好

　　jetty收到的最原始的二进制数组是这样的：

　　[-26, -120, -111, -27, -66, -120, -27, -91, -67]

　　固然这不是最原始的，最原始的0和1，固然为了好看就算他是最原始的吧，下一步jetty要开始编码了，按照jetty的GBK编码，他按照2个字节一个汉字的格式去编码，因而出现了这样的组合：

　　[-26, -120]  [ -111, -27]  [-66, -120]  [-27, -91]  [-67]

　　前面每两个字节都能找到对应的汉字，最后jetty发现最后竟然只有一个字节，找不到对应的汉字，内心想这SB是哪来的，因而jetty放弃它了，把它赶出去，把63丢过去，因而最后的组合成了：

　　[-26, -120]  [ -111, -27]  [-66, -120]  [-27, -91]  [63]

　　通过GBK的格式编码，两个字节对应一个汉字，就显示出了这样的东西：

　　骞茶帿瀛？

　　会出现5个，由于每2个字节表明一个汉字，最后一个字节是63，对应的符号是？，就出现了上面的东西，因而我对它作了强制的UTF-8编码，致使上面的二进制数组从新组合，通过UTF-8的组合以后，二进制数组成了这样：

　　[-26, -120, -111] [-27, -66, -120] [-27, -91, 63]

　　再通过UTF-8显示以后，变成了这样：

　　我很�?

　　前6个字节可以正常的显示出汉字，由于那就是真正的数据，然而最后3个字节，已经被GBK处理了，替换过了，即便使用UTF-8也没法还原它原来的容貌，因而它就显示成了上面的样子，可是为何偶数不会出错？

　　由于偶数可以被GBK正常的解码，也就是若是汉字是偶数，UTF-8和GBK是等同的，可是若是是奇数，则就出问题了，这也是传说中的最后一个汉字乱码的问题，由于最后一个 字节始终是63，要解决这个问题，必需要治标还要治本，项目中必须全程保证编码一致性，由于我这个项目是游戏服务器，走的WebSocket，要是Servlet能够直接在Servlet里面处理或者Filter处理。

　　不一样的编码方式，处理逻辑不同，不少时候咱们强转看似解决了问题，其实只是问题没有暴漏出来，知道其根本，方能指挥若定之中，决胜千里以外。

 

　　扯点题外话，前几天半夜不知道抽了什么风，将Centos升级到了6.6，结果在6.6下eclipse所有打不开，全是fatal级别的错误，反正不是我等闲人能解决的，那一次更新下载的更新包是1.4GB，明显是系统兼容性的问题，我了个擦，因而想到一代码农不能死于eclipse下，因而折腾下了VIM，弄了几个插件。虽然之前也用VIM，可是没有此次这么正式，弄了下发现其实这玩意儿至关优秀，基本除了eclipse的打断点Debug，其余和他差很少，写C/C++更快，一个\im过去整个文件注释main总体就起来了，至关便捷，另外Linux下的UI也至关不错，特别是DUCK桌面，和Mac基本差很少，甚至你能够用java写出这样的东西：

　　

　　对于程序猿，Linux是个好东西，有喜欢试水的朋友，能够试试。

　　附上最近给本身系统加了DUCK美容后的美照：

　　

　　

 

结语）其实这个问题很简单，只是当时太SB，想一想就揪心。。