unicodedata.normalize()对中文基本无效，因其仅处理规范等价（如é的组合/分解形式），而繁简体、全半角、中日韩汉字等属兼容等价或字形变体，需opencc、查表映射等业务层方案。
Python 的 unicodedata.normalize() 对中文字符基本无效，直接用它做“中文标准化”是常见误解。
为什么 unicodedata.normalize() 对中文几乎没用
该函数只处理 Unicode 标准中定义的「规范等价」（canonical equivalence），比如 'é' 的组合形式（'\u00e9'）和分解形式（'e\u0301'）。而简体中文、繁体中文、日文汉字、韩文汉字之间属于「兼容等价」或「字形变体」，不在 normalize() 覆盖范围内。
例如：'后'（U+540E，简体）和 '後'（U+5F8C，繁体）不是规范等价字符，normalize('NFC', '后') 不会变成 '後'，反之亦然。
常见误用场景：
立即学习“Python免费学习笔记（深入）”；
提示词大师-python版
下载
图片提示词生成器？不止如此。 马甲系统 —— 把脑海中的画面，翻译成AI能理解的专业表达。 用得越多，它越懂你：首次需要多问几句确认方向，用久了几乎一说就懂。 用得越多，它越快：缓存机制让后续对话越来越省。 RAG进化：成功案例持续入库，越跑越聪明。 输入「新手指南」查看完整功能介绍
- 想把用户输入的繁体自动转简体 →
normalize()完全不生效 - 想统一「〇」「零」「0」→ 这些是不同码位的独立字符，normalize 不处理
- 以为 NFC/NFD 能解决「Ａ」「A」这类全角/半角问题 → 实际上它们属于 Unicode 的兼容字符（
'Ａ'是 U+FF21），需用unicodedata.decomposition()或专门映射
真正有用的中文预处理：先识别再映射
对中文做“规范化”，本质是业务驱动的字符映射，不是 Unicode 层面的归一化。关键步骤是：识别目标类型 → 选择对应工具 → 明确转换边界。
实用建议：
- 繁简转换：用
opencc（推荐）或zhconv，不要碰unicodedata；opencc支持「s2t」「t2s」「s2tw」等策略，且保留标点和数字上下文 - 全角/半角：可借助
unicodedata.decomposition()检查是否为兼容字符，但更稳的方式是查表映射 —— 如'Ａ'→'A'，'１'→'1'，Python 标准库无内置函数，需自己建映射字典或用string.translate() - 中文数字/特殊符号：如「①」「❶」「⒈」，这些是不同区块的字符，
normalize()不合并；需按需替换，例如用正则re.sub(r'[①-⑳]', lambda m: str(ord(m.group()) - 0x245f), text)
什么时候 unicodedata 确实有用？
仅限于中文文本中混入的西文、符号、带音调字母等「可规范等价」部分。
示例场景：
- 用户输入
'café'写成'cafe\u0301'（e + 重音符），用unicodedata.normalize('NFC', s)可还原为标准'café' - 清理 HTML 导出的文本时，遇到
'\u00a0'（不换行空格）或'\u200b'（零宽空格），可用unicodedata.category()扫描并过滤 - 判断某字符是否为中文：用
unicodedata.name(c).startswith('CJK UNIFIED IDEOGRAPH')比正则[\u4e00-\u9fff]更准确（覆盖扩展区 A/B/C）
真正棘手的是混合场景：一段含繁体字、全角标点、西文音调、以及「〇」和「零」混用的文本。这时候 unicodedata.normalize() 最多帮上 10% 的忙，剩下 90% 得靠明确规则 + 分层处理 —— 先做繁简，再做全半角，最后人工校验映射边界。别指望一个 normalize 调用解决所有“看起来一样”的问题。
