Java Web中文编码问题

阳光穿透心脏的1/2处 2022-06-02 02:05 210阅读 0赞

### 一、为什么要编码？ ###

*  在计算机中存储信息的最小单元是1个字节，即8个bit，所以能表示的字符范围是0~255个。
 *  人类要表示的符号太多，无法用1个字节来完全表示。
 *  解决这个矛盾必须要有一个新的数据结构char，而从char到byte必须编码。

### 二、常见的编码格式 ###

*  ASCII码  
    
    
     *  总共128个，用1个字节的低七位表示，0~31是控制字符如换行、回车、删除等，32~126是打印字符，可以通过键盘输入并且能够显示出来。
 *  ISO-8859-1  
    
    
     *  128个字符显然是不够用的，于是ISO组织在ASCII码基础上又定制了一系列标准来扩展ASCII编码，它们是ISO-8859-1至ISO-8859-15，其中ISO-8859-1涵盖了大多数西欧语言字符，所以应用得最广泛。ISO-8859-1仍然是单字节编码，总共能表示256个字符。
 *  GB2312  
    
    
     *  GB2312的全称是《信息技术中文编码字符集》，它是双字节编码，总的编码范围是A1~F7，其中A1~A9是符号区，总共包含682个符号；B0~F7是汉字区，包含6763个汉字。
 *  GBK  
    
    
     *  GBK全称是《汉字内码扩展规范》，是国家技术监督局为Windows 95所制定的新的内码规范，它的出现时为了扩展GB2312，并加入更多的汉字。它的编码范围是8140~FEFE（去掉XX7F）），总共有23940个码位，它能表示21003个汉字，它的编码是和GB2312兼容的，也就是说GB2312编码的汉字可以用GBK来解码，并且不会有乱码。
 *  GB18030  
    
    
     *  GB18030全称是《信息技术中文编码字符集》，是我国的强制标准，它可能是单字节、双字节或者四字节编码，它的编码与GB2312编码兼容，虽然是国家标准，但是在实际应用系统中使用得并不广泛。
 *  UTF-16  
    
    
     *  说到UTF必须提到Unicode（Universal Code 统一码），ISO试图创建一个全新的超语言字典，世界上所有的语言都可以通过这个字典来相互翻译。可想而知这个字典是多么复杂。关于Unicode的详细规范可以参考相应文档。Unicode是Java和XML的基础。
     *  UTF-16具体定义了Unicode字符在计算机中的存取方法。UTF-16用两个字节来表示Unicode的转化格式，它采用定长的表示方法，即不论什么字符都可以用两个字节表示。两个字节是16个bit，所以叫UTF-16。UTF-16表示字符非常方便，每两个字节表示一个字符，这就大大简化了字符串操作，这也是Java以UTF-16作为内存的字符存储格式的一个很重要的原因。
 *  UTF-8  
    
    
     *  UTF-16统一采用两个字节来表示一个字符，虽然在表示上非常简单、方便，但是也有其缺点，有很大一部分字符用一个字节就可以表示的现在要用两个字节表示，存储空间放大了一倍，在现在的网络带宽还非常有限的情况下，这样会增大网络传输的流量，而且也没有必要。而UTF-8采用了一种变长技术，每个编码区域有不同的字码长度。不同类型的字符可以由1~6个字节组成。
     *  UTF-8有以下编码规则：  
        
        
         *  如果是1个字节，最高为（第8位）为0，则表示这是1个ASCII字符（00~7F）。可见，所有ASCII编码已经是UTF-8了。
         *  如果是1个字节，以11开头，则连续的1的个数暗示这个字符的字节数，例如：110xxxxx代表它是双字节UTF-8字符的首字节。
         *  如果是1个字节，以10开始，表示它不是首字节，则需要向前查找才能得到当前字符的首字节。

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

