JavaWeb的编码问题深入分析

布满荆棘的人生 2022-06-09 21:17 259阅读 0赞

## 一、为什么要进行编码 ##

编码问题一直困扰着程序开发人员，尤其是在 Java 中更加明显，因为 Java 是跨平台的语言，在不同平台的编码之间的切换较多。要对Java Web项目进行编码原因如下:  
1、在计算机中存储信息的最小单位是1个字节，即8个bit，所以能表示的字符范围是0~255个。  
2、电脑需要表示的符号（例如各国语言字符）太多（总数超过255）、所以无法用1个字节完全表示需要的符号。  
要解决这个问题，必须要有一个新的数据结构char，而从bit到char就要进行编码。

## 二、编码格式 ##

目前常见的编码格式如下：  
1、ASCII码  
总共128个，用1个字符的低7位表示，0~31是控制字符，如换行、回车、删除等。32~126是打印字符，可以通过键盘输入并且表示出来。

2、ISO-8859-1  
ISO组织在ASCII的基础上又制定了一系列标准来就、扩展ASCII编码，他们是ISO-8859-1和ISO-8859-15。其中前者涵盖了大多数西欧语言字符，所以运用得比较广泛。ISO-8859-1仍然是单字节编码，它总共能表示256个字符.  
因为ISO-8859-1是单字节的，所以很多中文字符（两个字节）在编码时用ISO-8859-1表示时，因超出表示范围，所以出现？？很多情况是将中文字符用ISO-8859-1表示。我们称之为“黑洞”（它会将不认识的字符吸收掉）。  
由于现在大部分基础的Java框架或系统默认的字符集编码都是ISO-8859-1，所以很容易出现乱码问题。

3、GB2312  
GB2312是双字节编码，总的编码范围是A1-F7，其中A1-A9是符号区，总共有682个符号，B0-F7是汉字区，包含6763个汉字。

4、GBK  
GBK全称是 汉字内码扩展规范，是中国国家技术监督局开发出来扩展GB2312，并加入了更多的汉字，它的编码范围是8140~FEFE，能表示21003个汉字。它与GB2312是兼容的。

5、GB18030  
Gb18030全称是 信息技术中文编码字符集，是我国的强制标准，它可能是单字节的、双字节或者是四字节编码。它的编码与GB2312编码兼容。

6、UTF-16  
ISO试图创建一个全新的超语言字典，世界上的语言都能使用这个字典进行翻译。UTF-16具体定义了Unicode字符在计算机中的存取方法，UTF-16用两个字节来表示Unicode的转化格式，它采用定长的表示方法，即无论什么字符都可以用两个字节表示。两个字节就是16个bit，所以叫做UTF-16。Java以UTF-16作为内存中字符存储格式。

7、UTF-8  
UTF-8采用变长的方法，克服了UTF-16中定长的浪费资源的缺点。每个编码区域都有自己不用的字码长度，不同类型的字符可以由1~6个字节组成。  
UTF-8对单字节范围内的字符仍然用1个字节表示，对汉字采用3个字节表示。  
UTF-8的编码规则：当是1个字节的时候，最高位为0，则表示这是一个ASCII字符，由此可见，所有ASCII编码已经是UTF-8.  
当是1个字节，以11开头，则连续的1的个数暗示这个字符的字节数，如110XXXXX表示它是双字节UTF-8字符的首字节。  
当是1个字节，以10开头，表示它不是首字节。则需要向前查找才能得到它的首字节。

上述几种编码格式的比较：  
GBK能处理所有的汉字字符，所以将GB2312和GBK进行比较时，应该选择GBK。  
UTF-8与UTF-16都是处理Unicode编码，尽管他们的编码格式不相同，但相对来说，UTF-16的编码效率较高，从字符到字节的转换更简单，进行字符串操作也更好，适合磁盘和内存之间使用，所以Java的内存编码采用UTF-16来编码。但是在网络传输的时候，应使用UTF-8，因为网络传输比较容易损坏字节流，而UTF-8对ASCII字符采用了单字节编码，另外单个字节损坏不会影响到后面的其他字符，在编码效率中介于GBK和UTF-16之间，所以，UTF-8在编码效率和编码安全性方面都做了平衡，是理想的中文编码方式。

## 三、Java中需要用到编码的场景 ##

### 1、Java I/O ###

![这里写图片描述][20170811094231238]  
如上图：Reader 类是在 Java 的 I/O 中读取字符的父类，而 InputStream 类是读字节的父类， InputStreamReader 类就是关联字节到字符的桥梁，它负责在 I/O 过程中处理读取字节到字符的转换，而对具体字节到字符的解码实现，它又委托 StreamDecoder 去做，在 StreamDecoder 解码过程中必须由用户指定 Charset 编码格式。值得注意的是，如果你没有指定 Charset，则将使用本地环境中默认的字符集，如在中文环境中将使用 GBK 编码。  
应用示例如下：

