java乱码

在做 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解码产生了不可恢复的错误，造成了信息丢失，至于为什么产生永久错误，得从编码的底层说起……