*  #### 在I/O操作中存在的编码 ####
    
     *  我们知道涉及编码的地方一般都在从字符到字节或者从字节到字符的转化上，而需要这种转化的场景主要是I/O，这个I/O包括磁盘I/O和网络I/O，网络I/O部分将以web应用为例进行介绍。
     *  如图所示是Java中处理I/O问题的接口。  
        ![java中处理IO问题的接口][java_IO]  
        
        
         *  Reader类是在Java的I/O中读字符的父类，而InputStream类是读字节的父类，InputStreamReader类就是关联字节到字符的桥梁，它负责在I/O过程中处理读取字节到字符的转换，而对具体字节到字符的解码实现，它又委托StreamDecoder去做，在StreamDecoder解码过程中必须由用户指定Charset编码格式。值得注意的是，如果你没有指定Charset，则将使用本地环境中的默认字符集，如在中文环境中将使用GBK编码。
     *  写的情况也类似，字符的父类是Writer，字节的父类是OutputStream，通过OutputStreamWriter转换字符到字节，如图所示。  
        ![这里写图片描述][SouthEast]  
        
        
         *  同样，StreamEncoder类负责将字符编码成字节，编码格式和默认编码规则与解码是一致的。
     *  在我们的应用程序中涉及I/O操作时，只要注意指定统一的编解码Charset字符集，一般不会出现乱码问题。
     *  对有些应用程序如果不注意指定字符编码，则在中文环境中会使用操作系统默认编码。如果编解码都在中文环境中，通常也没有问题，但还是不推荐使用操作系统的默认编码，因为这样会使你的应用程序的编码格式和运行环境绑定起来，在跨环境时很可能出现乱码问题。
 *  #### 在内存操作中的编码 ####
    
     *  在Java开发中除I/O涉及编码外，最常用的应该就是在内存中进行从字符到字节的数据类型转换，在Java中用String表示字符串，所以String类就提供了转换到字节的方法，也支持将字节转换为字符串的构造函数。
        
            String s = "这是一段中文字符串";
            byte[] b = s.getBytes("UTF-8");  
            String str = new String(b,"UTF-8");
     *  Charset提供encode与decode，分别对应char\[\]到byte\[\]的编码和byte\[\]到char\[\]的解码。
        
            String s = "这是一段中文字符串";
            Charset charset = Charset.forName("UTF-8");
            ByteBuffer byteBuffer = charset.encode(s);
            CharBuffer charBuffer = charset.decode(byteBuffer);
     *  在Java中还有一个ByteBuffer类，它提供一种char和byte之间的软转换，它们之间转换不需要编码与解码，只是把一个16bit的char拆分成为2个8 bit的byte表示，它们的实际值并没有被修改，仅仅是数据的类型做了转换。
        
            ByteBuffer heapByteBuffer = ByteBuffer.allocate(1024);
            ByteBuffer byteBuffer = heapByteBuffer.putChar(c);

### 四、在Java中如何编解码 ###

