JavaScript 如何正確處理 Unicode 編碼問題！

發表於2019-01-08

JavaScript 處理 Unicode 的方式至少可以說是令人驚訝的。本文解釋了 JavaScript 中的處理 Unicode 相關的痛點，提供了常見問題的解決方案，並解釋了ECMAScript 6 標準如何改進這種情況。

Unicode 基礎知識

在深入研究 JavaScript 之前，先解釋一下 Unicode 一些基礎知識，這樣在 Unicode 方面，我們至少都瞭解一些。

Unicode 是目前絕大多數程式使用的字元編碼，定義也很簡單，用一個 碼位(code point) 對映一個字元。碼位值的範圍是從 U+0000 到 U+10FFFF，可以表示超過 110 萬個字元。下面是一些字元與它們的碼位。

A 的碼位 U+0041
a 的碼位 U+0061
© 的碼位 U+00A9
☃ 的碼位 U+2603
的碼位 U+1F4A9

碼位通常被格式化為十六進位制數字，零填充至少四位數，格式為 U +字首。

Unicode 最前面的 65536 個字元位，稱為 基本多文種平面（BMP-—Basic Multilingual Plane），又簡稱為“零號平面”, plane 0）,它的碼位範圍是從 U+0000 到 U+FFFF。最常見的字元都放在這個平面上，這是 Unicode 最先定義和公佈的一個平面。

剩下的字元都放在 輔助平面(Supplementary Plane)或者 星形平面(astral planes) ，碼位範圍從 U+010000 一直到 U+10FFFF，共 16 個輔助平面。

輔助平面內的碼位很容易識別:如果需要超過 4 個十六進位制數字來表示碼位，那麼它就是一個輔助平面內的碼。

現在對 Unicode 有了基本的瞭解，接下來看看它如何應用於 JavaScript 字串。

轉義序列

在谷歌控制檯輸入如下:

>> '\x41\x42\x43'
'ABC'

>> '\x61\x62\x63'
'abc'

>> '\x41\x42\x43'

'ABC'

>> '\x61\x62\x63'

'abc'

以下稱為十六進位制轉義序列。它們由引用匹配碼位的兩個十六進位制數字組成。例如，\x41 碼位為 U+0041 表示大寫字母 A。這些轉義序列可用於 U+0000 到 U+00FF 範圍內的碼位。

同樣常見的還有以下型別的轉義:

>> '\u0041\u0042\u0043'
'ABC'

>> 'I \u2661 JavaScript!'
'I ♡ JavaScript!'

>> '\u0041\u0042\u0043'

'ABC'

>> 'I \u2661 JavaScript!'

'I ♡ JavaScript!'

這些被稱為 Unicode轉義序列。它們由表示碼位的 4 個十六進位制數字組成。例如，\u2661 表示碼位為 \U+2661 表示一個心。這些轉義序列可以用於 U+0000 到 U+FFFF 範圍內的碼位，即整個基本平面。

但是其他的所有輔助平面呢？我們需要 4 個以上的十六進位制數字來表示它們的碼位，那麼如何轉義它們呢?

在 ECMAScript 6中，這很簡單，因為它引入了一種新的轉義序列: Unicode 碼位轉義。例如:

>> '\u{41}\u{42}\u{43}'
'ABC'

>> '\u{1F4A9}'
'' // U+1F4A9 PILE OF POO

>> '\u{41}\u{42}\u{43}'

'ABC'

>> '\u{1F4A9}'

'' // U+1F4A9 PILE OF POO

在大括號之間可以使用最多 6 個十六進位制數字，這足以表示所有 Unicode 碼位。因此，通過使用這種型別的轉義序列，可以基於其程式碼位輕鬆轉義任何 Unicode 碼位。

為了向後相容 ECMAScript 5 和更舊的環境，不幸的解決方案是使用代理對:

>> '\uD83D\uDCA9'
'' // U+1F4A9 PILE OF POO

>> '\uD83D\uDCA9'

'' // U+1F4A9 PILE OF POO

在這種情況下，每個轉義表示代理項一半的碼位。兩個代理項就組成一個輔助碼位。

注意，代理項對碼位與原始碼位全不同。有公式可以根據給定的輔助碼位來計算代理項對碼位，反之亦然——根據代理對計算原始輔助程式碼位。

輔助平面（Supplementary Planes）中的碼位，在 UTF-16 中被編碼為一對16 位元長的碼元（即32bit,4Bytes），稱作代理對(surrogate pair)，具體方法是：

碼位減去 0x10000,得到的值的範圍為 20 位元長的 0..0xFFFFF.
高位的 10 位元的值（值的範圍為 0..0x3FF）被加上 0xD800 得到第一個碼元或稱作高位代理。
低位的 10 位元的值（值的範圍也是 0..0x3FF）被加上 0xDC00 得到第二個碼元或稱作低位代理（low surrogate），現在值的範圍是 0xDC00..0xDFFF.

