一、字符编码问题举例

1、支付宝代扣签约失败问题。

问题描述：用户在浏览器中输入中文请求，表单post给后台为中文乱码，导致通用代扣签约失败。

主要链路：用户签约->浏览器Post请求->mdeduct

原因解析：页面post请求使用GBK编码，后端使用了iso-8859-1进行解码，iso-8859-1不支持中文，所以中文属性解析乱码，导致后续系统鉴权处理时用户名不认识失败，进而整个签约失败。

2、微博红包提现失败问题。

问题描述：

主要链路：微博->Bizfund-> memerprod->淘宝

原因解析：微博昵称中含有繁体字，memerprod受理请求后，使用GB2312进行编码，但是GB2312不支持繁体字，所以编码后出现乱码，淘宝使用GBK解码时由于编码时已乱码解析出来乱码，导致昵称查询失败，进而微博提现失败。

二、字符编码介绍

看过了实例，后面我们就对编码做个统一的介绍，并进行一些对比，使我们更深入的了解编码。

1、ASCII：在计算机内部，所有的信息最终都表示为一个二进制的字符串。每一个二进制位（bit）有0和1两种状态，因此八个二进制位就可以组合出256种状态，这被称为一个字节（byte）。也就是说，一个字节一共可以用来表示256种不同的状态，每一个状态对应一个符号，就是256个符号，从0000000到11111111。上个世纪60年代，美国制定了一套字符编码，对英语字符与二进制位之间的关系，做了统一规定。这被称为ASCII码，一直沿用至今。ASCII码一共规定了128个字符的编码，比如空格“SPACE”是32（二进制00100000），大写的字母A是65（二进制01000001）。这128个符号（包括32个不能打印出来的控制符号），只占用了一个字节的后面7位，最前面的1位统一规定为0。

2、ISO-8859-1

：

又称Latin-1，计算机一开始只在美国使用，ASCII可以表示他们的符号，但是后来欧洲一些国家也开始使用计算机，很多国家使用的不是英文，ASCII的256个位置不够了，为了表示这些字符，就重新进行了编码，ISO-8859-1是单字节编码，向下兼容ASCII，其编码范围是0x00-0xFF，0x00-0x7F之间完全和ASCII一致，0x80-0x9F之间是控制字符，0xA0-0xFF之间是文字符号。此字符集主要支持欧洲使用的语言。

3、GB2312

：

后来计算机普及了，于是就中国要使用计算机了 但是机器不认得中文，于是就有了国际码, GB，是“国标”二字的汉语拼音首字母，1980年制定，由于“历史局限性”，此字符集内收录的字符很少，汉字总共收录了 6763 个，而且全部都是大陆通用的简体汉字。

4、BIG5

：

在GB2312肆虐横行的同时，我们的港澳台同胞，也制定了一个适用于当地繁体汉字需要的字符集，其对应编码名为 BIG5，也有人称之为大五码。

5、GBK

：

后来发现一些人名、文言文汉字、少数民族语言都需要支持，GB2312满足不了，就做了扩展，叫GBK标准

,

基本上采用了原来GB2312-80所有的汉字及码位，并涵盖了原Unicode中所有的汉字20902，总共收录了883个符号，21003个汉字及提供了1894个造字码位。

6、UNICODE

：

随着计算机的普及，编码也众多，需要统一，一个叫 ISO （国际标谁化组织）的国际组织决定着手解决这个问题。他们采用的方法很简单：废了所有的地区性编码方案，重新搞一个包括了地球上所有文化、所有字母和符号的编码！他们打算叫它”Universal Multiple-Octet Coded Character Set”，简称 UCS, 俗称 “UNICODE”。

7、UTF-8

:

互联网的普及，强烈要求出现一种统一的编码方式。UTF-8就是在互联网上使用最广的一种unicode的实现方式。

重复一遍，这里的关系是，


UTF-8


是


Unicode


的实现方式之一


,

其他实现方式还包括UTF-16和UTF-32，不过在互联网上基本不用

。

UTF-8最大的一个特点，就是它是一种变长的编码方式。它可以使用1~4个字节表示一个符号，根据不同的符号而变化字节长度。

UTF-8的编码规则很简单，只有二条：

a）对于单字节的符号，字节的第一位设为0，后面7位为这个符号的unicode码。因此对于英语字母，UTF-8编码和ASCII码是相同的。

b）对于n字节的符号（n>1），第一个字节的前n位都设为1，第n+1位设为0，后面字节的前两位一律设为10。剩下的没有提及的二进制位，全部为这个符号的unicode码。

8、ANSI: 不同的国家和地区制定了不同的标准，由此产生了 GB2312、GBK、GB18030、Big5、Shift_JIS 等各自的编码标准。这些使用多个字节来代表一个字符的各种汉字延伸编码方式，称为 ANSI 编码。在简体中文Windows操作系统中，ANSI 编码代表 GBK 编码；在繁体中文Windows操作系统中，ANSI编码代表Big5；在日文Windows操作系统中，ANSI 编码代表 Shift_JIS 编码。

