文字與校稿
全形、半形與空白：文字清理前的核對方法
全形代碼轉成半形後，其他欄位要不要一起改？用四行範例比較 NFC、NFKC 和空白處理，確認修改範圍與比對結果。
只改商品代碼：四行資料的完整比對
序號照通知輸入，報名表卻說格式錯誤，或商品代碼照型錄打，系統仍找不到品項。若收件規則要求半形英數，我會先檢查「ＡＢ－１２３」是不是該改成「AB-123」，只動這個欄位。姓名、圈號和網址不必跟著整份轉換。全形「Ａ」與半形「A」是不同字元，字型讓它們看起來接近，並不表示系統會視為相同。
改完序號再試著送出。若仍被拒絕，還要核對序號本身、欄位長度或報名資格，不能認定都是全半形造成的。本文的報名、補貨及活動通知均為自擬案例，實際要求要向收件人確認。
用四行補貨資料試一次，就能看出「只改代碼」和「整份轉換」差在哪裡。假設供應商要求商品代碼使用半形大寫英文字母、數字和連字號，其餘資料照原稿保留。下面四行依序是型錄代碼、聯絡署名、照片附件標號和商品網址；「林 安」是示意姓名。這次只處理第一行「ＡＢ－１２３」，姓名空白、照片圈號與網址都保留。
ＡＢ－１２３ 林 安 ① https://example.com/item?code=AB-123
把兩版貼進文字差異比對後，應得到一行刪除、一行新增、三行相同。刪除和新增都對應第一行的代碼替換，不是改了兩筆資料。若署名或附件標號也被標成不同，就需要回頭查看是否不小心對整份內容套用了轉換。
姓名空白看起來不整齊，要不要順手刪掉？這次我會保留，因為委託只要求改商品代碼，還沒確認姓名欄的規格。這不表示所有系統都接受這種寫法。其他欄位有疑問，先問收件要求或回看提供者的原稿，不必為了讓比對標記變少，連仍有用途的差異也刪掉。
實際比對：只修改第一行
本節附有原文、只改代碼、整份 NFKC 三份 TXT 範例。每份都只有四行欄位值，不包含欄位名稱，最後一行沒有另外加換行。先開啟「原文」與「只改代碼」，把全文分別貼進工具的「原文」和「新版文字」，按下「比對文字」。若自己從表格複製，請逐行貼上右側的值，避免把欄名、Tab 或多餘空白一起帶入。
下圖是用這兩份檔案在本站工具跑出的結果。第一行分成紅色的刪除與綠色的新增；姓名、圈號和網址仍列為相同。核對時除了看上方行數，也要讀變更內容：新代碼是 AB-123，姓名中間的全形空白與附件的圈形都有保留。
反例：整份轉換，多改了哪些內容？
接著保持左側原文不動，右側換成「整份 NFKC」範例，再按一次比對。這份新版是對四行欄位值整段套用 NFKC 的結果；本站比對工具只用來呈現差異，不會替你執行這個轉換。
這次得到三行新增、三行刪除、一行相同。除了商品代碼，第二行「林 安」的全形空白變成一般空格，第三行「①」變成「1」。網址原本就是半形，所以第四行沒變。如果這次委託只要求修正商品代碼，另外兩行便超出了修改範圍。
發現多改時，回到保存的原文，重新只處理指定欄位。把新版再轉一次全形，無法自動還原原先哪些位置用了半形、哪些位置用了圈號。若你另外保留了中文欄名與全形冒號，整段轉換也會改動冒號，行數不會和本文這組「只有欄位值」的結果相同。
| 欄位 | 修改前 | 修改後 |
|---|---|---|
| 商品代碼 | ＡＢ－１２３ | AB-123 |
| 署名 | 林 安 | 林 安 |
| 附件標號 | ① | ① |
| 資料網址 | https://example.com/item?code=AB-123 | https://example.com/item?code=AB-123 |
- 文字差異比對貼上原文與新版，核對這個範例是否只修改代碼那一行。
- 原文範例（TXT）四行自擬資料，供複製或另存；沒有真實個資。
- 只改代碼的結果（TXT）第一行改為 AB-123，其他三行保留。
- 整份 NFKC 的結果（TXT）與原文比較，觀察姓名空白與圈號的額外變動。
NFC 與 NFKC 會改動不同範圍
正規化是依一套規則統一某些字元的表示方式。常見的 NFC 可以整理像組合重音這類等價寫法，但不會把本文的全形商品代碼改成半形。NFKC 處理的相容範圍更廣，除了這些全形英數，圈號和部分特殊符號也可能改變。
同樣的情況也會出現在重音字母。畫面上的「é」，可能由一個字元儲存，也可能是「e」加上一個組合重音。對人來說是同一個字，直接比較原始文字時仍可能不同。先找出差異屬於哪一種，再決定要不要改，才能保留資料原本的意思。
表中的 NFC 與 NFKC 輸出可以用 JavaScript 字串的 normalize 方法重現。不過，看見工具寫「全形轉半形」，還不能認定它使用 NFKC。有些工具只替換指定字元範圍，我會先查它實際會改哪些字，再決定能不能整段套用。
例如附件用「①」標記時，NFKC 會得到「1」，圈形就消失了。若這個標記還要和圖中的圈號對照，我會保留原字，因為轉換後反而不容易辨認。Unicode 的規範也提醒，相容正規化會消除部分格式差異，不宜不分用途套用到所有文字。
| 原文 | NFC | NFKC |
|---|---|---|
| ＡＢ－１２３ | ＡＢ－１２３ | AB-123 |
| ① | ① | 1 |
| e 加組合重音 U+0301 | é | é |
空白、連接符號和換行各有用途
一般空格、不換行空白、全形空白與 Tab 都可能出現在複製的文字裡。它們看起來像留白，作用卻不完全一樣。用空格把欄位排整齊的名單，也可能混有 Tab，直接刪光會把原本分開的資料黏在一起。
NFKC 會把本文測試中的不換行空白 U+00A0 轉成一般空格，但不會刪除零寬空白 U+200B。正規化因此不是「清除所有看不見的字元」。像「👩💻」含有連接用的 U+200D，拿掉它就會變成分開的符號，不能只因沒有單獨顯示就當成多餘內容。
換行還要區分真正的換行字元與畫面自動折行。本站文字差異比對會先統一 CRLF、CR 和 LF，再逐行比較，但保留行內及行尾空白，也不自動統一全半形。因此兩行只差一個空格時，仍可能同時看到一行刪除與一行新增。
交件前核對原系統，別只看差異行數
先另存原稿，再交付修改後的版本，並記下本次只調整哪些欄位。帳號、密碼、驗證碼和網址應依原系統的規則使用，不要自行套用整段文字的整理方式。排查問題時，可以用不含個資的短範例重現，通常更容易看清是哪個字元造成差異。
比對結果符合預期，工作就完成了嗎？還差收件端這一關。代碼要能找到正確商品，附件標號要對得上，姓名也要符合要求。比對工具只能呈現兩版文字的差異，不能替收件系統判定哪一版有效。若仍被拒絕，也可能是欄位長度或允許的符號不同，不能只歸因於全半形。
需要核對文字長度時，可另外使用字數計算，再以收件端規則為準。正規化可能改變字元組成，字數相同也不表示文字完全相同。我會留下「這次為什麼改、改了哪些欄位」的紀錄，日後再遇到相同問題，比只保存一個「沒有差異」的結果更容易回查。
轉貼活動通知時，別把場次標號也改了
另一種常見用途是把活動資訊貼到群組。這份示範通知寫著「９／３０ １０：００，第①組在２樓集合。」主辦者想把日期、時間與樓層的數字統一成半形，場次圖卻仍用「①」標記。這次可以交付「9/30 10:00，第①組在2樓集合。」，讓群組通知仍能對照場次圖。這是本案例的排版需求，不表示中文通知一定得改成半形。
如果把整句套用 NFKC，結果會是「9/30 10:00,第1組在2樓集合。」圈號變成一般數字，中文逗號也變成半形。日期和時間看起來對了，不代表其他地方都符合需求。交給主辦者前，應把通知與場次圖放在一起，核對集合時間、樓層及標號，而不只是確認轉換按鈕有成功。
網拍商品連結也要留意。例如 https://example.com/item?code=ＡＢ－１２３ 整段轉換後，code 後面的值會變成 AB-123。本文只核對這個示意網址的文字，沒有向該網站查詢商品。要傳給客人的連結，應從原賣場取得並實際開啟確認；不要為了統一字寬，連網址也一起修改。
- 字數計算檢查修改前後的字元與單字統計，收件限制仍須依目的地規則判斷。
參考來源
- Unicode UAX #15：正規化形式說明等價與相容正規化，以及不宜任意消除格式差異的原因。
- MDN：String.normalize()本文 NFC 與 NFKC 比較使用的方法與適用範圍。