|
写在前昨天带实验的时候发现很多同学在读文件的时候老是要么多了一个字符，要么不能完全读取……以前在用C的时候对文件操作自己也会遇到一些问题，但是都没有去深究，昨晚突然心血来潮，决定把他弄清楚。
测试环境windowsc-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。
结论2：在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也能读，而且是全部字符都读到新文件中。
结论4：从一定程度上证明了测试三猜想的正确性。
最后通过上面四个试验，对C中的文件操作又有了更深的认识，在查资料的时候还发现文件操作跟操作系统、编译器也有一定的关系。不管怎么说，如果用C操作文件的时候，建议用上面测试四中的方法。
|
