本文主要是围绕Web开发中涉及到的中文编码这一常见问题展开，包括了对字符编码基础理论的简述以及常见几种编码标准的介绍。其中包括：ASCII、ISO8859-1、Unicode、GBK。下面先对这些字符编码集进行简单的介绍。 造成乱码的原因为:在服务器端设置网页的字符编码方式与浏览器的解码方式不同造成解码冲突，导致出现乱码

这一小节介绍软件开发中常见的中文编码乱码问题，在下面示例中：对于给定的一个包含中文的字符串"你好Java"，看一下都会出现哪些乱码问题。

这种情况一般是由于中文字符经ISO8859-1编码造成的。下面是编码的具体过程：

原字符串："你好Java"（默认）经ISO8859-1编码后：

上述字节码再由UTF-8解码后得:

解码后字符串："??Java"

我们知道ISO8859-1是单字节编码，而对于汉字已经超出ISO8859-1的编码范围，会被转化为"3f"，我们查UTF-8表可知，"3f"对应的UTF-8字符正是"?"。

乱码原因:

中文字符采用了ISO8859-1进行编码，然后经过UTF-8解码

中文变问号的乱码情况是非常常见的，大部分开源软件的默认编码设置成了ISO8859-1，这点需要格外注意。

原字符串："你好Java"经UTF-8编码后，一个中文用三个字节表示：

上述字节码再由ISO8859-1解码后得:

乱码原因:

对中文字符先用UTF-8编码或GBK编码，再由ISO8859-1解码，就会变成奇怪字符。对照ISO8859-1编码表后发现：e4 bd a0分别对应三个字符："ä½ ",e5 a5 bd分别对应三个字符"好",

下面依然是"你好Java"经过UTF-8编码后对应的字节序列：

上述字节码再由GBK解码后得:

在GBK表中查找：e4 bd对应字符："浣",a0 e5对应字符："犲",a5 bd对应字符："ソ"

乱码原因:

中文字符用UTF-8进行编码，然后用GBK解码就得到了"复杂中文"

同理，如果GBK编码的中文用UTF-8来解码的话，同样会出现乱码问题。

首先问号+黑色菱形的字符是Unicode中的"REPLACEMENT CHARACTER"，该字符的主要作用是用来表示不识别的字符。 所以产生乱码的原因可能有很多，下面通过原字符串："你好Java"，重现一种乱码方式：

原字符串：String str = "你好Java"经过UTF-16BE编码后对应的字节序列：

其中"fe ff"就是字节流起始的BOM标识符。"fe ff"在Unicode标准中属于"noncharacters"，只用于内部使用。所以在使用UTF-8解码输出该字节序列的时候，没有该码元对应的字符，对于不识别字符，就会用��替代。

乱码原因:

中文字符用UTF-16BE进行编码，然后用UTF-8解码

Web中的数据大多通过http协议进行传输，所涉及到的一些编解码问题都围绕着http协议。下面以Tomcat作为Web服务器， 探讨下一个完整的请求响应流程中哪些地方会涉及到中文的编解码。

web环境中的中文乱码问题，实验如下：

表单中填入内容： 用户名：你好 Java 地址：123 提交请求，firebug中的显示的url如下：

http://localhost:8080/fdyuntu-ssm/manager/codec/%E4%BD%A0%E5%A5%BD

查阅编码可以，firefox对url中出现的中文使用了UTF-8的编码方式。之所以url中出现%，这是因为根据URL编码规范，浏览器会将非ASCII字符（ASCII中不包含中文字符）编成16进制后，每个字节前需要加%。

后端控制台输出：

可见无论是url中的中文信息或是post表单中的中文都出现了乱码现象，从前一节中关于乱码情况的分析来看，这里应该是中文字符经过浏览器UTF-8编码后，Server端用ISO8859-1进行解码所致。下面逐个分析url和post表单如何进行编解码的。

在tomcat中url的byte -> char的转换是在org.apache.catalina.connector.CoyoteAdapter类的convertURI(MessageBytes uri, Request request)方法中执行的，源码如下：

