1.java内核和class都是基于Unicode的，所以跨平台性强，乱码原因分为两种：1.编译时源文件本身产生乱码 2.与其他媒介交互时产生乱码（如tomcat）
首先Java（包括JSP）源文件中很可能包含有中文，而Java和JSP源文件的保存方式是基于字节流的，如果Java和JSP编译成class文件过程中，使用的编码方式与源文件的编码不一致，就会出现乱码。基于这种乱码，建议在Java文件中尽量不要写中文（注释部分不参与编译，写中文没关系），如果必须写的话，尽量手动带参数－ecoding GBK或－ecoding gb2312编译；对于JSP，在文件头加上<%@ page contentType="text/html;charset=GBK"%>或<%@ page contentType="text/html;charset=gb2312"%>基本上就能解决这类乱码问题。
2.对于get请求和post请求之分
get:修改tomcat(默认iso8859-1)的编码，在url中加urlencoded
post:过滤器，或后台setCha...encode("utf-8")
修改tomcat下的conf/server.xml文件，找到Connector标签，添加useBodyEncodingForURI="true"，如下代码：
<Connector port="8080" useBodyEncodingForURI="true" protocol="HTTP/1.1"
connectionTimeout="20000"
redirectPort="8443" />
对于 URL 提交的数据和表单中 GET 方式提交的数据，在接收数据的 JSP 中设置 request.setCharacterEncoding 参数是不行的，因为在 Tomcat5.0 中，默认情况下使用ISO-8859-1 对 URL 提交的数据和表单中 GET 方式提交的数据进行重新编码（解码），而不使用该参数对 URL 提交的数据和表单中 GET 方式提交的数据进行重新编码（解码）。要解决该问题，应该在 Tomcat 的配置文件的 Connector 标签中设置useBodyEncodingForURI 或者 URIEncoding 属性，其中 useBodyEncodingForURI 参数表示是否用 request.setCharacterEncoding 参数对 URL 提交的数据和表单中 GET 方式提交的数据进行重新编码，在默认情况下，该参数为 false （Tomcat4.0 中该参数默认为true ）；
URIEncoding 和 useBodyEncodingForURI 区别是，URIEncoding 是对所有 GET 方式的请求的数据进行统一的重新编码（解码），而 useBodyEncodingForURI 则是根据响应该请求的页面的request.setCharacterEncoding 参数对数据进行的重新编码（解码），不同的页面可以有不同的重新编码（解码）的编码。所以对于 URL 提交的数据和表单中 GET 方式提交的数据，可以修改 URIEncoding 参数为浏览器编码或者修改 useBodyEncodingForURI 为true ，并且在获得数据的 JSP 页面中 request.setCharacterEncoding参数设置成浏览器编码。
譬如汉字“中”，以UTF-8编码后得到的是3字节的值%E4%B8%AD，然后通过GET或者POST方式把这3个字节提交到Tomcat容器，如果你不告诉Tomcat我的参数是用UTF-8编码的，那么tomcat就认为你是用ISO-8859-1来编码的，而ISO8859-1（兼容URI中的标准字符集US-ASCII）是兼容ASCII的单字节编码并且使用了单字节内的所有空间，因此Tomcat就以为你传递的用ISO-8859-1字符集编码过的3个字符，然后它就用ISO-8859-1来解码，得到ä¸-，解码后。字符串ä¸-在Jvm是以Unicode的形式存在的，而HTTP传输或者数据库保存的其实是字节，因此根据各终端的需要，你可以把unicode字符串ä¸-用UTF-8编码后得到相应的字节后存储到数据库（3个UTF-8字符），也可以取得这3个字符对应的ISO-8859-1的3个字节，然后用UTF-8重新编码后得到unicode字符“中”（特性：把其他任何编码的字节流当作ISO-8859-1编码看待都没有问题），然后用response传递给客户端（根据你设置的content-type不同，传递的字节也是不同的！）
总结：
- 1，HTTP GET或者POST传递的是字节？数据库保存的也是字节（譬如500MB空间就是500M字节）
- 2，乱码产生的原因是编码和解码的字符集（方式）不同导致的，即对于几个不同的字节，在不同的编码方案下对应的字符可能不同，也可能在某种编码下有些字节不存在（这也是乱码中？产生的原因）
- 3，解码后的字符串在jvm中以Unicode的形式存在
- 4，如果jvm中存在的Unicode字符就是你预期的字符（编码，解码的字符集相同或者兼容），那么没有任何问题，如果jvm中存在的字符集不是你预期的字符，譬如上述例子中jvm中存在的是3个Unicode字符，你也可以通过取得这3个unicode字符对应的3个字节，然后用UTF-8对这3个字节进行编码生成新的Unicode字符：汉字“中”
- 5，ISO8859-1是兼容ASCII的单字节编码并且使用了单字节内的所有空间，在支持ISO-8859-1的系统中传输和存储其他任何编码的字节流都不会被抛弃。换言之，把其他任何编码的字节流当作ISO-8859-1编码看待都没有问题。
http://desert3.iteye.com/blog/1418406