Java GBK中文乱码问题分析
博客专区 > skyshitt 的博客 > 博客详情
Java GBK中文乱码问题分析
skyshitt 发表于2年前
Java GBK中文乱码问题分析
  • 发表于 2年前
  • 阅读 3384
  • 收藏 127
  • 点赞 14
  • 评论 14

腾讯云 学生专属云服务套餐 10元起购>>>   

摘要: Java GBK中文乱码问题分析

在io相关的操作中经常会出现乱码问题


比如在一个txt文件中按GBK编码保存内容"淘!我喜欢!"

然后用RandomAccessFile类读取并打印一行。

RandomAccessFile raf = new RandomAccessFile("D:\\1.txt","r");
System.out.print(raf.readLine());

打印结果显示乱码:


在网上查询到加入相关编码解码操作后可以解决该问题

RandomAccessFile raf = new RandomAccessFile("D:\\1.txt","r");
System.out.print(new String(raf.readLine().getBytes("ISO-8859-1"),"gbk"));


问题:

在这个过程中发生了什么?


要解答这个问题首先要知道编码和解码的概念以及产生的原因:

为什么要编码

不知道大家有没有想过一个问题,那就是为什么要编码?我们能不能不编码?要回答这个问题必须要回到计算机是如何表示我们人类能够理解的符号的,这些符号也就是我们人类使用的语言。由于人类的语言有太多,因而表示这些语言的符号太多,无法用计算机中一个基本的存储单元—— byte 来表示,因而必须要经过拆分或一些翻译工作,才能让计算机能理解。我们可以把计算机能够理解的语言假定为英语,其它语言要能够在计算机中使用必须经过一次 翻译,把它翻译成英语。这个翻译的过程就是编码。所以可以想象只要不是说英语的国家要能够使用计算机就必须要经过编码。这看起来有些霸道,但是这就是现 状,这也和我们国家现在在大力推广汉语一样,希望其它国家都会说汉语,以后其它的语言都翻译成汉语,我们可以把计算机中存储信息的最小单位改成汉字,这样 我们就不存在编码问题了。

所以总的来说,编码的原因可以总结为:

    1.计算机中存储信息的最小单元是一个字节即 8 个 bit,所以能表示的字符范围是 0~255 个。

    2.人类要表示的符号太多,无法用一个字节来完全表示。

    3.要解决这个矛盾必须需要一个新的数据结构 char,从 char 到 byte 必须编码。

名词解释:

解码:将byte数组转为char数组。

编码:将char数组转为byte数组。


计算机存储的基本单位是byte,但打开一个文件时文件编辑器已经做了解码的工作。

以下为解码过程描述

文件实际存储的内容是(以下为16进制):

打开文件后看到的内容为

需要详细说明以下代码的处理过程

RandomAccessFile raf= new RandomAccessFile("D:\\1.txt","r");
System.out.print(raf.readLine());

首先看一下java.io.RandomAccessFile#readLine方法的源码

public final String readLine() throws IOException {
        StringBuffer input = new StringBuffer();
        int c = -1;
        boolean eol = false;
        while (!eol) {
            switch (c = read()) {
            case -1:
            case '\n':
                eol = true;
                break;
            case '\r':
                eol = true;
                long cur = getFilePointer();
                if ((read()) != '\n') {
                    seek(cur);
                }
                break;
            default:
                input.append((char)c);
                break;
            }
        }
        if ((c == -1) && (input.length() == 0)) {
            return null;
        }
        return input.toString();
    }

主要关注read()部分和(char)c,read()是一个本地方法,作用是从文件中读取一个byte字节。

(char)c是将变量c从byte类型转换为char类型,这是一个解码操作。

问题:此处是以什么格式进行解码?

解码格式是ISO-8859-1

raf.readLine()的处理过程如下


那么

new String(raf.readLine().getBytes("ISO-8859-1"),"gbk")

这行代码做了什么

首先readLine()按行一字节一字节地读取文件中的数据,并且按ISO-8859-1进行解码拼成char数组,然后getBytes("ISO-8859-1")对拼成后的char数组按ISO-8859-1进行编码获取byte数组,最后new String(string,"gbk")对编码后的byte数组用gbk格式进行解码成char数组。


参考资料:深入分析 Java 中的中文编码问题


遗留问题:

1、如何避免重复转码。

2、RandomAccessFile的readLine()效率非常低,如何提高效率。

共有 人打赏支持
粉丝 2
博文 1
码字总数 1037
评论 (14)
jianglibo
read()根本无需涉及编码问题。你用StringBuffer去保存,已经误用了。用byte[]才是正道。说起这个,我的编码检测代码对这个编码问题有比较深入的表达。http://git.oschina.net/jianglibo/char-encode-detector
jianglibo
想查看一个文件的内容,必须知道文件的编码格式。一个文件就是一个byte[],两者的内容是等价的,byte[]可能是gbk的字串,可能是mp3,也可能是jpg.
一堆BUG
2、RandomAccessFile的readLine()效率非常低,如何提高效率。
可以参考一下IBM文档
花1K内存实现高效I/O的RandomAccessFile类
https://www.ibm.com/developerworks/cn/java/l-javaio/
Feng_Yu

