关于中文乱码这坑

前阵子因为开发一个小项目吃过中文乱码的亏，这次因为迁移一个容器做优化又来乱码这戳，搞了4天。我不得不说中国人开发真心还要考虑乱码这事真苦逼。
前阵子事情是这样的要做一个外挂的接口，客户有专门的接口平台，已经开发好了对应接口，而我们要做的就是把数据取出来然后根据对方的规则传过去调用他们的接口，获取返回值然后再调用自己项目的接口插入数据。不要问我为什么要这么做，我只能说因为剧情需要好吧。重点要说的就是传过去的编码要utf-8的，大家都知道utf-8是国际通用编码，而gbk是相对中国人用的。问题是我之前开发都是用gbk的，我看了一下他们接口的通用方法，用的是charset.defaultcharset(); 二话不说开始工作，因为是外挂的程序，所以什么都要从头开始，搭框架填内容，关于搭框架这事有个小插曲，我本想搭个高大上的比如我现在接手的这个什么angularjs、restfulwebservice、JPAhibernate、jesery啥的，都是新名词又或者我用最最最大众的SSH框架。搭了2天我在想我到底是在玩呢还是在工作呢，搞了这么复杂干嘛，项目进度又这么赶。最后我老公说快点搞定，工作不是玩能最快把事情做好就好。于是听老公的，我就弄了个最最简单的，jsp\servelet\jdbcDao 半天就搞定了框架。填内容当然更简单了，1天搞定了所有内容加调试。问题来了我传过去那边接收到后是乱码。出现乱码的原因是因为我传过去的不是utf-8。
编码涉及到几个方面1、关于编译器的编码设置 2、容器的编码设置 3、传过去的编码设置
当我用编译器调接口的时候传过去没有乱码，放到容器里的时候传过去又是乱码了。另外就是传过去在headers上也可以设置编码。因为我当时看到的是charset.defaultcharset()这个方法，所以我一直在调试前2个原因。虽然最后只要headers改成charset.forName("UTF-8")就行了。
但是关于搞这前2个我就开始有点了解了编码。
首先要项目本身前后台编码不乱那么你前台页面编码gbk传到后台的contentType也要是gbk后台一定也要用gbk返回。那么至少项目内容传输不会乱码，其次就是tomcat编码，tomcat一般都是取系统编码的，当然你直接在代码中写charset.defaultcharset就知道tomcat编码了，网上说什么server.xml里面加一句URIEncoding="utf-8"就是utf-8编码了。这个我觉得不靠谱，这次我在cookie中就深刻的体会到了。
这就是我这两天做性能优化迁移容器遇到的中文乱码的事情，cookie中文乱码问题。
同一套代码在tomcat7中cookie就是乱码，在jetty中cookie就没有乱码。我不知道cookie的编码是取谁的。游览器我都是用chrome。查看cookie的时候都没有乱码，但是传输到后台的时候tomcat7就是乱码，jetty就不是。因为前台跳转是用angularjs，我也不知道怎么设置contentType所以我只能想办法把tomcat设置成utf-8，但是网上的方法都试过了，cookie还是乱码。最后的解决方案是在setcookie的时候用URIEncodeComponet()方法解决的，这时存在cookie上查看的时候是编译过的，看不懂。但是传到后台就是好的。

如果cookie是取容器的编码格式，那么tomcat7还是不是utf-8，但是编译成utf-8的cookie传到后台居然不需要utf-8解码，而tomcat显示的编码是window-1252取MS系统编码。而jetty我当时也打印过编码也是windows-1252，后台直接sql取数据打印出来都是？？？这三个字符。虽然我还是没有搞清楚编码这鸟事，但是由此我得出一个结论cookie千万不要存中文，存些英文和数字就好了。