使用代理對，所有輔助平面中的碼位(即從 U+010000 到 U+10FFFF )都可以表示，但是使用一個轉義來表示基本平面的碼位，以及使用兩個轉義來表示輔助平面中的碼位，整個概念是令人困惑的，並且會產生許多惱人的後果。

使用 JavaScript 字串方法來計算字元長度

例如，假設你想要計算給定字串中的字元個數。你會怎麼做呢?

首先想到可能是使用 length 屬性。

>> 'A'.length // 碼位： U+0041 表示 A
1

>> 'A' == '\u0041'
true

>> 'B'.length // 碼位： U+0042 表示 B
1

>> 'B' == '\u0042'
true

>> 'A'.length // 碼位： U+0041 表示 A

>> 'A' == '\u0041'

true

>> 'B'.length // 碼位： U+0042 表示 B

>> 'B' == '\u0042'

true

在這些例子中，字串的 length 屬性恰好反映了字元的個數。這是有道理的：如果我們使用轉義序列來表示字元，很明顯，我們只需要對每個字元進行一次轉義。但情況並非總是如此！這裡有一個稍微不同的例子:

>> ''.length // 碼位： U+1D400 表示 Math Bold 字型大寫 A
2

>> '' == '\uD835\uDC00'
true

>> ''.length // 碼位： U+1D401 表示 Math Bold 字型大寫 B
2

>> '' == '\uD835\uDC01'
true

>> ''.length // U+1F4A9 PILE OF POO
2

>> '' == '\uD83D\uDCA9'
true

>> ''.length // 碼位： U+1D400 表示 Math Bold 字型大寫 A

>> '' == '\uD835\uDC00'

true

>> ''.length // 碼位： U+1D401 表示 Math Bold 字型大寫 B

>> '' == '\uD835\uDC01'

true

>> ''.length // U+1F4A9 PILE OF POO

>> '' == '\uD83D\uDCA9'

true

在內部，JavaScript 將輔助平面內的字元表示為代理對，並將單獨的代理對部分開為單獨的 “字元”。如果僅使用 ECMAScript 5 相容轉義序列來表示字元，將看到每個輔助平面內的字元都需要兩個轉義。這是令人困惑的，因為人們通常用 Unicode 字元或圖形來代替。

計算輔助平面內的字元個數

回到這個問題:如何準確地計算 JavaScript 字串中的字元個數 ? 訣竅就是如何正確地解析代理對，並且只將每對代理對作為一個字元計數。你可以這樣使用:

var regexAstralSymbols = /[\uD800-\uDBFF][\uDC00-\uDFFF]/g;

function countSymbols(string) {
    return string
        // Replace every surrogate pair with a BMP symbol.
        .replace(regexAstralSymbols, '_')
        // …and *then* get the length.
        .length;
}

var regexAstralSymbols = /[\uD800-\uDBFF][\uDC00-\uDFFF]/g;

function countSymbols(string) {

return string

// Replace every surrogate pair with a BMP symbol.

.replace(regexAstralSymbols, '_')

// …and *then* get the length.

.length;

}

或者，如果你使用 Punycode.js，利用它的實用方法在 JavaScript 字串和 Unicode 碼位之間進行轉換。decode 方法接受一個字串並返回一個 Unicode 編碼位陣列;每個字元對應一項。

function countSymbols(string) {
    return punycode.ucs2.decode(string).length;
}

function countSymbols(string) {

return punycode.ucs2.decode(string).length;

}

在 ES6 中，可以使用 Array.from 來做類似的事情，它使用字串的迭代器將其拆分為一個字串陣列，每個字串陣列包含一個字元:

function countSymbols(string) {
    return Array.from(string).length;
}

function countSymbols(string) {

return Array.from(string).length;

}

或者，使用解構運算子 ... :

function countSymbols(string) {
    return [...string].length;
}

function countSymbols(string) {

return [...string].length;

}

使用這些實現，我們現在可以正確地計算碼位，這將導致更準確的結果:

>> countSymbols('A') // 碼位：U+0041 表示 A
1

>> countSymbols('') // 碼位： U+1D400 表示 Math Bold 字型大寫 A
1

>> countSymbols('') // U+1F4A9 PILE OF POO
1

>> countSymbols('A') // 碼位：U+0041 表示 A

>> countSymbols('') // 碼位： U+1D400 表示 Math Bold 字型大寫 A

>> countSymbols('') // U+1F4A9 PILE OF POO

找撞臉

考慮一下這個例子:

>> 'mañana' == 'mañana'
false

>> 'mañana' == 'mañana'

false

JavaScript告訴我們，這些字串是不同的，但視覺上，沒有辦法告訴我們！這是怎麼回事?

JavaScript 如何正確處理 Unicode 編碼問題！

JavaScript轉義工具會告訴你，原因如下:

>> 'ma\xF1ana' == 'man\u0303ana'
false

>> 'ma\xF1ana'.length
6

>> 'man\u0303ana'.length
7

>> 'ma\xF1ana' == 'man\u0303ana'

false

>> 'ma\xF1ana'.length

>> 'man\u0303ana'.length

