据了解，在所有文件的末尾，尤其是文本文件的末尾，都有一个EOF或NULL字符的十六进制代码。当我们想要编写程序并读取文本文件的内容时，我们发送 read 函数，直到我们收到 EOF hexcode。
我的问题：我下载了一些工具来查看文本文件的十六进制视图。但我看不到EOF（文件结尾/NULL）或EOT（文本结尾）的任何十六进制代码
ASCII/十六进制代码表：
这是十六进制查看器工具的输出：
注意：我的输入文件是一个文本文件，其内容是“EOF 的十六进制代码在哪里？”
感谢您的时间和考虑。
user3739941
问问题
81684 次
6 回答
49
没有 EOF 字符这样的东西。操作系统确切地知道一个文件包含多少字节（这与权限、创建日期和名称等其他元数据一起存储），因此可以告诉程序试图读取一个十字节文件的第十一个字节：你已经到达文件末尾，没有更多字节要读取。
事实上，例如由 C 函数返回的“EOF”值getchar显式地是超出 byte 范围的int值，因此它不可能存储在文件中！
有时，某些文件格式坚持添加 NUL 终止符（可能是因为这就是字符串通常存储在 C 中的方式），尽管通常这些分隔单个文件中的多个记录，而不是整个文件。而且这种装饰通常会使文件不被视为“文本文件”。
ETX 和 NUL 等 ASCII 代码可以追溯到电传打字机和朋友的时代。NUL 在 C 中用于内存中的字符串，但这与文件系统无关。
于 2014-07-28T09:16:15.347 回答
22
很久很久以前，有一个文件结束标记，但它已经很多年没有在文件中使用了。
您可以使用以下命令在 Windows 上演示它的遥远回声：
C:\>copy con junk.txt
Hello
Hello again
- Press <Ctrl> and <z>
C:\>dump junk.txt
junk.txt:
00000000 4865 6c6c 6f0d 0a48 656c 6c6f 2061 6761 Hello..Hello aga
00000010 696e 0d0a in..
C:\>
注意Ctrl-Z用作 EOT 标记。
但是，还要注意Ctrl-Z不再出现在文件中 - 它曾经作为 a 出现，0x1a但仅在某些操作系统上出现，即使那样也不一致。
ETX( )的使用0x03甚至在那些昏暗而遥远的时代之前就停止了。
于 2014-07-28T09:42:51.787 回答
9
没有EOF这样的东西。EOF 只是文件读取函数返回的值，用于告诉您文件指针已到达文件末尾。
于 2014-07-28T09:13:29.787 回答
2
直到今天，unix tty 终端都使用EOT字节 ( 0x04) 来指示输入的结束。您使用Ctrl+ D（即^D）键入它以结束对 shell 或从 stdin 读取的任何其他程序的输入。
然而，正如其他人所指出的，这与 EOF 不同，EOF 是一个条件而不是数据本身。
于 2018-05-07T22:45:09.823 回答
1
曾经甚至有不同的 EOF 字符（针对不同的操作系统）。再也见不到了。（通常文件是 128 字节的块。）用于编码 PITA，就像现在的 BOM 一样。
相反，仍然有一个int read()通常提供字节值，但对于 EOF 提供 -1。
NUL 字符是 C 中的字符串终止符。在 Java 中，您可以在字符串中间使用 NUL 字符。为了与 C 合作，生成的 UTF-8 字节对大于 127 的 Unicode 字符和 NUL 都使用多字节编码。
（其中一些可能已经为人所知。）
于 2014-07-28T09:22:58.263 回答
1
在 7 位 Wintel 世界中，它是 0x1A 或 chr(26)。
它仍然常见于较旧的文本文件和档案中，并且仍然由某些文件传输协议产生。特别是从 BBS 系统下载的文本文件通常以该字符结尾。
对于旧系统，还有其他此类标记值，并且需要不时预测 EOL（CR、LF、CR+LF）。
看到它仍在使用可能会令人烦恼，例如与 return(0) 处于同一级别。
于 2019-02-22T02:47:03.050 回答