在做java项目（特别是web项目）的过程中，中文乱码一直是我们开发人员比较头疼的问题，因为涉及到编码，解码，字符集，以及国际化等诸多问题，所以在着手解决的时候也缺乏相关的知识。我花了一些时间自己动手实验了一把，虽然没有洞悉编码，解码这些底层原理，但是解决实际问题应该足够了。这里主要针对java web项目中的文乱码问题。
从浏览器采用form方式提交数据到服务器，可以分为post和get方法。
1，post方法：
在jsp页面中的page指令中，有一个pageEncoding，这个指令表示jsp翻译成servlet时采用的编码，以及form提交数据的编码格式。所以post方法提交数据的编码格式由pageEncoding指定。那解码方式呢？通常，我们在页面设置了pageEncoding=”utf-8”，在后台用request.getParameter()得到的往往是乱码，而进一步通过new String(getBytes(“iso-8859-1”),”utf-8”)处理之后就能得到正确的数据。这是因为服务器默认的解码方式是iso-8859-1，所以用编码，解码流程解释上面那2个动作分别是：utf-8编码—>iso-8859-1解码（当然是乱码）； utf-8编码—>iso-8859-1解码—>iso-8859-1编码—>utf-8解码，这是个对称的过程，所以能正确得到数据。那服务器默认的解码方式能改吗？当然可以，调用request.setCharacterEncoding()就能设置，而且只针对post方式有效，设置以后request.getParameter()直接就是正确的数据了。
2，get方法
与post方法一样，编码方式由pageEncoding指定，但是get方式的解码方式与post就不一样了。在tomcat的conf目录下有一个server.xml的配置文件，在里面找到Connector节点，有一个URIEncoding属性，这个属性就是指定get方式的数据解码格式的，而且只针对get方式有效。其他处理与post一样。
另外，通过Ajax请求向后台发送的数据由于是附在URL地址后面的，所以跟get请求一样。编码由pageEncoding指定，解码由URIEncoding指定。但是有很多开发人员乐于另外一种方式：用两次encodeURI编码，然后在后台用URLDecoder.decode(str,”utf-8”)解码。这是一个什么过程呢？我们知道，encodeURI编码是采用的utf-8编码，所以，这个过程为：utf-8编码—>utf-8编码—>iso-8859-1解码—>utf-8解码。这看起来不像一个对称过程，但最后为什么能得到正确结果呢？这是因为经过第一次utf-8编码之后，产生的已经是非中文字符，所以，对非中文字符采再用utf-8编码，iso-8859-1解码不会有任何问题，这样看来，它还是一个对称的编码，解码过程，当然能正确解析了。
当然，我所说的这个“对称”编码解码过程，也不是所有编码都适用，例如：
gbk编码—>utf-8解码—>utf-8编码—>gbk解码，最后还是乱码！
因为gbk编码—>utf-8解码产生了不可恢复的错误，造成了信息丢失，至于为什么产生永久错误，得从编码的底层说起……