常用编码对比：

三、页面与服务器的交互编码

我们看一下 Java Web 中那些地方可能会存在编码转换？

用户从浏览器端发起一个 HTTP 请求，需要存在编码的地方是 URL、Cookie、Parameter。服务器端接受到 HTTP 请求后要解析 HTTP 协议，其中 URI、Cookie 和 POST 表单参数需要解码，服务器端可能还需要读取数据库中的数据，本地或网络中其它地方的文本文件，这些数据都可能存在编码问题，当 Servlet 处理完所有请求的数据后，需要将这些数据再编码通过 Socket 发送到用户请求的浏览器里，再经过浏览器解码成为文本。这些过程如下图所示：

下图是一次 HTTP 请求的编码示例

下面我们来看看页面和服务器交互的字符编码情况。

1


、网址路径中包含汉字


。

打开IE（我用的是8.0版），输入网址“

http://zh.wikipedia.org/wiki/


春节

”。 注意，“春节”这两个字此时是网址路径的一部分。

查看HTTP请求的头信息，会发现IE实际查询的网址是“http://zh.wikipedia.org/wiki/%E6%98%A5%E8%8A%82


”。 也就是说，IE自动将“春节”编码成了“%E6%98%A5%E8%8A%82”。

我们知道，“春”和“节”的utf-8编码分别是“E6 98 A5”和“E8 8A 82”，因此，“%E6%98%A5%E8%8A%82”就是按照顺序，在每个字节前加上%而得到的。

在Firefox中测试，也得到了同样的结果。所以，

结论


1


就是，网址路径的编码，用的是


utf-8


编码。

2


、


查询字符串包含汉字

在IE中输入网址“

http://www.baidu.com/s?wd=


春节

”。注意，“春节”这两个字此时 属于查询字符串，不属于网址路径，不要与情况1混淆。

查看HTTP请求的头信息，会发现IE将“春节”转化成了一个乱码。

切换到十六进制方式，才能清楚地看到，“春节”被转成了“B4 BA BD DA”。

我们知道，“春”和“节”的GB2312编码（我的操作系统“Windows XP”中文版的默认编码）分别是“B4 BA”和“BD DA”。因此，IE实际上就是将查询字符串，以GB2312编码的格式发送出去。

Firefox的处理方法，略有不同。它发送的HTTP Head是“wd=%B4%BA%BD%DA”。也就是说，同样采用GB2312编码，但是在每个字节前加上了%。

所以，

结论


2


就是，查询字符串的编码，用的是操作系统的默认编码。

3、

Get


或


Post


方法生成的


URL


包含汉字

前面说的是直接输入网址的情况，但是更常见的情况是，在已打开的网页上，直接用Get或Post方法发出HTTP请求。这时的编码方法由网页的编码决定，也就是由HTML源码中字符集的设定决定。

<meta http-equiv=”Content-Type” content=”text/html;charset=xxxx”>

如果上面这一行最后的charset是UTF-8，则URL就以UTF-8编码；如果是GB2312，URL就以GB2312编码。

举例来说，百度是GB2312编码，Google是UTF-8编码。因此，从它们的搜索框中搜索同一个词“春节”，生成的查询字符串是不一样的。

百度生成的是%B4%BA%BD%DA，这是GB2312编码。

Google生成的是%E6%98%A5%E8%8A%82，这是UTF-8编码。

所以，

结论


3


就是，


GET


和


POST


方法的编码，用的是网页的编码。

4、

Ajax


调用的


URL


包含汉字

前面三种情况都是由浏览器发出HTTP请求，最后一种情况则是由Javascript生成HTTP请求，也就是Ajax调用。还是根据吕瑞麟老师的 文章，在这种情况下，IE和Firefox的处理方式完全不一样。

举例来说，有这样两行代码：

url = url + “?q=” +document.myform.elements[0].value; // 假定用户在表单中提交的值是“春节”这两个字

http_request.open(‘GET’, url, true);

那么，无论网页使用什么字符集，IE传送给服务器的总是“q=%B4%BA%BD%DA”，而Firefox传送给服务器的总是“q=%E6%98 %A5%E8%8A%82”。也就是说，在Ajax调用中，IE总是采用GB2312编码（操作系统的默认编码），而Firefox总是 采用utf-8编码。这就是我们的结论4。

我们使用表格来做个比较。

不同的操作系统、不同的浏览器、不同的网页字符集，将导致完全不同的编码结果。在前后端交互的时候怎么避免这个问题，就是前端先对发送请求进行编码，然后再向服务器提交，服务器获取前端的编码方式进行解码，不要给浏览器插手的机会。 这样就保证了服务器得到的数据是格式统一的。