String file = "c:/stream.txt"; 
     String charset = "UTF-8"; 
     // 写字符换转成字节流
     FileOutputStream outputStream = new FileOutputStream(file); 
     OutputStreamWriter writer = new OutputStreamWriter( 
     outputStream, charset); //指定输出流和编码格式
     try { 
        writer.write("这是要保存的中文字符"); 
     } finally { 
        writer.close(); 
     } 
     // 读取字节转换成字符
     FileInputStream inputStream = new FileInputStream(file); 
     InputStreamReader reader = new InputStreamReader( 
     inputStream, charset); //制定输入流和编码格式
     StringBuffer buffer = new StringBuffer(); 
     char[] buf = new char[64]; 
     int count = 0; 
     try { 
        while ((count = reader.read(buf)) != -1) { 
            buffer.append(buffer, 0, count); 
        } 
     } finally { 
        reader.close(); 
     }

在我们的应用程序中涉及 I/O 操作时，推荐设定统一的编解码字符集，避免跨平台是的乱码困扰。只要注意显式指定统一的且合适的编解码 Charset 字符集，一般不会出现乱码问题。

### 2、内存操作 ###

在内存中进行从字符到字节的数据类型转换时会涉及编解码。  
1、String 类提供字符串转换到字节的方法，也支持将字节转换成字符串的构造函数。

String s  = "字符串"；
    byte[] b = s.getBytes("UTF-8");
    String n = new String(b, "UTF-8");

2、Charset 提供 encode 与 decode，分别对应 char\[\] 到 byte\[\] 的编码 和 byte\[\] 到 char\[\] 的解码。

Charset charset = Charset.forName("UTF-8");
    ByteBuffer byteBuffer = charset.encode(string);
    CharBuffer charBuffer = charset.decode(byteBuffer);

### 3、在 Java Web 中涉及的编解码 ###

对于使用中文来说，有 I/O 的地方就会涉及到编码，前面已经提到了 I/O 操作会引起编码，而大部分 I/O 引起的乱码都是网络 I/O，因为现在几乎所有的应用程序都涉及到网络操作，而数据经过网络传输都是以字节为单位的，所以所有的数据都必须能够被序列化为字节。在 Java 中数据被序列化必须继承 Serializable 接口。

一段文本它的实际大小应该怎么计算？所谓的压缩只是将多个单字节字符通过编码转变成一个多字节字符。减少的是 String.length()，而并没有减少最终的字节数。例如将“ab”两个字符通过某种编码转变成一个奇怪的字符，虽然字符数从两个变成一个，但是如果采用 UTF-8 编码这个奇怪的字符最后经过编码可能又会变成三个或更多的字节。同样的道理比如整型数字 1234567 如果当成字符来存储，采用 UTF-8 来编码占用 7 个 byte，采用 UTF-16 编码将会占用 14 个 byte，但是把它当成 int 型数字来存储只需要 4 个 byte 来存储。所以看一段文本的大小，看字符本身的长度是没有意义的，即使是一样的字符采用不同的编码最终存储的大小也会不同，所以从字符到字节一定要看编码类型。

我们能够看到的汉字都是以字符形式出现的，例如在 Java 中“淘宝”两个字符，它在计算机中的数值 10 进制是 28120 和 23453，16 进制是 6bd8 和 5d9d，也就是这两个字符是由这两个数字唯一表示的。Java 中一个 char 是 16 个 bit 相当于两个字节，所以两个汉字用 char 表示在内存中占用相当于四个字节的空间。

这两个问题搞清楚后，我们看一下 Java Web 中那些地方可能会存在编码转换？

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

*  URL 的编解码

用户提交一个 URL，这个 URL 中可能存在中文，因此需要编码，如何对这个 URL 进行编码？根据什么规则来编码？有如何来解码？如下图一个 URL：  
![这里写图片描述][20170811100421769]  
上图中以 Tomcat 作为 Servlet Engine 为例，它们分别对应到下面这些配置文件中：  
Port 对应在 Tomcat 的 `<Connector port="8080"/>` 中配置，而 Context Path 在 中配置，Servlet Path 在 Web 应用的 web.xml 中的

