java byte转string乱码_Java程序员必看之如何深入理解字符流的编码?

Java中是以流的形式来实现数据在网络中的传输,而所说的“流”则是字节流。因为所有的数据的最底层都是以字节为单位存储的,所以以字节为单位传输数据无疑是最简单也是最有效的传输方式。

cac9cbbd27465a4e78bc09474dd3cec1.png

我们在学习Java的过程中,也经常接触字符流,字符流顾名思义则是以字符为单位进行数据传输,但是其实字符流的应用面是很窄的,并不是所有的文件都存在字符的概念的,比如视频文件、音频文件、图片文件,这些是无法以字符为单位进行传输的。字符流只能对文本字符进行操作。

提到字符,我们首先就会想到的是编码,因为计算机存储的是字节,我们看到的却是字符,这之间是靠编码表对应起来的,那么这也就是本篇文章索要研究的内容—字符流编码。

首先我们来看下面的案例:

471500ac65dc0503439d9ea8230d8746.png

案例显示,Demo.java的项目编码和b.txt的编码格式一样,则能够正常写入,不会乱码。原理如下图所示:

a1003772f7a86d4005f974d2a0c6365d.png

字符流,每一个字符流都存在一个缓冲区,缓冲区的编码格式是和项目的编码格式一致的,上述代码执行流程是:字符串“黑马”在FileWriter的缓冲区里面通过GBK编码把汉字编码成对应的字节,然后底层通过字节流将字节写入到b.txt。 很多人我们打开b.txt时看到的是“黑马”这两个字啊,并不是什么码值啊。其实所有文件的底层都是字节,子不过我们打开b.txt时,记事本软件就通过此文件的编码—GBK帮我们把码值解码成“黑马”这两个字了,所以我们看到的是黑马。照这样看来,如果b.txt的文件编码是UTF-8的话,肯定就会乱码,因为记事本会按照UTF-8进行解码,效果如下图所示:

d9526b4ef5aa22a04daf5647fe95f248.png

接下来难点才真正的来临(很多人看了下面的代码和运行效果就蒙圈),我们把上图的代码改下(其他编码格式不变),你会发现不乱码了,如下图:源码如下:

8aed5235aeabe60c306e83e5fd8ccf7e.png

public class Demo {[/align]

public static void main(String[] args) throws IOException {

FileWriter fw = new FileWriter("b.txt");

String s = "黑马";

byte[] bytes = s.getBytes("UTF-8");

String s1 = new String(bytes);

fw.write(s1);

fw.close();

}

}

很多人蒙圈的原因是因为,先把字符转为了UTF-8 但是又通过new String(bytes)转成了GBK啊,但是b.txt是UTF-8格式的编码啊。为什么没有乱码呢? 下图解释的很详细:

fe1e7142608843e1108248d655ed9463.png

执行流程是:先通过UTF-8编码把“黑马”编码成几个字节比如13 42 35 86 59 47,然后再通过GBK编码,把该码值解码成对应的字符比如“传智人”,然后“传智人”进入缓冲区会通过GBK编码编码成刚才的字节 也就是13 42 35 86 59 47,然后再通过字节流写入到b.txt中,当打开b.txt时,记事本软件会按照此文件编码格式-UTF-8解码成“黑马”,所以我们看到的是没有乱码。

总结:通过比价复杂的案例我们明白了一、每个字符流都存在缓冲区,而且缓冲区的编码是和项目编码一致。二、字符流的底层依然是使用的字节流,而且还存在缓冲区的编码动作,所以效率比字节流会慢很多,所以通常数据的传输我们都会使用字节流。三、文本文件的底层存储的也是字节,我们打开文件看到的字符,是记事本软件所做的解码。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值