Java 웹의 중국어 인코딩 문제에 대한 심층 분석

배경:

코딩 문제는 항상 프로그램 개발자를 괴롭혀 왔습니다. 특히 Java에서는 Java가 크로스 플랫폼 언어이고 다른 플랫폼에서 코딩 간에 전환이 많이 발생하기 때문입니다. 다음으로 Java 인코딩 문제의 근본 원인, Java에서 자주 발생하는 여러 인코딩 형식의 차이점, Java 웹 개발 시 발생할 수 있는 인코딩 문제의 원인 분석을 소개합니다. HTTP 요청의 인코딩 형식을 제어하는 ​​방법, 중국어 인코딩 문제를 방지하는 방법 등

1. 몇 가지 일반적인 인코딩 형식

1.1 인코딩을 해야 하는 이유

• 컴퓨터에서 정보를 저장하는 최소 단위는 1바이트, 즉 8비트이므로 표현할 수 있는 문자의 범위는 0~255이다.

• 
  

• 표현할 수 있는 기호가 너무 많아 1바이트로 다 표현할 수 없습니다.

1.2 번역 방법

컴퓨터는 다양한 번역 방법을 제공하며 일반적인 방법으로는 ASCII, ISO-8859-1, GB2312, GBK, UTF-8, UTF-16 등이 있습니다. 이것들은 모두 변환 규칙을 규정하고 있습니다. 이 규칙에 따라 컴퓨터는 우리의 문자를 정확하게 표현할 수 있습니다. 이러한 인코딩 형식은 아래에 소개되어 있습니다.

• ASCII 코드

  총 128개가 있는데 1바이트의 하위 7비트로 표현되며, 0~31은 줄 바꿈, 캐리지 리턴, 삭제 등의 제어 문자이고, 32~126은 키보드를 통해 입력할 수 있는 인쇄 문자이고, 표시될 수 있습니다.

• 
  

• ISO-8859-1

  128자는 분명히 충분하지 않으므로 ISO 조직은 ASCII를 기반으로 확장되었습니다. ISO-8859-1은 ISO-8859-15로 대부분의 문자를 포함하며 가장 널리 사용됩니다. ISO-8859-1은 여전히 ​​단일 바이트 인코딩으로 총 256자를 나타낼 수 있습니다.

• 
  

• GB2312

  더블바이트 인코딩이며 전체 인코딩 범위는 A1 ~ F7입니다. 여기서 A1 ~ A9는 기호 영역으로 총 682개의 기호가 포함되어 있으며 B0 ~ F7은 한자 영역으로 6763개의 한자가 포함되어 있습니다.

• 
  

• GBk

  GBK는 GB2312의 확장인 "한자 내부 코드 확장 사양"입니다. 인코딩 범위는 8140 ~ FEFE(XX7F 제외)이며 총 21003개의 한자를 나타낼 수 있습니다. GB2312 인코딩을 사용하며 잘못된 문자가 없습니다.

• 
  

• UTF-16

  이는 컴퓨터에서 유니코드 문자에 액세스하는 방법을 구체적으로 정의합니다. UTF-16은 유니코드 변환 형식을 표현하기 위해 2바이트를 사용합니다. 즉, 어떤 문자든 2바이트로 표현합니다. 2바이트는 16비트이므로 UTF-16이라고 합니다. 문자를 나타내는 것이 매우 편리합니다. 2바이트가 하나의 문자를 나타내지 않으므로 문자열 작업이 크게 단순화됩니다.

• 
  

• UTF-8

  UTF-16에서는 2바이트를 일률적으로 사용하여 문자를 표현하는 것이 간단하고 편리하지만, 문자의 대부분을 1바이트로 표현하면 저장 공간이 두 배가 됩니다. 네트워크 대역폭이 제한되면 문제가 발생합니다. 이 경우 네트워크 전송 트래픽이 증가합니다. UTF-8은 가변 길이 기술을 사용합니다. 각 인코딩 영역은 서로 다른 문자 길이를 가지며 1~6바이트까지 다양한 문자를 구성할 수 있습니다.

  UTF-8에는 다음과 같은 인코딩 규칙이 있습니다.

• 1바이트이고 최상위 비트(8번째 비트)가 0이면 ASCII 문자(00~7F)라는 뜻이다.

• 
  

• 1바이트인 경우 11부터 시작하여 연속되는 1의 개수는 해당 문자의 바이트 수를 의미합니다.

• 
  

• 10으로 시작하는 1바이트라면 첫 번째 바이트가 아니라는 뜻이고, 현재 문자의 첫 번째 바이트를 얻으려면 기대해야 한다

