如何区分 EOF 字符和实际的文件结尾？
读取文件时，我知道提供的最后一个字符是 EOF。现在，当我在该文件中有 EOF 字符时会发生什么？
如何区分文件的“真实”结尾和 EOF 字符？
When reading a file, I understand the last character provided is an EOF. Now, what happens, when I have an EOF character in that file?
How do I distinguish between the "real" end of a file, and the EOF character?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我决定将我的评论移至答案。
文件中不能有“EOF 字符”，因为不存在这样的东西。底层文件系统知道一个文件有多少字节；它不依赖于文件的内容来知道结尾在哪里。
您使用的 C 函数返回
EOF(-1) 但未从文件中读取。这只是函数告诉您已到达终点的方式。由于 -1 在任何字符集中都不是有效字符，因此不会产生混淆。I decided to move my comments to an answer.
You can't have an "EOF character" in your file because there is no such thing. The underlying filesystem knows how many bytes are in a file; it doesn't rely on the contents of the file to know where the end is.
The C functions you're using return
EOF(-1) but that wasn't read from the file. It's just the way the function tells you that you're reached the end. And because -1 isn't a valid character in any character set, there's no confusion.对于这个问题，你需要一些背景信息。在 Windows 上，有一个过时的 DOS 概念，即真正的“EOF 字符”——Ctrl-Z。实际上无法区分“真”和“假”；从程序的角度来看，嵌入 Ctrl-Z 的文件将包含一些尾随隐藏数据，该程序实际上正在寻找 Ctrl-Z 作为文件结束字符。不要再尝试编写这种代码——没有必要。
在可移植 C API 和 UNIX 上，使用 32 位
-1来指示文件结束，它不能是有效的 8 或 16 位字符，因此很容易区分不同之处。You need some context for this question. On Windows, there's the outdated DOS concept of a real "EOF character" -- Ctrl-Z. It is actually not possible to tell a "real" one from a "fake" one; a file with an embedded Ctrl-Z will contain some trailing hidden data from the perspective of a program which is actually looking for Ctrl-Z as an end of file character. Don't try to write this kind of code anymore -- it's not necessary.
In the portable C API and on UNIX, a 32-bit
-1is used to indicate end of file, which can't be a valid 8 or 16-bit character, so it's easy to tell the difference.假设您正在谈论 C，
EOF是 -1，它不是一个字符（因此不会混淆）。Assuming you're talking about C,
EOFis -1, which is not a character (hence there is no confusion).