C文件操作探索

写在前
以前在用C的时候对文件操作自己也会遇到一些问题，但是都没有去深究，老是要么多了一个字符，要么不能完全读取……昨晚突然心血来潮，决定把他弄清楚。

测试环境
windows
c-free3.0

C文件操作遇到的状况
1.将一个文件读到另一个文件，用“(ch = getc(fp)) != EOF”来判断文件是否结束，如果文件是全英文文本的话绝对没问题，新文件的大小和原文件大小一样；但是如果是一些有中文字符或者是二进制文件，原文件没读完就结束。
2.将一个文件读到另一个文件，用“!feof(fp)”判断文件是否结束，不管原文件是什么类型的都可以将原文件全部读完才结束，但是新文件的大小比原文件多了一个字节。
问题：在C里如何才能正确判断文件结束？？

探索
测试一，我们写了一个函数来试用EOF判断文件结束的情况：
-------in.txt内容如下---------
abcde
-------in.txt结束-------------
-------test1.c----------------
int main(int argc, char* argv[]){
    char ch;
    FILE* in;
    FILE* out;
   
    in = fopen("in.txt", "rb");  /* in.txt全为英文字符 */
    out = fopen("out.txt", "wb");
    while ((ch = getc(in)) != EOF){
         putc(ch, out);
    }
}
运行后结果是：out.txt的大小和in.txt的大小完全一样。
然后修改in.txt如下，在原来的基础上加入一些中文：
-------in.txt修改后的内容如下---------
abcde
这是一个测试文件
测试中文字符
-------in.txt结束--------------------
运行后记过也是大小是一样的。将源程序中的“in = fopen("in.txt", "rb");out = fopen("out.txt", "w");”改为“in = fopen("in.rar", "rb");out = fopen("out.rar", "wb");”，其中，in.rar是一个压缩包文件，大小有4M多，运行程序后，得到的out.rar文件只有800多k，双击解压也出现错误，无法解 压。

结论1：在C里，操作文件的时候，如果打开方式是“r”或者“w”，是以文本形式打开，也就是读如内存的字符值都是0－256之间，不可能出现－1，所以 用EOF来判断是可以的，但是如果以“rb”或者“wb”方式打开，以二进制读入内存或者写入文件，出现负数是可能的，所以用EOF来判断不能将文件读完 就已经结束了。之所以在上面测试中有中文的in.txt文件没有出错，是因为在这个文中的中文恰好没有一个的二进制码是-1的；在后来的.rar测试中， 就是读到800多K时就遇到了－1，所以文件结束。

测试二，修改test1.c为test2.c
-------test2.c----------------
int main(int argc, char* argv[]){
    FILE* in;
    FILE* out;
   
    in = fopen("in.txt", "rb");
    out = fopen("out.txt", "wb");
    while (!feof(in)){
         putc(getc(in), out);
    }
}
不管是什么方式打开，打开什么文件，都能把原文件完全读到新文件中，不过在新文件的末尾多了一个奇怪的字符（y上面多两点，其二进制值是－1）。
在读in.rar的时候，我们把循环该成了永真循环，执行后用CTR+Z结束，out.rar大小为11M,比in.rar（4.2M）大了一倍多，但是 我们打开out.rar可以解压，而且解压出来的文件跟in.rar解压出的文件的大小是一样的。用UtralEdit打开out.rar发现从某一个时 候开始，后面的所有二进制都是‘FF’（即－1），顿时明白out.rar比in.rar大的那部分其实全是－1。

结论：在C里－1被定义成是文件结束符，所以在文件末尾多余的－1都不会影响文件的使用。

测试三，根据第二得到的结论，我们想那如果一开始读第一个字符的时候就读到－1（文件结束符）会怎么样呢？我们又做了测试，
-------test3.c----------------
int main(int argc, char* argv[]){
    char ch= -1;
    FILE* in;
     
    in = fopen("in.txt", "wb");
    putc(ch, in);
}
然后又用记事本打开in.txt，在那个奇怪的字符（y上面多两点，其二进制值是－1）后面自己加了一些英文字符。分别用test1.c和test2.c 进行试验，test1中新文件没有内容；test2全部都能读到新文件中，只不过test2中的新文件后面仍让有那个奇怪字符（y上面多两点，其二进制值 是－1）。很奇怪阿，如果－1是文件结束符的话，应该在读第一个字符的时候就停止了阿，怎么还能把－1后面的字符都读到新文件中呢？又查阅了资料，自己猜 想结论如下：虽然－1在C里被定义成文件结束符（EOF），但并不是说文件里出现了－1就表示文件结束，其实文件结束时候的－1是系统在读到文件结束时候 返回的一个值，而不是说系统读到－1就知道文件结束（不知道有没有把我们的意思描述清楚），简言之就是系统现知道文件结束了才返回－1，而不是先读到－1 才知道文件结束。所以，在文件中出现的－1并不是说文件结束，只有当真正文件指针指向文件结尾的时候系统返回的那个－1才表示文件结束。之所以在 test1中不能读是因为EOF＝－1，用读出来的－1跟EOF比较肯定是真的。（这个部分很难描述，大家可以去实际试验下，有什么问题欢迎讨论。）

第四，用fread（）函数来判断文件结束：
-------test4.c----------------
int main(int argc, char* argv[]){
    char ch;
    FILE* in;
    FILE* out;
   
    in = fopen("in.txt", "rb");
    out = fopen("out.txt", "wb");
    while (fread(&ch, sizeof(char), 1, in) == 1){
         putc(ch, out);
    }
}
这个方法能够把文件都读到新文件中，并且能有效判断文件结束（不会在末尾添加上奇怪字符（y上面多两点，其二进制值是－1）），在测试三中试验的文本in.txt也能读，而且是全部字符都读到新文件中。

结论：从一定程度上证明了测试三猜想的正确性。

最后
通过上面四个试验，对C中的文件操作又有了更深的认识，在查资料的时候还发现文件操作跟操作系统、编译器也有一定的关系。不管怎么说，如果用C操作文件的时候，建议用上面测试四中的方法。