OmniDoc术语表明明有这个词却匹配失败？先查 Unicode 表示
術語表裡明明有這個詞，程式卻說沒有命中。把字串印出來看，兩邊似乎一模一樣。原因可能不在翻譯，而在 Unicode 表示：一個重音字元既可以是單一碼點，也可以由基礎字母加組合符號組成。
術語表裡明明有這個詞，程式卻說沒有命中。把字串印出來看，兩邊似乎一模一樣。這類問題常見於批次翻譯、術語檢索和文件比對場景。原因往往不在譯文本身，而在 Unicode 表示：一個帶有重音的字符，既可以是單一碼點，也可以由基礎字母加組合符號構成。
本文用合成樣本示範處理方法，幫你先找到差異來源，再決定怎麼歸一化、怎麼保存資料。
程式碼已通過隔離環境中的範例檢查，這不代表對所有真實文件或產品效果的保證。處理重要文件前，請保留原件，並依文中的邊界與驗收項複審。
术语匹配失败怎么办？一句話結論
先判斷是表示差異還是內容差異：表示差異可以透過 NFC 等歸一化對齊，內容差異則需要回到術語本身處理。
| 你的情況 | 推薦做法 | 原因 |
|---|---|---|
| 字串看起來一樣，但匹配失敗 | 比較前做 NFC 歸一化 | NFC 常用於把規範等價的表示對齊 |
| 需要更寬的搜尋匹配，如全角半角 | 評估 NFKC，但不涵蓋原文 | NFKC 範圍更廣，會摺疊相容字元，不一定適合檔案或技術符號 |
| 大小寫不一致 | 建立大小寫不敏感的匹配鍵 | casefold 可用於不區分大小寫的匹配 |
| 需要高亮或回寫到原文 | 保留原文片段映射，或在原文層面重新定位 | 歸一化後長度可能會變化，直接用偏移會切錯範圍 |
先確認是表示差異，還是內容差異
比較前做 NFC 歸一化，常用於把規範等價的表示對齊。 NFKC 的範圍更廣，會把一些相容字元摺疊。 這可能符合搜尋需求，卻不一定符合檔案保存或技術符號比較的需求。
不要把“更容易匹配”誤當成“語義一定不變”。
在合成範例中，é 的兩種寫法經過 NFC 後應一致；全角字母和上標字則用來展示 NFKC 會帶來的變化。它們只是具體例子，並不意味著所有項目都應統一採用某一種形式。
用程式碼看到原來沒看見的差別
import unicodedata as ud
composed = "café"
decomposed = "cafe\u0301"
assert composed != decomposed
assert ud.normalize("NFC", composed) == ud.normalize("NFC", decomposed)
fullwidth = "ＡＢＣ"
assert ud.normalize("NFC", fullwidth) == fullwidth
assert ud.normalize("NFKC", fullwidth) == "ABC"
assert ud.normalize("NFKC", "x²") == "x2"
def term_key(text):
return ud.normalize("NFC", text).casefold()
assert term_key("CAFÉ") == term_key(decomposed)
assert term_key("x²") != term_key("x2")
print([f"U+{ord(c):04X}" for c in decomposed])範例為術語匹配選擇了 NFC 加 casefold，這是一個有意限定的匹配策略。 casefold 也會產生與語言相關的摺疊結果，因此不能因為它方便，就把產生的鍵直接替換掉所有原始文字。
原文和匹配鍵分開存
保留 original_text，另建 normalized_key。前者用於展示、追溯和複核，後者用於當前策略下的檢索。
同時記錄策略名稱與版本。 將來改用其他規則時，才能據此重建索引，而不是發現原始文字已被不可逆地覆蓋。
| 觀察 | 可以嘗試的動作 | 不應順手做的事 |
|---|---|---|
| 組合重音差異 | 按明確策略做 NFC | 宣稱字元數不再重要 |
| 全角半角差異 | 按業務需求評估 NFKC | 直接覆蓋技術文件原文 |
| 大小寫差異 | 建立大小寫不敏感匹配鍵 | 把展示文本全部小寫 |
| 仍未命中 | 查看碼點與實際上下文 | 不斷疊加替換規則碰運氣 |
歸一化並不能解決所有“看起來一樣”
外形相近的拉丁字母與其他文字中的字符，未必存在規範或兼容等價關係。 零寬字元、不同的空格，以及 OCR 把字母識別成數字，都需要各自單獨診斷。
涉及帳號、檔案識別碼等安全敏感場景時，請不要把本文的術語匹配範例當成完整的混淆字元防護。
位置追溯要單獨處理
歸一化後字串長度可能發生變化。 用匹配鍵中的字元偏移去裁切原文，可能切錯範圍。
需要高亮或回寫時，應保留原文片段與匹配鍵之間的映射，或者重新在原文層面定位。
把問題交給翻譯前，先保留證據
評估OmniDoc的術語與翻譯工作流時，可以準備同一術語的兩種 Unicode 表示，記錄源文本、所用策略和譯文。
這樣發現不一致時，就能區分問題出在輸入匹配還是譯文選擇上，避免把所有差異都歸咎於翻譯模型。
📊 核心對比
| 策略 | 主要作用 | 需要注意 |
|---|---|---|
| NFC | 對齊規範等價的表示，適合比較前處理 | 不改變兼容字元的形式 |
| NFKC | 範圍更廣，會摺疊相容字元，可能更利於搜尋 | 不一定適合檔案保存或技術符號比較 |
| casefold | 建立大小寫不敏感的匹配鍵 | 結果與語言相關，不宜直接替換原始文字 |
🎯 哪種做法適合你？
如果你需要判斷兩個字串是否相同
先做 NFC 歸一化，再比較。 這是檢查表示差異的起點。
如果你在做搜尋或術語檢索
可以建立 normalized_key，並記錄策略名稱與版本，原始文字保持不動。
如果你需要保留原文用於展示或複核
保留 original_text，不要用匹配鍵覆蓋它。
如果你處理的是檔案、技術符號或安全敏感內容
先評估 NFKC 是否合適，並單獨排查零寬字元、相似字元等問題，不要把歸一化當作完整防護。
❓ 常見問題（FAQ）
1. 兩個字串看起來一樣，為什麼匹配不上？
可能是同一個帶重音字元採用了兩種表示：單個碼點，或基礎字母加組合符號。 比較前做 NFC 歸一化，可以把它們對齊。
2. 能不能直接用 NFKC 統一所有字元？
不一定。 NFKC 會摺疊相容字元，可能不符合檔案保存或技術符號比較的需求，應按業務需求評估。
3. 歸一化後，能否直接用字符偏移高亮原文？
不能直接用。 歸一化後長度可能變化，需要保留片段映射，或在原文層面重新定位。
4. 歸一化能否識別所有外形相似的字符？
不能。 外形相近的字元未必存在規範或兼容等價關係，零寬字元、空格和 OCR 錯誤也需要單獨診斷。
📝 總結
術語匹配失敗時，先確認是 Unicode 表示差異還是內容差異，再選擇明確的歸一化策略。 原始文字與匹配鍵分開保存，才能兼顧檢索效果與可追溯性。
參考資料：Python unicodedata
