在哪些情况下 normalize('NFKC') 方法有效？答案

【问题标题】：In which cases normalize('NFKC') method work?在哪些情况下 normalize('NFKC') 方法有效？
【发布时间】：2021-11-02 14:10:33
【问题描述】：

我尝试对不同字符使用normalize('NFKC') 方法，但没有成功。幸运的是，NFC 不能这么说。在可能的情况下，normalize('NFC') 总是用单个代码点替换多个代码点。例如：

let t1 = `\u00F4`; //ô
let t2 = `\u006F\u0302`; //ô
console.log(t2.normalize('NFC') == t1); //true

下面是 NFKC 的示例，它永远不会起作用：

let s1 = '\uFB00'; //"ﬀ"
let s2 = '\u0066\u0066'; //"ff"
console.log(s2.normalize('NFKC') == s1); //false

我之前认为NFKC 将多个代码点替换为代表兼容字符的单个代码点。简单来说，我以为NFKC会用\uFB00代替\u0066\u0066。

如果NFKC 不能这样工作，那么……它是如何工作的？

【问题讨论】：

连字 ff 与连续两个纯“f”字符不同。
另请注意，在同一字符串上使用 NFC 也不会标准化为连字字符。
@Pointy 是的，不一样。但这两个符号是兼容的。这就是为什么我想我所想的。那么NFKC是做什么的呢？搜索了这方面的信息，没有找到有用的东西
@Pointy：不，不！来自 Unicode 数据：DB00,...,<compat> 0066 0066,...。而且从兼容性的意义来看，如果连字与分解字符不兼容，那就大错特错了（这会使兼容性变得毫无用处）。 ——问题是方向。我们永远不应该“连接”一个字符（这是字体的任务），但我们可能想要简化一些事情（兼容性的原因）
@Pointy：忘记理解。这是关于“自然/人类”的事情，所以这是不可能的。太多的例外，特殊情况，旧错误等。而且不同的人有不同的看法（在学术层面上也是如此）。语言是如此复杂。 Unicode 是“字符”部分的表示，但是它太复杂而无法制定秩序（它试图描述世界，而不是制定新的综合规则）。事实上，Unicode 不仅仅是 UnicodeData（数据库），而是很多特殊情况的特殊文档）。地图、数字、日期、颜色：每年我们都会发现新问题。

【解决方案1】：

问题是NFKC（以及NFKD）支持兼容且规范等效的规范化。

选择的完全分解类型取决于所涉及的 Unicode 规范化形式。对于 NFC 或 NFD，进行完全规范分解，仅使用规范 Decomposition_Mapping 值。 对于 NFKC 或 NFKD，进行完整的兼容性分解，利用规范和兼容性 Decomposition_Mapping 值。

这完全可以理解，因为正如 MDN 所说：

所有规范等价的序列也是兼容的，但反之则不然。

但同样值得注意的是，NFKC 以不同的方式进行兼容且规范等效的规范化。 NFKC 的规范化等效规范化的产生方式与 NFC 相同。例如：

//"ô" (U+00F4) -> "a" (U+006F) + " ̂" (U+0302) -> "â" (U+00F4)
let c1 = `\u006F\u0302`; //ô
console.log(c1.normalize('NFKC').length); //1

但此参数的兼容规范化工作方式不同。 spec 说：

规范化形式 KC 不会尝试将字符序列映射到兼容性组合。例如，“office”的兼容性组合不会产生“o\uFB03ce”，即使“\uFB03”是与三个字符“ffi”序列的兼容性等效的字符。换言之，NFC 和 NFKC 的组成阶段是相同的——只是它们的分解阶段不同，NFKC 应用了兼容性分解。

例如：

//"ﬀ"(U+FB00) -> "f"(U+0066) + "i"(U+0066) -> "f"(U+0066) + "i"(U+0066)
let c2 = '\u0066\u0066'; //ff
console.log(c2.normalize('NFKC').length); //2

【讨论】：