換行，在計算機領域中是加在一行文字最後位置的特殊字元，在換行字元的下一個字元將會出現在下一行。實際上換行字元根據不同的硬體平臺或作業系統平臺會有不同的編碼方式。 換行字元可以看作是行的結束符，也可以看作行之間的分隔符，這兩種處理方式之間存在一些歧義。如果換行字元被當作分隔符，那麼檔案的最後一行就不需要再有換行字元。但是多數系統的做法是在最後一行的後面也加上一個換行字元，也就是把換行字元看作是行的結束符。這樣的程式在處理末行沒有換行字元的檔案時，可能會存在問題。相反地，有的程式把換行符看作分隔符，就會把最末尾的換行字元看作是新行的開始，也就是多出了一個空行。 歷史 早期計算機系統常使用電傳打字機作為控制檯裝置，需要使用 CRLF 字元序列將印表機定位在新行的開頭。列印頭無法及時從最右邊返回到下一行的開頭來列印下一個字元。在 CR 之後列印的字元通常會在頁面中間列印為汙跡，這是因為列印頭仍在移回行首位置的途中。解決方案是將換行符設定為兩個字元：CR 將列印頭回車移動到第一列，LF 將紙張向上移動。 事實上，通常需要傳送額外的但會被忽略的字元（無關的 CR 或 NUL）以給列印頭更多時間移動到左邊距。 MSDOS（1981 年）為了相容採用了遵循 DEC 小型機標準的 CPM 的 CRLF，而這個約定也被微軟後來的 Windows 作業系統繼承了。 1964 年開始開發的 Multics 作業系統使用單獨的 LF 作為換行符。Multics 使用裝置驅動程式將 LF 字元轉換為印表機所需的任何字元序列（包括額外的填充字元），且單位元組更便於程式設計。CR 字元提供了將一行與另一行疊印以建立粗體、下劃線和刪除線效果的有用功能。單獨使用 LF 作為行終止符已經被納入最終的 ISOIEC 646 標準草案中。Unix 遵循了 Multics 的做法，後來類 Unix 系統也遵循了 Unix。 這在 Windows 和類 Unix 作業系統之間造成了衝突，在一個作業系統上編寫的檔案無法正確格式化或由另一個作業系統解釋。 表示 應用軟體以及作業系統對於換行字元的表示方式： 以 ASCII 為基礎的或相容的字元集使用分別 LF（Line feed，U000A）或 CR（Carriage Return，U000D）或 CRLF；下面列出各系統換行字元編碼的列表 LF：在 Unix 或類 Unix 系統（GNULinux，AIX，Xenix，Mac OS X，）、BeOS、Amiga、RISC OS CRLF：DOS（MSDOS、PCDOS 等）、微軟視窗作業系統（Microsoft Windows）、大部分非 Unix 的系統 CR：Apple II 家族，Mac OS 至版本 9 程式語言 CC 利用轉義序列 n 來換行。 printf Hello worldn Unicode Unicode 標準指定以下的字元為相容標準的應用程式應識別的換行字元： ：換行，U000A ：垂直定位，U000B ：換頁符，U000C ：回車符，U000D ：CR（U000D）後跟 LF（U000A） ：下一行，U0085 ：分行，U2028 ：分段，U2029 程式語言支援 為了便於建立可移植程式，程式語言提供了一些抽象來處理不同環境中使用的不同型別的換行序列。 C 語言提供轉義序列 n（換行符）和 r（回車符）。但是，這些字元不需要等同於 ASCII 編碼中的 LF 和 CR 控制字元。C 語言標準只保證兩件事： 這些轉義序列中的每一個都對映到一個唯一的實現定義的數字，該數字可以作為單個字元值儲存。 當以文字模式寫入檔案、裝置節點或 socketfifo 時，n 會透明地轉換為系統使用的本機換行序列，該序列可能比一個字元長。在文字模式下讀取時，本機換行符序列將轉換回 n。在二進位制模式下，不進行任何翻譯，直接輸出 n 產生的內部表示。 在 C 起源的 Unix 平臺上，本機換行序列是 ASCII LF 0x0A，因此 n 被簡單地定義為該值。由於內部和外部表示相同，因此在文字模式下執行的翻譯是無操作的，並且 Unix 沒有文字模式或二進位制模式的概念。這導致許多在 Unix 系統上開發軟體的程式設計師完全忽略了這種區別，導致程式碼無法移植到不同的平臺。 最好避免在二進位制模式下使用 C 標準庫函式 fgets ，因為任何未使用 Unix 換行符約定寫入的檔案都將被誤讀。 另外，在文字模式下，任何未使用系統本機換行序列寫入的檔案（例如在 Unix 系統上建立的檔案，然後複製到 Windows 系統）也會被誤讀。 另一個常見問題是在使用強制使用 ASCII CRLF 來結束行的 Internet 協議進行通訊時使用 n。將 n 寫入文字模式流在 Windows 系統上可以正常工作，但在 Unix 上僅產生 LF，而在更奇特的系統上則完全不同。在二進位制模式下使用 rn 稍好一些。 許多語言，例如 C、Perl、Haskell 都提供與 C 語言相同的 n 解釋。C 有另一種 IO 模型，其中操縱器 stdendl 可用於輸出換行符（並重新整理流緩衝區）。 Java、PHP 和 Python 提供 rn 序列（對應於 ASCII 的 CRLF）。與 C 不同，它們保證分別表示值 U000D 和 U000A。 Java IO 庫不會透明地將這些轉換為輸入或輸出上依賴於平臺的換行序列。 相反，它們提供了用於寫入自動新增本機換行序列的整行的函式，以及用於讀取接受 CR、LF 或 CRLF 作為行終止符的行的函式。SystemlineSeparator 方法可用於檢索底層行分隔符。 C 例子 string eol EnvironmentNewLine string lineColor Color Red eol string eol2 n string lineColor2 Color Blue eol2 不同換行符格式帶來的問題 不同的換行約定會導致在不同型別的系統之間傳輸的文字檔案顯示不正確。 使用類 Unix 或經典 Mac OS 上常見的程式建立的檔案中的文字，在 MSDOS 和 Microsoft Windows 常見的大多數程式中顯示為單長行，因為這些程式不把單個換行符或單個回車符顯示為換行。 相反，在類 Unix 系統上檢視源自 Windows 計算機的檔案時，額外的回車符可能會顯示為第二個換行符、或每行末尾的。 此外，文字編輯器以外的程式可能不接受檔案，例如一些配置檔案，使用外部換行約定編碼視作有效檔案。 這個問題可能很難發現，因為有些程式可以正確處理外部換行符，而另一些則不能。例如，即使原始檔在控制檯或編輯器中顯示時看起來正確，編譯器也可能會因模糊語法錯誤而失敗。現代文字編輯器通常可以識別所有型別的 CRLF 換行符，並允許使用者在不同標準之間進行轉換。Web 瀏覽器通常還能夠顯示使用不同型別換行符的文字檔案和網站。 即使程式支援不同的換行符約定，這些功能通常也沒有得到充分的標記、描述或記錄。通常，將向用戶顯示列舉不同換行符約定的選單或組合框，而不指示該選擇是否將重新解釋、臨時轉換或永久轉換換行符。有些程式會在開啟、複製、貼上或儲存時隱式進行轉換。 大多數文字 Internet 協議包括 HTTP、SMTP、FTP、IRC 等）都要求在協議級別使用 ASCII 的 CRLF（rn 0x0D 0x0A），但建議寬容的應用程式識別單獨的 LF n 0x0A 也視作換行。儘管有規定的標準，許多應用程式錯誤地使用 C 語言換行轉義序列 n LF，而不是回車轉義序列和換行轉義序列 rn CRLF 的正確組合。 當嘗試與遵循更嚴格的標準解釋而不是建議的寬容解釋的系統進行通訊時，這種意外使用錯誤的轉義序列會導致問題。qmail 郵件傳輸代理就是這樣一種不寬容的系統，它主動拒絕接受來自發送裸 LF 而不是所需 CRLF 的系統的訊息。 電子郵件的標準網際網路訊息格式規定：CR 和 LF 必須僅作為 CRLF 一起出現；它們不得獨立出現在正文中。 當傳輸以 ASCII 模式 完成時，檔案傳輸協議可以自動轉換在具有不同換行符表示的系統之間傳輸的檔案中的換行符。然而，以這種模式傳輸二進位制檔案通常會產生災難性的結果：任何出現的換行符位元組序列（在此上下文中沒有行終止符語義，但只是正常位元組序列的一部分）都將被轉換為任何換行符表示形式其他系統使用，實質上損壞了檔案。FTP 客戶端通常採用一些啟發式方法（例如，檢查副檔名）來自動選擇二進位制或 ASCII 模式，但最終由使用者來確保其檔案以正確的模式傳輸。如果對正確模式有任何疑問，應使用二進位制模式，因為這樣 FTP 不會更改任何檔案，儘管它們可能顯示不正確。 相關條目 回車符 參考資料 外部連結 The EndofLine Story The NEL Newline Character Category 控制字元