Python 中 Unicode 正规化的边缘情况

很多 Python 开发者觉得：

unicodedata.normalize()

只是：

“把 Unicode 字符统一格式”

但实际上：

Unicode 正规化（Normalization）远比想象中复杂。

尤其：

用户名比较

搜索引擎

数据库存储

文件系统

URL

安全过滤

OCR

爬虫

里。

很多“看起来一样”的字符串：

实际上并不相等

一、最经典问题：视觉相同，但字符串不同

例如：

s1 = "é"

s2 = "é"

看起来完全一样。

但：

print(s1 == s2)

输出：

False

因为：

s1

是：

U+00E9

LATIN SMALL LETTER E WITH ACUTE

单个字符。

s2

实际上是：

U+0065 e

U+0301 COMBINING ACUTE ACCENT

也就是：

e + 重音组合符

二、正规化就是“统一表示方式”

Python 提供：

import unicodedata

然后：

unicodedata.normalize("NFC", s)

即可统一。

例如：

import unicodedata

s1 = "é"

s2 = "é"

print(

unicodedata.normalize("NFC", s1)

==

unicodedata.normalize("NFC", s2)

)

输出：

True

三、NFC 与 NFD 的差异

这是最容易混淆的地方。

NFC

Canonical Composition

规范组合

尽量合并字符。

例如：

e + ´

→ é

NFD

Canonical Decomposition

规范分解

尽量拆开。

例如：

é

→ e + ´

四、还有更危险的 NFKC/NFKD

很多人完全不知道：

兼容正规化

会：

改变字符语义

例如：

s = "①"

经过：

unicodedata.normalize("NFKC", s)

变成：

"1"

五、全角字符会被折叠

例如：

"ＡＢＣ"

NFKC 后：

"ABC"

因此：

用户名系统

搜索系统

登录系统

如果没考虑：

全角/半角

就会出问题。

六、数学字符也会被破坏

例如：

"?"

这是：

MATHEMATICAL BOLD CAPITAL A

但：

unicodedata.normalize("NFKC", s)

后：

"A"

字体语义丢失。

七、某些“不同语言字符”看起来一样

例如：

拉丁字母 A

U+0041

西里尔字母 А

U+0410

视觉几乎一样。

但：

"A" == "А"

结果：

False

正规化：

normalize()

也不会统一。

因为：

它们语义不同

八、这会导致“同形异义攻击”

例如：

аррӏе.com

看起来像：

apple.com

但实际：

部分字符来自：

西里尔

希腊

这类攻击叫：

Homoglyph Attack

Unicode 正规化：

无法完全解决

九、Emoji 正规化更复杂

例如：

"?‍?‍?"

实际上是：

多个 emoji + ZWJ

组成。

其中：

ZWJ = Zero Width Joiner

如果错误正规化或切分：

家庭 emoji

可能被拆散。

十、Variation Selector 会让字符“看起来没变化”

例如：

"❤"

和：

"❤️"

看起来几乎一样。

但：

后者包含：

U+FE0F Variation Selector-16

用于：

emoji 风格显示

因此：

len("❤️")

可能是：

2

而不是 1。

十一、字符串长度可能正规化后变化

例如：

len("é")

可能：

1

但：

len(unicodedata.normalize("NFD", "é"))

变成：

2

这会影响：

截断

数据库存储

UI 对齐

字符限制

十二、文件系统正规化差异极坑

macOS

HFS+/APFS 常使用：

NFD-like

存文件名。

Linux

通常原样保存。

Windows

更接近：

NFC

因此：

同一个文件名

跨平台可能：

无法匹配

重复文件

git 冲突

十三、数据库唯一索引问题

例如：

用户注册：

José

另一个用户：

José

视觉一样。

但如果数据库：

不做正规化

可能：

允许重复注册

十四、正则表达式也会受影响

例如：

import re

re.match("é", "é")

可能失败。

因为：

底层 code point 不同

很多人误以为：

regex 会自动理解 Unicode 等价

实际上不会。

十五、排序问题

例如：

sorted(["é", "é"])

结果可能不稳定。

因为：

底层编码不同

搜索引擎和数据库通常会：

normalize

casefold

locale compare

组合处理。

十六、casefold 比 lower 更复杂

例如：

"ß".lower()

结果：

"ß"

但：

"ß".casefold()

结果：

"ss"

因此：

很多“Unicode 安全比较”实际上应该：

normalize + casefold

组合。

十七、推荐的安全比较方式

通常：

import unicodedata

def safe_equal(a, b):

return (

unicodedata.normalize("NFKC", a).casefold()

==

unicodedata.normalize("NFKC", b).casefold()

)

但：

即使这样也不能完全防御同形攻击。

十八、不要轻易使用 NFKC

很多系统：

盲目 NFKC

会：

丢失数学语义

破坏排版

改变字符含义

影响密码

例如密码：

?BC123

NFKC 后：

ABC123

安全性直接变化。

十九、密码系统尤其危险

很多网站会：

normalize(password)

导致：

用户输入的密码被修改

这其实并不总安全。

因为：

Unicode 等价

≠

用户认为等价

二十、Python 自己内部也依赖 Unicode 正规化

例如：

Python 标识符：

变量名

会做：

NFKC normalization

因此：

某些看起来不同的变量名：

实际上会冲突