*  下图是Java中编码所需要用到的类图  
    ![这里写图片描述][SouthEast 1]
 *  首先根据指定的charsetName通过Charset.forName(charsetName)找到Charset类，然后根据Charset创建CharsetEncoder对象，再调用CharsetEncoder.encode对字符串进行编码，不同的编码类型都会对应到一个类中，实际的编码过程是在这些类中完成的。
 *  下图是String.getBytes(charsetName)编码过程的时序图。  
    ![这里写图片描述][SouthEast 2]
 *  从图中可以看出，根据charsetName找到Charset类，然后根据这个字符集编码生成CharsetEncoder，这个类是所有字符编码的父类，针对不同的字符编码集在其自类中定义了如何实现编码，有了CharsetEncoder对象后就可以调用encode方法去实现编码了。这个是String.getBytes编码方法，其他的(如StreamEncoder)也是类似的方式。
 *  下面看看不同的字符集是如何将前面的字符串编码成byte数组的。
 *  #### 按照ISO-8859-1编码 ####
    
     *  字符串“I am 君山”用ISO-8859-1编码时，编码结果如图：  
        ![这里写图片描述][SouthEast 3]
     *  可以看出，7个 char 字符经过 ISO-8859-1 编码转变成7个 byte 数组，ISO-8859-1 是单字节编码，中文“君山”被转化成值是 3f 的 byte。3f 也就是“？”字符，所以经常会出现中文变成“？”，很可能就是错误的使用了 ISO-8859-1 这个编码导致的。中文字符经过 ISO-8859-1 编码会丢失信息，通常我们称之为“黑洞”，它会把不认识的字符吸收掉。由于现在大部分基础的 Java 框架或系统默认的字符集编码都是 ISO-8859-1，所以很容易出现乱码问题。
 *  #### 按照GB2312编码 ####
    
     *  字符串“I am 君山”用GB2312编码时，编码结果如图：  
        ![这里写图片描述][SouthEast 4]
     *  GB2312 对应的 Charset 是 sun.nio.cs.ext.EUC\_CN，而对应的 CharsetDecoder 编码类是 sun.nio.cs.ext.DoubleByte，GB2312 字符集有一个 char 到 byte 的码表，不同的字符编码就是查这个码表找到与每个字符的对应的字节，然后拼装成 byte 数组。查表的规则如下：
        
            c2b[c2bIndex[char >> 8] + (char & 0xff)]
     *  如果查到的码位值大于 oxff 则是双字节，否则是单字节。双字节高 8 位作为第一个字节，低 8 位作为第二个字节，如下代码所示：
        
            if (bb > 0xff) {    // DoubleByte 
                       if (dl - dp < 2) 
                           return CoderResult.OVERFLOW; 
                       da[dp++] = (byte) (bb >> 8); 
                       da[dp++] = (byte) bb; 
            } else {                      // SingleByte 
                       if (dl - dp < 1) 
                           return CoderResult.OVERFLOW; 
                       da[dp++] = (byte) bb; 
            }
     *  从上图可以看出前 5 个字符经过编码后仍然是 5 个字节，而汉字被编码成双字节，在前面介绍到 GB2312 只支持 6763 个汉字，所以并不是所有汉字都能够用 GB2312 编码。
 *  #### 按照 GBK 编码 ####
    
     *  字符串“I am 君山”用GBK编码时，编码结果如图：  
        ![这里写图片描述][SouthEast 5]
     *  你可能已经发现，上图与 GB2312 编码的结果是一样的，没错，GBK 与 GB2312 编码结果是一样的，由此可以得出 GBK 编码是兼容 GB2312 编码的，它们的编码算法也是一样的。不同的是它们的码表长度不一样，GBK 包含的汉字字符更多。所以只要是经过 GB2312 编码的汉字都可以用 GBK 进行解码，反过来则不然。
 *  #### 按照 UTF-16 编码 ####
    
     *  字符串“I am 君山”用UTF-16编码时，编码结果如图：  
        ![这里写图片描述][SouthEast 6]
     *  用 UTF-16 编码将 char 数组放大了一倍，单字节范围内的字符，在高位补 0 变成两个字节，中文字符也变成两个字节。从 UTF-16 编码规则来看，仅仅将字符的高位和地位进行拆分变成两个字节。特点是编码效率非常高，规则很简单，由于不同处理器对 2 字节处理方式不同，Big-endian（高位字节在前，低位字节在后）或 Little-endian（低位字节在前，高位字节在后）编码，所以在对一串字符串进行编码是需要指明到底是 Big-endian 还是 Little-endian，所以前面有两个字节用来保存 BYTE\_ORDER\_MARK 值，UTF-16 是用定长 16 位（2 字节）来表示的 UCS-2 或 Unicode 转换格式，通过代理对来访问 BMP 之外的字符编码。
 *  #### 按照 UTF-8 编码 ####
    
     *  字符串“I am 君山”用UTF-8编码时，编码结果如图：  
        ![这里写图片描述][SouthEast 7]
     *  UTF-16 虽然编码效率很高，但是对单字节范围内字符也放大了一倍，这无形也浪费了存储空间，另外 UTF-16 采用顺序编码，不能对单个字符的编码值进行校验，如果中间的一个字符码值损坏，后面的所有码值都将受影响。而 UTF-8 这些问题都不存在，UTF-8 对单字节范围内字符仍然用一个字节表示，对汉字采用三个字节表示。
     *  UTF-8 编码与 GBK 和 GB2312 不同，不用查码表，所以在编码效率上 UTF-8 的效率会更好，所以在存储中文字符时 UTF-8 编码比较理想。

