基于UCD检测Unicode规范化中断变更的方法可行性问询

你的初步筛选思路方向非常正确，而且已经抓住了Unicode规范化变化的核心维度——完全没必要退回到只关注分解映射及类型的方案。咱们来拆解下为什么：

你的现有方案的合理性 #

你提到的几个筛选条件，都是利用Unicode字符数据库（UCD）中官方预计算的属性，既高效又能精准覆盖目标场景：

• 规范组合类（ccc != 0）：这部分字符本身就是规范组合/分解体系的核心参与者，它们的存在必然会导致规范化过程中的结构调整（比如重新排序组合字符），是筛选“会变化”字符的基础条件。
• NFC_QC/NFD_QC等快速检查属性：NFC_QC != 'Y'这类标记，本质是官方提前帮你跑完了完整的规范化算法，直接告诉你该字符在对应规范下需要调整——这比自己实现分解/组合逻辑高效太多，而且能避免手动处理时遗漏的边缘场景（比如组合顺序依赖）。
• 大小写折叠相关属性（CWKCF='Y'或CWCF='Y'）：这两个属性直接对应了casefold和NFKC_Casefold会产生变化的字符，覆盖了普通大小写映射之外的特殊折叠规则（比如多字符映射、兼容字符的折叠），同样是官方验证过的可靠标记。

为什么不能只关注分解映射及类型？ #

只看Decomposition_Type和Decomposition_Mapping会漏掉很多关键的规范化“中断”场景：

• 有些规范化变化不涉及分解/合成，而是组合顺序调整：比如两个ccc非0的字符顺序不符合规范要求，NFC会重新排序它们，但它们的分解映射本身并没有变化——这种情况只有通过ccc或QC属性才能捕捉到。
• 大小写折叠的特殊规则很多和分解映射无关：比如某些字符的casefold是跨脚本的映射，或者结合了NFKC的兼容处理，这些场景单纯看分解映射完全覆盖不了，而CWKCF/CWCF已经帮你标记好了这些特殊案例。
• Unicode的稳定性变更中，很多是对QC属性、ccc的微调，而不是分解映射的修改：比如某个字符的ccc从0改为非0，或者QC状态从'Y'变为'N'，这些变化直接影响规范化行为，但分解映射可能完全没变。

优化你的方案的小建议 #

如果你的目标是追踪不同Unicode版本（4-6）间的规范化“中断”变更，还可以在现有基础上补充这些细节：

• 跨版本属性对比：比如同一字符在Unicode 5和6中，ccc、QC属性、大小写折叠标记是否发生变化——这些变化就是你要找的“中断”点。
• 深入拆解Case_Folding字段：除了CWKCF/CWCF，关注Case_Folding中的映射类型（C/F/S/T），尤其是T类型（特殊映射），这类字符的折叠规则最容易在版本迭代中调整。
• 留意兼容分解相关属性：如果要覆盖NFKC的变化，还要结合NFKC_QC以及Decomposition_Type为“兼容”的字符，这些字符的规范化行为在版本间也可能有调整。

总的来说，你的初步方案已经是高效且全面的最优选择，它充分利用了UCD的官方属性，避免了重复造轮子，还能覆盖到分解映射之外的所有规范化变化场景。

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