Java读写文件时的GBK和UTF8转换问题-Toy模板网

这篇具有很好参考价值的文章主要介绍了Java读写文件时的GBK和UTF8转换问题。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

问题引入

文件中的文本以UTF-8的编码方式存储，在Java程序中以GBK的编码方式从文件中读入，最后再将读入的内容转换为UTF-8编码，即UTF-8 --> GBK --> UTF-8。这种操作方式能正确读入文件中的内容吗？

背景知识

因为本文主要讨论不同的编码之间的转换问题，所以有必要先介绍一下文中会用到的几种编码方式。

编码和解码

将某个字符映射成计算机能存储和处理的二进制数的过程称为编码，比如字符A的ASCII编码为b0100 0001，我们通常用十六进制来表示成0x41；将某个二进制数映射成人类可读的字符的过程称为解码，编码的逆过程就是解码。

UTF-8

UTF-8编码兼容ASCII编码，也就是说任何一个ASCII编码的字符，也是UTF-8编码的字符。比如字符A的ASCII编码的十六进制表示为0x41，占1个字节，那么字符A的UTF-8编码也是0x41，占1个字节。对于一个汉字来说，需要用三个字节存储UTF-8编码，大家可以通过UTF8在线网站获得任意字符的UTF-8编码。

GBK

和UTF-8一样，GBK也是兼容ASCII编码的。对于一个汉字来说，需要用两个字节存储GBK编码，大家可以通过GBK在线网站获得任意汉字的GBK编码。

Unicode

和UTF-8一样，Unicode也是兼容ASCII编码的。对于一个汉字来说，需要用两个字节存储Unicode编码，大家可以通过Unicode在线网站获得任意汉字的Unicode编码。也可以通过GBK2Unicode在线网站获得某个GBK编码对应的Unicode编码。

实验与分析

为了回答上面的问题，我编写了两种不同的文本内容，也就是后面的实验设置1和实验设置2，以此来看一下对于不同类型的文本内容，采用上述方式是否都可以正确的读取。因为Java中对文本文件的读取主要有两种类型：读入到字符串和读入到字符数组，因此我分别实现了这两种读取方式，也就是后面的实验代码1和实验代码2，以此来探究不同的读取方式对实验结果是否有影响。

实验环境

JDK：16
OS：Monterey 12.2.1
系统默认编码：UTF-8

实验代码1

//将文件中的内容读入到字符串
try(BufferedReader br = new BufferedReader(new FileReader(fileName, Charset.forName("GBK")))){
    String content = br.readLine();
    byte[] bytes = content.getBytes("GBK");
    String str = new String(bytes, "UTF-8");
    System.out.println(str);
}

实验代码2

//将文件中的内容读入到字符数组
try(Reader reader = new FileReader(fileName, Charset.forName("GBK"))){
    char[] content = new char[2];
    reader.read(content);
    String str = new String(content);
    byte[] bytes = str.getBytes("GBK");
    str = new String(bytes, "UTF-8");
    System.out.println(str);
}

实验设置1

文件的编码方式为UTF8，文件的内容为：

你

此设置下，文件中只有一个用UTF-8编码的汉字你。我们知道，在UTF-8编码下，每个汉字占3个字节，大家可以自行检查一下文件的大小是否为3字节，以避免因为其它的字符（如空格等）影响复现实验的效果。

在第一个份代码中（将文件内容读入到字符串），通过单步调试可以看到，content的内容为浣�，和文件中的内容不一样，而且看起来有点像乱码。继续单步运行，将字符串按照GBK的编码方式转换为字节数组。此处需要指定编码方式为GBK的原因是，我们从文件中读取的时候指定了GBK的解码方式，因此，想要转换成字节数组也得按照GBK的方式编码。完成转换之后，得到的字节数组bytes的大小为3。现在我们已经有了GBK编码之后的字节数组bytes了，最后将其按照UFT8的方式解码成字符串，得到�?。看样子我们没能正确的读取到文本文件的内容，下面分析一下原因。