四、其它需要编码的地方

除了 URL 和参数编码问题外，在服务端还有很多地方可能存在编码，如可能需要读取 xml、velocity 模版引擎或者从数据库读取数据等。

xml 文件可以通过设置头来制定编码格式

<?xml version=”1.0″ encoding=”UTF-8″?>

Velocity 模版设置编码格式：

services.VelocityService.input.encoding=UTF-8

访问数据库都是通过客户端 JDBC 驱动来完成，用 JDBC 来存取数据要和数据的内置编码保持一致，可以通过设置 JDBC URL 来制定如 MySQL：url=”jdbc:mysql://localhost:3306/DB?useUnicode=true&characterEncoding=GBK”。

五、测试建议

经过以上了解，可以发现，常出现的问题是中文的支持，编码和解码不一致导致乱码。所以日常测试中，对与get、psot、Ajax请求中含有中文属性的，需要做相应的测试验证。

• 支持中文的话，必须测试中文，另外注意繁体字。
• Get请求含有中文测试。
• Post请求中含有中文测试。
• Ajax请求中含有中文测试。

六、常见问题分析

下面看一下，当我们碰到一些乱码时，应该怎么分析这些问题？出现乱码问题的原因都是在转换中编码和解码的字符集不一致导致的，由于往往一次操作涉及到多次编解码，所以出现乱码时很难查找到底是哪个环节出现了问题，下面就几种常见的现象进行分析。

1、中文变成了看不懂的字符

例如，字符串“淘！我喜欢！”变成了“Ì Ô £ ¡Î Ò Ï²»¶ £ ¡”编码过程如下图所示

字符串在解码时所用的字符集与编码字符集不一致导致汉字变成了看不懂的乱码，而且是一个汉字字符变成两个乱码字符。

2、一个汉字变成一个问号

例如，字符串“淘！我喜欢！”变成了“？？？？？？”编码过程如下图所示

将中文和中文符号经过不支持中文的 ISO-8859-1 编码后，所有字符变成了“？”，这是因为用 ISO-8859-1 进行编解码时遇到不在码值范围内的字符时统一用 3f 表示，这也就是通常所说的“黑洞”，所有 ISO-8859-1 不认识的字符都变成了“？”。

3、一个汉字变成两个问号

例如，字符串“淘！我喜欢！”变成了“？？？？？？？？？？？？”编码过程如下图所示

这种情况比较复杂，中文经过多次编码，但是其中有一次编码或者解码不对仍然会出现中文字符变成“？”现象，出现这种情况要仔细查看中间的编码环节，找出出现编码错误的地方。

4、一种不正常的正确编码

这种情况是这样的，ISO-8859-1 字符集的编码范围是 0000-00FF，正好和一个字节的编码范围相对应。这种特性保证了使用 ISO-8859-1 进行编码和解码可以保持编码数值“不变”。虽然中文字符在经过网络传输时，被错误地“拆”成了两个欧洲字符，但由于输出时也是用 ISO-8859-1，结果被“拆”开的中文字的两半又被合并在一起，从而又刚好组成了一个正确的汉字。虽然最终能取得正确的汉字，但是还是不建议用这种不正常的方式取得参数值，因为这中间增加了一次额外的编码与解码，这种情况出现乱码时因为 Tomcat 的配置文件中 useBodyEncodingForURI 配置项没有设置为”true”，从而造成第一次解析式用 ISO-8859-1 来解析才造成乱码的。

附：

windows联通之谜事件：

原因解析：

因为GB2312编码与UTF8编码产生了编码冲撞的原因。

下表是从UNICODE到UTF8的转换规则，

当你新建一个文本文件时，记事本的编码默认是ANSI, 如果你在ANSI的编码输入汉字，那么他实际就是GB2312系列的编码方式，在这种编码下，”联通”的内码是：

c1 1100 0001

aa 1010 1010

cd 1100 1101

a8 1010 1000

巧合的地方在于联通这两个字的ANSI编码符合utf8编码的第二个模板。第一二个字节、第三四个字节的起始部分的都是”110″和”10″，正好与UTF8规则里的两字节模板是一致的，于是再次打开记事本时，记事本就误认为这是一个UTF8编码的文件，让我们把第一个字节的110和第二个字节的10去掉，我们就得到了”00001 101010″，再把各位对齐，补上前导的0，就得到了”0000 0000 0110 1010″，不好意思，这是UNICODE的006A，也就是小写的字母”j”，而之后的两字节用UTF8解码之后是0368，这个字符什么也不是。这就是只有”联通”两个字的文件没有办法在记事本里正常显示的原因。可以认为，当文档中的所有字符的二进制编码在

C0≤AA(


第一个字节


)≤DF  80≤BB(


第二个字节


)≤BF

时，记事本都无法确认文本的编码格式，就按照UTF-8的格式来显示。