我去试了一下，发现并不会buf数组并不会初始化，第二次读取的数据会直接覆盖数组原来的内容。

假设第二次循环b=1002，那么buf[0]~buf[1001]的值会与第一次循环时的值不一致，而buf[1002]之后的数据与第一次循环一致。没覆盖的值不为0就证明了没有初始化，这就说明第二次读取时的内容直接覆盖原来的内容。

我自己回答一下吧。read方法返回值赋给b不能在while体外，否则将执行无限循环。相当于b是给定的不为-1的值，而在while循环中，b是一直在检验的，检验输入流是否读取到文件末端。

数组下标0代表数组中的1，就是从第一位开始

老师讲了几种copy方法，都是边读边写，我自己写了一个Demo你看看是不是这个意思。

public class FISDemo {
    public static void main(String[] args) throws IOException {
        FileInputStream fis = new FileInputStream("demo");
        FileOutputStream fos = new FileOutputStream("demo-copy");

        //如果没读完就一直读
        for (int b; (b = fis.read()) != -1; ) {
            fos.write(b);    //把读到的一个字节写入 demo-copy
        }

        fis.close();
        fos.close();
    }
}

后面的参数是指在写文件的时候,如果文件存在是否以追加文件内容的方式进行写入

上百度去搜一下就可以

将内容刷新到硬盘中

因为 批量读写的话 当时非文本文件 比如说是mp3等 他们的存储是01代码 如果批量的话 可能把本来没有编码的东西给编码了 然后你复制的东西就会打不开

你是说写‘A’的时候吗，貌似并未读完，也只读了8位

1024字节就是1KB大小，8*1024个字节就是8KB，凑个整方便些

严谨的写法应该添加try catch finally， catch中throw异常，finally中关闭流

FileInputStream所读的文件必须是FileOutputStream或是file创建的文件。

效率不好把 

IoUtil下的HexString静态方法

哦，那又怎么了？

我也是遇到了这个问题，我知道问题所在，但是现在还没有找到解决的方法，这个问题和前面有一节的是一样的，写入数字会有错误，会乱码，通过我的检测，这个数字写入文件会变成ASCII存储，你可以把数据改一下，对照ASCII码表，就会发现输入的数字是一一对应的。然而我还没有解决的办法。。。。

以为printHex（）方法是在IOUtil类中的静态方法，只能通过类名来调用

a十进制是15，b十进制是-42，a>b

printHex()是IOUtil类里写的静态函数，所以能够直接通过IOUtil类来调用该函数

，他不是FileInputStream的方法，而是IOUtil里的方法

因为输入流和输出流是从程序运行所在的内存角度划分的，不是从存储介质的角度划分的。内存读取存储介质数据叫输入流，内存写入存储介质叫输出流。

""改成''

我在文件名之后追加true后，确实没有覆盖，但是新文件的内容也没有追加进去啊！还是第一次copy进去的内容！

偏移量可以理解为从第几个位置开始，其实可以理解为数组下标，用一个int表示偏移量，写0就表示从第一个开始，因为数组的下标从0开始

文件比buf大的情况下，那么一次就不能全读进来，就需要循环

数组读满 或者到结尾写一次

因为读取到数组是一个完整的操作   这个动作完成以后才会去判断条件

直接放只是放入2个字符串，new file（）是放入到文件

我感觉这个参数设置的在创建这个FileOutputStream变量的时候的动作

append参数的不同会导致是创建新的文件还是在原先的文件末尾添加

而不会影响后面的write操作

write操作位置好像是依赖于iterator也就是迭代器的

at java.io.FileOutputStream这个有问题

我也是初学者，不知道对不对，"10".getBytes()是将10这个字符串编码成byte序列储存到byte数组中，然后调用write(byte[])方法把字符数组写入，但是这些方法的基础都是write(byte)。

1、你检查一下代码，是否正确。

2、也存在，不同IDE、或不同版本的代码编译后有不同输出结果。

3、其实听课程，学习到的是文件读写过程的一个思路，但具体的执行过程，需具体分析、编码。