bae java乱码_Java乱码总结（一）

1.实际项目中的乱码问题

(1)项目背景

我们的项目是以百度云服务器为开发平台的，然后我们把写好的框架和代码部署到上面去，让百度帮我们运行程序代码！这样既减少了维护的人力，又节约了开发的成本！但是，奇怪的事情就发生了。我们的新服务是11月2号部署上去的，然后当客户端访问注册平台的时候，突然发现乱码！！！

(2)解决之路

乱码？乱码？当时我的第一反应就是肯定是编码格式的问题！然后就开始走上了寻找到底是哪个环节导致了我们的乱码问题的不归之路....

A.首先问了一下百度客服，百度客服说百度云数据库默认的编码格式是gbk，我们的数据库的编码格式是UTF-8，我想是不是因为我们的新部署的工程和上一版本的工程的数据库编码不一致导致的，然后我就查看了上一版本数据库的编码格式，发现是UTF-8！！纳尼，为什么上一个版本的数据库编码格式是UTF-8，却没有乱码呢？再次搜索类似的问题后，发现原来百度的云数据库是用phpMyadmin来管理的。可以通过导入dll语句来自动生成表。网友有的人建议我在生成数据库表的时候set names UTF8,然后默认每个表的编码格式都设置成UTF8！！ok，抱着试试看的态度，自动生成表，重启之后，客户端注册的时候发现还是乱码(失败一次)！！

B.额，好吧！我已经排除了新版本云端数据库与旧版本云数据库编码格式不一致的原因。然后，我再想，我们在本地服务器测试的时候根本没有任何的乱码问题，但是部署到百度云平台的时候就出现了乱码问题！肯定是云端数据库的编码格式和本地数据库的编码格式不一样导致的！然后立即查看了本地数据的编码格式，发现是UTF-8,每个字段的编码格式也是UTF-8！当我再看一下云数据库的时候发现！尼玛，虽然是UTF-8，但是字段整理的时候是用gbk_chinese_ci来整理的，但是就想是不是这个原因导致的乱码！！然后立即把字段整理方式都改成UTF-8，然后重新注册的时候发现还是乱码(失败二次)。

C.通过对比！发现我们云端的数据库和老版本云端数据库编码是一致的，不行！当和本地数据库的编码格式是一样的时候，不行！那会是哪个环节出了问题呢？之间折腾了我好久来整理思路和重新倒腾数据库和工程，然后又想到了我们本地工程在用户操作后，都会打印出来一些基本的信息(这是我便于查错而手动添加的代码)，会不会部署到云端后也会有打印信息呢？？果然，点击进入工程日志的时候，发现竟然所有的中文都是乱码！！！难怪数据库里面保存的是乱码，原来解析数据的时候得到的就是乱码啊！然后问了一下百度客服，客服的回答是：“您好，acl权限没过，应该是您的acl写错了。”额，好吧，我信了！查看下后，发现没有任何的错误啊(失败三次)... 我静心想一下，因为我们的本地工程用的服务器是Jetty，部署到百度后用的是tomcat服务器！是不是因为我们服务器不同而导致的原因呢？这时候，我就把工程删除掉！重新部署使用的服务器改成jetty服务器。然后，客户端注册的时候发现，还是乱码(失败四次)！我已经疯了！！

D.到底是哪个环节出了问题呢？？仔细想，我之前做卓越班网站的时候曾经遇到过乱码问题，当时是因为部署工程后没有设置服务器的编码格式导致的。所以，我再想！要不就设置一下服务器的编码格式吧。。然后百度了好久，才了解到百度云值支持通过svn工具自己设计tomcat的属性和一些配置文件的！这时候，我就大概了解到了应该是我们的工程和服务器的工程编码方式不一样！所以当服务器解码war文件的时候，出现了乱码问题！然后我重新部署工程，设置了云端服务器(tomcat)的编码格式为utf-8,这时候，我觉得应该没有问题了吧~~  可是万万没想到，当客户端注册的时候还是出现了乱码(失败五次)。额！！好吧，我已经无言以对了，怎么回事？？到底怎么了？

E.不是服务器编码格式的问题，不是数据库编码格式的问题！当我再次查看工程日志的时候发现还是乱码？这次我终于忍不住问了句：为什么我们的工程日志是乱码呢？百度也给面子，一天多时间就回答：您好，BAE对中文日志支持不好，请您不要使用中文日志。！！额，好吧！百度，你赢了。然后我想可能排除了服务器的编码格式和war编码格式的原因了。然后，我再想，是不是因为数据传输过程的时候，编码格式改变了而导致的呢？然后就立即行动，把工程里面得到客户端数据的那个地方强制进行编码格式的转变String str = new String(jsonstring,"utf-8");，这时候想：应该就没问题了吧。然后重新部署，重新注册。乱码！(失败六次)这到底是什么原因呢？然后我就做了一次尝试，在工程里面手动设置用户的信息，然后发现，这些信息在数据库里面保存的完整的中文，没有任何编码上的问题！我就更加坚定地相信了应该是数据传输过程中而导致的乱码，并不是所谓的工程编码还有服务器编码等等...

F.通过对比，发现这次的工程和之前版本最大的区别在于，我们这次的版本使用了数据的压缩，签名认证，数据加密等等....我想应该就是这方面而导致数据的编码格式改变了吧。然后通过控制变量法，当客户端和服务器约定使用数据压缩和签名认证的时候，保存在数据中的数据，不是乱码！这时候当使用数据的加密的时候，出现了乱码情况。。这时候已经找到问题的原因了。。就是因为我们使用了数据的加解密而导致数据传输过程中的乱码！然后发现我们在使用AES算法的时候使用了base64编解码。这个应该就是问题的本质所在！解决方法：换了一种编解码的方式！我么把客户端把数据解密成16进制的数据，然后通过byte数组的形式传输过来，我们在反向得到真实数据！这样就没有设计到编码，然后重新部署工程，那么问题就解决了！

G.其实，编码问题并不是大问题，问题的关键在于找到出现编码问题的根源...  要搞清楚哪些地方引起从字符到字节的编码以及从字节到字符的解码，还有就是针对数据的框架或系统是如何控制编码的；最后正确设置编码格式，避免使用软件默认的或者是操作系统平台默认的编码格式。