Java基础补充.Day14

字节缓冲流

image-20210827091805505

减少底层调用，提高效率

image-20210827091856853

image-20210827092043114

image-20210827092102343

image-20210827092228249

image-20210827092309229

用缓冲区写数据

image-20210827093029123

看源码，调用缓冲区构造器的时候创建了一个大小为8192字节的数组存数据作为缓冲

image-20210827093210212

缓冲区读数据

image-20210827094840365

复制avi视频

使用System.currentTimeMillis();计算时长

image-20210827095629893

image-20210827095641989

字符流

为什么要用字符流？

GBK编码占用2个字节，UTF-8编码占用3个字节

image-20210827100136428

这种拿到一个字节就读了就出问题了

字节流复制中文不出问题的原因：

因为中文无论是按照GBK--2字节还是UTF-8--3字节编码，第一个字节都会是负数，这样系统按照编码方式转译

image-20210827100849076

字符流的底层还是字节流

编码表

image-20210827112848824

image-20210827112916482

image-20210827112958471

image-20210827113022485

image-20210827113058763

image-20210827113158736

image-20210827113234800

image-20210827113252903

编码解码问题

image-20210827113418398

image-20210827161154390

字符流的编码解码问题

image-20210827161904175

InputStreamReader类

image-20210827161854732

image-20210827162049046

同理OutputStreamWriter类

image-20210827162234491

编码构造器

image-20210827162550175

image-20210827163516519

如果后面是GBK，打开文件就会出现乱码，因为文件的编码方式是UTF-8，而指定了GBK的编码方式，所以出现乱码

但如果用GBk的方式去解码就能顺利读出来

  • 把用GBK编码的文件按默认UTF-8解码

image-20210827165054345

  • 把用GBK编码的文件按GBK解码

image-20210827165140365

字符流写数据

image-20210827184116276

image-20210827185203872

直接这么写写不进去文件，因为字符流通过字节流去写，数据现在存在缓冲区里，需要刷新缓冲，用flush()方法

image-20210827185338237

但如果不写刷新在后面写关闭也行，因为close方法是先刷新缓冲再释放资源，但close方法后面不能继续写数据image-20210827185429549

image-20210827191133125

字符流读数据

image-20210827194703292

 

posted on 2021-08-27 19:48  托马斯源  阅读(36)  评论(0)    收藏  举报
博客园  ©  2004-2025
浙公网安备 33010602011771号 浙ICP备2021040463号-3