为了账号安全,请及时绑定邮箱和手机立即绑定

什么时候元音变音不是元音变音(u-umlaut 映射到 charCode 117)

什么时候元音变音不是元音变音(u-umlaut 映射到 charCode 117)

缥缈止盈 2023-04-01 15:58:20
> let uValFromStr  = "Würzburg".charCodeAt(1)undefined> uValFromStr117> String.fromCharCode(252)'ü'> "Würzburg".charCodeAt(1) === String.fromCharCode(252)false> 我们有一个情况,字符串中的变音符号没有通过简单的字符串比较测试,因为它的值实际上映射到 charCode 117。u-umlaut 应该映射到 charCode 252。注意我们提取字符的 charCode 的前两行。因此,当发生这种情况时,用户输入的文本字符串与前三个字符匹配,但匹配失败,因为代码正在评估 117===252。关于如何发生的任何想法?我们的数据中有许多使用变音符号的用例,这些用例可以正常工作,因此这不是一个地方性问题,而是一个仅针对此输入(到目前为止)的问题。
查看完整描述

1 回答

?
动漫人物

TA贡献1815条经验 获得超10个赞

特定"Würzburg"字符串中的 是使用 (U+0075) 的 Unicode 代码点编写的u,后跟一个对其进行修改的变音组合标记ü(U+0308),但是您要与之比较的是使用单个 Unicode 代码点编写的u-with-umlaut (U+00FC)。几乎所有 JavaScript 的字符串处理都非常简单,这就是它们不相等的原因。这种幼稚(但很快!)的性质有两个部分:1)它不知道组合标记,这就是为什么"Würzburg".length9 而不是 8(如果使用 U+0075 和 U+00FC 编写);和2)JavaScript“字符”实际上是UTF-16 代码单元,可能只是一个代码点的一半("😊".length是 2,例如,因为虽然它是单个 Unicode 代码点 (U+1F60A),但它需要两个代码单元才能用 UTF-16 表示)。(有人可能会争辩说 JavaScript 字符串是UCS-2,因为它们容忍无效的代理项对 [代码单元对一起描述一个代码点],但规范说“......字符串中的每个元素都被视为UTF-16 编码单元值..." )

您可以通过使用normalization比较这两个元音变音 u 来解决这个问题,通过 JavaScript 的(相对较新的)normalize方法:

const word = "Würzburg";


// Iteration moves through the string by code points, not code units

for (const ch of word) {

    console.log(`${ch} = ${ch.codePointAt(0)}`);

}


const char = String.fromCharCode(252);


const normalizedWord = word.normalize();

const normalizedChar = char.normalize();


// Using iteration to grab the second "character" (code point) from the string

const [, secondCharOfWord] = normalizedWord;


console.log(normalizedChar === secondCharOfWord); // true

.as-console-wrapper {

    max-height: 100% !important;

}

在该示例中,我们使用默认规范化(“NFC”,规范化形式 C),它更喜欢特定代码点而不是组合标记,因此单词的规范化版本使用 u-with-umlaut 代码点 U+00FC。normalize通过将参数传递给(例如规范化形式 D,它更喜欢将标记组合到特定字符代码点),还有其他规范化形式可用,但默认值通常是您想要的。



查看完整回答
反对 回复 2023-04-01
  • 1 回答
  • 0 关注
  • 93 浏览
慕课专栏
更多

添加回答

举报

0/150
提交
取消
意见反馈 帮助中心 APP下载
官方微信