開發者工具·文字比較
為什麼 Windows 和 Unix 在行結尾上不一致：CR、LF 和 CRLF 故事
· 背景
文字差異 行結束符 軟體歷史記錄
追蹤從打字機和電傳打字機到現代作業系統的行結尾，並解釋為什麼兩種約定仍然在每個跨平台項目中共存。
一個看不見的角色，數十年的摩擦——以持續的跨平台煩惱打開
行結尾在普通編輯器中是不可見的，但對檔案和協定可能很重要。然而，在 ToolAcre 中，CR、LF 和 CRLF 在行比較之前被標準化。僅這些分隔符號不同的一對會產生相同的線性陣列和相同的結果。
該行為解決了該路線的實際問題，同時限制了它可以診斷的內容。比較無法證明文字到達編輯器後原始檔案包含哪些換行位元組。保存或協定檢查需要位元組感知工具。
打字機上的回車和換行 — 解釋了角色最初描述的兩個物理動作
回車和換行一詞具有物理和歷史意義，但儲存庫不包含打字機來源。即使這個敘述聽起來很熟悉，憑記憶重複機械起源故事也會違反證據契約。
本文將 CR 視為 ` ` 程式碼單元，將 LF 視為 ` ` 僅在實現使用它們的地方。歷史解釋應在以後從主要標準或檔案中添加，而不是從明確不是來源的大綱中藉用。
打字機意義是需要外在來源的歷史主張
同樣，原始檔案不記錄電傳打字約定或早期作業系統決策。它們僅揭示了當前 JavaScript 中的相容性選擇：在拆分之前用 LF 替換每個 CRLF 或單獨的 CR。
此轉換接受根據多種約定產生的貼上文字，而不用僅結尾更改填充輸出。這是一個在一個正規表示式中可見的實作決策，並由所有三種形式的測試固定。
電傳打字機和作業系統譜系位於儲存庫證據之外
通常將 Unix 與 LF 關聯起來，將 Windows 與 CRLF 關聯起來，將舊系統與單獨的 CR 關聯起來，但目前的儲存庫不能作為這些採用的歷史證明。安全宣告可操作：所有三個輸入在 `splitLines` 內變成 LF。
終端 LF 不會建立最終的空白行，而中間的空白行仍然存在。這種區別意味著即使物理分隔符號差異被刪除，邏輯內容仍被保留。比較是面向行的，而不是保留位元組的。
代碼證明了三個約定規範化；它並不能證明為什麼系統採用它們
一些網路和訊息協定指定了精確的線路終止符，但它們的要求必須來自它們的規範。 ToolAcre 的標準化使其不適合證明與這種有線格式的一致性，因為原始分隔符號證據被有意刪除。
當精確的 CRLF 序列很重要時，在解析之前使用十六進位檢視器或協定驗證器。乾淨的文字差異結果可以確認匹配的邏輯行並同時隱藏傳輸級缺陷。這兩種觀察都可能是正確的，因為這些工具回答了不同的問題。
協定要求需要有自己的規範，此處省略
比較 `alpha beta`, `alpha beta` and `alpha beta` 成對出現。每個產生兩條線，α和β，並沒有添加或刪除。忽略空白不會導致這種平等；分裂期間已經發生了標準化。
將尾隨空格加入到一個測試行，普通模式現在將報告差異。啟用忽略空白，它可能會消失。此序列將換行符處理與行鍵空白處理分開，並防止記入錯誤的選項。
工作範例：所有三種結尾形式在空白選項之前比較為相等
此路線不配置編輯器、重寫檔案、設定 Git 屬性或批次轉換結尾。它還不會暴露結果行中的原始分隔符號。貼上的字串進入比較管道，而不是換行遷移實用程式。
歷史因果關係和協議標準被省略，待定來源。這個限制留下了一篇更小但更精確的文章：在這個實現中三個約定做了什麼，保留了哪些空行以及為什麼這裡的相等不建立字節標識。
重點：了解您的文字採用哪種約定 - 總結歷史以及 ToolAcre 的文字比較如何幫助確認差異是否僅是行結尾
了解哪些證據在該工具中存活下來。標準化後，ToolAcre 可以比較公用分隔符號之間的邏輯行內容。它無法告訴您來源使用了哪種約定，也無法告訴您下游消費者是否需要一個確切的位元組序列。
使用瀏覽器差異進行人工審查，並使用位元組級檢查來執行儲存庫或協定。當工具的轉換是明確的時，它就是可靠的；審閱者仍然有責任選擇一個保留他們需要驗證的屬性的人。