### 五、对几种编码格式的比较 ###

*  对于中文字符，GB2312与GBK编码规则类似，但是GBK范围更大，它能处理所有汉字字符，所以将GB2312与GBK进行比较，应该选择GBK。
 *  UTF-16与UTF-8都是处理Unicode编码，它们的编码规则不太相同，相对来说，UTF-16的编码效率较高，从字符到到字节的相互转换更简单，进行字符串操作也更好。它适合在本地磁盘和内存之间使用，可以进行字符和字节之间的快速切换，如Java的内存编码就采用UTF-16编码。
 *  但是它不合适在网络之间传输，因为网络传输容易损坏字节流，一旦字节流损坏将很难恢复，所以相比较而言UTF-8更适合网络传输。
 *  UTF-8对ASCII字符采用单字节存储，另外单个字符损坏也不会影响后面的其他字符，在编码效率上介于GBK和UTF-16之间，所以UTF-8在编码效率上和编码安全上做了平衡，是理想的中文编码方式。

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

*  前面已经提到了I/O操作会引起编码，而大部分I/O引起的乱码都是网络I/O，因为现在几乎所有的应用程序都涉及网络操作，而数据经过网络传输时是以字节为单位的，所以所有的数据都必须能够被序列化为字节。在Java中数据要被序列化，必须继承Serializable接口。
 *  用户从浏览器发起一个HTTP请求，存在编码的地方是URL、Cookie、Parameter。服务器端接收到HTTP请求后要解析HTTP，其中URL、Cookie和Post表单参数需要解码，服务器端可能还需要读取数据库中的数据——本地或网络中其他地方的文本文件，这些数据都可能存在编码问题。当Servlet处理完所有请求的数据后，需要将这些数据再编码，通过Socket发送到用户请求的浏览器里，再经过浏览器解码成文本。这个过程如图：  
    ![这里写图片描述][SouthEast 8]
 *  #### URL的编解码 ####
    
     *  浏览器编码URL是将非ASCII字符按照某种编码格式编码成16进制数字后将每个16进制表示的字节前加上“%”。
     *  用户提交一个URL，在这个URL中可能存在中文，因此需要编码。如图为用户提交的一个URL：  
        ![这里写图片描述][SouthEast 9]
     *  以Tomcat作为ServletEngine为例，把它们分别对应到配置文件中：
        
         *  Port对应在Tomcat->server.xml的< Connector port=”8080”/>中配置，而ContextPath在context.xml的< context path=”/examples”>中配置，ServletPath在Web应用的web.xml的< url-pattern>中配置，PathInfo是我们请求的具体的Servlet，QueryString是要传递的参数。
         *  注意这里是在浏览器里直接输入URL，所以是通过Get方法请求的，如果通过POST方法请求，QueryString将通过表单方式提交到服务器端。
            
                <servlet-mapping>
                    <servlet-name>junshangExample</servlet-name>
                    <url-pattern>/servlets/servlet/*</url-pattern>
                </servlet-mapping>
     *  当我们在浏览器直接输入这个URL时，在浏览器端和服务器端会如何编码和解析这个URL呢？  
        
        
         *  浏览器端编码  
            
            
             *  Firefox浏览器的HTTPFox插件测试结果如图：  
                ![这里写图片描述][SouthEast 10]
             *  君、山的编码结果为别是e5 90 9b e5 b1 b1和be fd c9 bd，查阅有关编码的内容可知，PathInfo是UTF编码，而QueryString是GBK编码。
             *  浏览器对PathInfo和QueryString的编码是不一样的，不同浏览器对PathInfo的编码也可能不一样，这就为服务器的解码带来很大困难。
         *  服务器端解析  
            
            
             *  对URL的URI部分进行解码的字符集是在connector的< Connector URIEncoding=”UTF-8”/>中定义的，如果没有定义，那么将默认编码ISO-8859-1解析（ISO-8859-1不包含中文）。所以有中文URL时最好把URIEncodeing设置成UTF-8编码。
             *  对QueryString的解析过程：以GET方式HTTP请求的QueryString与以POST方式HTTP请求的表单参数都是作为Parameters保存的，都通过request.getParameter获取参数值。对它们的解码是在request.getParameter方法第一次被调用时进行的。
             *  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时，如果一定要传递非ASCII字符，可以先将这些字符用org.apache.catalina.util.URLEncoder编码，再添加到Header中，这样在从浏览器到服务器的传递过程中就不会丢失信息了，我们要访问这些项时再按照相应的字符集解码即可。
 *  #### POST表单的编解码 ####
    
     *  POST表单提交的参数的解码是在第一次调用request.getParameter时发生的，POST表单的参数传递方式与QueryString不同，它是通过HTTP的BODY传递到服务端的。
     *  当我们在页面上单击提交按钮时浏览器首先将根据ContentType的Charset编码格式对表单中填入的参数进行编码，然后提交到服务器端，在服务器端同样也是用ContentType中的字符集进行解码的。
     *  这个字符集我们可以通过request.setCharacterEncoding(charset)来设置。
     *  另外，针对multipart/form-data类型的参数，也就是上传的文件编码，同样也使用ContentType定义的字符集编码。注意，上传文件是用字节流的方式传输到服务器的本地临时目录，这个过程并没有涉及字符编码，而真正编码是在将文件内容添加到parameters中时，如果用这个不能编码，则将会使用默认编码ISO-8859-1来编码。
 *  #### HTTP Body的编解码 ####
    
     *  当用户请求的资源已经成功获取后，这些内容将通过Response返回给客户端浏览器。这个过程要先经过编码，再到浏览器进行解码。
     *  编解码字符集可以通过response.serCharacterEncoding来设置，它将会覆盖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来解码。如果也没有定义，那么浏览器将使用默认的编码来解码。
     *  访问数据库都是通过客户端JDBC驱动来完成的，用JDBC来存取数据时要和数据的内置编码保持一致，可以通过设置JDBC URL来指定，如MySQL: url=”jdbc:mysql://localhost:3306/DB?useUnicode=true&characterEncoding=GBK”。

### 七、在JS中的编码问题 ###

*  #### 外部引入JS文件 ####
    
     *  在一个单独的JS文件中包含字符串输入的情况，如：
        
            <html>
            <head>
            <script src="statics/javascript/script.js" charset="gbk"></script>
     *  如果引入一个script.js脚本，这个脚本中有如下代码：
        
            document.write("这是一段中文");
            //document.getElementById('testid').innerHTML = '这是一段中文';
     *  这时如果script没有设置charset，浏览器就会以当前这个页面默认字符集解析这个JS文件。
     *  如果外部的JS文件的编码格式与当前页面的编码格式一致，那么可以不设置这个charset。但是，如果script.js文件与当前页面的编码格式不一致，如script.js是UTF-8编码而页面是GBK编码，上面的代码中的中文输入就会变成乱码。
 *  #### JS的URL编码 ####
    
     *  通过JS发起异步调用的URL默认编码也是受浏览器影响的，如使用原始Ajax的http\_request.open(‘GET’,url,true)调用，URL的编码在IE下是操作系统的默认编码，而在Firefox下则是UTF-8编码。另外，不同JS框架可能对URL的编码处理也不一样。
     *  那么如何处理JS的URL编码问题呢？
     *  1、encodeURI()和decodeURI()  
        
        
         *  JS用来对URL编码的函数，它可以将整个URL中的字符（一些特殊字符除外）进行UTF-8编码，在每个码值前加上”%”。
     *  2、 encodeURIComponent()和decodeURIComponent()  
        
        
         *  encodeURIComponent()这个函数比encodeURI()编码更彻底。通常用于将一个URL当做一个参数放在另一个URL中。
     *  3、 Java与JS编解码问题  
        
        
         *  在Java端处理URL编解码有两个类，分别是 java.net.URLDecoder和 java.net.URLEncoder。这两个类可以将所有”%”加UTF-8码值用UTF-8解码，从而得到原始的字符。
         *  Java端的URLEncode和URLDecoder与前端JS对应的是encodeURIComponent和decodeURIComponent。
         *  注意：前端用encodeURIComponent编码后，到服务端用URLDecoder解码可能会出现乱码，这一定是两个字符编码类型不一致导致的。JS编码默认的是UTF-8编码，而服务器中文解码一段都是GBK或者GB2312，所以用encodeURIComponent编码后是UTF-8，而java用GBK去解码显然不对。
         *  解决的办法是用encodeURIComponent两次编码，如encodeURIComponent(encodeURIComponent(str))。这样在Java端通过request.getParamter()用GBK解码后取得的就是UTF-8编码的字符串，如果Java端需要使用这个字符串，则再用UTF-8解码一次；如果是将这个结果直接通过JS输出到前端，那么这个UTF-8字符串可以直接在前端正常显示。
 *  #### 其他需要编码的地方 ####
    
     *  除了URL和参数编码问题，在服务端还有很多地方可能存在编码，如可能需要读取XML、Velocity模板引擎、JSP或者从数据库读取数据等。
     *  XML文件可以通过设置头来指定编码格式：
        
            <?xml version="1.0" encoding="UTF-8"?>
     *  Velocity模板设置编码的格式：
        
            services.VelocityService.input.encoding=UTF-8
     *  JSP设置编码的格式：
        
            <%@ page contentType="text/html; charset=UTF-8"%>

### 八、常见问题分析 ###

*  在了解了 Java Web 中可能需要编码的地方后，下面看一下，当我们碰到一些乱码时，应该怎么处理这些问题？出现乱码问题唯一的原因都是在 char 到 byte 或 byte 到 char 转换中编码和解码的字符集不一致导致的，由于往往一次操作涉及到多次编解码，所以出现乱码时很难查找到底是哪个环节出现了问题，下面就几种常见的现象进行分析。
    
     *  #### 中文变成了看不懂的字符 ####
     *  例如，字符串“淘！我喜欢！”变成了“Ì Ô £ ¡Î Ò Ï²»¶ £ ¡”编码过程如下图所示  
        ![这里写图片描述][SouthEast 11]
     *  字符串在解码时所用的字符集与编码字符集不一致导致汉字变成了看不懂的乱码，而且是一个汉字字符变成两个乱码字符。
     *  #### 一个汉字变成一个问号 ####
     *  例如，字符串“淘！我喜欢！”变成了“？？？？？？”编码过程如下图所示  
        ![这里写图片描述][SouthEast 12]
     *  将中文和中文符号经过不支持中文的 ISO-8859-1 编码后，所有字符变成了“？”，这是因为用 ISO-8859-1 进行编解码时遇到不在码值范围内的字符时统一用 3f 表示，这也就是通常所说的“黑洞”，所有 ISO-8859-1 不认识的字符都变成了“？”。
     *  #### 一个汉字变成两个问号 ####
     *  例如，字符串“淘！我喜欢！”变成了“？？？？？？？？？？？？”编码过程如下图所示  
        ![这里写图片描述][SouthEast 13]
     *  这种情况比较复杂，中文经过多次编码，但是其中有一次编码或者解码不对仍然会出现中文字符变成“？”现象，出现这种情况要仔细查看中间的编码环节，找出出现编码错误的地方。
     *  #### 一种不正常的正确编码 ####
     *  还有一种情况是在我们通过 request.getParameter 获取参数值时，当我们直接调用下面代码会出现乱码
        
            String value = request.getParameter(name);
     *  但是如果用下面的方式解析时取得的 value 会是正确的汉字字符
        
            String value = String(request.getParameter(name).getBytes("ISO-8859-1"), "GBK");
     *  这种情况是怎么造成的呢？看下图：  
        ![这里写图片描述][SouthEast 14]
     *  这种情况是这样的，ISO-8859-1 字符集的编码范围是 0000-00FF，正好和一个字节的编码范围相对应。这种特性保证了使用 ISO-8859-1 进行编码和解码可以保持编码数值“不变”。虽然中文字符在经过网络传输时，被错误地“拆”成了两个欧洲字符，但由于输出时也是用 ISO-8859-1，结果被“拆”开的中文字的两半又被合并在一起，从而又刚好组成了一个正确的汉字。虽然最终能取得正确的汉字，但是还是不建议用这种不正常的方式取得参数值，因为这中间增加了一次额外的编码与解码，这种情况出现乱码时因为 Tomcat 的配置文件中 useBodyEncodingForURI 配置项没有设置为”true”，从而造成第一次解析式用 ISO-8859-1 来解析才造成乱码的。

### 九、总结 ###

*  要解决中文编码问题，首先要搞清楚哪些地方会引起字符到字节的编码以及字节到字符的解码，最常见的地方就是存储数据到磁盘或者数据要经过网络传输。其次应针对这些地方搞清楚操作这些数据的框架或系统是如何控制编码的。最后正确设置编码格式，避免使用软件默认的或者操作系统平台默认的编码格式。

--------------------

#### 文章整理于《深入分析Java Web技术内幕》 ####

[java_IO]: /images/20220602/da368c40be0d42aa9e2820968a2adcac.png
[SouthEast]: /images/20220602/29beed11a8024ecfb2efa0374fc9f64c.png
[SouthEast 1]: /images/20220602/de09144a3e744d11ace96437293cc3f1.png
[SouthEast 2]: /images/20220602/7dde795fa0a5467c8f27988547a4ffb7.png
[SouthEast 3]: /images/20220602/1eb8747fb8da469c8ba69c01b85c67d0.png
[SouthEast 4]: /images/20220602/5bfa53396fbc4ee3ae18ed2ff8264dd1.png
[SouthEast 5]: /images/20220602/c373f8c4d368494eae63a0ee29a448ad.png
[SouthEast 6]: /images/20220602/6bdc9c7deb184f0fac807810226e11a8.png
[SouthEast 7]: /images/20220602/66ce99ecf1af4c29b2407c31687c496e.png
[SouthEast 8]: /images/20220602/aed19b7285f44fb7b6ab2c6fba50c5f0.png
[SouthEast 9]: /images/20220602/7c414de2840c4618bee1c87e9fd6d0a0.png
[SouthEast 10]: /images/20220602/80874e5b18734489b24a900f519d30e2.png
[SouthEast 11]: /images/20220602/895c27e367884d2085916429461df786.png
[SouthEast 12]: /images/20220602/6e3f74c8269c49d08125f8995dcc8a76.png
[SouthEast 13]: /images/20220602/a5608274b1714bf89b9b4fd223035284.png
[SouthEast 14]: /images/20220602/5a2c4b887b3648ec801a47e01d43c37d.png