ASCII码0x1A使文件意外结束的处理方法

        在windows操作系统中，大家在编写带有文件操作的程序时，有时候会遇到一种奇怪的现象，在对一个文件以文本方式进行读取的过程中，读到中途还没到文件末尾时feof()函数就意外地为真，这让人很惊讶，一时难以找到原因，实际上，这是ASCII码0x1A在作怪。运行下面程序：

int main(void)
{
        int i;
        unsigned char c;
        FILE *fp;       
        fp=fopen("test.dat", "w");
        fprintf(fp, "abc/x1A def");
        fclose(fp);
        fp=fopen("test.dat", "r");
        for(i=0; i<=7; ++i)
        {
                fread(&c, sizeof(char), 1, fp);
                printf("%02X feof=%d/n", c, feof(fp));
        }
        fclose(fp);
        return 0;
}

运行的结果是：

61 feof=0
62 feof=0
63 feof=0
63 feof=16
63 feof=16
63 feof=16
63 feof=16
63 feof=16

        从以上结果可见，在读到第四个字符就是0x1A的时候，feof为真了。这种现象目前只发现存在于windows中，unix/linux没有。为什么会这样呢？

        0x1A在ASCII码中代表EOF，在过去，ASCII码EOF曾经在unix/linux中被作为文件结束符使用，微软继承了这个传统，也以EOF作为文件的结束符，不过，笔者手里的一些资料表明，微软在dos5.0以后就抛弃了这种做法。但实际情况是，笔者在dos6.22、windows3.1、windows3.2、windows9x、windows2k、xp、2003都存在这种问题。同时，这种问题是系统还是库函数造成的也有待进一步查证，由于没有源码，无法证实，如果哪位朋友有这方面的资料，希望可以共享。另一方面，鉴于dos/windows下所有主流编译器例如VC、BCB、gcc、tc2.0、bc3.1等都是同样的结果，笔者倾向于这是系统原因造成的。

        那么这种0x1A现象是否符合标准呢？C89/C99是这样定义文件流的两种方式的：

7.19.2 Streams

    A text stream is an ordered sequence of characters composed into lines, each line consisting of zero or more characters plus a terminating new-line character. Whether the last line requires a terminating new-line character is implementation-defined. Characters may have to be added, altered, or deleted on input and output to conform to differing conventions for representing text in the host environment.  Thus, there need not be a one-to-one correspondence between the characters in a stream and those in the external representation.

    A binary stream is an ordered sequence of characters that can transparently record internal data. Data read in from a binary stream shall compare equal to the data that were earlier written out to that stream, under the same implementation. 

        规定中说明，文本方式可以对输入输出文件的字符进行添加、替换和删除，0x1A现象是否属于这三种情况之列呢？笔者认为不属于，因为它在逻辑上使文件发生了截断，已经不仅仅是对字符的添加、替换或删除了。如果这被证实是非法的话，那么，无论是库函数还是系统的原因，库函数都有责任对此进行修正。

        如何解决这个问题？其实标准已经给出了其中一种解决方法，由于二进制方式的输入输出是一一对应的，字符不会产生变化，那么用二进制读取就不会产生这个问题，事实也证明是可以的，只是存在一点麻烦，由于windows下会把/n转换为/r/n，二进制读取时必须对此转换进行堙别和还原，这会增加代码的复杂性，这种麻烦很让人讨厌。因此笔者尝试在低级函数中寻找更好的答案，但让人失望的是几款主流编译器的低级函数即使在文本方式下都没有对/r/n进行转换，由于低级函数的行为跟标准无关，如果有哪款编译器的低级函数对/r/n进行了还原，那就是比二进制方式更好的解决方法。

        但无论如何，以上方法都不完美，这是否意味着windows的文本方式没有任何意义？这实在让人沮丧。如果哪位朋友对此有深入的研究，欢迎一起讨论。