这个Google闭包UTF-8字符串有效吗？

Question

在Google闭包中，UTF-8到字节数组测试是字符串

\u0000\u007F\u0080\u07FF\u0800\uFFFF

它应该转换为数组。

[0x00, 0x7F, 0xC2, 0x80, 0xDF, 0xBF, 0xE0, 0xA0, 0x80, 0xEF, 0xBF, 0xBF]

我尝试过一些其他的JavaScript和TypeScript UTF-8字节数组实现，他们声称UTF-8字符串无效。

字符串似乎涵盖了从1字节到2字节到3字节值的转换值。

谷歌是正确的还是其他图书馆？

Answer 1

谷歌是对的。

字符串'\u0000\u007F\u0080\u07FF\u0800\uFFFF'表示Unicode代码点U+0000 U+007F U+0080 U+07FF U+0800 U+FFFF。

正如谷歌所说，将这些代码点直译为UTF-8确实是字节00 7F C2 80 DF BF E0 A0 80 EF BF BF。

注意，U+FFFF是一个非字符码点，根据Unicode标准

“非字符”是在Unicode标准中永久保留的用于内部使用的代码点。 ..。 在Unicode1.0中，代码点U+FFFE、和U+FFFF在代码图表中被注释为“非字符代码”，而不是实际的名称被标记为"Not字符“。标准的后期版本中的“非字符”一词是从早期的注解和标签演变而来的。

特别是：

问:非字符是否用于交换？ 答:没有。它们是内部使用的解释。例如，它们可能在内部用作字符串中特定类型的对象占位符。或者，它们可以用于排序规则裁剪，作为不同脚本的“真实”字符的权重之间加权的目标，从而简化了对“字母索引”实现的支持。 问：是中禁止使用的非字符吗？ 答：这个问题引起了的一些争议，因为Unicode标准对非字符的状态有点模糊。标准中“非字符”定义的正式措辞一直表明，非字符“永远不应该互换”。导致一些人认为该定义实际上意味着“不应该互换”，因此，在任何Unicode字符串中存在一个非字符会立即使该字符串按照标准格式错误。但是非字符的意图需要在有限的上下文中交换它们，至少需要跨API，甚至通过数据文件和其他“交换”手段，这样就可以按预期的方式处理它们。在最初的定义中选择“应该”一词是有意的，并指出人们不应该试图精确地交换非字符，因为--它们的解释严格地说是使用它们的实现--的内部解释，因此它们没有公开可互换的语义。但是，核心规格案文和字符名称清单中的其他内容丰富的措辞不同，措辞更加强烈，导致相互矛盾的解释。 考虑到这种含糊不清的意图，世界协调委员会在2013年发布了更正#9，从非字符的定义中删除了“而且永远不应该互换”这一短语，以明确禁止交换并不是非字符正式定义的一部分。更正#9已被纳入Unicode 7.0的核心规范。 问:在Unicode字符串和UTFs?中，非字符无效吗？ 绝对不是。非字符不会导致Unicode字符串在任何UTF中格式错误。在上表中可以清楚地看到这一点，其中每个非字符代码点都有一个格式良好的表示形式的，在UTF-32中，在UTF-16中，在中，在UTF-8中。在一个UTF表示和另一个表示之间转换非字符代码点的实现必须正确地保留这些值。事实上，它们被称为“非字符”而不是用于开放交换，这并不意味着它们在某种程度上是非法的或无效的代码点，使得包含它们的字符串无效。