文字差異檢查器的替代方案應在本地逐行比較兩份有限範圍的純文字版本，並清楚標示新增、刪除、未變更的行及總數。Text Diff Checker正扮演這個角色：每一側最多可接受 500 行與 200,000 個 UTF-16 程式碼單位，然後產生單一且有順序的比較畫面。原始版本位於左側，變更後的版本位於右側。選擇 Compare lines 後，相同的行會加上中性前綴，新行以加號開頭，刪除的行以減號開頭；摘要會計算新增、刪除及未變更的行數。比較單位是整行，因此單一字元的編輯會顯示為一行刪除及一行新增，而不是字元層級的醒目提示。所有分割、比較、列產生與算繪作業都在你的瀏覽器中進行，兩側內容都不會上傳至 Lizely。因此，當你想要清楚檢視行層級的變更，而非自動套用的修補檔時，這項工具適合用於短篇草稿、配置檔、日誌、清單、散文段落及小型程式碼片段。
選擇符合需求的逐行替代方案
搜尋「文字差異檢查器替代方案」背後的實務需求，是將兩個版本並排呈現、指出變更的行，並判斷每項變更是否為刻意進行。這是一項檢查工作，而不是自動要求產生可由機器套用的修補檔。兩個版本可能是修訂後的配置內容、清單、編輯過的文案、預期的日誌輸出或小型程式碼片段。當你希望取得易讀的結果，又不上傳任一來源內容時，專注的瀏覽器比較方式很適合這些工作。
Text Diff Checker 刻意適合有限範圍且以行為單位的檢查。它採用最長公共子序列比較來找出相符的行，並將其餘行整理為新增或刪除。當每一行代表配置屬性、日誌事件、清單項目、段落或簡短的原始碼陳述時，這種方法能讓輸出保持易於理解。
| 檢查情境 | 最適合方案 | 原因 |
|---|---|---|
| 短篇配置內容、清單、草稿、日誌或程式碼片段 | Text Diff Checker | 提供本地的逐行畫面，顯示新增、刪除、未變更的列及數量。 |
| 具修訂歷史的原始碼儲存庫 | Git | 追蹤歷史、檔名、重新命名、修補檔、作者身分及衝突解決。 |
| 非常大的文字檔 | 串流或原生 diff 工具 | 可處理大型輸入，無須將其貼入基於瀏覽器的比較工具。 |
瞭解每個比較列的意義
比較作業會先找出兩個行陣列的最長公共子序列。選入該子序列的相同行會顯示為未變更。從序列中略過的原始行會顯示為刪除，而從序列中略過的變更側行則會顯示為新增。產生的列會保留原始行字串及其在各來源中的順序，因此結果仍與你貼上的文字相互對應。
| 列類型 | 前綴 | 意義 |
|---|---|---|
| 未變更 | 中性 | 完整行在兩側完全相同。 |
| 新增 | 加號 | 此行存在於變更後的版本，但在原始版本中被略過。 |
| 刪除 | 減號 | 此行存在於原始版本，但在變更後的版本中被略過。 |
摘要計數來自這些最終列類型，使可見總數與比較畫面保持一致。重複的行可能不只具有一種有效的最佳對齊方式，但平手規則是確定性的，當剩餘子序列長度相同時會優先 favor 新增。因此，完全相同的已接受輸入一律會產生相同且有順序的列。
以三個步驟比較兩個版本
- 貼上兩份文字。 將原始純文字放入左側欄位，將變更後的純文字放入右側欄位。只納入你想比較的內容，因為放在任一欄位內的標題或標籤也會成為該文字的一部分。
- 選擇 Compare lines。 此工具會先檢查兩側內容，再建立比較表。如果任一側超過 500 個正規化行或 200,000 個 UTF-16 程式碼單位，該側就會被拒絕，而不會在未告知的情況下縮短。
- 讀取排序後的結果。 將帶有加號的行視為新增、帶有減號的行視為刪除，並將帶中性前綴的行視為未變更。然後使用新增、刪除及未變更行的摘要計數，檢查修訂內容的整體樣貌。
編輯任一輸入後，之前的比較結果就會清除。修正或替換其中一側後，請再次選擇 Compare lines，讓顯示的列與摘要依目前輸入產生。
套用精確的行比對規則
精確比對是刻意設計的。畫面顯示相等，表示完整行字串依工具記載的規則相等，並不表示這些行具有等同意涵。在認定沒有重大變更之前，請先檢查以下差異：
- 大小寫與標點符號都會算入。 字母大小寫、標點符號及行內的每個其他字元都會影響相等判定。
- 空白具有重要性。 開頭空格、結尾空格及定位字元都是行的一部分。此工具不會忽略空白，也不會將字母大小寫視為相同。
- 空行會正常參與比較。 非空文字中的空行是有效的行值。完全空白的輸入包含零行。
- 會辨識行界線。 CRLF、單獨的 CR 及 LF 都可作為行界線，其中 CRLF 會視為單一界線。分析時會正規化界線語法，但會保留每行內的內容。
- 小幅文字編輯看起來會很大。 變更一個字元會使整行不再相符，因此原始行會顯示為一行刪除，修訂後的行則顯示為一行新增。
因此，Unicode 正規化形式、外觀相似的字元、隱藏空白或行內經逸出的行結尾序列，都可能產生差異。如果這些差異對你的檢查很重要，請在最終使用的目的地格式中檢查，而不要假設外觀相似的行必然等價。
瞭解限制、隱私與可重現的結果
每一側最多限制為 500 行與 200,000 個 UTF-16 程式碼單位。行數限制之所以重要，是因為最長公共子序列比較會隨行數執行平方級運算。明確的上限有助於避免貼上的大型文件使瀏覽器分頁凍結，而字元限制則能界定輸入儲存與算繪的範圍。超過上限的一側會在建立動態程式設計表之前被拒絕；不會有任何內容在未告知的情況下遭到截斷。
整個工作流程的處理作業都在本地進行。分割、比較、列產生與算繪都在瀏覽器中完成，兩份文字都留在瀏覽器內，兩側內容都不會上傳至 Lizely。此工具不會呼叫任何第三方程式庫或服務，也不會在頁面關閉或重新整理後保留比較歷史。處理敏感資料時，請自行保留來源副本，直到檢查完成，並在文字最終使用的格式中檢查重要變更。
當檢查需要更多功能時，選擇其他工作流程
若要處理原始碼儲存庫，Git 是更好的選擇，因為它會追蹤歷史、檔名、重新命名、修補檔、作者身分及衝突解決。對於非常大的檔案，請使用串流或原生 diff 工具，不要將其貼入瀏覽器。這些工作流程可解決更廣泛的版本控制與大型檔案問題，而這些並非有限範圍的行比較所設計要處理的範圍。
Text Diff Checker 不是修補檔產生器。它的輸出是說明性畫面，而不是適合自動套用的 unified-diff 檔案。它不會加入行號、偵測移動的區塊、忽略空白、將字母大小寫視為相同、解析程式語言、醒目提示字元層級編輯、合併衝突或寫入任一來源。如果你需要字詞層級或字元層級的醒目提示，或需要其他程式能套用的修補檔，請使用專為該任務設計的工作流程。
使用最終檢查清單
接受比較結果前，請依序完成以下簡短的最終檢查：
- 確認左側欄位包含預期的原始版本，右側欄位包含預期的修訂版本。
- 在逐一檢視各列之前，先閱讀新增、刪除及未變更的數量。
- 在上下文中檢查加號行與減號行，不要將其順序視為修補檔。
- 仔細檢視字母大小寫、標點符號、開頭或結尾空格、定位字元及不尋常的 Unicode 字元。
- 保留來源版本，直到所有敏感或重要的變更都已檢查完畢。
- 編輯任一欄位後再次執行比較，因為先前的結果會被清除。