我們知道Windows 使用 CR LF 對作為其新行，Unix（包括 Linux 和 OS X）使用單個 LF，而 MacOS 使用單個 CR。
這是否意味著 C 和 C 中換行符的解釋取決于執行環境，即使K&R (section 1.5.3 Line Counting)非常明確地陳述了以下內容？
所以 '\n' 代表換行符的值，在 ASCII 中是 10。
uj5u.com熱心網友回復：
我們知道 Windows 使用 CR LF 對作為其新行，...
您鏈接到的頁面沒有說 Windows 使用“CR LF”作為其換行符。它說 Windows 用回車符和換行符標記文本檔案中的行尾。這并不意味著這些字符是換行符，反之亦然。
這是否意味著換行符的解釋......
換行符是換行符。在 C 中，它旨在標記一個新行。使用 ASCII 時，ASCII 的換行符（代碼 10）通常用作 C 的換行符 ( '\n')。
如果 C 程式使用二進制流讀取 Windows 樣式的文本檔案，它將看到一個回車符和一個標記行尾的換行符。如果 C 程式使用文本流（在支持此的環境中）讀取 Windows 樣式的文本檔案，Windows 行結束指示（回車符和換行符）將自動轉換為 C 換行符人物。
相反，如果 C 程式使用文本流寫入 Windows 樣式的文本檔案，它寫入的換行符將被轉換為 Windows 行結束指示。如果它使用二進制流寫入，它必須自己寫入回車符和換行符。
uj5u.com熱心網友回復：
這是否意味著 C 和 C 中換行符的解釋取決于執行環境
不，這不取決于。解釋取決于讀取平臺建議但可能不同的檔案的工具。一個強大的文本工具將容忍各種編碼并處理變化。
此外，源自一個系統的文本檔案由具有不同規則的其他平面圖訪問/編輯。
uj5u.com熱心網友回復：
不，\n總是意味著 LF。
在 Windows 上，如果流以文本模式（而不是二進制模式）打開，則由 IO 流 ( FILE *, std::??stream)執行 LF <-> CR-LF 轉換。
uj5u.com熱心網友回復：
這是否意味著 C 和 C 中換行符的解釋取決于執行環境？
檔案內容的解釋確實取決于執行環境，因此 C 程式員不必顯式處理不同的約定：
如果流以二進制形式打開
"rb"，則不執行任何轉換，檔案內容的每個位元組都由getchar(). Unix 系統以相同方式處理文本檔案和二進制檔案，因此文本檔案也不會發生翻譯。在其他系統上，流以文本模式打開
"rt"或僅以"r"系統特定的方式處理，以將行尾模式轉換為單位元組'\n'，在 ASCII 中具有值10。在 Windows 和 MS/DOS 系統上，這種轉換將CR/LF對轉換為單個位元組'\n'，這可以實作為簡單地洗掉CR位元組。這個約定繼承自以前的微型計算機作業系統，例如Gary Kildall的 CP/M，其 API 在 QDOS 中被模擬，Seattle Computer Products的原始 8086 作業系統后來成為 MS/DOS。較舊的 Mac 系統（在 OS/X 之前）過去使用單個 CR 位元組來表示行尾，但 Apple 在他們的 OS/X 系統采用 Unix 內核時改變了這一點。在 macOS 上不再執行翻譯。
老式系統曾經對文本檔案有更繁瑣的表示，例如固定長度的記錄，并且流實作
'\n'在以文本模式讀取此類流時插入額外的位元組來模擬 unix 行結尾。
重要的是要了解此翻譯程序是系統特定的，并非旨在處理從使用不同約定的其他系統復制的檔案。高級文本工具（例如 QEmacs 程式員的編輯器）可以檢測不同的行結尾并執行適當的翻譯，而不管當前的執行環境如何，保留檔案中使用的約定，或將其轉換為用戶控制下的另一種約定。
轉載請註明出處，本文鏈接：https://www.uj5u.com/gongcheng/464178.html
上一篇：類似宏的功能
下一篇：替代功能（無間斷切換）