首頁猿問什么時候元音變音不是元音變音（u-...

什么時候元音變音不是元音變音（u-umlaut 映射到 charCode 117）

JavaScript

縹緲止盈 2023-04-01 15:58:20

> let uValFromStr = "Wu?rzburg".charCodeAt(1)undefined> uValFromStr117> String.fromCharCode(252)'ü'> "Wu?rzburg".charCodeAt(1) === String.fromCharCode(252)false> 我們有一個情況，字符串中的變音符號沒有通過簡單的字符串比較測試，因為它的值實際上映射到 charCode 117。u-umlaut 應該映射到 charCode 252。注意我們提取字符的 charCode 的前兩行。因此，當發生這種情況時，用戶輸入的文本字符串與前三個字符匹配，但匹配失敗，因為代碼正在評估 117===252。關于如何發生的任何想法？我們的數據中有許多使用變音符號的用例，這些用例可以正常工作，因此這不是一個地方性問題，而是一個僅針對此輸入（到目前為止）的問題。

查看完整描述

1 回答

動漫人物

TA貢獻1815條經驗獲得超10個贊

該u?特定"Wu?rzburg"字符串中的是使用 (U+0075) 的 Unicode 代碼點編寫的u，后跟一個對其進行修改的變音組合標記ü(U+0308)，但是您要與之比較的是使用單個 Unicode 代碼點編寫的u-with-umlaut (U+00FC)。幾乎所有 JavaScript 的字符串處理都非常簡單，這就是它們不相等的原因。這種幼稚（但很快?。┑男再|有兩個部分：1）它不知道組合標記，這就是為什么"Wu?rzburg".length9 而不是 8（如果u?使用 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 = "Wu?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 關注
117 瀏覽

關注

添加回答

舉報

0/150

提交

取消

亚洲在线久爱草,狠狠天天香蕉网,天天搞日日干久草,伊人亚洲日本欧美

熱搜

最近搜索清空

什么時候元音變音不是元音變音（u-umlaut 映射到 charCode 117）

什么時候元音變音不是元音變音（u-umlaut 映射到 charCode 117）

1 回答

添加回答