Java码农的福音：再也不怕乱码了

即便是Java这样成熟的语言，开发者们也常常会遇到一个恼人的问题——乱码。

本文将深入探讨乱码的根本原因，并针对Java开发中的乱码场景提出有效的解决方案，辅以实战代码，让Java程序员从此告别乱码困扰。

一，字符集的故事

1，计算机不懂字符

敲代码时，键盘上输入的是字符，屏幕上显示的是字符，计算机的大脑CPU根本不知道字符是什么，CPU能处理的只有二进制，即数字0和1。

在这里插入图片描述
键盘上敲下的字符并不会直接被CPU处理，而是转换为一个二进制，CPU将这个二进制交给GPU，GPU根据❶二进制对应的数字从❷字库中找到对应的字符，以点阵的方式显示在屏幕上。在计算机内部，字符始终是二进制的形式。

上述过程有两个关键点：
❶二进制对应的数字，是字符的编号，称之为码点
❷字库包含所有字符及其对应的码点，称之为字符编码集

2，4个基本概念

为了更清晰的认知字符的原理，出来上述码点和字符编码集之外，还有2个概念，总共是4个基本概念：

字符集合（Character set）：是各种文字和符号的总称，包括各国家文字、标点符号、图形符号、数字等，简单理解就是一个字库，与计算机以及编码无关。
字符编码集（Coded character set）：是一组字符对应的编码（即数字），为字符集合中的每一个字符给予一个数字，如 Unicode 为每一个字符分配一个唯一的码点与之一一对应。如下图所示：

在这里插入图片描述

字符编码（Character Encoding）：简单理解就是一个映射关系，将字符集对应的码点映射为一个个二进制序列，从而使得计算机可以存储和处理。常见的编码方式有 ASCII 编码、ISO-8859-1(不支持中文)、GBK、GB2312（中国编码，支持中文）、UTF-8 等等。字符编码的本质就是把码点通过一个映射函数转换为另一个数字。

这里大家要思考一个问题，码点不就是一个数字吗？直接转换为二进制不就行了吗，为什么又要转换为另一个数字呢？
①答案要从字符集的发展历史说起，因为计算机产生在英语国家，字符比较少，所以只需要一个字节就可以表示所有字符，这个表示所有英文世界的字符就是大名鼎鼎的ASCII字符编码集。
②当计算机出现在其他国家后，比如中国，ASCII字符编码集无法表示中文字符，因为其最多只能表示128个字符，而中文字符有几万个。所以非英语国家也各自制定了字符集。如果中国大陆的简体字GBK字符编码集，港澳台的繁体字Big5字符编码集，这样全世界就出现了各种各样的字符编码集。
③后来，一种包含全世界所有字符的字符编码集出现了，即UTF-32，这个字符集用4个字节来表示一个字符，4个字节最多能容纳超过42亿个字符，远远超过了实际需要。但是这个字符集会浪费大量的存储空间，如对于英文字符，本来只要1个字节，但是使用UTF-32，需要4个字节，扩大了4倍。
④解决这个问题的最佳方案是弹性灵活的根据码点选择不同的编码方式，比如英文字母用一个字节的二进制，中文字母用2个几个的二进制，某些特殊符号用3个或者4个字节存储。此时，情况就变得复杂起来，不能直接用码点对应的二进制来存储了，因为这个二进制不仅要包含码点信息，还要包含二进制的长度信息，因为这个二进制是变长的，可能是一个字节，也可能是2、3、4个字节。于是，字符编码就出现了。

字符集（Charset）：包括编码字符集和字符编码，如 ASCII 字符集、ISO-8859-X、GB2312 字符集（简中）、BIG5 字符集（繁中）、GB18030 字符集、Shift-JIS 等，即下文中提到的字符集。多种多样的字符集是出现乱码的罪魁祸首。

二，为什么会乱码及其解决方案

1，乱码案例

尽管有UTF-8字符集，但因为各种原因，各个字符集仍然有广泛的应用。于是，乱码的出现了。

比如，大陆的兄弟写了一个文本文件，因为操作系统的原因，默认用GBK保存，这个文件通过邮件发送给了香港的同学，香港的计算机操作系统默认使用Big5字符集，香港同学打开时，出现了乱码。
在这里插入图片描述
根本原因是，相同的码点在GBK字符集和Big5字符集表示不同的字符，比如GBK下“兄”的码点是48019，但是在Big5字符集下，并没有这个码点，就会出现乱码。

总结乱码的一般过程：
①写文件使用字符集A进行编码；
②读文件使用字符集B进行解码；

2，乱码的本质：字符集的牛唇不对马嘴

出现乱码，最根本的原因是编码和解码使用了不同的字符集。

3，乱码的解决方案

知道了根本原因之后，解决问题就有了思路，解码和编码使用相同的字符集就可以解决乱码问题。

虽然，乱码的表现方式各种各样，需要我们在处理具体的乱码场景时不断积累经验，但万变不离其宗，根本原因还是编码、解码的字符集不一致导致的。

四，Java乱码的常见场景及解决方案

Java内部使用Unicode（通常是UTF-16）作为字符集，这意味着Java源代码、字符串字面量、以及char类型的变量都默认使用Unicode编码。但在输入输出、网络传输、文件操作等环节，Java需要与外部环境交互，这就容易因为编码不一致而导致乱码。

1. 控制台输出乱码

场景：在IDE（如Eclipse、IntelliJ IDEA）中运行Java程序，控制台输出中文时出现乱码。

原因：IDE使用的默认字符编码与Java虚拟机（JVM）的默认编码不一致。

解决方案：

修改IDE设置：在IDE中设置项目的字符编码为UTF-8。
- 例如，在Eclipse中，可以通过右击项目 > Properties > Resource > Text file encoding 设置为UTF-8。

启动参数设置：通过JVM参数指定编码。

// 在程序启动参数中添加以下内容
-Dfile.encoding=UTF-8

2. 文件读写乱码

场景：读取或写入含有中文的文本文件时出现乱码。

原因：文件的实际编码与程序中指定的编码不匹配。

解决方案：

明确指定编码：使用InputStreamReader和OutputStreamWriter时显式指定字符编码。

// 写文件示例
try (FileOutputStream fos = new FileOutputStream("test.txt");
     OutputStreamWriter osw = new OutputStreamWriter(fos, StandardCharsets.UTF_8)) {
    osw.write("你好，世界！");
}

// 读文件示例
try (FileInputStream fis = new FileInputStream("test.txt");
     InputStreamReader isr = new InputStreamReader(fis, StandardCharsets.UTF_8)) {
    char[] buffer = new char[1024];
    int len;
    while ((len = isr.read(buffer)) != -1) {
        System.out.print(new String(buffer, 0, len));
    }
}

3. 网络传输乱码

场景：在进行HTTP请求或响应时，中文参数或内容出现乱码。

原因：HTTP协议默认使用ISO-8859-1编码，不支持中文等多字节字符。

解决方案：

URL编码与解码：对中文参数进行URL编码和解码。

// 编码
String encodedParam = URLEncoder.encode("中文参数", StandardCharsets.UTF_8);

// 解码
String decodedParam = URLDecoder.decode(encodedParam, StandardCharsets.UTF_8);

设置Content-Type：在HTTP请求或响应头中指定正确的字符编码。

对于客户端请求：

HttpURLConnection connection = (HttpURLConnection) url.openConnection();
connection.setRequestProperty("Content-Type", "application/x-www-form-urlencoded; charset=utf-8");