zoukankan      html  css  js  c++  java
  • 关于FileOutputStream的异常

    今日起兴搞搞文件与流的知识,刚起手写了个读取与生成文件的小程序,跑完以后,发现一张366kb的图像被代码给生生的写成了180kb大小的损坏文件?!我艹,这是几个意思?刚起手就被拍死了啊!
    原始的代码:
    FileInputStream in=null;
    FileOutputStream out=null;
    try {
    in=new FileInputStream("C:\Users\Administrator\Desktop\promo\20150417114.jpg");
    out=new FileOutputStream("C:\Users\Administrator\Desktop\promo\sub\test.jpg");
    while(in.read()!=-1){
    out.write(in.read());
    out.flush();
    }
    } catch (FileNotFoundException e) {
    // TODO Auto-generated catch block
    e.printStackTrace();
    } catch (IOException e) {
    // TODO Auto-generated catch block
    e.printStackTrace();
    }finally{

    out.close();

    in.close();
    }
    从逻辑上来看一点事都没有,可是在跑完了以后,与写之前设想的效果差的太远!本来就简短的代码,瞬间充满了陌生···,于是开始一句一句的推敲。首先关于输入和输出对象是没问题的,可以排除,继续,读取也是没有问题的,要不然也不会生成半拉莫名文件。问题于是就锁定在了write()方法上。查看outputstream的api,发现关于outputstream的write()方法的介绍很凝练,很简洁,就一句话,"将指定字节写入此文件输出流。"这是没问题的。不过后半句留下了线索,"实现outputstream的write方法"。好的,路没断就行,顺藤摸瓜,查看outputstream的write方法,"将指定的字节写入此输出流。write方法的常规协定是:向输出流写入一个字节。要写入的字节是参数b的八个低位。b的24个高位将被忽略。outputstream的子类必须提供此方法的实现"。也是很短的但是却很详细很关键的一句话,"b的24个高位将被忽略"。我了个大艹!问题已经很明确了,就是在文件传输过程中丢失了一些数据。是很明确了!可是这个高低位是个毛意思?还是不甚清楚啊。当然,其实,到了这,有两个选择,一是既然知道问题出现在哪里,就可以避免这个这个坑,就选择别的方法,不让数据丢失,另外一个就是去看看这丢失的数据到底是什么?有时候人的好奇心就是这么自然的出现的,很自觉的就去百度了,字节的高地位。看到很多不知道牛逼几何的人物的文章都说百度不咋滴,查资料都用谷歌什么的,我只想说你可以鄙视百度,但不能鄙视百度出来的结果。好的,结果出来了,话说有个叫字节序的名词,其含义很直白,就是字节的顺序。嗯,很白。通俗易懂到很通俗,嗯,懂了。不过更深的内涵就有点意思了,起码对于解决问题有了后续的线索。"大于一个字节类型的数据在内存中的存放顺序"。都说一入某某深似海,查资料也是这样,引出来的新名词又引出来新的名词,瞪着俩眼看吧,Big—Endia和little-Endia。Big-Endia,就是高位字节排放在内存的低地址端,低位字节排放在内存的高地址端。Little-Endia,就是低位字节排放在内存的低地址端,高位字节排放在内存的高地址端。我擦,有点晕,故事不到结束,那就还有剧情。且看着。网络字节序:4个字节的32bit值以一种神秘的次序传输,首先是0-7bit,然后8-15bit,再然后16-23bit,最后是24-31bit.嗯,很神奇。然后这种神奇的传输次序被有关行业称作大端字节序。到目前为止,对于解决问题我自认为还没什么进展。耐心,面对着急是脆弱的。跳一下看看···有时候吃坏东西拉肚子不是东西不能吃,而是我们的消化能力有问题。答案就在那里,偏偏看了还不懂,此时我懂了,为什么会有限制级这个名词了,因为有些东西可能看了也不懂。好的,心态调好了,就再换一份看,等到消化能力上去了,再看吧。看着看着,发现查出来的资料都不能解我心头之惑。反而牵扯出来新的东西开始在脑海里打转,查资料的解决方式到此应该打住了,不管新的问题有多大,都不能湮灭最初的起点。我只是想知道b的24个高位是啥玩意?我就是想知道我写出的文件为啥无辜的成了半拉?答案已经出来了,只是我看不懂而已。东西能吃,拉肚子只是我消化能力不行而已。为啥文件成了半拉?因为调用的方法将读入的数据在写出的时候丢了一部分。好的,勉强也算是完成了逻辑上的圆满。好,既然write方法会丢失数据,那么有没有别的方法解决问题呢?嗯,有的。除了write()方法不是还有write(byte[] b)吗?这么一改,用一个byte数组去接数据,果然就好了
    byte[] b=new byte[1024];
    while(in.read(b)!=-1){
    out.write(b);
    out.flush();
    }
    这又是什么情况?这到底是什么情况?查看outputstream的源码:
    public void write(byte b[], int off, int len) throws IOException {
    if (b == null) {
    throw new NullPointerException();
    } else if ((off < 0) || (off > b.length) || (len < 0) ||
    ((off + len) > b.length) || ((off + len) < 0)) {
    throw new IndexOutOfBoundsException();
    } else if (len == 0) {
    return;
    }
    for (int i = 0 ; i < len ; i++) {
    write(b[off + i]);
    }
    }
    write(byte[]b)和write(byte[] b, int off,int len)最后走的都是上边的方法。到了这里我突然很好奇我的in.read()方法到底读了些什么玩意儿?把in.read()打到控制台输出的是一大堆没有规律的数字,把in.read(b)打到控制台,是清一色的1024,哦,最后一个是683。这是几个意思?瞬间我感觉是这个read()方法出了问题同样的走到了顶层的InputStream里边的是个抽象方法,谁用谁重写。那就看Read(byte[]b)
    public int read(byte b[], int off, int len) throws IOException {
    if (b == null) {
    throw new NullPointerException();
    } else if (off < 0 || len < 0 || len > b.length - off) {
    throw new IndexOutOfBoundsException();
    } else if (len == 0) {
    return 0;
    }

    int c = read();
    if (c == -1) {
    return -1;
    }
    b[off] = (byte)c;

    int i = 1;
    try {
    for (; i < len ; i++) {
    c = read();
    if (c == -1) {
    break;
    }
    b[off + i] = (byte)c;
    }
    } catch (IOException ee) {
    }
    return i;
    }
    返回的是个int?返回的是i?返回的是个长度?那我刚才打出的read(byte[]b)的就是文件的size?我统计了一下,打出了366个1024。我晕了,懵了,愣了,傻了,蛋疼了···各种心酸各种苦涩,我读书少,我好怕,折腾了这么一大圈,我还是不能理解我那个183kb大小的文件到底是怎么出来的,而我更不能理解的是为什么换了个方法就可以输出正确?那个read(byte b[], int off, int len)方法里的for循环到底是有怎样的魔力?只不过是把读到的字节按顺序附加到了数组里而已。这尼玛?····哎,有点意思啊?根据打出的read()和Read(byte[]b)结果对比,好像有点启发,read()方法每次读取一个字节,read(byte[]b)每次读取b.length大小字节,不不不,read()方法读取的数据有问题,大大的有问题,我直接循环打出read()方法,竟然是无数个255,跑了三分钟也没停止。这个不是重点,重点是255,255,虽然不太清楚是什么含义,但是我就是认为它有问题,诬陷有罪,怀疑合理。我就是怀疑它有问题,嗯,有问题,图片的存储方式是什么的?read()读到的到底是什么玩意儿?!我使用的是jpg格式的图片,百度出来的东西让我开始疼,头疼,蛋疼,全身疼···,没事,没事,只要顺着线索总会有结束的真相。不对,255=2^8-1也就是一个字节?!哈哈,我找到了
    FileInputStream in=null;
    FileOutputStream out=null;
    int a=0;
    try {
    in=new FileInputStream("C:\Users\Administrator\Desktop\promo\20150417114.jpg");
    out=new FileOutputStream("C:\Users\Administrator\Desktop\promo\sub\test.jpg");
    while(in.available()>0){
    out.write(in.read());
    out.flush();
    }
    /* byte[] b=new byte[2048];
    while(in.read(b)!=-1){
    out.write(b);
    out.flush();
    }*/
    } catch (FileNotFoundException e) {
    // TODO Auto-generated catch block
    e.printStackTrace();
    } catch (IOException e) {
    // TODO Auto-generated catch block
    e.printStackTrace();
    }finally{
    System.out.println(a);
    out.close();
    in.close();
    }
    }
    我把猜想跑了一遍,果然,结果是正确的!有时候,问题越研究越被复杂,其实,最初的问题,很简单。重新梳理一下,首先创建一个输入对象,然后按每次一字节读取
    in=new FileInputStream("C:\Users\Administrator\Desktop\promo\20150417114.jpg");
    out=new FileOutputStream("C:\Users\Administrator\Desktop\promo\sub\test.jpg");
    int c=0;
    while((c=in.read())!=-1){
    out.write(c);
    out.flush();
    }
    这样是没问题的,按最最开始的代码跑的话,最后的图片只有183kb大小,问题就出在

    while(in.read()!=-1){
    out.write(in.read());
    out.flush();
    }
    人最容易忽略的地方就是明明脑子里是这样想的,手却不是这样做的!仔细,看api,"从输入流中读取一个数据字节如果没有输入可用,则此方法将阻塞",下面还有一句,"返回:下一个数据字节;如果已达文件末尾,则返回-1",就是这样一句话,导致了图片的数据缺失!当条件in.read()!=-1,调用了一次read(),此时输入流是刚刚好对应的是图片的假设是第一个数据点,而写入到输出流时又调用了read()方法,此时数据已经是图片的第二个数据点了!所以整个程序跑完,图片就这样被一次少一个数据点,一次少一个的给无辜的裁剪了···为了验证猜想,
    while(in.read()!=-1){
    out.write(in.read());
    out.flush();
    }
    这样跑完,生成的图片是183kb大小,
    while(in.read()!=-1){
    System.out.println(in.read());
    out.write(in.read());
    out.flush();
    }
    这样跑完,图片的大小成了122kb大小
    while(in.read()!=-1){
    System.out.println("===="+in.read());
    System.out.println("---"+in.read());
    out.write(in.read());
    out.flush();
    }
    这样跑完,图片的大小成了92kb大小
    while(in.read()!=-1){
    System.out.println("=="+in.read());
    System.out.println("--"+in.read());
    System.out.println("-+-"+in.read());
    out.write(in.read());
    out.flush();
    }
    这样跑完,图片仅剩72kb大小,这不是搞了压缩,这是数据丢失!丢失!什么是真相?这就是真相!要说贱人是怎么犯贱的,我想他们都是很自然的把原本应该不自然的事情给做了出来,还做的洋洋得意,然后一个人贱贱的慨叹高处不胜寒,贱贱的慨叹独孤求败了···
    int c=in.read();
    while(c!=-1){
    out.write(c);
    out.flush();

    刚把数据丢失的问题给解决我只是挪了一下read的位置,问题又来了,图片的size开始猛涨,像嚼了炫卖似的停不下了!一兆,两兆···我艹,这是几个意思?!在往控制台输出,255,又见255!无数个草泥马般的255蜂拥着奔袭控制台,停不下来!根本停不下来!这是好事,一部好的小说,挖了坑,埋了伏,就要有个交代,没错,这个255就是龙套的255=2^8-1,没错,就是它!话说有时候一个问题解决了,所有的问题就都不是问题了。如果我没猜错,这个255是图片的第一个数据点,而打出的无数个255全部都是第一个数据点,c=in.read();只读了一个字节,然后就开始进入了死循环···阿弥陀佛,至此,最初的问题,是已经解决了。可是,因果轮回,无意间种下的因,不知何时会结成孽果···什么是字节序?不是说b的24个高位将被忽略?图片的存储方式?唉,生命不息,折腾不止···

  • 相关阅读:
    湖湘杯2020misc
    BUUOJ(Misc)
    BUUOJ(Web)
    网络信息安全攻防学习平台
    CTFHub web部分题解
    BugkuCTF 部分WP(搬运了很多WP)
    Web安全之机器学习入门 第2章-第5章学习笔记
    结构体
    排序的使用
    字符串和日期
  • 原文地址:https://www.cnblogs.com/yidongdematong/p/4441605.html
Copyright © 2011-2022 走看看