開發者工具·文字比較

每行都改變了？差異中的行尾、尾隨空格和 BOM

2026年2月8日 · 工作原理

文字差異行結束符偵錯

診斷報告每一行不同的比較的三個看不見的原因，並展示如何在指責作者之前分辨出哪一個原因。

同一個檔案，保存兩次，顯然是重寫的 — 設定在兩個作業系統上編輯檔案的常見情況

當編輯器變更不可見字元時，兩次儲存看起來像是重寫，但 ToolAcre 的行為取決於變更的字元。它在匹配之前標準化行結尾，而行邊緣的空格和開頭的 U+FEFF 仍然是普通的行內容，除非另一個選項更改鍵。

建立一個診斷裝置，而不是根據顏色猜測。比較一對僅結尾不同、另一對尾隨空格不同、第三對具有前導 BOM。受控對比同時包含多個不可見變更的真實檔案更可靠地揭示工具的邊界。

`splitLines` 用 LF 取代 CRLF 和單獨的 CR，然後分割。測試顯示所有三種約定都會產生相同的陣列。因此，即使關閉“忽略空白”，僅 CRLF 的差異也是不可見的；該大綱聲稱每行都會有所不同，這與此實現相矛盾。

最後的換行符號也不會建立額外的行。拆分後，刪除一個終端空條目。中間的真正空行仍然是比較單元，因此該行為將檔案結束約定與檔案內有意的垂直分隔區分開來。

尾隨空格保留在原始行中。透過普通比較，`name=value` 和 `name=value ` 有不同的鍵。忽略空白會修剪兩端並折疊內部執行，因此該選項可以使配對匹配，同時保留顯示的相等行中的左側原始文字。

该庫还實現了更窄的 `ignoreTrailingWhitespace` 選項，但當前 UI 並未公開它。文章不得描述使用者無法選擇的複選框。附帶的面板提供忽略大小寫、忽略所有空白差異和折疊長期未更改的執行。

解碼為 JavaScript 文字的 UTF-8 位元組順序標記在第一行的開頭為 U+FEFF。 `splitLines` 沒有明確的 BOM 刪除。透過普通匹配，該字元只能使第一行不同，而後面的行保持相同。

當忽略空白呼叫 `trim` 時，JavaScript 空白操作可能會將 U+FEFF 視為空白，但本文不會將其概括為檔案解碼行為。編輯器接收字串；它不讀取檔案位元組或報告編碼。當位元組級來源很重要時，檢查實際字元。

從 `alpha beta` 和 `alpha beta` 開始：結果是相同的。接下來將 `alpha beta` 與 `alpha beta` 進行比較：普通模式報告替換行，而空白模式則匹配它們。最後給一側的alpha加上U+FEFF前綴，觀察一線效果。

此序列使用經過儲存庫驗證的操作來分隔原因。如果結束標準化後每行仍然不同，請調查內容、縮排或尾隨字符，而不是僅僅歸咎於 CRLF。如果只有第一行不同，請在重寫整個檔案之前檢查其前導程式碼點。

忽略空格對於尾隨空格雜訊很有用，因為它會修剪和壓縮行鍵。它不負責隱藏 CRLF 與 LF；這在分裂期間已經發生了。將這些階段分開可以防止得出關於哪個選項修復了比較的誤導性結論。

執行這兩個視圖，因為修剪可以隱藏有意義的縮進，而壓縮可以改變固定寬度值或字串文字。安靜的標準化結果表明鍵在該轉換下匹配。它不證明原始檔案是位元組相同的或語義上可互換的。

文字差異不會轉換檔案、設定 Git、更改編輯器設定或公開十六進位位元組。它接受貼上的字串並報告行操作。有關 `.gitattributes`、`core.autocrlf` 或編碼修復的建議屬於可以單獨驗證其行為的工具。

該工具也無法區分不可見字元如何輸入文字。格式化程式、剪貼簿、解碼器或手動編輯可能會產生相同的字串。使用比較來定位行，然後在分配原因之前檢查來源管道。

依固定順序檢查不可見字元：結尾、尾隨或內部空格，然後是前導特殊字元。 ToolAcre 的測試為第一類提供了可靠的結果，其選項有助於隔離第二類。第三種可能需要這條路線以外的性格檢查員。

瀏覽器端的行分割使跨平台的結尾差異在設計上消失。這很方便，但這也意味著該工具無法證明兩個原始檔案使用相同的實體換行符位元組。當需要保留精確的線路或儲存庫表示時，請選擇位元組感知實用程式。