为何NFKC规范化会丢失上标与下标信息？

这个问题问到点子上了——NFKC的转换逻辑其实是由它的核心定位决定的，咱们从几个关键角度拆解：

1. NFKC的本质：追求「功能等价性」而非「视觉/语义完整性」 #

NFKC全称是Normalization Form Compatibility Composition，重点就在「Compatibility（兼容性）」这俩字上。它的设计目标不是保留所有字符的视觉或上下文语义，而是把那些视觉呈现不同，但功能上等价的字符统一成标准形式。

比如上标字符¹（U+00B9）、²（U+00B2），它们本质上和ASCII数字1、2在「表示数值」这个核心功能上是完全等价的。NFKC的逻辑是：不管你用什么视觉样式（上标、下标、全角）来表示这个数值，都应该被当成同一个内容处理——这样在搜索、排序、字符串比较时，就不会出现“搜不到用了上标数字的内容”这种尴尬情况。

2. 设计依据的历史与实用场景 #

这种转换规则的诞生，和Unicode兼容旧编码体系的需求直接相关：

• 早期不同系统、编码里，会用特殊字符实现排版效果（比如上标数字），但这些字符本质上就是普通数字的“排版变体”；
• NFKC的作用就是消除这些变体带来的歧义，让跨系统的文本处理更一致——比如你在一个系统里输入“x²”，另一个系统里输入“x2”，NFKC处理后都会变成“x2”，这样字符串比较会返回相等，搜索时也能互相匹配。

3. 关于「信息丢失」：这是场景选择的权衡 #

你说得完全没错，上标数字有时候确实承载着特定上下文——比如数学里的指数、化学分子式里的原子数，这时候NFKC的转换就会破坏语义。但这其实是NFKC的适用边界：

• 它适合只关心「文本内容本身」的场景（比如文本搜索、数据库存储的标准化）；
• 如果需要保留排版或专业语义，你应该避免使用NFKC，改用其他方式：比如用HTML的<sup>标签标记上标，或者直接保留原始的上标字符，选择NFC/NFD这类只处理字符组合分解的规范化形式（它们不会转换兼容字符）。

总结一下：NFKC的转换是为了实现功能等价性的统一，牺牲了部分视觉/上下文信息——这是一种明确的取舍，需要根据你的具体使用场景来判断是否适用。

内容的提问来源于stack exchange，提问作者codesniffer