Tho*_*hom 19 c binaryfiles eof
我已经掌握了这个知识,这EOF是一个在文本文件末尾自动插入的特殊字符,以表明它的结束.但我现在觉得有必要对此作一些澄清.我检查了谷歌和维基百科页面,EOF但他们无法回答以下内容,并且没有确切的Stack Overflow链接.所以请帮助我:
我的书说二进制模式文件根据文件目录条目中存在的字符数来跟踪文件的结尾.(与具有特殊EOF字符标记结尾的文本文件形成对比).那么EOF二进制文件的上下文是什么？我很困惑,因为在以下程序中,我在二进制模式下!=EOF从.exe文件读取时成功使用了比较:
#include<stdio.h>
#include<stdlib.h>
int main()
{
int ch;
FILE *fp1,*fp2;
fp1=fopen("source.exe","rb");
fp2=fopen("dest.exe","wb");
if(fp1==NULL||fp2==NULL)
{
printf("Error opening files");
exit(-1);
}
while((ch=getc(fp1))!=EOF)
putc(ch,fp2);
fclose(fp1);
fclose(fp2);
}
是EOF一个特殊的"角色"吗？或者它是一个条件为维基说,当计算机知道何时返回像一个特定值的情况-1(EOF我的电脑上)？这种"条件"的例子是当字符读取功能完成读取所有存在的字符,或者字符/字符串I/O功能在读/写时遇到错误时？
有趣的是,Stack Overflow标签用于EOF混合那些定义 EOF.EOF所述"在编程领域中的标签,EOF是一个字节序列(或一个字符),表示此后没有更多的内容." 虽然它在"约"部分也说过" 文件结尾(通常缩写为EOF)是计算机操作系统中不能从数据源读取数据的条件.数据源通常称为文件或流."
但我强烈的感觉EOF不会是一个角色,因为在I/O期间遇到错误时,其他所有函数似乎都会返回它.
如果你能为我解决这个问题,那将是非常好的.
Eri*_*hil 26
C提供给您的各种EOF指标不一定与文件系统标记文件结尾的方式有关.
大多数现代文件系统都知道文件的长度,因为它们将文件记录在某处,与文件内容分开.读取文件的例程会跟踪您正在阅读的位置,并在您到达目的地时停止.C库例程生成一个EOF值以返回给您; 它们不返回文件中实际存在的值.
请注意,C库例程返回的EOF实际上不是字符.C库例程通常返回int,这int是任一字符值或EOF.例如,在一个实现中,字符可以具有从0到255的值,并且EOF可以具有值-1.当库例程遇到文件末尾时,它实际上没有看到-1字符,因为没有这样的字符.相反,底层系统例程告诉它已到达文件末尾,并通过向您返回-1来响应.
旧文件系统和原始文件系统可能在文件中具有标记文件末尾的值.由于各种原因,这通常是不合需要的.在最简单的实现中,它使得无法在文件中存储任意数据,因为您无法将文件结束标记存储为数据.然而,可以有一种实现,其中文件中的原始数据包含指示文件结尾的内容,但是在读取或写入时转换数据以便可以存储任意数据.(例如,通过"引用"文件结束标记.)
在某些情况下,诸如文件结束标记之类的内容也会出现在流中.这在从终端(或伪终端或类似终端的设备)读取时很常见.在Windows上,按下control-Z表示用户已完成输入,并且对其进行类似处理以达到文件结尾.这并不意味着控制-Z是EOF.从终端读取的软件看到control-Z,将其视为文件结束,并返回文件结束指示,这可能与control-Z不同.在Unix上,control-D通常是标记输入结束的类似标记.