序）很多时候其实问题很简单，问题在于自己懂得过于肤浅

　　项目中需要用到一个功能，机器人模拟和人类聊天，玩家说出一句话之后，机器人本能的和他开始聊天，这破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，想想就揪心。。

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