引用来自“jianglibo”的评论

想查看一个文件的内容,必须知道文件的编码格式。一个文件就是一个byte[],两者的内容是等价的,byte[]可能是gbk的字串,可能是mp3,也可能是jpg.
GBK,GB2312这两编码有何不同,以及GB18030?一个是另一个的子集么?实际使用的时候我发现这两个编码几乎通用。 在windows的python编码甚至还有cp936来指代GBK的。实在对这些繁杂的编码有些头大。期待UTF-8大一统的美好世界
jianglibo

引用来自“jianglibo”的评论

想查看一个文件的内容,必须知道文件的编码格式。一个文件就是一个byte[],两者的内容是等价的,byte[]可能是gbk的字串,可能是mp3,也可能是jpg.

引用来自“Feng_Yu”的评论

GBK,GB2312这两编码有何不同,以及GB18030?一个是另一个的子集么?实际使用的时候我发现这两个编码几乎通用。 在windows的python编码甚至还有cp936来指代GBK的。实在对这些繁杂的编码有些头大。期待UTF-8大一统的美好世界
可以在wikipedia找到详细的解释。如果有时间的话,可以帮我的项目实现一个检测日语编码的实现。只要继承一个abstract类即可。它会一个byte,2个byte,3个byte地喂给你的类,只要按照规则匹配即可。这样对于编码问题就会非常熟悉了。
阿信sxq

引用来自“jianglibo”的评论

想查看一个文件的内容,必须知道文件的编码格式。一个文件就是一个byte[],两者的内容是等价的,byte[]可能是gbk的字串,可能是mp3,也可能是jpg.

引用来自“Feng_Yu”的评论

GBK,GB2312这两编码有何不同,以及GB18030?一个是另一个的子集么?实际使用的时候我发现这两个编码几乎通用。 在windows的python编码甚至还有cp936来指代GBK的。实在对这些繁杂的编码有些头大。期待UTF-8大一统的美好世界
不管怎么样,不同的操作系统就是一个坑,不同操作系统的编码不一样,特别是windows,最大的坑
sunnytu
最后一个图应该是不对的,应该是按照iso编码方式解码为byte[],然后在编码为char[]
jianglibo

引用来自“sunnytu”的评论

最后一个图应该是不对的,应该是按照iso编码方式解码为byte[],然后在编码为char[]
read()时不存在编码问题,就是读取一个byte。“然后编码为char[]",这句话是错的,从byte到char叫解码,从char到byte叫编码。
赵开锦
推荐直接使用org.apache.commons.io.FileUtils把,一般不直接使用原生的文件读写方式。
skyshitt

引用来自“jianglibo”的评论

read()根本无需涉及编码问题。你用StringBuffer去保存,已经误用了。用byte[]才是正道。说起这个,我的编码检测代码对这个编码问题有比较深入的表达。http://git.oschina.net/jianglibo/char-encode-detector
StringBuffer部分的代码是jdk里边RandomAccessFile类的源码。所以平常如果不注意乱用的话就会出现乱码问题。
skyshitt

引用来自“一堆BUG”的评论

2、RandomAccessFile的readLine()效率非常低,如何提高效率。
可以参考一下IBM文档
花1K内存实现高效I/O的RandomAccessFile类
https://www.ibm.com/developerworks/cn/java/l-javaio/
感谢提供参考资料。
skyshitt

引用来自“赵开锦”的评论

推荐直接使用org.apache.commons.io.FileUtils把,一般不直接使用原生的文件读写方式。
FileUtils的确比RandomAccessFile类好用很多,而且效率更高。
李文轩
Reader:想成行读,就要存到String;存到String,就避免不了二次解码。
InputStream:想一次解码,就要自己判断行尾。
cys1357
File file = new File("D:\\1.txt");   
FileInputStream fis = new FileInputStream(file);
  FileChannel channel=fis.getChannel();
  int size=(int) channel.size();
  ByteBuffer buffer=ByteBuffer.allocate(size);
  channel.read(buffer);
  String b=new String(buffer.array(),"gbk");
  System.out.print(b);
或者
File file = new File("D:\\1.txt");
byte[] tempchars =new byte30;
  BufferedInputStream reader = null;
  reader = new BufferedInputStream(new FileInputStream(file));
reader.read(tempchars);
  String b=new String(tempchars,"gbk");
  System.out.print(b);
都可以打印出正常字符
淘!我喜欢!
其实问题出在楼主读文件时使用的方法假定了文件内容是字符,
java对字符的处理显然有一些默认的假设,这些假设中显然没有考虑gb系列编码,所以将其当作别的字符集字符,于是做了错误的转换。其实只要对文件读处理时不做任何字符假设,将文件内容作为纯粹的字节数组读入,然后new String时指明这个数组中存放的内容是gbk编码的字符,java就可以正确打印出字符串。
×
skyshitt
如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
* 金额(元)
¥1 ¥5 ¥10 ¥20 其他金额
打赏人
留言
* 支付类型
微信扫码支付
打赏金额:
已支付成功
打赏金额: