코딩 문제는 항상 프로그램 개발자를 괴롭혀 왔습니다. 특히 Java에서는 Java가 크로스 플랫폼 언어이고 다른 플랫폼에서 코딩 간에 전환이 많이 발생하기 때문입니다. 다음으로 Java 인코딩 문제의 근본 원인, Java에서 자주 발생하는 여러 인코딩 형식의 차이점, Java 웹 개발 시 발생할 수 있는 인코딩 문제의 원인 분석을 소개합니다. HTTP 요청의 인코딩 형식을 제어하는 방법, 중국어 인코딩 문제를 방지하는 방법 등
컴퓨터에서 정보를 저장하는 최소 단위는 1바이트, 즉 8비트이므로 표현할 수 있는 문자의 범위는 0~255이다.
표현할 수 있는 기호가 너무 많아 1바이트로 다 표현할 수 없습니다.
컴퓨터는 다양한 번역 방법을 제공하며 일반적인 방법으로는 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바이트라면 첫 번째 바이트가 아니라는 뜻이고, 현재 문자의 첫 번째 바이트를 얻으려면 기대해야 한다
위에 표시된 대로 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 문자 집합을 지정하는 데 주의를 기울이는 한 일반적으로 잘못된 코드 문제는 발생하지 않습니다.
메모리의 문자에서 바이트로 데이터 유형 변환을 수행합니다.
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);...
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 在编码效率上和编码安全性上做了平衡，是理想的中文编码方式。
对于使用中文来说，有 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 请求的编码示例
用户提交一个 URL，这个 URL 中可能存在中文，因此需要编码，如何对这个 URL 进行编码？根据什么规则来编码？有如何来解码？如下图一个 URL：
上图中以 Tomcat 作为 Servlet Engine 为例，它们分别对应到下面这些配置文件中：
Port 对应在 Tomcat 的
<servlet-mapping>
<servlet-name>junshanExample</servlet-name>
<url-pattern>/servlets/servlet/*</url-pattern>
</servlet-mapping>
上图中 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 的
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에 정의된 인코딩을 사용하려면 커넥터의
위의 URL 인코딩 및 디코딩 프로세스로 판단하면 상대적으로 복잡하며 인코딩 및 디코딩은 애플리케이션에서 완전히 제어할 수 없습니다. 따라서 애플리케이션의 URL에 ASCII가 아닌 문자를 사용하지 않도록 해야 합니다. 매우 어려울 수 있습니다. 물론 서버 측의
클라이언트가 HTTP 요청을 시작할 때 위의 URL 외에도 헤더에 Cookie, RedirectPath 등과 같은 다른 매개변수를 전달할 수도 있습니다. 이러한 사용자 설정 값에는 Tomcat이 이를 어떻게 디코딩하는지에 대한 인코딩 문제가 있을 수도 있습니다. ?
요청된 Header 항목이 디코딩되지 않으면 MessageBytes의 toString 메소드가 호출되어 바이트에서 문자로 변환되는 기본 인코딩도 ISO-8859입니다. -1. 헤더의 다른 디코딩 형식을 설정할 수 없으므로 헤더에서 ASCII가 아닌 문자의 디코딩을 설정하면 확실히 문자가 깨집니다.
헤더를 추가할 때도 마찬가지입니다. 헤더에 ASCII가 아닌 문자를 전달하지 마십시오. 이를 전달해야 하는 경우 먼저 이러한 문자를 org.apache.catalina.util.URLEncoder로 인코딩한 다음 헤더에 추가할 수 있습니다. 이렇게 하면 브라우저에서 서버로 전송되는 동안 정보가 손실되지 않습니다. 이러한 항목에 액세스하려고 할 때 해당 문자 집합에 따라 정보를 디코딩하면 좋을 것입니다.
앞서 언급했듯이 POST 폼에서 제출한 매개변수의 디코딩은 request.getParameter가 처음 호출될 때 발생하며 POST 폼 매개변수 전송 방법은 HTTP의 BODY를 통해 서버에 전달됩니다. 페이지에서 제출 버튼을 클릭하면 브라우저는 먼저 ContentType의 Charset 인코딩 형식에 따라 양식에 채워진 매개변수를 인코딩한 다음 서버에 제출합니다. 또한 서버는 디코딩을 위해 ContentType의 문자 세트를 사용합니다. 따라서 POST 형식을 통해 제출된 매개변수는 일반적으로 문제가 발생하지 않으며, 이 문자 세트 인코딩은 자체적으로 설정하며 request.setCharacterEncoding(charset)을 통해 설정할 수 있습니다.
또한 multipart/form-data 유형 매개변수의 경우, 즉 업로드된 파일 인코딩도 ContentType에서 정의한 문자 세트 인코딩을 사용합니다. 업로드된 파일은 서버의 로컬 임시 디렉터리에 바이트 단위로 전송된다는 점에 유의할 필요가 있습니다. 이 프로세스에는 문자 인코딩이 포함되지 않지만 실제 인코딩은 파일 콘텐츠를 매개변수에 추가하는 것입니다. 이 인코딩을 사용하여 인코딩할 수 없는 경우 기본 인코딩 ISO-8859-1이 사용됩니다.
사용자가 요청한 리소스가 성공적으로 획득되면 해당 콘텐츠는 응답을 통해 클라이언트 브라우저로 반환됩니다. 이 프로세스는 먼저 브라우저에서 인코딩된 다음 디코딩되어야 합니다. 이 프로세스의 인코딩 및 디코딩 문자 세트는 response.setCharacterEncoding을 통해 설정할 수 있으며, 이는 request.getCharacterEncoding 값을 재정의하고 브라우저가 반환된 소켓 스트림을 수신하면 헤더의 Content-Type을 통해 클라이언트에 반환됩니다. 반환된 HTTP 헤더의 Content-Type이 문자 세트를 설정하지 않은 경우 브라우저는
除了 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"%>
访问数据库都是通过客户端 JDBC 驱动来完成，用 JDBC 来存取数据要和数据的内置编码保持一致，可以通过设置 JDBC URL 来制定如 MySQL：url="jdbc:mysql://localhost:3306/DB?useUnicode=true&characterEncoding=GBK"。
下面看一下，当我们碰到一些乱码时，应该怎么处理这些问题？出现乱码问题唯一的原因都是在 char 到 byte 或 byte 到 char 转换中编码和解码的字符集不一致导致的，由于往往一次操作涉及到多次编解码，所以出现乱码时很难查找到底是哪个环节出现了问题，下面就几种常见的现象进行分析。
例如，字符串“淘！我喜欢！”变成了“Ì Ô £ ¡Î Ò Ï²»¶ £ ¡”编码过程如下图所示：
字符串在解码时所用的字符集与编码字符集不一致导致汉字变成了看不懂的乱码，而且是一个汉字字符变成两个乱码字符。
例如，字符串“淘！我喜欢！”变成了“？？？？？？”编码过程如下图所示:
将中文和中文符号经过不支持中文的 ISO-8859-1 编码后，所有字符变成了“？”，这是因为用 ISO-8859-1 进行编解码时遇到不在码值范围内的字符时统一用 3f 表示，这也就是通常所说的“黑洞”，所有 ISO-8859-1 不认识的字符都变成了“？”。
例如，字符串“淘！我喜欢！”变成了“？？？？？？？？？？？？”编码过程如下图所示:
这种情况比较复杂，中文经过多次编码，但是其中有一次编码或者解码不对仍然会出现中文字符变成“？”现象，出现这种情况要仔细查看中间的编码环节，找出出现编码错误的地方。
还有一种情况是在我们通过 request.getParameter 获取参数值时，当我们直接调用
String value = request.getParameter(name); 会出现乱码，但是如果用下面的方式
String value = String(request.getParameter(name).getBytes(" ISO-8859-1"), "GBK");
解析时取得的 value 会是正确的汉字字符，这种情况是怎么造成的呢？
看下如所示：
这种情况是这样的，ISO-8859-1 字符集的编码范围是 0000-00FF，正好和一个字节的编码范围相对应。这种特性保证了使用 ISO-8859-1 进行编码和解码可以保持编码数值“不变”。虽然中文字符在经过网络传输时，被错误地“拆”成了两个欧洲字符，但由于输出时也是用 ISO-8859-1，结果被“拆”开的中文字的两半又被合并在一起，从而又刚好组成了一个正确的汉字。虽然最终能取得正确的汉字，但是还是不建议用这种不正常的方式取得参数值，因为这中间增加了一次额外的编码与解码，这种情况出现乱码时因为 Tomcat 的配置文件中 useBodyEncodingForURI 配置项没有设置为”true”，从而造成第一次解析式用 ISO-8859-1 来解析才造成乱码的。
本文首先总结了几种常见编码格式的区别，然后介绍了支持中文的几种编码格式，并比较了它们的使用场景。接着介绍了 Java 那些地方会涉及到编码问题，已经 Java 中如何对编码的支持。并以网络 I/O 为例重点介绍了 HTTP 请求中的存在编码的地方，以及 Tomcat 对 HTTP 协议的解析，最后分析了我们平常遇到的乱码问题出现的原因。
요약하자면, 중국어 문제를 해결하려면 먼저 문자-바이트 인코딩과 바이트-문자 디코딩이 어디서 발생하는지 파악해야 합니다. 가장 일반적인 장소는 데이터를 디스크에 읽고 저장하는 곳이거나 네트워크를 통해 전달되는 데이터입니다. . 전염. 그런 다음 이러한 위치에 대해 이러한 데이터를 작동하는 프레임워크 또는 시스템이 인코딩을 제어하고, 인코딩 형식을 올바르게 설정하고, 소프트웨어 또는 운영 체제 플랫폼의 기본 인코딩 형식을 사용하지 않는 방법을 파악하십시오.
참고: 기사의 대부분은 "Insider Java Web Technology" 책의 세 번째 장을 참조합니다. 재인쇄할 때는 출처를 꼭 밝혀주세요.
위 내용은 Java 웹의 중국어 인코딩 문제에 대한 심층 분석의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
