Java乱码解决之道
ASCII，American Standard Code for Information Interchange，是基于拉丁字母的一套电脑编码系统，主要用于显示现代英语和其他西欧语言。它是现今最通用的单字节编码系统。
ASCII最大的缺点就是显示字符有限，他虽然解决了部分西欧语言的显示问题，但是对更多的其他语言他实在是无能为了。随着计算机技术的发展，使用 范围越来越广泛了，ASCII的缺陷越来越明显了，其他国家和地区需要使用计算机，必须要设计一套符合本国/本地区的编码规则。例如为了显示中文，我们就 必须要设计一套编码规则用于将汉字转换为计算机可以接受的数字系统的数。
GB2312，用于汉字处理、 汉字通信等系统之间的信息交换，通行于中国大陆。它的编码规则是：小于127的字符的意义与原来相同，但两个大于127的字符连在一起时，就表示一个汉 字，前面的一个字节（他称之为高字节）从0xA1用到 0xF7，后面一个字节（低字节）从0xA1到0xFE，这样我们就可以组合出大约7000多个简体汉字了。虽然GB2312收录了这么多汉子，他所覆盖 的使用率可以达到99%，但是对于那些不常见的汉字，例如人名、地名、古汉语，它就不能处理了，于是就有下面的GBK、GB 18030的出现。（点击GB2312简体中文编码表查看）。
GB18030，全 称：国家标准GB 18030-2005《信息技术 中文编码字符集》,是我国计算机系统必须遵循的基础性标准之一,GB18030有两个版本：GB18030-2000和GB18030-2005。 GB18030-2000是GBK的取代版本，它的主要特点是在GBK基础上增加了CJK统一汉字扩充A的汉字。
GB 18030主要有以下特点：
与UTF-8相同，采用多字节编码，每个字可以由1个、2个或4个字节组成。
编码空间庞大，最多可定义161万个字符。
支持中国国内少数民族的文字，不需要动用造字区。
GBK，汉字编码标准之一，全称《汉字内码扩展规范》，它 向下与 GB 2312 编码兼容，向上支持 ISO 10646.1 国际标准，是前者向后者过渡过程中的一个承上启下的标准。它的编码范围如下图：
正如前面前面所提到的一样，世界存在这么多国家，也存在着多种编码风格，像中文的GB232、GBK、GB18030，这样乱搞一套，虽然在本地运行没有问题，但是一旦出现在网络上，由于互不兼容，访问则会出现乱码。为了解决这个问题，伟大的Unicode编码腾空出世。
Unicode编码的作用就是能够使计算机实现夸平台、跨语言的文本转换和处理。它几乎包含了世界上所有的符号，并且每个符号都是独一无二的。在它的编码世界里，每一个数字代表一个符号，每一个符号代表了一个数字，不存在二义性。
互联网的普及，强烈要求出现一种统一的编码方式。UTF-8就是在互联网上使用最广的一种unicode的实现方式。其他实现方式还包括UTF-16和UTF-32，不过在互联网上基本不用。重复一遍：UTF-8是Unicode的实现方式之一。
UTF-8的编码规则很简单，只有两条：
1）对于单字节的符号，字节的第一位设为0，后面7位为这个符号的unicode码。因此对于英语字母，UTF-8编码和ASCII码是相同的。
public static void main(String[] args) throws UnsupportedEncodingException {
String string = "我是 cm";
Test02.printChart(string.toCharArray());
Test02.printChart(string.getBytes("ISO-8859-1"));
Test02.printChart(string.getBytes("GBK"));
Test02.printChart(string.getBytes("UTF-8"));
}
/**
* char转换为16进制
*/
public static void printChart(char[] chars){
for(int i = 0 ; i < chars.length ; i++){
System.out.print(Integer.toHexString(chars[i]) + " ");
}
System.out.println("");
}
/**
* byte转换为16进制
*/
public static void printChart(byte[] bytes){
for(int i = 0 ; i < bytes.length ; i++){
String hex = Integer.toHexString(bytes[i] & 0xFF);
if (hex.length() == 1) {
hex = '0' + hex;
}
System.out.print(hex.toUpperCase() + " ");
}
System.out.println("");
}
}
-------------------------outPut:
6211 662f 20 63 6d
3F 3F 20 63 6D
CE D2 CA C7 20 63 6D
通过程序我们可以看到“我是 cm”的结果为：
char[]：6211 662f 20 63 6d
ISO-8859-1：3F 3F 20 63 6D
GBK：CE D2 CA C7 20 63 6D
UTF-8：E6 88 91 E6 98 AF 20 63 6D
客户端想服务器发送请求无非就通过四中情况：
1、URL方式直接访问。
2、页面链接。
3、表单get提交
可以看到各大浏览器对“我是”的编码情况如下：
|
path部分 |
Query String |
|
|
Firefox |
E6 88 91 E6 98 AF |
E6 88 91 E6 98 AF |
|
Chrome |
E6 88 91 E6 98 AF |
E6 88 91 E6 98 AF |
|
IE |
E6 88 91 E6 98 AF |
CE D2 CA C7 |
查阅上篇博客的编码可知对于path部分Firefox、chrome、IE都是采用UTF-8编码格式，对于Query String部分Firefox、chrome采用UTF-8，IE采用GBK。至于为什么会加上%，这是因为URL的编码规范规定浏览器将ASCII字 符非 ASCII 字符按照某种编码格式编码成 16 进制数字然后将每个 16 进制表示的字节前加上“%”。
当然对于不同的浏览器，相同浏览器不同版本，不同的操作系统等环境都会导致编码结果不同，上表某一种情况，对于URL编码规则下任何结论都是过早 的。由于各大浏览器、各个操作系统对URL的URI、QueryString编码都可能存在不同，这样对服务器的解码势必会造成很大的困扰，下面我们将已 tomcat，看tomcat是如何对URL进行解码操作的。
解析请求的 URL 是在 org.apache.coyote.HTTP11.InternalInputBuffer 的 parseRequestLine 方法中，这个方法把传过来的 URL 的 byte[] 设置到 org.apache.coyote.Request 的相应的属性中。这里的 URL 仍然是 byte 格式，转成 char 是在 org.apache.catalina.connector.CoyoteAdapter 的 convertURI 方法中完成的：
protected void convertURI(MessageBytes uri, Request request)
throws Exception {
ByteChunk bc = uri.getByteChunk();
int length = bc.getLength();
CharChunk cc = uri.getCharChunk();
cc.allocate(length, -1);
String enc = connector.getURIEncoding(); //获取URI解码集
if (enc != null) {
B2CConverter conv = request.getURIConverter();
try {
if (conv == null) {
conv = new B2CConverter(enc);
request.setURIConverter(conv);
}
} catch (IOException e) {...}
if (conv != null) {
try {
conv.convert(bc, cc, cc.getBuffer().length - cc.getEnd());
uri.setChars(cc.getBuffer(), cc.getStart(), cc.getLength());
return;
} catch (IOException e) {...}
}
}
// Default encoding: fast conversion
byte[] bbuf = bc.getBuffer();
char[] cbuf = cc.getBuffer();
int start = bc.getStart();
for (int i = 0; i < length; i++) {
cbuf[i] = (char) (bbuf[i + start] & 0xff);
}
uri.setChars(cbuf, 0, length);
}
从上面的代码可知，对URI的解码操作是首先获取Connector的解码集，该配置在server.xml中
<Connector URIEncoding="utf-8" />
如果没有定义则会采用默认编码ISO-8859-1来解析。
对于Query String部分，我们知道无论我们是通过get方式还是POST方式提交，所有的参数都是保存在Parameters，然后我们通过 request.getParameter，解码工作就是在第一次调用getParameter方法时进行的。在getParameter方法内部它调用 org.apache.catalina.connector.Request 的 parseParameters 方法，这个方法将会对传递的参数进行解码。下面代码只是parseParameters方法的一部分：
//获取编码
String enc = getCharacterEncoding();
//获取ContentType 中定义的 Charset
boolean useBodyEncodingForURI = connector.getUseBodyEncodingForURI();
if (enc != null) { //如果设置编码不为空，则设置编码为enc parameters.setEncoding(enc);
if (useBodyEncodingForURI) { //如果设置了Chartset，则设置queryString的解码为ChartSet parameters.setQueryStringEncoding(enc);
}
} else { //设置默认解码方式 parameters.setEncoding(org.apache.coyote.Constants.DEFAULT_CHARACTER_ENCODING);
if (useBodyEncodingForURI) {
parameters.setQueryStringEncoding(org.apache.coyote.Constants.DEFAULT_CHARACTER_ENCODING);
}
}
从上面代码可以看出对query String的解码格式要么采用设置的ChartSet要么采用默认的解码格式ISO-8859-1。注意这个设置的ChartSet是在 http Header中定义的ContentType，同时如果我们需要改指定属性生效，还需要进行如下配置：
<Connector URIEncoding="UTF-8" useBodyEncodingForURI="true"/>
上面部分详细介绍了URL方式请求的编码解码过程。其实对于我们而言，我们更多的方式是通过表单的形式来提交。
表单GET
我们知道通过URL方式提交数据是很容易产生乱码问题的，所以我们更加倾向于通过表单形式。当用户点击submit提交表单时，浏览器会更加设定的 编码来编码数据传递给服务器。通过GET方式提交的数据都是拼接在URL后面（可以当做query String？？）来提交的，所以tomcat服务器在进行解码过程中URIEncoding就起到作用了。tomcat服务器会根据设置的 URIEncoding来进行解码，如果没有设置则会使用默认的ISO-8859-1来解码。假如我们在页面将编码设置为UTF-8，而 URIEncoding设置的不是或者没有设置，那么服务器进行解码时就会产生乱码。这个时候我们一般可以通过new String(request.getParameter(“name”).getBytes(“iso-8859-1″),”utf-8″) 的形式来获取正确数据。
表单POST
我们知道JSP页面是需要转换为servlet的，在转换过程中肯定是要进行编码的。在JSP转换为servlet过程中下面一段代码起到至关重要的作用。
<%@ page language="java" contentType="text/html; charset=UTF-8" pageEncoding="GBK" %>
在上面代码中有两个地方存在编码：pageEncoding、contentType的charset。其中pageEncoding是jsp文件本身的编码，而contentType的charset是指服务器发送给客户端时的内容编码。
在前面一篇博客中就提到过（java中文乱码解决之道（四）—–java编码转换过程）jsp在转换为Servlet的过程中是需要经过主要的三次编码转换过程（除去数据库编码转换、页面参数输入编码转换）：
第一次：转换为.java文件；
第二次：转换为.class文件；
第三次：业务逻辑处理后输出。
第一阶段
JVM将JSP编译为.jsp文件。在这个过程中pageEncoding就起到作用了，JVM首先会获取pageEncoding的值，如果该值存在则采用它设定的编码来编译，否则则采用file.encoding编码来编译。
第二阶段
JVM将.java文件转换为.class文件。在这个过程就与任何编码的设置都没有关系了，不管JSP采用了什么样的编码格式都将无效。经过这个阶段后.jsp文件就转换成了统一的Unicode格式的.class文件了。
第三阶段
- 后台经过业务逻辑处理后将产生的结果输出到客户端。在这个过程中contentType的charset就发挥了功效。如果设置了charset则浏览器就会使用指定的编码格式进行解码，否则采用默认的ISO-8859-1编码格式进行解码处理。
流程如如下：
我们主要通过两种形式提交向服务器发送请求：URL、表单。而表单形式一般都不会出现乱码问题，乱码问题主要是在URL上面。通过前面几篇博客的介 绍我们知道URL向服务器发送请求编码过程实在是实在太混乱了。不同的操作系统、不同的浏览器、不同的网页字符集，将导致完全不同的编码结果。如果程序员 要把每一种结果都考虑进去，是不是太恐怖了？有没有办法，能够保证客户端只用一种编码方法向服务器发出请求？
一、javascript
使用javascript编码不给浏览器插手的机会，编码之后再向服务器发送请求，然后在服务器中解码。在掌握该方法的时候，我们需要料及javascript编码的三个方法：escape()、encodeURI()、encodeURIComponent()。
escape
采用SIO Latin字符集对指定的字符串进行编码。所有非ASCII字符都会被编码为%xx格式的字符串，其中xx表示该字符在字符集中所对应的16进制数字。例如，格式对应的编码为%20。它对应的解码方法为unescape()。
注意，escape()不对”+”编码。但是我们知道，网页在提交表单的时候，如果有空格，则会被转化为+字符。服务器处理数据的时候，会把+号处理成空格。所以，使用的时候要小心。
encodeURI
对整个URL进行编码，它采用的是UTF-8格式输出编码后的字符串。不过encodeURI除了ASCII编码外对于一些特殊的字符也不会进行编码如：! @ # $& * ( ) = : / ; ? + ‘。
encodeURIComponent()
把URI字符串采用UTF-8编码格式转化成escape格式的字符串。相对于encodeURI，encodeURIComponent会更加强 大，它会对那些在encodeURI()中不被编码的符号（; / ? : @ & = + $ , #）统统会被编码。但是encodeURIComponent只会对URL的组成部分进行个别编码，而不用于对整个URL进行编码。对应解码函数方法 decodeURIComponent。
当然我们一般都是使用encodeURI方来进行编码操作。所谓的javascript两次编码后台两次解码就是使用该方法。javascript解决该问题有一次转码、两次转码两种解决方法。
一次转码
javascript转码：
var url = '<s:property value="webPath" />/ShowMoblieQRCode.servlet?name=我是cm';
window.location.href = encodeURI(url);
转码后的URL：http://127.0.0.1:8080/perbank/ShowMoblieQRCode.servlet?name=%E6%88%91%E6%98%AFcm
后台处理:
String name = request.getParameter("name");
System.out.println("前台传入参数：" + name);
name = new String(name.getBytes("ISO-8859-1"),"UTF-8");
System.out.println("经过解码后参数：" + name);
输出结果：
前台传入参数：??????cm
经过解码后参数：我是cm
二次转码
javascript
var url = '<s:property value="webPath" />/ShowMoblieQRCode.servlet?name=我是cm';
window.location.href = encodeURI(encodeURI(url));
转码后的url:http://127.0.0.1:8080/perbank/ShowMoblieQRCode.servlet?name=%25E6%2588%2591%25E6%2598%25AFcm
后台处理：
String name = request.getParameter("name");
System.out.println("前台传入参数：" + name);
name = URLDecoder.decode(name,"UTF-8");
System.out.println("经过解码后参数：" + name);
输出结果：
前台传入参数：E68891E698AFcm
经过解码后参数：我是cm
filter
使用过滤器，过滤器LZ提供两种，第一种设置编码，第二种直接在过滤器中进行解码操作。
过滤器1
该过滤器是直接设置request的编码格式的。
public class CharacterEncoding implements Filter {
private FilterConfig config ;
String encoding = null;
public void destroy() {
config = null;
}
public void doFilter(ServletRequest request, ServletResponse response,
FilterChain chain) throws IOException, ServletException {
request.setCharacterEncoding(encoding);
chain.doFilter(request, response);
}
public void init(FilterConfig config) throws ServletException {
this.config = config;
//获取配置参数
String str = config.getInitParameter("encoding");
if(str!=null){
encoding = str;
}
}
}
配置：
<!-- 中文过滤器的配置 -->
<filter>
<filter-name>chineseEncoding</filter-name>
<filter-class>com.test.filter.CharacterEncoding</filter-class>
<init-param>
<param-name>encoding</param-name>
<param-value>utf-8</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>chineseEncoding</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
过滤器2
public class CharacterEncoding implements Filter {
protected FilterConfig filterConfig ;
String encoding = null;
public void destroy() {
this.filterConfig = null;
}
/**
* 初始化
*/
public void init(FilterConfig filterConfig) {
this.filterConfig = filterConfig;
}
/**
* 将 inStr 转为 UTF-8 的编码形式
*
* @param inStr 输入字符串
* @return UTF - 8 的编码形式的字符串
* @throws UnsupportedEncodingException
*/
private String toUTF(String inStr) throws UnsupportedEncodingException {
String outStr = "";
if (inStr != null) {
outStr = new String(inStr.getBytes("iso-8859-1"), "UTF-8");
}
return outStr;
}
/**
* 中文乱码过滤处理
*/
public void doFilter(ServletRequest servletRequest,
ServletResponse servletResponse, FilterChain chain) throws IOException,
ServletException {
HttpServletRequest request = (HttpServletRequest) servletRequest;
HttpServletResponse response = (HttpServletResponse) servletResponse;
// 获得请求的方式 (1.post or 2.get), 根据不同请求方式进行不同处理
String method = request.getMethod();
// 1. 以 post 方式提交的请求 , 直接设置编码为 UTF-8
if (method.equalsIgnoreCase("post")) {
try {
request.setCharacterEncoding("UTF-8");
} catch (UnsupportedEncodingException e) {
e.printStackTrace();
}
}
// 2. 以 get 方式提交的请求
else {
// 取出客户提交的参数集
Enumeration<String> paramNames = request.getParameterNames();
// 遍历参数集取出每个参数的名称及值
while (paramNames.hasMoreElements()) {
String name = paramNames.nextElement(); // 取出参数名称
String values[] = request.getParameterValues(name); // 根据参数名称取出其值
// 如果参数值集不为空
if (values != null) {
// 遍历参数值集
for (int i = 0; i < values.length; i++) {
try {
// 回圈依次将每个值调用 toUTF(values[i]) 方法转换参数值的字元编码
String vlustr = toUTF(values[i]);
values[i] = vlustr;
} catch (UnsupportedEncodingException e) {
e.printStackTrace();
}
}
// 将该值以属性的形式藏在 request request.setAttribute(name, values);
}
}
}
// 设置响应方式和支持中文的字元集
response.setContentType("text/html;charset=UTF-8");
// 继续执行下一个 filter, 无一下个 filter 则执行请求 chain.doFilter(request, response);
}
}
配置：
<!-- 中文过滤器的配置 -->
<filter>
<filter-name>chineseEncoding</filter-name>
<filter-class>com.test.filter.CharacterEncoding</filter-class>
</filter>
<filter-mapping>
<filter-name>chineseEncoding</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
其他
1、设置pageEncoding、contentType
<%@ page language="java" contentType="text/html;charset=UTF-8" pageEncoding="UTF-8"%>
2、设置tomcat的URIEncoding