第一個字串包含碼位 U+00F1 表示字母 n 和 n 頭上波浪號，而第二個字串使用兩個單獨的碼位(U+006E表示字母 n 和 U+0303 表示波浪號)來建立相同的字元。這就解釋了為什麼它們的長度不同。

然而，如果我們想用我們習慣的方式來計算這些字串中的字元個數，我們希望這兩個字串的長度都為 6，因為這是每個字串中可視可區分的字元的個數。要怎樣才能做到這一點呢?

在ECMAScript 6 中，解決方案相當簡單:

function countSymbolsPedantically(string) {
    // Unicode Normalization, NFC form, to account for lookalikes:
    var normalized = string.normalize('NFC');
    // Account for astral symbols / surrogates, just like we did before:
    return punycode.ucs2.decode(normalized).length;
}

function countSymbolsPedantically(string) {

// Unicode Normalization, NFC form, to account for lookalikes:

var normalized = string.normalize('NFC');

// Account for astral symbols / surrogates, just like we did before:

return punycode.ucs2.decode(normalized).length;

}

String.prototype 上的 normalize 方法執行 Unicode規範化，這解釋了這些差異。如果有一個碼位表示與另一個碼位後跟組合標記相同的字元，則會將其標準化為單個碼位形式。

>> countSymbolsPedantically('mañana') // U+00F1
6
>> countSymbolsPedantically('mañana') // U+006E + U+0303
6

>> countSymbolsPedantically('mañana') // U+00F1

>> countSymbolsPedantically('mañana') // U+006E + U+0303

為了向後相容 ECMAScript5 和舊環境，可以使用 String.prototype.normalize polyfill。

計算其他組合標記

然而，上述方案仍然不是完美的——應用多個組合標記的碼位總是導致單個可視字元，但可能沒有 normalize 的形式，在這種情況下，normalize 是沒有幫助。例如:

>> 'q\u0307\u0323'.normalize('NFC') // `q̣̇`
'q\u0307\u0323'

>> countSymbolsPedantically('q\u0307\u0323')
3 // not 1

>> countSymbolsPedantically('Z͑ͫ̓ͪ̂ͫ̽͏̴̙̤̞͉͚̯̞̠͍A̴̵̜̰͔ͫ͗͢L̠ͨͧͩ͘G̴̻͈͍͔̹̑͗̎̅͛́Ǫ̵̹̻̝̳͂̌̌͘!͖̬̰̙̗̿̋ͥͥ̂ͣ̐́́͜͞')
74 // not 6

>> 'q\u0307\u0323'.normalize('NFC') // `q̣̇`

'q\u0307\u0323'

>> countSymbolsPedantically('q\u0307\u0323')

3 // not 1

>> countSymbolsPedantically('Z͑ͫ̓ͪ̂ͫ̽͏̴̙̤̞͉͚̯̞̠͍A̴̵̜̰͔ͫ͗͢L̠ͨͧͩ͘G̴̻͈͍͔̹̑͗̎̅͛́Ǫ̵̹̻̝̳͂̌̌͘!͖̬̰̙̗̿̋ͥͥ̂ͣ̐́́͜͞')

74 // not 6

如果需要更精確的解決方案，可以使用正規表示式從輸入字串中刪除任何組合標記。

//  將下面的正規表示式替換為經過轉換的等效表示式，以使其在舊環境中工作

var regexSymbolWithCombiningMarks = /(\P{Mark})(\p{Mark}+)/gu;

function countSymbolsIgnoringCombiningMarks(string) {
    // 刪除任何組合字元，只留下它們所屬的字元:
    var stripped = string.replace(regexSymbolWithCombiningMarks, function($0, symbol, combiningMarks) {
        return symbol;
    });
    
    return punycode.ucs2.decode(stripped).length;
}

// 將下面的正規表示式替換為經過轉換的等效表示式，以使其在舊環境中工作

var regexSymbolWithCombiningMarks = /(\P{Mark})(\p{Mark}+)/gu;

function countSymbolsIgnoringCombiningMarks(string) {

// 刪除任何組合字元，只留下它們所屬的字元:

var stripped = string.replace(regexSymbolWithCombiningMarks, function($0, symbol, combiningMarks) {

return symbol;

});

return punycode.ucs2.decode(stripped).length;

}

此函式刪除任何組合標記，只留下它們所屬的字元。任何不匹配的組合標記(在字串開頭)都保持不變。這個解決方案甚至可以在 ECMAScript3 環境中工作，並且它提供了迄今為止最準確的結果:

>> countSymbolsIgnoringCombiningMarks('q\u0307\u0323')
1
>> countSymbolsIgnoringCombiningMarks('Z͑ͫ̓ͪ̂ͫ̽͏̴̙̤̞͉͚̯̞̠͍A̴̵̜̰͔ͫ͗͢L̠ͨͧͩ͘G̴̻͈͍͔̹̑͗̎̅͛́Ǫ̵̹̻̝̳͂̌̌͘!͖̬̰̙̗̿̋ͥͥ̂ͣ̐́́͜͞')
6

