文件實際上是否包含文件結束 (EOF) 字元？
美國國家海洋和大氣管理局 (NOAA)的地球靜止執行環境衛星 (GOES)-R 產品使用者指南 (PUG)包含以下對純文字文件 (§4.3) 的冗長描述（重點是我的）：
Unix 文本文件格式用於 1b 級和 2+ 級半靜態源數據文件的一小部分。Unix 文本文件格式（減去文件結尾字元）嵌入 GRB 元數據包中，以儲存 netCDF 文件規範的基於 XML 的 netCDF 標記語言 (NcML) 表示，其中包括產品元數據的值。
Unix 文本文件格式是電子文本的一系列行（即記錄），其長度可能可變。對於 GOES-R 地面系統，電子文本、換行符和文件結尾字元符合美國資訊交換標準程式碼 (ASCII)。每行的末尾是換行符。在文件末尾，有一個文件結束符。
這是對文件內容的準確描述嗎？我認為文件結束是作業系統或庫常式在無法從文件（或其他流）中讀取更多數據時返回的條件。這個字節實際上包含在文件中嗎？
> > Unix 文本文件格式是電子文本的一系列行（即記錄），其長度可能可變。每行的末尾是換行符。在文件末尾，有一個文件結束符。 > > >
這是對文件內容的準確描述嗎？
直到但不包括最後一個粗體部分，是的。但我不知道有任何 Unixy 系統會使用文件結尾字元，它們都將文件的長度儲存到一個字節，因此不需要這樣的標記。
再說一次，似乎有些系統確實使用了文件結尾字元。至少維基百科聲稱：
CP/M 文件系統僅以 128 字節“記錄”的倍數記錄文件長度，因此按照慣例，如果有意義數據在記錄的中間結束，則使用 Control-Z 字元來標記有意義數據的結束。
將文件長度僅儲存到一個塊將需要某種自定義來對數據流中最後一行的末尾進行編碼。任何處理二進制數據的程序當然也必須以某種方式處理更細粒度的文件大小。但是，對於二進製文件，可能更容易忽略尾隨的“額外”字節。
我想我已經看到 Control-Z 在 MS-DOS 上用作 EOF 標記，但在那裡也沒有必要。
引用的文本似乎對目前系統中的文本文件有錯誤的認識。如果我們看一下 POSIX 標準所說的，沒有提到文本文件的文件結束字元或標記，只是它們不包含 NUL 字節並且由行組成（以換行符結尾）。
另請參閱：文件中的最後一個字元是什麼？
至於這部分…
> > 對於 GOES-R 地面系統， > > $$ … $$和文件結尾字元符合美國資訊交換標準程式碼 (ASCII)。 >
就像其他人在評論中所說的那樣，ASCII 中沒有文件結尾字元，至少沒有那個名稱(*)。上面提到的Control-Z是26位，或者“替代”（SUB），“用來表示亂碼或無效字元”。因此，僅基於該文本，很難知道 EOF 字元是什麼，如果使用它。
（* 有“文本結束”（ETX，程式碼 3）、“傳輸結束”（EOT，程式碼 4）、“傳輸塊結束”（ETB，23）、“媒體結束”（EOM，25）和也是“文件分隔符”（FS，28）。關閉，但不准確。）
我認為文件結束是作業系統或庫常式在無法從文件（或其他流）中讀取更多數據時返回的條件。
確實如此。
read()當到達文件末尾時，系統呼叫返回零字節（沒有錯誤），而一些 stdio 函式 (getchar()) 有一個返回特殊值，不出所料地稱為EOF。另請參閱：EOT 和 EOF 之間的區別