```
import unicodedata
import sys

s = '⻝'
print(f"Python 版本: {sys.version}")
print(f"Unicode 版本: {unicodedata.unidata_version}")
print(f"字符: '{s}'")
print(f"Unicode: U+{ord(s):04X}")
print(f"字符名称: {unicodedata.name(s, '未知')}")

# 尝试不同的归一化形式
forms = ['NFC', 'NFD', 'NFKC', 'NFKD']
for form in forms:
result = unicodedata.normalize(form, s)
print(f"{form}: '{result}' (U+{ord(result):04X}) - 是否变化: {s != result}")
```

unicode 姿势 +1

目前知道的：
1. 字素组合字
2. 空白字符识别

还挺神奇的，U+2EDD （⻝）和 U+2F29 （⼩）都是康熙部首字符：

2F29;KANGXI RADICAL SMALL;So;0;ON;<compat> 5C0F;;;;N;;;;;

2FB7;KANGXI RADICAL EAT;So;0;ON;<compat> 98DF;;;;N;;;;;

UnicodeData.txt 里面也都相应标出了 <compat> 的分解形式：一个是 U+5C0F （汉字的“小”），一个是 U+98DF （汉字的“食”），但是它们 NFKC normalize 的结果却不同：

>>> f'U+{ord(unicodedata.normalize('NFKC', chr(0x2F29))):04X}'

'U+5C0F' (中文“小”）

>>> f'U+{ord(unicodedata.normalize('NFKC', chr(0x2FB7))):04X}'

'U+2FB7' (仍然是康熙部首“⻝”）

感觉会不会是 Unicode 的问题……但无论如何，要想手动 normalize 的话应该把 UnicodeData.txt 里面的第六列提出来也可以。但例如 Firefox 用的似乎是 confusables.txt [1]，比 UnicodeData 来说提供了更多基于字形的 normalization ，也可以考虑一下。

[1] https://github.com/unicode-org/icu/blob/main/icu4c/source/data/unidata/confusables.txt

我这边遇到过一次异体字问题，功能是客户自行上传文件，文件名含有一些固定格式的重要信息，需要使用正则匹配解析内容，结果出现了异体字定位了很久才发现差异，怀疑客户是五笔输入并且没有选对字。解决办法是加了个 replaceAll 给全部替换掉，暂时只能这么解决了。
'内'、'內'