文字與日常工具·文字工具包
CR、LF 與 CRLF:行尾從何而來、貼上文字為何中斷
· 背景
行結束符 文字清理 資料匯出
解釋回車和換行的電傳打字機起源、作業系統選擇不同約定的原因,以及這些選擇如何在貼上的文字中顯示為雙空行和雜散字元。
匯出時每行後面都有一個空白行 - 為什麼來自另一個系統的檔案貼上的行數是原來的兩倍
您貼上三行匯出並在每筆記錄後看到一個空白行。人們很容易立即責怪 Windows CRLF,但符合標準的文字區域通常會以標準化形式顯示換行符。雙行通常意味著早期轉換將回車符和換行符視為兩個獨立的分隔符,或在記錄之間插入額外的換行符。
保留原始版本,直到您知道哪個階段更改了它。在可以顯示控製字元的編輯器中比較原始程式碼,然後比較貼上的行數。 ToolAcre 故意接受 CRLF、LF 和單獨的 CR 作為一個邊界,因此未更改的三記錄檔案應該產生三行而不是六行,僅僅因為它來自 Windows。
額外的空白行是一種症狀,不能證明 CRLF 單獨導致它
這些名稱描述了列印終端上的實體操作。回車將筆架移動到目前行的開頭,而換行則將紙張推進到下一行。它們是單獨的控件,因為任一運動都可以獨立請求。 ASCII 將它們保留為十進位 13 處的控製字元 CR 和十進位 10 處的 LF。
現代螢幕不再移動紙張,但位元組值在檔案、協定和程式設計介面中仍然存在。歷史解釋了為什麼 CR 和 LF 不是可互換的標點符號以及為什麼 CRLF 是兩個字元序列。這並不意味著每個現代應用程式都單獨處理它們;解析器通常將這一對識別為一個邏輯行結尾。
三種約定 - Unix 和現代 macOS 上的 LF、Windows 上的 CRLF、經典 Mac 作業系統上的 CR,以及為什麼每種約定看起來都很合理
Unix 和類別 Unix 系統通常使用 LF 作為行結尾,現代 macOS 也遵循該約定。 Windows 文字檔案通常使用 CRLF。經典Mac OS單獨使用CR,但Mac OS X採用了Unix基礎和LF。當工具在未就規範化達成一致的情況下交換純文字時,這些選擇仍然可見。
沒有任何約定可以使詞語本身有所不同。問題出現在讀者只期望一種表示形式或天真地在每個控製字元上分割的邊界處。強大的行解析器在檢查單獨的 CR 或 LF 之前先將 CRLF 作為一對進行檢查。 ToolAcre 正是使用有序模式 ` | | `,然後將轉換後的輸出與 LF 連接。
瀏覽器文字方塊中發生的情況 - 通常如何在貼上時規範換行符以及仍然出現雜散字元的位置
HTML 定義了文字控制項中換行符號的特殊處理。在文字區域值中,瀏覽器將公開值中的 CRLF 和單獨的 CR 規範化為 LF,而表單提交可以套用表單資料規則來換行。因此,在盒子中看起來正確的貼上仍然可以由另一層以不同的方式序列化,或者按照另一種約定複製到軟體中。
當文字繞過普通文字區域、顯示轉義位元組(例如文字字元 `\r`)或解析器僅在 LF 上分割並將 CR 附加到每個欄位時,雜散 CR 仍然可能出現。瀏覽器只是路徑中的一個階段,而不是檔案、剪貼簿產生器、API 和命令列使用者的通用修復服務。
瀏覽器規範文字區域換行符,但剪貼簿和下游格式仍然不同
空白行和尾隨回車符需要不同的診斷。在 ToolAcre 識別出所有三種行結束樣式後,「刪除空白行」會刪除內容為空白或空格的行。修剪線刪除每一行的前導和尾隨空白。由於 ToolAcre 的分離器會消耗真正的 CR 分隔符,因此通常不需要僅為了擦除該分隔符號而進行修剪。
僅在保留空格、製表符或文字未使用的字元時才使用修剪,並在更改之前檢查有意義的縮排。如果文字包含可見的 `^M`,請確定檢視器正在渲染實際的 CR 還是這兩個可列印字元。毯子更換可能會損壞預期內容,而檢查之前和之後的計數會給出可審查的結果。
刪除空白行修復空白行;ToolAcre正確分割CR後通常不需要修剪
對於可重現的範例,從三個名稱開始,其損壞的中間表示在每個名稱之間包含一個空白行:`Ada`、空白、`Grace`、空白、`Linus`。字數和字元計數器報告五行。這是故意加倍輸入;僅真正的 CRLF 序列將被識別為一個邊界,並不會在 ToolAcre 中創建那些空白行。
選擇“刪除空白行”,輸出將變成用 LF 連接的三行。計數器現在應該報告三。如果匯入的值還帶有填充,請單獨執行修剪線並查看結果。將這些操作分開可以證明每個操作修復了哪些缺陷,而不是將每個清理都歸因於 Windows 文字的模糊轉換。
工作範例:清理故意加倍的匯出並驗證行數
行結束清理不會修復硬換行,即邏輯句子被故意以列寬打斷。從該材料中刪除每個換行符也會加入真正的段落和清單項目。在對整個區塊應用線條操作之前,確定邊界是否代表一筆記錄、一個段落或視覺換行。
它也不診斷字符編碼。 UTF-8 位元組順序標記、替換菱形、mojibake 和解碼失敗涉及位元組如何變成字符,而不是 CR 或 LF 是否將這些字符分隔成行。在將奇怪的可見符號視為行結尾之前,保留原始檔案並使用適當的檔案感知工具識別其編碼。
重點—行尾是您可以看到的歷史;文字工具包的線條工具和計數器可讓您在幾秒鐘內修復症狀
CR、LF 和 CRLF 是歷史控件,具有當今的相容性後果。最安全的心智模式是具有多種物理表示的一條邏輯線邊界。在刪除任何內容之前,計算記錄數、檢查來源約定並確定引入空白行或保留控製字元的階段。
對於貼上的材料,請打開位於 `/tools/text/` 的文字工具包,記下初始行數,僅在確實不需要空白行時應用“刪除空行”,並僅對周圍的空白使用“修剪行”。之後重新檢查計數和樣本記錄。這個簡短的審核將不可見的格式問題轉化為受控的、可逆的文字轉換。