<servlet-mapping> 
            <servlet-name>junshanExample</servlet-name> 
            <url-pattern>/servlets/servlet/*</url-pattern> 
     </servlet-mapping>

`<url-pattern>` 中配置，PathInfo 是我们请求的具体的 Servlet，QueryString 是要传递的参数，注意这里是在浏览器里直接输入 URL 所以是通过 Get 方法请求的，如果是 POST 方法请求的话，QueryString 将通过表单方式提交到服务器端。

上图中 PathInfo 和 QueryString 出现了中文，当我们在浏览器中直接输入这个 URL 时，在浏览器端和服务端会如何编码和解析这个 URL 呢？  
为了验证浏览器是怎么编码 URL 的我选择的是Chrome浏览器开发者工具观察我们请求的 URL 的实际的内容，以下是 URL：

HTTP://localhost:8080/examples/servlets/servlet/君山?author=君山

![这里写图片描述][20170811100833496]  
君山的编码结果是：e5 90 9b e5 b1 b1，和《深入分析 Java Web 技术内幕》中的结果不一样，这是因为我使用的浏览器和插件和原作者是有区别的，那么这些浏览器之间的默认编码是不一样的，原文中的结果是：  
君山的编码结果分别是：e5 90 9b e5 b1 b1，be fd c9 bd，查阅编码可知，PathInfo 是 UTF-8 编码而 QueryString 是经过 GBK 编码，至于为什么会有“%”？查阅 URL 的编码规范 RFC3986 可知浏览器编码 URL 是将非 ASCII 字符按照某种编码格式编码成 16 进制数字然后将每个 16 进制表示的字节前加上“%”，所以最终的 URL 就成了上图的格式了。

从上面测试结果可知浏览器对 PathInfo 和 QueryString 的编码是不一样的，不同浏览器对 PathInfo 也可能不一样，这就对服务器的解码造成很大的困难，下面我们以 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(); 
            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); 
     }

从上面的代码中可以知道对 URL 的 URI 部分进行解码的字符集是在 connector 的 中定义的，如果没有定义，那么将以默认编码 ISO-8859-1 解析。所以如果有中文 URL 时最好把 URIEncoding 设置成 UTF-8 编码。

QueryString 又如何解析？ GET 方式 HTTP 请求的 QueryString 与 POST 方式 HTTP 请求的表单参数都是作为 Parameters 保存，都是通过 request.getParameter 获取参数值。对它们的解码是在 request.getParameter 方法第一次被调用时进行的。request.getParameter 方法被调用时将会调用 `org.apache.catalina.connector.Request` 的 `parseParameters` 方法。这个方法将会对 GET 和 POST 方式传递的参数进行解码，但是它们的解码字符集有可能不一样。POST 表单的解码将在后面介绍，QueryString 的解码字符集是在哪定义的呢？它本身是通过 HTTP 的 Header 传到服务端的，并且也在 URL 中，是否和 URI 的解码字符集一样呢？从前面浏览器对 PathInfo 和 QueryString 的编码采取不同的编码格式不同可以猜测到解码字符集肯定也不会是一致的。的确是这样 QueryString 的解码字符集要么是 Header 中 ContentType 中定义的 Charset 要么就是默认的 ISO-8859-1，要使用 ContentType 中定义的编码就要设置 connector 的 `<Connector URIEncoding=”UTF-8” useBodyEncodingForURI=”true”/>` 中的 useBodyEncodingForURI 设置为 true。这个配置项的名字有点让人产生混淆，它并不是对整个 URI 都采用 BodyEncoding 进行解码而仅仅是对 QueryString 使用 BodyEncoding 解码，这一点还要特别注意。

从上面的 URL 编码和解码过程来看，比较复杂，而且编码和解码并不是我们在应用程序中能完全控制的，所以在我们的应用程序中应该尽量避免在 URL 中使用非 ASCII 字符，不然很可能会碰到乱码问题，当然在我们的服务器端最好设置 `<Connector/>` 中的 `URIEncoding` 和 `useBodyEncodingForURI` 两个参数。

*  HTTP Header 的编解码

当客户端发起一个 HTTP 请求，除了上面的 URL 外还可能会在 Header 中传递其它参数如 Cookie、redirectPath 等，这些用户设置的值很可能也会存在编码问题，Tomcat 对它们又是怎么解码的呢？

对 Header 中的项进行解码也是在调用 request.getHeader 是进行的，如果请求的 Header 项没有解码则调用 MessageBytes 的 toString 方法，这个方法将从 byte 到 char 的转化使用的默认编码也是 ISO-8859-1，而我们也不能设置 Header 的其它解码格式，所以如果你设置 Header 中有非 ASCII 字符解码肯定会有乱码。

我们在添加 Header 时也是同样的道理，不要在 Header 中传递非 ASCII 字符，如果一定要传递的话，我们可以先将这些字符用 org.apache.catalina.util.URLEncoder 编码然后再添加到 Header 中，这样在浏览器到服务器的传递过程中就不会丢失信息了，如果我们要访问这些项时再按照相应的字符集解码就好了。

*  POST 表单的编解码

在前面提到了 POST 表单提交的参数的解码是在第一次调用 request.getParameter 发生的，POST 表单参数传递方式与 QueryString 不同，它是通过 HTTP 的 BODY 传递到服务端的。当我们在页面上点击 submit 按钮时浏览器首先将根据 ContentType 的 Charset 编码格式对表单填的参数进行编码然后提交到服务器端，在服务器端同样也是用 ContentType 中字符集进行解码。所以通过 POST 表单提交的参数一般不会出现问题，而且这个字符集编码是我们自己设置的，可以通过 request.setCharacterEncoding(charset) 来设置。

另外针对 multipart/form-data 类型的参数，也就是上传的文件编码同样也是使用 ContentType 定义的字符集编码，值得注意的地方是上传文件是用字节流的方式传输到服务器的本地临时目录，这个过程并没有涉及到字符编码，而真正编码是在将文件内容添加到 parameters 中，如果用这个编码不能编码时将会用默认编码 ISO-8859-1 来编码。

*  HTTP BODY 的编解码

当用户请求的资源已经成功获取后，这些内容将通过 Response 返回给客户端浏览器，这个过程先要经过编码再到浏览器进行解码。这个过程的编解码字符集可以通过 response.setCharacterEncoding 来设置，它将会覆盖 request.getCharacterEncoding 的值，并且通过 Header 的 Content-Type 返回客户端，浏览器接受到返回的 socket 流时将通过 Content-Type 的 charset 来解码，如果返回的 HTTP Header 中 Content-Type 没有设置 charset，那么浏览器将根据 Html 的 `<meta HTTP-equiv="Content-Type" content="text/html; charset=GBK" />` 中的 charset 来解码。如果也没有定义的话，那么浏览器将使用默认的编码来解码。

*  其它需要编码的地方

除了 URL 和参数编码问题外，在服务端还有很多地方可能存在编码，如可能需要读取 xml、JSP 或者从数据库读取数据等。  
xml 文件可以通过设置头来制定编码格式

<?xml version="1.0" encoding="UTF-8"?>

JSP 设置编码格式：

<%@page contentType="text/html; charset=UTF-8"%>

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

## 四、常见编解码问题分析 ##

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

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

例如，字符串“淘！我喜欢！”变成了“Ì Ô £ ¡Î Ò Ï²»¶ £ ¡”编码过程如下图所示：  
![这里写图片描述][20170811102545786]  
原因：字符串在解码时所用的字符集与编码字符集不一致导致汉字变成了看不懂的乱码，而且是一个汉字字符变成两个乱码字符。这是说明编码时是将一个汉字编码为两个字节，而解码时直接将一个字节对应一个字节。可以确定解码一定使用的是IOS-8859-1。

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

例如，字符串“淘！我喜欢！”变成了“？？？？？？”编码过程如下图所示:  
![这里写图片描述][20170811103000418]  
原因：将中文和中文符号经过不支持中文的 ISO-8859-1 编码后，所有字符变成了“？”，这是因为用 ISO-8859-1 进行编解码时遇到不在码值范围内的字符时统一用 3f 表示，这也就是通常所说的“黑洞”，所有 ISO-8859-1 不认识的字符都变成了“？”。

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

例如，字符串“淘！我喜欢！”变成了“？？？？？？？？？？？？”编码过程如下图所示:  
![这里写图片描述][20170811103139609]  
原因：这种情况比较复杂，中文经过多次编码，但是其中有一次编码或者解码不对仍然会出现中文字符变成“？”现象，出现这种情况要仔细查看中间的编码环节，找出出现编码错误的地方。

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

还有一种情况是在我们通过 request.getParameter 获取参数值时，当我们直接调用

String value = request.getParameter(name);

会出现乱码，但是如果用下面的方式

String value = String(request.getParameter(name).getBytes(" ISO-8859-1"), "GBK");

解析时取得的 value 会是正确的汉字字符，这种情况是怎么造成的呢？

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

## 参考文献 ##

《深入分析 Java Web 技术内幕》 许令波著

[20170811094231238]: /images/20220610/d7d5cef24c5541b48890ec73ec88d1ea.png
[20170811100313074]: /images/20220610/f71c089d82d3475d8f403903f82f357f.png
[20170811100421769]: /images/20220610/3e2d6bad65ba42559b1229a89c200b62.png
[20170811100833496]: /images/20220610/c79f0270209b417482d269c839a2e33b.png
[20170811102545786]: /images/20220610/59505ee96704462ea707bc61ccfa202e.png
[20170811103000418]: /images/20220610/fc6201533ded4135a10135be89726867.png
[20170811103139609]: /images/20220610/97a20bfb9ee24caabfb509ee2c53c023.png
[20170811103342663]: /images/20220610/c7915484abb343838e55e6bfc67f9e89.png