• 
  

2. Java 코딩이 필요한 시나리오

​2.1 I/O 작업에 존재하는 인코딩

위에 표시된 대로 Reader 클래스는 Java I/O에서 문자를 읽는 상위 클래스이고, InputStream 클래스는 바이트를 읽는 상위 클래스입니다. 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.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 中如何编解码

　　Java 编码类图

　　首先根据指定的 charsetName 通过 Charset.forName(charsetName) 设置 Charset 类，然后根据 Charset 创建 CharsetEncoder 对象，再调用 CharsetEncoder.encode 对字符串进行编码，不同的编码类型都会对应到一个类中，实际的编码过程是在这些类中完成的。下面是 String. getBytes(charsetName) 编码过程的时序图

　　Java 编码时序图

　　从上图可以看出根据 charsetName 找到 Charset 类，然后根据这个字符集编码生成 CharsetEncoder，这个类是所有字符编码的父类，针对不同的字符编码集在其子类中定义了如何实现编码，有了 CharsetEncoder 对象后就可以调用 encode 方法去实现编码了。这个是 String.getBytes 编码方法，其它的如 StreamEncoder 中也是类似的方式。

　　经常会出现中文变成“？”很可能就是错误的使用了 ISO-8859-1 这个编码导致的。中文字符经过 ISO-8859-1 编码会丢失信息，通常我们称之为“黑洞”，它会把不认识的字符吸收掉。由于现在大部分基础的 Java 框架或系统默认的字符集编码都是 ISO-8859-1，所以很容易出现乱码问题，后面将会分析不同的乱码形式是怎么出现的。

　　几种编码格式的比较

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

　　4、在 Java Web 中涉及的编解码

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

　　一段文本它的实际大小应该怎么计算，我曾经碰到过一个问题：就是要想办法压缩 Cookie 大小，减少网络传输量，当时有选择不同的压缩算法，发现压缩后字符数是减少了，但是并没有减少字节数。所谓的压缩只是将多个单字节字符通过编码转变成一个多字节字符。减少的是 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 发送到用户请求的浏览器里，再经过浏览器解码成为文本。这些过程如下图所示：

　　一次 HTTP 请求的编码示例

　　4.1 URL 的编解码

　　用户提交一个 URL，这个 URL 中可能存在中文，因此需要编码，如何对这个 URL 进行编码？根据什么规则来编码？有如何来解码？如下图一个 URL：

　　上图中以 Tomcat 作为 Servlet Engine 为例，它们分别对应到下面这些配置文件中：

　　Port 对应在 Tomcat 的 中配置，而 Context Path 在 中配置，Servlet Path 在 Web 应用的 web.xml 中的

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

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

　　上图中 PathInfo 和 QueryString 出现了中文，当我们在浏览器中直接输入这个 URL 时，在浏览器端和服务端会如何编码和解析这个 URL 呢？为了验证浏览器是怎么编码 URL 的我选择的是360极速浏览器并通过 Postman 插件观察我们请求的 URL 的实际的内容，以下是 URL：

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

　　君山的编码结果是：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 요청의 form 매개변수는 Parameter로 저장되며, request.getParameter를 통해 매개변수 값을 얻습니다. request.getParameter 메소드가 처음 호출될 때 디코딩됩니다. request.getParameter 메소드가 호출되면 org.apache.catalina.connector.Request의parseParameters 메소드를 호출합니다. 이 메소드는 GET 및 POST에 의해 전달된 매개변수를 디코딩하지만 해당 디코딩 문자 세트는 다를 수 있습니다. POST 형식의 디코딩은 나중에 소개됩니다. QueryString의 디코딩 문자 집합은 어디에 정의되어 있습니까? HTTP 헤더를 통해 서버로 전송되며 URL에도 포함되어 있습니다. URI의 디코딩 문자 집합과 동일합니까? PathInfo 및 QueryString에 대해 서로 다른 인코딩 형식을 사용하는 이전 브라우저에서 디코딩된 문자 집합이 확실히 일관성이 없을 것이라고 추측할 수 있습니다. 실제로 QueryString의 디코딩 문자 집합은 헤더의 ContentType에 정의된 Charset이거나 기본 ISO-8859-1입니다. ContentType에 정의된 인코딩을 사용하려면 커넥터의 useBodyEncodingForURI가 true로 설정됩니다. 이 구성 항목의 이름은 다소 혼란스럽습니다. 전체 URI를 디코딩하는 데 BodyEncoding을 사용하지 않고 QueryString을 디코딩하는 데만 BodyEncoding을 사용합니다.

