谁执行 unicode 规范化以及何时执行？答案

【问题标题】：Who performs unicode normalization and when?谁执行 unicode 规范化以及何时执行？
【发布时间】：2017-12-29 08:05:52
【问题描述】：

根据JavaScript - The Definitive guide，

JavaScript 假定它正在解释的源代码已经被规范化，并且不会尝试对标识符、字符串或正则表达式本身进行规范化。

Unicode 标准定义了所有字符的首选编码，并指定了将文本转换为适合比较的规范形式的规范化过程。

如果 JS 不规范化 Unicode，那么是谁在什么时候做的？

如果 JavaScript 没有规范化 Unicode，那是怎么回事

"café" === "caf\u00e9"   // => true

为什么是

"café" === "cafe\u0301"   // => false

因为两者（\u00e9 和 e\u0301）都是 Unicode 方式来形成 é。

【问题讨论】：

标签： javascript unicode

【解决方案1】：

您混淆了 unicode 规范化和字符串转义。

"café"

…是由code points 0x63, 0x61, 0x66, 0xe9 的字符组成的字符串。

您可以使用转义表示获得完全相同的字符串

"caf\u00e9"
// or even
"\u0063\u0061\u0066\u00e9"
// or why not
"\u0063\u0061fé"

当读取这样的字符串时，javascript 会取消转义字符串。也就是说，它用匹配的字符替换转义序列。将“\n”替换为新行的过程完全相同。

现在，您的第二个示例实际上是另一个字符串，因为它没有被规范化。它是由字符 0x63、0x61、0x66、0x65、0x301 组成的字符串。由于没有发生标准化，所以它不是同一个字符串。

现在尝试使用相同的字符串，使用该序列，您无法使用键盘键入，但我在这里为您复制粘贴："café"。立即测试：

> a = "café"     // this one is copy-pasted with the combining acute
> b = "café"     // this one is typed using the "é" key on my keyboard
> a === "cafe\u0301"
<- true
> b === "cafe\u0301"
<- false
> a === "caf\u00e9"
<- false
> b === "caf\u00e9"
<- true
> a === b
<- false
// Now just making sure...
> a.length
<- 5
> b.length
<- 4

“café”和“café”呈现相同的事实并不使它们成为相同的字符串。 JavaScript 比较字符串，发现0x63, 0x61, 0x66, 0xe9 和0x63, 0x61, 0x66, 0x65, 0x301 不一样，返回false。

【讨论】：

我如何知道一个字符串是否被规范化？你是怎么发现 cafe\u0301 没有被规范化而 caf\u00e9 被规范化的？
这是一个敏感的问题。在您定义您认为是“规范”之前，两者都不是，因为 JS 没有定义一个。有several norms。大多数浏览器都支持normalize 方法，这可能很方便。
Unicode 标准定义a === b 应该返回true。一个 Powershell 示例："café".Normalize('formD').Length -eq 5; "café".Normalize('formC').Length -eq 4; "café".Normalize('formD') -eq "café".Normalize('formC') 返回 true 三次。
unicode 标准与 JavaScript（或任何与之相关的编程语言）无关，我真的不明白 powershell 行为如何帮助 OP 处理他的 javascript 代码。