unicodedata.normalize()是最稳妥的Unicode标准化方式，但必须依场景选对形式：NFC（推荐存储显示）、NFD（适合剥离变音符）、NFKC/NFKD（激进兼容转换，易失语义），乱用会导致字符误删、错位或语义改变。
直接说结论：用 unicodedata.normalize() 是最稳妥的方式，但必须选对正规化形式（NFC/NFD/NFKC/NFKD），否则可能把本该保留的字符“吃掉”或“拆散”。
为什么 unicodedata.normalize() 不能乱用？
同一个视觉字符可能有多种 Unicode 表示方式。比如 “é” 可以是单个预组字符 U+00E9（LATIN SMALL LETTER E WITH ACUTE），也可以是基础字符 e + 组合符 U+0301（COMBINING ACUTE ACCENT）。不正规化，字符串比较、搜索、去重都会出错。
但四种正规化形式行为差异很大：
-
NFC：组合为预组字符（推荐用于存储和显示） -
NFD：完全分解为基字+组合符（适合文本分析、音标处理） -
NFKC：兼容性组合（会把全角数字转半角、罗马数字转 ASCII、连字如 “ffi” 拆成 “ffi”） -
NFKD：兼容性分解（最激进，可能丢失语义，比如把 “①” → “1”）
常见踩坑：NFKC 处理用户昵称时把 “ＯＳＸ”（全角字母）变成 “OSX”，看似整洁，实则破坏了用户原始意图；NFD 后直接 .lower() 可能让组合符错位，导致显示异常。
立即学习“Python免费学习笔记（深入）”；
如何安全地做等价比较或去重？
核心原则：先正规化，再操作，且全程保持同一形式。
例如判断两个字符串是否“看起来一样”：
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
import unicodedata
<p>def is_visually_equal(a, b):
return unicodedata.normalize("NFC", a) == unicodedata.normalize("NFC", b)</p><h1>✅ 正确：é (U+00E9) 和 e + U+0301 都变成 NFC 后相等</h1><p>is_visually_equal("café", "cafe\u0301") # True</p><h1>❌ 错误：用 NFD 做比较后又拿结果当显示用，可能触发渲染问题</h1><p>去重时也同理：用 NFC 做 key，但保留原始字符串值：
- 不要直接修改用户输入存库，而是额外存一个
normalized_key - 避免用
NFKC当 key —— 它会把 “½” → “1/2”，“℡” → “TEL”，语义已变
哪些场景必须用 NFD 或 NFKD？
不是所有任务都适合“看起来一样”。需要剥离格式、提取纯文本语义时才用分解型。
典型用例：
- 搜索引擎索引前的预处理（把 “München” → “Munchen”，方便匹配 “Munchen travel”）
- 拼写检查或语音转写（需访问每个基字，忽略重音位置）
- 生成 ASCII-only 的 URL slug（先
NFD，再过滤组合符，最后.encode("ascii", "ignore").decode()）
注意：NFKD 会把上标数字 “⁴” → “4”，但也会把版权符号 “©” → “(c)”——这种替换在法律文本中不可接受，得人工白名单控制。
容易被忽略的边界情况
正规化不是万能胶。以下情况它无能为力：
- 不同语言的等价字形（如中文繁体「為」和简体「为」，Unicode 不视为正规化等价）
- 字体渲染差异导致的视觉混淆（如 “l”（L小写） vs “1”（数字一），它们码位完全不同）
- 零宽空格
\u200b、零宽连接符\u200d等控制字符，normalize()默认不删除，需单独 strip
真正上线前，务必拿真实用户数据跑一遍：抽样看 len(s) 是否突变、repr() 输出是否含意外组合符、前端渲染是否错位。Unicode 正规化是把双刃剑，稳住 NFC/NFD 这两条主线，其他形式除非明确需要兼容性转换，否则别碰。