위의 URL 인코딩 및 디코딩 프로세스로 판단하면 상대적으로 복잡하며 인코딩 및 디코딩은 애플리케이션에서 완전히 제어할 수 없습니다. 따라서 애플리케이션의 URL에 ASCII가 아닌 문자를 사용하지 않도록 해야 합니다. 매우 어려울 수 있습니다. 물론 서버 측의 에서 두 매개변수 URIEncoding 및 useBodyEncodingForURI를 설정하는 것이 가장 좋습니다.

4.2 HTTP 헤더 인코딩 및 디코딩

클라이언트가 HTTP 요청을 시작할 때 위의 URL 외에도 헤더에 Cookie, RedirectPath 등과 같은 다른 매개변수를 전달할 수도 있습니다. 이러한 사용자 설정 값에는 Tomcat이 이를 어떻게 디코딩하는지에 대한 인코딩 문제가 있을 수도 있습니다. ?

요청된 Header 항목이 디코딩되지 않으면 MessageBytes의 toString 메소드가 호출되어 바이트에서 문자로 변환되는 기본 인코딩도 ISO-8859입니다. -1. 헤더의 다른 디코딩 형식을 설정할 수 없으므로 헤더에서 ASCII가 아닌 문자의 디코딩을 설정하면 확실히 문자가 깨집니다.

헤더를 추가할 때도 마찬가지입니다. 헤더에 ASCII가 아닌 문자를 전달하지 마십시오. 이를 전달해야 하는 경우 먼저 이러한 문자를 org.apache.catalina.util.URLEncoder로 인코딩한 다음 헤더에 추가할 수 있습니다. 이렇게 하면 브라우저에서 서버로 전송되는 동안 정보가 손실되지 않습니다. 이러한 항목에 액세스하려고 할 때 해당 문자 집합에 따라 정보를 디코딩하면 좋을 것입니다.

4.3 POST 형식의 코딩 및 디코딩

앞서 언급했듯이 POST 폼에서 제출한 매개변수의 디코딩은 request.getParameter가 처음 호출될 때 발생하며 POST 폼 매개변수 전송 방법은 HTTP의 BODY를 통해 서버에 전달됩니다. 페이지에서 제출 버튼을 클릭하면 브라우저는 먼저 ContentType의 Charset 인코딩 형식에 따라 양식에 채워진 매개변수를 인코딩한 다음 서버에 제출합니다. 또한 서버는 디코딩을 위해 ContentType의 문자 세트를 사용합니다. 따라서 POST 형식을 통해 제출된 매개변수는 일반적으로 문제가 발생하지 않으며, 이 문자 세트 인코딩은 자체적으로 설정하며 request.setCharacterEncoding(charset)을 통해 설정할 수 있습니다.

또한 multipart/form-data 유형 매개변수의 경우, 즉 업로드된 파일 인코딩도 ContentType에서 정의한 문자 세트 인코딩을 사용합니다. 업로드된 파일은 서버의 로컬 임시 디렉터리에 바이트 단위로 전송된다는 점에 유의할 필요가 있습니다. 이 프로세스에는 문자 인코딩이 포함되지 않지만 실제 인코딩은 파일 콘텐츠를 매개변수에 추가하는 것입니다. 이 인코딩을 사용하여 인코딩할 수 없는 경우 기본 인코딩 ISO-8859-1이 사용됩니다.

4.4 HTTP BODY 인코딩 및 디코딩

사용자가 요청한 리소스가 성공적으로 획득되면 해당 콘텐츠는 응답을 통해 클라이언트 브라우저로 반환됩니다. 이 프로세스는 먼저 브라우저에서 인코딩된 다음 디코딩되어야 합니다. 이 프로세스의 인코딩 및 디코딩 문자 세트는 response.setCharacterEncoding을 통해 설정할 수 있으며, 이는 request.getCharacterEncoding 값을 재정의하고 브라우저가 반환된 소켓 스트림을 수신하면 헤더의 Content-Type을 통해 클라이언트에 반환됩니다. 반환된 HTTP 헤더의 Content-Type이 문자 세트를 설정하지 않은 경우 브라우저는

銆€銆€4.5 鍏跺畠闇€瑕佺紪鐮佺殑鍦版柟

銆€銆€闄や簡 URL 鍜屽弬鏁扮紪鐮侀棶棰樺

위 내용은 Java 웹의 중국어 인코딩 문제에 대한 심층 분석의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!