- 原文：Javascript 如何正确处理 Unicode 编码问题！
- 作者：前端小智
Fundebug经授权转载，版权归原作者所有。
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 字符串。
转义序列在谷歌控制台输入如下:
>> 'x41x42x43'
'ABC'
>> 'x61x62x63'
'abc'
以下称为十六进制转义序列。它们由引用匹配码位的两个十六进制数字组成。例如，x41 码位为 U+0041 表示大写字母 A。这些转义序列可用于 U+0000 到 U+00FF 范围内的码位。
同样常见的还有以下类型的转义:
>> 'u0041u0042u0043'
'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
在大括号之间可以使用最多 6 个十六进制数字，这足以表示所有 Unicode 码位。因此，通过使用这种类型的转义序列，可以基于其代码位轻松转义任何 Unicode 码位。
为了向后兼容 ECMAscript 5 和更旧的环境，不幸的解决方案是使用代理对:
>> 'uD83DuDCA9'
'' // 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
在这些例子中，字符串的 length 属性恰好反映了字符的个数。这是有道理的：如果我们使用转义序列来表示字符，很明显，我们只需要对每个字符进行一次转义。但情况并非总是如此！这里有一个稍微不同的例子:
>> '퐀'.length // 码位： U+1D400 表示 Math Bold 字体大写 A
2
>> '퐀' == 'uD835uDC00'
true
>> '퐁'.length // 码位： U+1D401 表示 Math Bold 字体大写 B
2
>> '퐁' == 'uD835uDC01'
true
>> ''.length // U+1F4A9 PILE OF POO
2
>> '' == 'uD83DuDCA9'
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;
}
或者，如果你使用 Punycode.js，利用它的实用方法在 Javascript 字符串和 Unicode 码位之间进行转换。decode 方法接受一个字符串并返回一个 Unicode 编码位数组;每个字符对应一项。
function countSymbols(string) {
return punycode.ucs2.decode(string).length;
}
在 ES6 中，可以使用 Array.from 来做类似的事情，它使用字符串的迭代器将其拆分为一个字符串数组，每个字符串数组包含一个字符:
function countSymbols(string) {
return Array.from(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
考虑一下这个例子:
>> 'mañana' == 'mañana'
false
Javascript告诉我们，这些字符串是不同的，但视觉上，没有办法告诉我们！这是怎么回事?
Javascript转义工具会告诉你，原因如下:
>> 'maxF1ana' == 'manu0303ana'
false
>> 'maxF1ana'.length
6
>> 'manu0303ana'.length
7
第一个字符串包含码位 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;
}
String.prototype 上的 normalize 方法执行 Unicode规范化，这解释了这些差异。 如果有一个码位表示与另一个码位后跟组合标记相同的字符，则会将其标准化为单个码位形式。
>> countSymbolsPedantically('mañana') // U+00F1
6
>> countSymbolsPedantically('mañana') // U+006E + U+0303
6
为了向后兼容 ECMAscript5 和旧环境，可以使用 String.prototype.normalize polyfill。
计算其他组合标记然而，上述方案仍然不是完美的——应用多个组合标记的码位总是导致单个可视字符，但可能没有 normalize 的形式，在这种情况下，normalize 是没有帮助。例如:
>> 'qu0307u0323'.normalize('NFC') // `q̣̇`
'qu0307u0323'
>> countSymbolsPedantically('qu0307u0323')
3 // not 1
>> countSymbolsPedantically('Z͑ͫ̓ͪ̂ͫ̽͏̴̙̤̞͉͚̯̞̠͍A̴̵̜̰͔ͫ͗͢L̠ͨͧͩ͘G̴̻͈͍͔̹̑͗̎̅͛́Ǫ̵̹̻̝̳͂̌̌͘!͖̬̰̙̗̿̋ͥͥ̂ͣ̐́́͜͞')
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;
}
此函数删除任何组合标记，只留下它们所属的字符。任何不匹配的组合标记(在字符串开头)都保持不变。这个解决方案甚至可以在 ECMAscript3 环境中工作，并且它提供了迄今为止最准确的结果:
>> countSymbolsIgnoringCombiningMarks('qu0307u0323')
1
>> countSymbolsIgnoringCombiningMarks('Z͑ͫ̓ͪ̂ͫ̽͏̴̙̤̞͉͚̯̞̠͍A̴̵̜̰͔ͫ͗͢L̠ͨͧͩ͘G̴̻͈͍͔̹̑͗̎̅͛́Ǫ̵̹̻̝̳͂̌̌͘!͖̬̰̙̗̿̋ͥͥ̂ͣ̐́́͜͞')
6
上面的算法仍然是一个简化—它还是无法正确计算像这样的字符：நி，汉语言由连体的 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('');
}
它似乎在很多情况下都很有效:
>> reverse('abc')
'cba'
>> reverse('mañana') // U+00F1
'anañam'
然而，它完全打乱了包含组合标记或位于辅助平面字符的字符串。
>> reverse('mañana') // U+006E + U+0303
'anãnam' // note: the `~` is now applied to the `a` instead of the `n`
>> reverse('') // U+1F4A9
'��' // `'uDCA9uD83D'`, the surrogate pair for `` in the wrong order
要在 ES6 中正确反转位于辅助平面字符，字符串迭代器可以与 Array.from 结合使用：
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
这种行为也会影响其他字符串方法。
将码位转转换为字符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(0xD83D, 0xDCA9)
'' // U+1F4A9
如果不想计算代理项的一半，可以使用 Punycode.js 的实用方法:
>> punycode.ucs2.encode([ 0x1F4A9 ])
'' // U+1F4A9
幸运的是，ECMAscript 6 引入了 String.fromCodePoint(codePoint)，它可以位于基本平面外的码位的字符。它可以用于任何 Unicode 编码点，即从 U+000000 到 U+10FFFF。
>> 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
有人提议在 ECMAscript 7 中引入 String.prototype.at(position)。它类似于charAt，只不过它尽可能地处理完整的字符而不是代理项的一半。
>> ''.at(0) // U+1F4A9
'' // U+1F4A9
为了向后兼容 ECMAscript 5 和更旧的环境，可以使用 String.prototype.at() polyfill/prollyfill。
从字符串中获取码位类似地，如果使用 String.prototype.charCodeAt(position) 检索字符串中第一个字符的码位，将获得第一个代理项的码位，而不是 poo 字符堆的码位。
>> ''.charCodeAt(0)
0xD83D
幸运的是，ECMAscript 6 引入了 String.prototype.codePointAt(position)，它类似于 charCodeAt，只不过它尽可能处理完整的字符而不是代理项的一半。
>> ''.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 == '');
});
或者可以使用正则表达式，如 var regexCodePoint = /[^uD800-uDFFF]|[uD800-uDBFF][uDC00-uDFFF]|[uD800-uDFFF]/g; 并迭代匹配
在 ECMAscript 6中，你可以简单地使用 for…of。字符串迭代器处理整个字符，而不是代理对。
for (const symbol of '') {
console.log(symbol == '');
}
不幸的是，没有办法对它进行填充，因为 for…of 是一个语法级结构。
其他问题此行为会影响几乎所有字符串方法，包括此处未明确提及的方法（如 String.prototype.substring，String.prototype.slice 等），因此在使用它们时要小心。
正则表达式中的 Unicode 问题 匹配码位和 Unicode 标量值正则表达式中的点运算符(.)只匹配一个“字符”， 但是由于Javascript将代理半部分公开为单独的 “字符”，所以它永远不会匹配位于辅助平面上的字符。
>> /foo.bar/.test('foobar')
false
让我们思考一下，我们可以使用什么正则表达式来匹配任何 Unicode字符? 什么好主意吗? 如下所示的,. 这w个是不够的，因为它不匹配换行符或整个位于辅助平面上的字符。
>> /^.$/.test('')
false
为了正确匹配换行符，我们可以使用 [sS] 来代替，但这仍然不能匹配整个位于辅助平面上的字符。
>> /^[sS]$/.test('')
false
事实证明，匹配任何 Unicode 编码点的正则表达式一点也不简单:
>> /[ -uD7FFuE000-uFFFF]|[uD800-uDBFF][uDC00-uDFFF]|[uD800-uDBFF](?![uDC00-uDFFF])|(?:[^uD800-uDBFF]|^)[uDC00-uDFFF]/.test('') // wtf
true
当然，你不希望手工编写这些正则表达式，更不用说调试它们了。为了生成像上面的一个正则表达式，可以使用了一个名为 Regenerate的库，它可以根据码位或字符列表轻松地创建正则表达式:
>> regenerate().addRange(0x0, 0x10FFFF).toString()
'[ -uD7FFuE000-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()
/[ -uD7FFuE000-uFFFF]|[uD800-uDBFF][uDC00-uDFFF]/
Regenerate作为构建脚本的一部分使用的，用于创建复杂的正则表达式，同时仍然保持生成这些表达式的脚本的可读性和易于维护。
ECMAscript 6 为正则表达式引入一个 u 标志，它会使用 . 操作符匹配整个码位，而不是代理项的一半。
>> /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
0x000D, // Carriage Return
0x2028, // Line Separator
0x2029 // Paragraph Separator
)
.toString();
'[ -tx0Bfx0E-u2027u202A-uD7FFuE000-uFFFF]|[uD800-uDBFF][uDC00-uDFFF]|[uD800-uDBFF](?![uDC00-uDFFF])|(?:[^uD800-uDBFF]|^)[uDC00-uDFFF]'
>> /foo(?:[ -tx0Bfx0E-u2027u202A-uD7FFuE000-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
发生这种情况的原因是，正则表达式等价于:
>> /[uD83DuDCA9-uD83DuDCAB]/
SyntaxError: Invalid regular expression: Range out of order in character class
事实证明，不像我们想的那样匹配码位 U+1F4A9 到码位 U+1F4AB，而是匹配正则表达式:
-
U+D83D(高代理位)
-
从 U+DCA9 到 U+D83D 的范围（无效，因为起始码位大于标记范围结束的码位）
-
U+DCAB(低代理位)
>> /[uD83DuDCA9-uD83DuDCAB]/u.test('uD83DuDCA9') // match U+1F4A9
true
>> /[u{1F4A9}-u{1F4AB}]/u.test('u{1F4A9}') // match U+1F4A9
true
>> /[-]/u.test('') // match U+1F4A9
true
>> /[uD83DuDCA9-uD83DuDCAB]/u.test('uD83DuDCAA') // match U+1F4AA
true
>> /[u{1F4A9}-u{1F4AB}]/u.test('u{1F4AA}') // match U+1F4AA
true
>> /[-]/u.test('') // match U+1F4AA
true
>> /[uD83DuDCA9-uD83DuDCAB]/u.test('uD83DuDCAB') // 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
这种行为会导致许多问题。例如，Twitter 每条 tweet 允许 140 个字符，而它们的后端并不介意它是什么类型的字符——是否为辅助平面内的字符。但由于Javascript 计数在其网站上的某个时间点只是读出字符串的长度，而不考虑代理项对，因此不可能输入超过 70 个辅助平面内的字符。(这个bug已经修复。)
许多处理字符串的Javascript库不能正确地解析辅助平面内的字符。
例如，Countable.js 它没有正确计算辅助平面内的字符。
Underscore.string 有一个 reverse 方法，它不处理组合标记或辅助平面内的字符。(改用 Missy Elliot 的算法)
它还错误地解码辅助平面内的字符的 HTML 数字实体，例如 💩。 许多其他 HTML 实体转换库也存在类似的问题。(在修复这些错误之前，请考虑使用 he 代替所有 HTML 编码/解码需求。)
原文:
https://firebase.google.com/docs/cloud-messaging/
代码部署后可能存在的BUG没法实时知道，事后为了解决这些BUG，花了大量的时间进行log 调试，这边顺便给大家推荐一个好用的BUG监控工具 Fundebug。
你的点赞是我持续分享好东西的动力，欢迎点赞！
一个笨笨的码农，我的世界只能终身学习！
更多内容请关注公众号《大迁世界》！