>> countSymbolsIgnoringCombiningMarks('q\u0307\u0323')

>> countSymbolsIgnoringCombiningMarks('Z͑ͫ̓ͪ̂ͫ̽͏̴̙̤̞͉͚̯̞̠͍A̴̵̜̰͔ͫ͗͢L̠ͨͧͩ͘G̴̻͈͍͔̹̑͗̎̅͛́Ǫ̵̹̻̝̳͂̌̌͘!͖̬̰̙̗̿̋ͥͥ̂ͣ̐́́͜͞')

計算其他型別的圖形叢集

上面的演算法仍然是一個簡化—它還是無法正確計算像這樣的字元：நி，漢語言由連體的 Jamo 組成，如 깍，表情字元序列，如 ‍‍‍ （( U+200D + U+200D + + U+200D + ）或其他類似字元。

Unicode 文字分段上的 Unicode 標準附件＃29 描述了用於確定字形簇邊界的演算法。對於適用於所有 Unicode指令碼的完全準確的解決方案，請在 JavaScript 中實現此演算法，然後將每個字形叢集計為單個字元。有人建議將Intl.Segmenter（一種文字分段API）新增到ECMAScript中。

JavaScript 中字串反轉

下面是一個類似問題的示例:在JavaScript中反轉字串。這能有多難，對吧? 解決這個問題的一個常見的、非常簡單的方法是:

function reverse(string) {
    return string.split('').reverse().join('');
}

function reverse(string) {

return string.split('').reverse().join('');

}

它似乎在很多情況下都很有效:

>> reverse('abc')
'cba'

>> reverse('mañana') // U+00F1
'anañam'

>> reverse('abc')

'cba'

>> reverse('mañana') // U+00F1

'anañam'

然而，它完全打亂了包含組合標記或位於輔助平面字元的字串。

>> reverse('mañana') // U+006E + U+0303
'anãnam' // note: the `~` is now applied to the `a` instead of the `n`

>> reverse('') // U+1F4A9
'��' // `'\uDCA9\uD83D'`, the surrogate pair for `` in the wrong order

>> reverse('mañana') // U+006E + U+0303

'anãnam' // note: the `~` is now applied to the `a` instead of the `n`

>> reverse('') // U+1F4A9

'��' // `'\uDCA9\uD83D'`, the surrogate pair for `` in the wrong order

要在 ES6 中正確反轉位於輔助平面字元，字串迭代器可以與 Array.from 結合使用：

function reverse(string) {
  return Array.from(string).reverse().join('');
}

function reverse(string) {

return Array.from(string).reverse().join('');

}

但是，這仍然不能解決組合標記的問題。

幸運的是，一位名叫 Missy Elliot 的聰明的電腦科學家提出了一個防彈演算法來解釋這些問題。它看上去像這樣:

我把丁字褲放下，翻轉，然後倒過來。我把丁字褲放下，翻轉，然後倒過來。

事實上：通過將任何組合標記的位置與它們所屬的字元交換，以及在進一步處理字串之前反轉任何代理對，可以成功避免問題。

// 使用庫 Esrever (https://mths.be/esrever)

>> esrever.reverse('mañana') // U+006E + U+0303
'anañam'

>> esrever.reverse('') // U+1F4A9
'' // U+1F4A9

// 使用庫 Esrever (https://mths.be/esrever)

>> esrever.reverse('mañana') // U+006E + U+0303

'anañam'

>> esrever.reverse('') // U+1F4A9

'' // U+1F4A9

字串方法中的 Unicode 的問題

這種行為也會影響其他字串方法。

將碼位轉轉換為字元

String.fromCharCode 可以將一個碼位轉換為字元。但它只適用於 BMP 範圍內的碼位 ( 即從 U+0000 到U+FFFF)。如果將它用於轉換超過 BMP 平面外的碼位，將獲得意想不到的結果。

>> String.fromCharCode(0x0041) // U+0041
'A' // U+0041

>> String.fromCharCode(0x1F4A9) // U+1F4A9
'' // U+F4A9, not U+1F4A9

>> String.fromCharCode(0x0041) // U+0041

'A' // U+0041

>> String.fromCharCode(0x1F4A9) // U+1F4A9

'' // U+F4A9, not U+1F4A9

唯一的解決方法是自己計算代理項一半的碼位，並將它們作為單獨的引數傳遞。

>> String.fromCharCode(0xD83D, 0xDCA9)
'' // U+1F4A9

>> String.fromCharCode(0xD83D, 0xDCA9)

'' // U+1F4A9

如果不想計算代理項的一半，可以使用 Punycode.js 的實用方法:

>> punycode.ucs2.encode([ 0x1F4A9 ])
'' // U+1F4A9

>> punycode.ucs2.encode([ 0x1F4A9 ])

'' // U+1F4A9

幸運的是，ECMAScript 6 引入了 String.fromCodePoint(codePoint)，它可以位於基本平面外的碼位的字元。它可以用於任何 Unicode 編碼點，即從 U+000000 到 U+10FFFF。

>> String.fromCodePoint(0x1F4A9)
'' // U+1F4A9

>> String.fromCodePoint(0x1F4A9)

'' // U+1F4A9

為了向後相容ECMAScript 5 和更舊的環境，使用 String.fromCodePoint() polyfill。

從字串中獲取字元

如果使用 String.prototype.charAt(position) 來檢索包含字串中的第一個字元，則只能獲得第一個代理項而不是整個字元。

>> ''.charAt(0) // U+1F4A9
'\uD83D' // U+D83D, i.e. the first surrogate half for U+1F4A9

>> ''.charAt(0) // U+1F4A9

'\uD83D' // U+D83D, i.e. the first surrogate half for U+1F4A9

有人提議在 ECMAScript 7 中引入 String.prototype.at(position)。它類似於charAt，只不過它儘可能地處理完整的字元而不是代理項的一半。

>> ''.at(0) // U+1F4A9
'' // U+1F4A9

>> ''.at(0) // U+1F4A9

'' // U+1F4A9

為了向後相容 ECMAScript 5 和更舊的環境，可以使用 String.prototype.at() polyfill/prollyfill。

從字串中獲取碼位

類似地，如果使用 String.prototype.charCodeAt(position) 檢索字串中第一個字元的碼位，將獲得第一個代理項的碼位，而不是 poo 字元堆的碼位。

>> ''.charCodeAt(0)
0xD83D

>> ''.charCodeAt(0)

0xD83D

幸運的是，ECMAScript 6 引入了 String.prototype.codePointAt(position)，它類似於 charCodeAt，只不過它儘可能處理完整的字元而不是代理項的一半。

>> ''.codePointAt(0)
0x1F4A9

>> ''.codePointAt(0)

0x1F4A9

為了向後相容 ECMAScript 5 和更舊的環境，使用 String.prototype.codePointAt()_polyfill。

遍歷字串中的所有字元

假設想要迴圈字串中的每個字元，並對每個單獨的字元執行一些操作。

在 ECMAScript 5 中，你必須編寫大量的樣板程式碼來判斷代理對:

function getSymbols(string) {
    var index = 0;
    var length = string.length;
    var output = [];
    for (; index < length - 1; ++index) {
        var charCode = string.charCodeAt(index);
        if (charCode >= 0xD800 && charCode <= 0xDBFF) {
            charCode = string.charCodeAt(index + 1);
            if (charCode >= 0xDC00 && charCode <= 0xDFFF) {
                output.push(string.slice(index, index + 2));
                ++index;
                continue;
            }
        }
        output.push(string.charAt(index));
    }
    output.push(string.charAt(index));
    return output;
}

var symbols = getSymbols('');
symbols.forEach(function(symbol) {
    console.log(symbol == '');
});

function getSymbols(string) {

var index = 0;

var length = string.length;

var output = [];

for (; index < length - 1; ++index) {

var charCode = string.charCodeAt(index);

if (charCode >= 0xD800 && charCode <= 0xDBFF) {

charCode = string.charCodeAt(index + 1);

if (charCode >= 0xDC00 && charCode <= 0xDFFF) {

output.push(string.slice(index, index + 2));

++index;

continue;

}

output.push(string.charAt(index));

}

output.push(string.charAt(index));

return output;

}

var symbols = getSymbols('');

symbols.forEach(function(symbol) {

console.log(symbol == '');

});

或者可以使用正規表示式，如 var regexCodePoint = /[^\uD800-\uDFFF]|[\uD800-\uDBFF][\uDC00-\uDFFF]|[\uD800-\uDFFF]/g; 並迭代匹配

在 ECMAScript 6中，你可以簡單地使用 for…of。字串迭代器處理整個字元，而不是代理對。

for (const symbol of '') {
    console.log(symbol == '');
}

for (const symbol of '') {

console.log(symbol == '');

}

不幸的是，沒有辦法對它進行填充，因為 for…of 是一個語法級結構。

其他問題

此行為會影響幾乎所有字串方法，包括此處未明確提及的方法（如 String.prototype.substring，String.prototype.slice 等），因此在使用它們時要小心。

正規表示式中的 Unicode 問題

匹配碼位和 Unicode 標量值

正規表示式中的點運算子(.)只匹配一個“字元”，但是由於JavaScript將代理半部分公開為單獨的 “字元”，所以它永遠不會匹配位於輔助平面上的字元。

>> /foo.bar/.test('foobar')
false

>> /foo.bar/.test('foobar')

false

讓我們思考一下，我們可以使用什麼正規表示式來匹配任何 Unicode字元? 什麼好主意嗎? 如下所示的,. 這w個是不夠的，因為它不匹配換行符或整個位於輔助平面上的字元。

>> /^.$/.test('')
false

>> /^.$/.test('')

false

為了正確匹配換行符，我們可以使用 [\s\S] 來代替，但這仍然不能匹配整個位於輔助平面上的字元。

>> /^[\s\S]$/.test('')
false

>> /^[\s\S]$/.test('')

false

事實證明，匹配任何 Unicode 編碼點的正規表示式一點也不簡單:

>> /[\0-\uD7FF\uE000-\uFFFF]|[\uD800-\uDBFF][\uDC00-\uDFFF]|[\uD800-\uDBFF](?![\uDC00-\uDFFF])|(?:[^\uD800-\uDBFF]|^)[\uDC00-\uDFFF]/.test('') // wtf
true

>> /[\0-\uD7FF\uE000-\uFFFF]|[\uD800-\uDBFF][\uDC00-\uDFFF]|[\uD800-\uDBFF](?![\uDC00-\uDFFF])|(?:[^\uD800-\uDBFF]|^)[\uDC00-\uDFFF]/.test('') // wtf

true

當然，你不希望手工編寫這些正規表示式，更不用說除錯它們了。為了生成像上面的一個正規表示式，可以使用了一個名為 Regenerate 的庫，它可以根據碼位或字元列表輕鬆地建立正規表示式:

>> regenerate().addRange(0x0, 0x10FFFF).toString()
'[\0-\uD7FF\uE000-\uFFFF]|[\uD800-\uDBFF][\uDC00-\uDFFF]|[\uD800-\uDBFF](?![\uDC00-\uDFFF])|(?:[^\uD800-\uDBFF]|^)[\uDC00-\uDFFF]'

>> regenerate().addRange(0x0, 0x10FFFF).toString()

'[\0-\uD7FF\uE000-\uFFFF]|[\uD800-\uDBFF][\uDC00-\uDFFF]|[\uD800-\uDBFF](?![\uDC00-\uDFFF])|(?:[^\uD800-\uDBFF]|^)[\uDC00-\uDFFF]'

從左到右，這個正規表示式匹配BMP字元、代理項對或單個代理項。

雖然在 JavaScript 字串中技術上允許使用單獨的代理，但是它們本身並不對映到任何字元，因此應該避免使用。術語 Unicode標量值指除代理碼位之外的所有碼位。下面是一個正規表示式，它匹配任何 Unicode 標量值:

>> regenerate()
     .addRange(0x0, 0x10FFFF)     // all Unicode code points
     .removeRange(0xD800, 0xDBFF) // minus high surrogates
     .removeRange(0xDC00, 0xDFFF) // minus low surrogates
     .toRegExp()
/[\0-\uD7FF\uE000-\uFFFF]|[\uD800-\uDBFF][\uDC00-\uDFFF]/

>> regenerate()

.addRange(0x0, 0x10FFFF) // all Unicode code points

.removeRange(0xD800, 0xDBFF) // minus high surrogates

.removeRange(0xDC00, 0xDFFF) // minus low surrogates

.toRegExp()

/[\0-\uD7FF\uE000-\uFFFF]|[\uD800-\uDBFF][\uDC00-\uDFFF]/

Regenerate 作為構建指令碼的一部分使用的，用於建立複雜的正規表示式，同時仍然保持生成這些表示式的指令碼的可讀性和易於維護。

ECMAScript 6 為正規表示式引入一個 u 標誌，它會使用 . 操作符匹配整個碼位，而不是代理項的一半。

>> /foo.bar/.test('foobar')
false

>> /foo.bar/u.test('foobar')
true

>> /foo.bar/.test('foobar')

false

>> /foo.bar/u.test('foobar')

true

注意 . 操作符仍然不會匹配換行符，設定 u 標誌時，. 操作符等效於以下向後相容的正規表示式模式：

>> regenerate()
     .addRange(0x0, 0x10FFFF) // all Unicode code points
     .remove(  // minus `LineTerminator`s (https://ecma-international.org/ecma-262/5.1/#sec-7.3):
       0x000A, // Line Feed <LF>
       0x000D, // Carriage Return <CR>
       0x2028, // Line Separator <LS>
       0x2029  // Paragraph Separator <PS>
     )
     .toString();
'[\0-\t\x0B\f\x0E-\u2027\u202A-\uD7FF\uE000-\uFFFF]|[\uD800-\uDBFF][\uDC00-\uDFFF]|[\uD800-\uDBFF](?![\uDC00-\uDFFF])|(?:[^\uD800-\uDBFF]|^)[\uDC00-\uDFFF]'

>> /foo(?:[\0-\t\x0B\f\x0E-\u2027\u202A-\uD7FF\uE000-\uFFFF]|[\uD800-\uDBFF][\uDC00-\uDFFF]|[\uD800-\uDBFF](?![\uDC00-\uDFFF])|(?:[^\uD800-\uDBFF]|^)[\uDC00-\uDFFF])bar/u.test('foobar')
true

>> regenerate()

.addRange(0x0, 0x10FFFF) // all Unicode code points

.remove( // minus `LineTerminator`s (https://ecma-international.org/ecma-262/5.1/#sec-7.3):

0x000A, // Line Feed <LF>

0x000D, // Carriage Return <CR>

0x2028, // Line Separator <LS>

0x2029 // Paragraph Separator <PS>

)

.toString();

'[\0-\t\x0B\f\x0E-\u2027\u202A-\uD7FF\uE000-\uFFFF]|[\uD800-\uDBFF][\uDC00-\uDFFF]|[\uD800-\uDBFF](?![\uDC00-\uDFFF])|(?:[^\uD800-\uDBFF]|^)[\uDC00-\uDFFF]'

>> /foo(?:[\0-\t\x0B\f\x0E-\u2027\u202A-\uD7FF\uE000-\uFFFF]|[\uD800-\uDBFF][\uDC00-\uDFFF]|[\uD800-\uDBFF](?![\uDC00-\uDFFF])|(?:[^\uD800-\uDBFF]|^)[\uDC00-\uDFFF])bar/u.test('foobar')

true

位於輔助平面碼位上的字元

考慮到 /[a-c]/ 匹配任何字元從碼位為 U+0061 的字母 a 到碼位為 U+0063 的字母 c,似乎/[-]/ 會匹配碼位 U+1F4A9 到碼位 U+1F4AB，然而事實並非如此：

>> /[-]/
SyntaxError: Invalid regular expression: Range out of order in character class

>> /[-]/

SyntaxError: Invalid regular expression: Range out of order in character class

發生這種情況的原因是，正規表示式等價於:

>> /[\uD83D\uDCA9-\uD83D\uDCAB]/
SyntaxError: Invalid regular expression: Range out of order in character class

>> /[\uD83D\uDCA9-\uD83D\uDCAB]/

SyntaxError: Invalid regular expression: Range out of order in character class

事實證明，不像我們想的那樣匹配碼位 U+1F4A9 到碼位 U+1F4AB，而是匹配正規表示式:

U+D83D(高代理位)
從 U+DCA9 到 U+D83D 的範圍（無效，因為起始碼位大於標記範圍結束的碼位）
U+DCAB(低代理位)

>> /[\uD83D\uDCA9-\uD83D\uDCAB]/u.test('\uD83D\uDCA9') // match U+1F4A9
true

>> /[\u{1F4A9}-\u{1F4AB}]/u.test('\u{1F4A9}') // match U+1F4A9
true

>> /[-]/u.test('') // match U+1F4A9
true

>> /[\uD83D\uDCA9-\uD83D\uDCAB]/u.test('\uD83D\uDCAA') // match U+1F4AA
true

>> /[\u{1F4A9}-\u{1F4AB}]/u.test('\u{1F4AA}') // match U+1F4AA
true

>> /[-]/u.test('') // match U+1F4AA
true

>> /[\uD83D\uDCA9-\uD83D\uDCAB]/u.test('\uD83D\uDCAB') // match U+1F4AB
true

>> /[\u{1F4A9}-\u{1F4AB}]/u.test('\u{1F4AB}') // match U+1F4AB
true

>> /[-]/u.test('') // match U+1F4AB
true

>> /[\uD83D\uDCA9-\uD83D\uDCAB]/u.test('\uD83D\uDCA9') // match U+1F4A9

true

>> /[\u{1F4A9}-\u{1F4AB}]/u.test('\u{1F4A9}') // match U+1F4A9

true

>> /[-]/u.test('') // match U+1F4A9

true

>> /[\uD83D\uDCA9-\uD83D\uDCAB]/u.test('\uD83D\uDCAA') // match U+1F4AA

true

>> /[\u{1F4A9}-\u{1F4AB}]/u.test('\u{1F4AA}') // match U+1F4AA

true

>> /[-]/u.test('') // match U+1F4AA

true

>> /[\uD83D\uDCA9-\uD83D\uDCAB]/u.test('\uD83D\uDCAB') // match U+1F4AB

true

>> /[\u{1F4A9}-\u{1F4AB}]/u.test('\u{1F4AB}') // match U+1F4AB

true

>> /[-]/u.test('') // match U+1F4AB

true

遺憾的是，這個解決方案不能向後相容 ECMAScript 5 和更舊的環境。如果這是一個問題，應該使用 Regenerate 生成 es5相容的正規表示式，處理輔助平面範圍內的字元:

>> regenerate().addRange('', '')
'\uD83D[\uDCA9-\uDCAB]'

>> /^\uD83D[\uDCA9-\uDCAB]$/.test('') // match U+1F4A9
true

>> /^\uD83D[\uDCA9-\uDCAB]$/.test('') // match U+1F4AA
true

>> /^\uD83D[\uDCA9-\uDCAB]$/.test('') // match U+1F4AB
true

>> regenerate().addRange('', '')

'\uD83D[\uDCA9-\uDCAB]'

>> /^\uD83D[\uDCA9-\uDCAB]$/.test('') // match U+1F4A9

true

>> /^\uD83D[\uDCA9-\uDCAB]$/.test('') // match U+1F4AA

true

>> /^\uD83D[\uDCA9-\uDCAB]$/.test('') // match U+1F4AB

true

實戰中的 bug 以及如何避免它們

這種行為會導致許多問題。例如，Twitter 每條 tweet 允許 140 個字元，而它們的後端並不介意它是什麼型別的字元——是否為輔助平面內的字元。但由於JavaScript 計數在其網站上的某個時間點只是讀出字串的長度，而不考慮代理項對，因此不可能輸入超過 70 個輔助平面內的字元。(這個bug已經修復。)

許多處理字串的JavaScript庫不能正確地解析輔助平面內的字元。

例如，Countable.js 它沒有正確計算輔助平面內的字元。

Underscore.string 有一個 reverse 方法，它不處理組合標記或輔助平面內的字元。(改用 Missy Elliot 的演算法)

它還錯誤地解碼輔助平面內的字元的 HTML 數字實體，例如。許多其他 HTML 實體轉換庫也存在類似的問題。(在修復這些錯誤之前，請考慮使用 he 代替所有 HTML 編碼/解碼需求。)

原文:

https://mathiasbynens.be/note…

程式碼部署後可能存在的BUG沒法實時知道，事後為了解決這些BUG，花了大量的時間進行log 除錯，這邊順便給大家推薦一個好用的BUG監控工具 Fundebug。

你的點贊是我持續分享好東西的動力，歡迎點贊！

一個笨笨的碼農，我的世界只能終身學習！

更多內容請關注公眾號《大遷世界》！

JavaScript如何正確處理Unicode編碼問題！
2019-01-07
JavaScriptUnicode
如何正確處理nonce
2018-09-14
ptyon 特殊處理 url 編碼與解碼，字元編碼轉化 unicode
2020-05-19
字元Unicode
【廖雪峰python入門筆記】Unicode編碼_UnicodeDecodeError處理
2018-07-05
Python筆記UnicodeError
Troubleshooting 專題 - 問正確的問題得到正確的答案
2023-04-03
Python編解碼問題與文字檔案處理
2021-06-19
Python
Java處理正則匹配卡死（正則回溯問題）
2023-03-01
Java
如何在Kubernetes部署期間正確處理DB模式
2018-08-31
模式
遇到股票套牢該如何正確處理？股票套牢解套技
2022-03-03
Unicode編碼解碼
2023-12-09
Unicode
Linux 和 Windows 下編碼問題處理 codestyle 解決方法
2020-04-17
LinuxWindows
使用 pymysql 的時候如何正確的處理轉義字元
2021-12-26
MySql字元
MySQL：亂碼問題處理流程
2021-02-16
MySql
iOS --NSDecimalNumber 處理計算精度不準確問題
2018-07-02
iOSDecimal
如何處理 No DMARC Record Found 問題
2019-09-12
如何處理HTTP 503故障問題？
2023-04-11
HTTP
Recoil 中預設值的正確處理
2021-04-13
Unicode編碼介紹
2024-09-05
Unicode
如何在Java中輕鬆處理Emoji Unicode - Udayakumar
2020-10-02
JavaUnicode
前端工作流編譯正確操作流程和錯誤處理記錄
2020-04-11
前端編譯
[譯]JavaScript async / await：好處、坑和正確用法
2018-09-28
JavaScriptAI
提出問題，解答問題！這才是理解程式碼設計的正確方法
2022-05-14
一文講透Windows平臺下的ASCII，Unicode編碼問題
2024-11-13
WindowsASCIIUnicode
Sass將Unicode編譯成文字字元導致icon亂碼問題
2021-10-19
Unicode編譯字元
材質最佳化：如何正確處理紋理和材質的關係
2020-11-18
[20231012]如何檢視unicode編碼內容.txt
2023-10-16
Unicode
ORACLE問題處理十個指令碼
2020-04-14
Oracle指令碼
Node中POST請求的正確處理方式
2019-06-19
【問題處理】MySQL忘記root密碼的處理辦法
2021-01-05
MySql密碼
Java 正確的做字串編碼轉換
2018-08-09
Java字串編碼
軟體效能問題正確定位思路
2020-06-14
解碼返回Unicode編碼的文字
2024-04-22
Unicode
JavaScript 中遇到的錯誤問題，該怎麼處理？
2019-07-22
JavaScript
Java異常處理：如何寫出“正確”但被編譯器認為有語法錯誤的程式
2018-10-23
Java編譯
字符集編碼（三）：Unicode
2022-02-28
Unicode
Java 如何獲取字元所對應的UniCode編碼
2019-04-15
Java字元Unicode
golang json處理問題
2018-09-26
GolangJSON
[git] git問題處理
2024-10-19
Git

JavaScript 如何正確處理 Unicode 編碼問題！

Unicode 基礎知識

轉義序列

使用 JavaScript 字串方法來計算字元長度

計算輔助平面內的字元個數

找撞臉

計算其他組合標記

計算其他型別的圖形叢集

JavaScript 中字串反轉

字串方法中的 Unicode 的問題

將碼位轉轉換為字元

從字串中獲取字元

從字串中獲取碼位

遍歷字串中的所有字元

其他問題

正規表示式中的 Unicode 問題

匹配碼位和 Unicode 標量值

位於輔助平面碼位上的字元

實戰中的 bug 以及如何避免它們

相關文章