汉字你的UTF8编码可以通过之前提到的在线网站得到，其为e4 bd a0，因为Java程序采用GBK的解码方式读取文件，所以当读到第一个字节e4时，判断出还需要再读一个字节才能构成完整的编码，因此现在读入的内容是e4 bd，通过在线网站知道它对应于汉字浣。因为Java程序内部采用Unicode编码存储字符串，所以需要将浣转换为Unicode编码，通过在线网站可知它对应的Unicode编码为6d 63。要注意，实际上Java程序并不需要先把GBK码解码成字符，然后再根据字符做Unicode编码，而是直接由GBK码映射到表示相同字符的Unicode码。Java程序继续读入第三个字节a0，同时判断出a0不是一个合法的GBK编码，但是此时已经读到文件的末尾了，无法继续读入下一个字节。对于此种情况，Java会将非法的GBK编码映射成默认的Unicode码ff fd，此编码对应的字符是�。可以看到，这种映射具有不可逆性，我们无法从ff fd映射回非法的GBK码，也就是说，这种映射会改变我们的原始数据。分析到这儿，我们应该知道，字符串变量content在内存中的实际内容为6d 63 ff fd（不去考虑大端小端的问题），共四个字节，表示两个字符浣和�。

接下来将字符串变量content按照GBK的编码方式转换成字节数组。前面说过，content的内容为浣�，首先转换第一个字符浣，其对应的GBK编码为e4 bd。接下来转换第二个字符�，很遗憾的是，此字符并没有被GBK收录，也就是说这个字符没有对应的GBK编码，此种情况下会将其转换为GBK编码3f，它对应的字符是?。因此，字节数组bytes = [e4, bd, 3f]。

最后一步将字节数组按照UTF-8的方式解码。当遇到第一个字节e4时，发现它不是一个合法的UTF-8编码，因此继续读入下一个字节，然后发现e4 bd也不是一个合法的UTF-8编码，继续读入，发现e4 bd 3f仍然不是一个合法的编码，但是已没有更多的字节可以读了。不过UTF-8解码器发现e4 bd 3f虽然不是一个合法的编码，但3f却是一个合法的UTF-8编码，它对应于字符?。此时解码器会选择将3f解码为?，而认为e4 bd是一个错误的编码，并将其解码为默认字符�。因此，最终得到的解码结果为�?。

以上是对运行实验代码1时的分析，也就是将文本内容读入到字符串中的情况。对于将文本内容读入到字符数组的情况，分析过程和实验代码1差不多，只是在某些地方有细微的差别。下面简要的分析一下运行实验代码2时的情况。

文件中存储的数据仍然是e4 bd a0，对e4 bd按照GBK解码得到浣，因为Java中的char类型也是和String类型一样，按照Unicode的编码方式存储，浣对应的Unicode码为6d 63，所以字符数组中的第一个字符在内存中实际存储的是6d 63。接下来对a0按照GBK解码，如前所述，a0不是一个合法的GBK码，对于此种情况，字符数组会舍弃非法的编码，因此字符数组的第二个字符仍然是默认的00 00。下一步中的将字符数组变为字符串的目的是方便转换为字节数组，经过转换之后得到的字节数组bytes = [e4, bd, 00, 00]。最后一步将字节数组按照UTF-8的解码方式转化成字符串，最终得到的解码结果为�。

实验设置2

文件的编码方式为UTF8，文件的内容为：

你A

首先分析代码1。文件内容你A的UTF-8编码为e4 bd a0 41，按照GBK解码得到浣燗，其对应的Unicode码为6d 63 71 d7。因为字符串使用Unicode编码进行存储，所以content在内存中存储的内容为6d 63 71 d7。之后对content按GBK编码获得对应的字节数组，这就又回到了e4 bd a0 41，即bytes = [e4, bd, a0, 41]。最后对此字节数组按UTF-8解码得到你A。

对于代码2的分析，因为e4 bd和a0 41都是合法的GBK编码，所以不存在丢弃数据的问题，那么代码2的分析就和代码1的分析完全相同。