在org.apache.tomcat.util.buf.ByteChunk中可以看到默认编码的定义：

所以对于请求url中的中文，我们按UTF-8进行编码，在服务端却按ISO8859-1进行解码，所以出现乱码现象。我们可以在Tomcat的server.xml中指定url的编解码格式，如下：

此时重复上面实验，后端控制台输出：name:ä½ å¥½ Java,param:你好

虽然url中的参数可以正常显示了，但是form表单中的参数name依然乱码，下面进一步分析。

name参数的编码依然是乱码的，为啥？首先定位form表单中参数是在哪里进行解码的。Form表单中的字符解码时机是发生在第一次调用request.getParameter时，可以通过request.setCharacterEncoding设置。需要注意的是setCharacterEncoding必须在getParameter之前调用！否则，setCharacterEncoding不会起作用。

Tomcat中HttpServletRequest接口的实现类是org.apache.catalina.connector.Request。下面是Request类中getParameter源码：

从以上源码中可以看出为什么需要在第一次调用getParameter之前设置CharacterEncoding。因为第一次执行parseParameters时，会把parametersParsed变量设为true。所以parseParameters只会在第一次getParameter时调用。有时会出现这么一种怪像：通过request.getCharacterEncoding()得到的是我们认为正确的编码字符集，但是request.getParameter得到的依然是乱码。此时就需要考虑下我们调用setCharacterEncoding之前是否已经调用过getParameter方法了。

经过上面的分析后，对于form表单参数乱码问题就很好解决了，在第一次调用request.getParameter方法前，通过request.setCharacterEncoding("Expected_Encoding");设置即可。这一步可以用Servlet标准中的Filter实现，不过，常用的MVC框架中已经有现成的Filter实现了，比如SpringMVC中的org.springframework.web.filter.CharacterEncodingFilter,如下：

jsp中可以通过page指令指定一些编码参数，如下：

在Servlet标准中，jsp最终也会被编译成一个servlet。index.jsp->index_jsp.java.pageEncoding="UTF-8"就是在这个解析过程中起作用的。

contentType="text/html; charset=UTF-8"的作用？

contentType是响应头中特定信息，主要的作用是告诉浏览器response中存放的主体对象类型和编码，这样浏览器就可以对指定类型进行正确解码，保证了数据在server和client端的一致性。当进行Servlet编程的时候，可以手动进行设置，如下：

Web中的文件操作主要是上传和下载，这个过程也是依托于Http协议作为数据载体。所以，最终是否乱码重点在于是否正确的设置http的request、response的header中的相关字段。如ContentType、Content-Disposition的设定等。如下：

这里需要注意的是Content-Disposition的filename属性值，如果fileName含有中文，那么要格外注意fileName字符串的编码格式。在rfc5987对于HTTP的Header中参数的编码做出了明确的规定：

By default, message header field parameters in Hypertext Transfer Protocol (HTTP) messages cannot carry characters outside the ISO-8859-1 character set.

也就是说默认情况下，Http的Header中的参数只能用ISO-8859-1字符集中的字符，那么是否意味着Content-Disposition中的fileName字符串也要转成ISO-8859-1了呢？答案是：NO！原因如下：Content-Disposition其实不属于Http/1.1标准。这在RFC2616中有明确的说明。只因为其使用广泛，HTTP才对其支持。在rfc6266中也详细介绍了Content-Disposition的filename参数含义和用法。下面是对于下载包含中文名称的文件时的解决方案。

最简单就是直接用ISO8859-1对文件名进行编码，大多数浏览器都支持。如下：

或通过其它编码，如UTF-8。

编解码问题是多语言交互系统中必然要面对的问题，尤其对于中文环境中的开发者来说，在入门阶段或多或少都会遇到此类问题。乱码问题本质就是通信双方使用的标准不一致。所以，解决乱码问题的方法其实也很简单，统一下编解码标准即可。此外，深入理解各种编码标准的原理和关系也非常重要，在以后遇到类似问题的时候能够更加准确的判断出造成乱码的原因。