本文主要是围绕Web开发中涉及到的中文编码这一常见问题展开，包括了对字符编码基础理论的简述以及常见几种编码标准的介绍。其中包括：ASCII、ISO8859-1、Unicode、GBK。下面先对这些字符编码集进行简单的介绍。

ASCII也就是美国信息交换标准码，采用单字节编码方案，但是编码只用了后七位字节，表示范围0-127共128个字符。ASCII码相对于其它编码也是最早出现的。从上世纪60年代提出开始，到1986年最终定型。

为什么选择7位编码?ASCII在最初设计的时候需要至少能表示64个码元：包括26个字母+10个数字+图形标示+控制字符，如果用6bit编码，可扩展部分没有了，所以至少需要7bit。那么8bit呢？最终也被标准委员会否定，原因很简单：满足编码需求的前提下，最小化传输开销。

ISO-8859-1也被称为Latin1，使用单字节8bit编码，可以表示256个西欧字符。其隶属于ISO8859标准的一部分，还有ISO8859-2、ISO8859-3等等。每一种编码都对应一个地区的字符集。比如：ISO8859-1表示西欧字符，ISO-8859-16表示中欧字符集，等等。

不管是ASCII还是ISO8859-1，其编码范围都是有局限的。而Unicode标准的目标就是消除传统编码的局限性。

这里的局限性一方面指编码范围的局限性：比如ASCII只能表示128个字符。还有编码兼容性方面的局限性：比如ISO8859代表的一系列编码字符集虽然可以表示大部分国家地区的字符，但是彼此的兼容性做的不好。Unicode的目标就如同其名称的含义一样：“实现字符编码统一”

Unicode标准的实现方案有如下三种：UTF-8、UTF-16和UTF-32**.

UTF-8是变长编码，使用1到4个字节。UTF-8在设计时考虑到向前兼容，所以其前128个字符和ASCII完全一样，也就是说，所有ASCII同时也都符合UTF-8编码格式。其格式如下：

字节首部为0的话，也就是前面说的ASCII了。此外，字节首部连续1的个数就代表了该字符编码后所占的字节数。目前全世界的网页编码绝大多数使用的就是UTF-8，占比接近90%。

UTF-16也是变长编码，但其最初是固定16-bit宽度的定长编码，主要因为Unicode涵盖的字符太多了。两字节更本不够用！

UTF-32是32-bit定长编码，优点：定长编码在处理效率上相对于变长编码要高，此外，可通过索引访问任意字符是其另一大优势；缺点也很明显：32bit太浪费了！存储效率太低！

big-endian和little-endian？在多字节编码标准中可能会遇到这样的问题：假如一个字符用两个字节表示，那么当读取这个字符的时候，哪个字节表示高有效位？哪个表示低有效位呢？这就涉及到字节的存储顺序问题。在Unicode中UTF-16和UTF-32都会面临这个问题。通常用BOM（Byte Order Mark）来进行区分。BOM用一个"U+FEFF"来表示，这个值在 Unicode中是没有对应字符的。不仅可以用其来指定字节顺序，还可以表示字节流的编码方式。

输出结果：

len1:4

len2:6

为什么是4和6，不应该是2和4吗！？。输出编码后的字节序列可以发现，起始的两个字节都是："fe ff"。

Java的char类型用什么编码格式？Java语言规范规定了Java的char类型使用的是UTF-16。这就是为什么Java的char占用两个字节的原因。此外，Java标准库实现的对char与String的序列化规定使用UTF-8。Java的Class文件中的字符串常量与符号名字也都规定用UTF-8编码。这大概是当时设计者为了平衡运行时的时间效率（采用定长编码的UTF-16，当然，在设计java的时候UTF-16还是定长的）与外部存储的空间效率（采用变长的UTF-8编码）而做的取舍。

GBK是用于对简体中文进行编码。每个字符用两字节表示，同时兼容GB2312标准。

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

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

原字符串："你好Java"

经ISO8859-1编码后：

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

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

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

原字符串："你好Java"

经UTF-8编码后，一个中文用三个字节表示：

你 | 好 | J| a| v| a ---|---|---|---|---|---|---|--- e4 bd a0 | e5 a5 bd | 4a| 61| 76| 61

乱码原因：UTF8编码或GBK编码，再由ISO8859-1解码。对照ISO8859-1编码表后发现：e4 bd a0分别对应三个字符："ä½ ",e5 a5 bd分别对应三个字符"好",

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

你 | 好 | J| a| v| a ---|---|---|---|---|---|---|--- e4 bd a0 | e5 a5 bd | 4a| 61| 76| 61

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

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

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

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

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字符编成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是响应头中特定信息，主要的作用是告诉浏览器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。

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