Confusables.txt 與 NFKC 在 31 個字元上存在分歧

背景

在構建身分驗證系統時，開發者常面臨「同形異義字攻擊」（Homoglyph attacks），即攻擊者利用外觀極其相似的 Unicode 字元來冒充他人。為此，Unicode 聯盟提供了 confusables.txt 標準來識別視覺上的混淆字，同時也建議使用 NFKC 正規化來處理字元的一致性。然而，這兩項標準在處理特定字元時存在邏輯衝突，導致某些混淆字偵測在正規化後會失效。

社群觀點

針對這項技術衝突，Hacker News 的討論呈現出多樣化的立場。部分開發者對「拒絕混淆字元」的安全性建議感到反感，認為這是一種對非拉丁語系使用者極不友好的行為。批評者指出，許多被標記為混淆的字元在其他語言中是完全合法的，若系統僅因其與拉丁字母相似就予以拒絕，本質上是一種「拉丁中心主義」的表現。他們主張，如果系統只打算支援拉丁字母，應該直接明確限制輸入範圍，而非透過複雜且不一致的混淆字清單來過濾，否則只會讓非英語使用者感到困惑與被歧視。

另一派觀點則從實務經驗出發，探討了顯示名稱與機器識別碼之間的區別。有留言者認為，對於登入帳號等底層標識符，強制使用 ASCII 字元是為了系統穩定性與跨平台相容性的必要之惡，但在顯示名稱上應給予使用者最大的自由。然而，這也引發了關於 UI 設計的爭論：如果系統允許任意 Unicode 字元作為顯示名稱，那麼防止冒名的責任應落在介面設計上（例如使用不同的顏色或圖標標註官方帳號），而非試圖透過字元過濾來解決。

此外，社群中對於 NFKC 正規化的必要性也存在質疑。有專家指出，原文宣稱「所有網頁應用都應使用 NFKC」的說法並不準確，因為 NFKC 屬於「相容性」正規化，會導致原始資訊的流失（例如將上標數字轉為普通數字）。大多數網頁應用實際上更傾向於使用 NFC 正規化，後者在保持語義一致的同時不會破壞字元的原始型態。這進一步說明了混淆字偵測與正規化之間的衝突，可能源於開發者對不同正規化標準用途的誤解。

最後，討論中也觸及了字體渲染帶來的物理限制。有網友幽默地提到，即便不使用 Unicode，某些字體下的拉丁字母組合（如 rn 與 m）本身就極難分辨。這反映出安全性問題不僅存在於編碼層面，也深受視覺呈現與排版技術的影響。部分資深開發者總結道，處理使用者輸入應視其為「有毒廢棄物」，無論標準如何定義，最終仍需透過嚴格的 UI 隔離與後端邏輯來確保系統安全。

延伸閱讀

• Unicode Technical Standard #39 (Security Mechanisms)：關於混淆字偵測的官方安全機制說明。
• Unicode Normalization Forms (UAX #15)：詳細解釋 NFC、NFD、NFKC、NFKD 四種正規化形式的差異。
• Wikipedia: Long s：關於文中提到的長 S（ſ）歷史背景與演進。