一、UTF-16 的编码逻辑
UTF-16 编码很简单，对于给定一个 Unicode 码点 cp（CodePoint 也就是这个字符在 Unicode 中的唯一编号）:
如果码点小于等于 U+FFFF（也就是基本平面的所有字符），不需要处理，直接使用。
否则，将拆分为两个部分 ((cp – 65536) / 1024) + 0xD800，((cp – 65536) % 1024) + 0xDC00 来存储。
Unicode 标准规定 U+D800...U+DFFF 的值不对应于任何字符，所以可以用来做标记。
举个具体的例子：字符 A 的码点是 U+0041，可以直接用一个码元表示。
'\u0041' // -> A
A === '\u0041' // -> true
Javascript 中 \u 表示 Unicode 的转义字符，后面跟着一个十六进制数。
而字符 💩 的码点是 U+1f4a9，处于补充平面的字符，经过 👆 公式计算得到两个码元 55357, 56489 这两个数字用十六进制表示为 d83d, dca9，将这两个编码结果组合成代理对。
'\ud83d\udca9' // -> '💩'
'💩' === '\ud83d\udca9' // -> true
二、为什么 length 判断会有问题
要解答这个问题，可以继续查看规范，里面提到：在 ECMAScript 操作解释字符串值的地方，每个元素都被解释为单个 UTF-16 代码单元。
Where ECMAScript operations interpret String values, each element is interpreted as a single UTF-16 code unit.
所以像💩 字符实际上占用了两个 UTF-16 的码元，也就是两个元素，所以它的 length 属性就是 2。（这跟一开始 JS 使用 USC-2 编码有关，当初以为 65536 个字符就可以满足所有需求了）
但对于普通用户而言，这就完全没办法理解了，为什么明明只填了一个 '𠮷'，程序上却提示占用了两个字符长度，要怎样才能正确识别出 Unicode 字符长度呢？
我在 Antd Form 表单使用的 async-validator 包中可以看到下面这段代码
const spRegexp = /[\uD800-\uDBFF][\uDC00-\uDFFF]/g;
if (str) {
val = value.replace(spRegexp, '_').length;
}
当需要进行字符串长度的判断时，会将码点范围在补充平面的字符全部替换为下划线，这样长度判断就和实际显示的一致了。
三、ES6 对 Unicode 的支持
length 属性的问题，主要还是最初设计 JS 这门语言的时候，没有考虑到会有这么多字符，认为两个字节就完全可以满足。所以不止是 length，字符串常见的一些操作在 Unicode 支持上也会表现异常。下面的内容将介绍部分存在异常的 API 以及在 ES6 中如何正确处理这些问题。
1、for vs for of
例如使用 for 循环打印字符串，字符串会按照 JS 理解的每个“元素”遍历，辅助平面的字符将会被识别成两个“元素”，于是出现“乱码”。
var str = '👻yo𠮷'
for (var i = 0; i < str.length; i ++) {
console.log(str[i])
}
// -> �
// -> �
// -> y
// -> o
// -> �
// -> �
而使用 ES6 的 for of 语法就不会。
var str = '👻yo𠮷'
for (const char of str) {
console.log(char)
}
// -> 👻
// -> y
// -> o
// -> 𠮷
2、展开语法(Spread syntax)
前面提到了使用正则表达式，将辅助平面的字符替换的方式来统计字符长度。使用展开语法也可以得到同样的效果。
[...'💩'].length // -> 1
slice, substr 等等方法也存在同样的问题
'💩'.substr(0,1) // '\uD83D'
'💩'.slice(0,1)
3、正则表达式 u
ES6 中还针对 Unicode 字符增加了 u 描述符
/^.$/.test('👻') // -> false
/^.$/u.test('👻') // -> true
4、String.prototype.normalize()
由于 JS 中将字符串理解成一串两个字节的码元序列，判断是否相等是根据序列的值来判断的。所以可能存在一些字符串看起来长得一模一样，但是字符串相等判断结果确是 false。
'café' === 'café' // false
上面代码中第一个 café 是有 cafe 加上一个缩进的音标字符\u0301组成的，而第二个 café 则是由一个 caf + é 字符组成的。所以两者虽然看上去一样，但码点不一样，所以 JS 相等判断结果为 false
'cafe\u0301' // -> 'café'
'cafe\u0301'.length // -> 5
'café'.length // -> 4
为了能正确识别这种码点不一样，但是语意一样的字符串判断，ES6 增加了 String.prototype.normalize 方法。
'cafe\u0301'.normalize() === 'café'.normalize() // -> true
'cafe\u0301'.normalize().length // -> 4
四、String.prototype.normalize()方法介绍
normalize() 方法会按照指定的一种 Unicode 正规形式将当前字符串正规化，这是一个ES6方法。
许多欧洲语言有语调符号和重音符号。为了表示它们，Unicode 提供了两种方法。一种是直接提供带重音符号的字符，比如Ǒ（\u01D1）。另一种是提供合成符号（combining character），即原字符与重音符号的合成，两个字符合成一个字符，比如O（\u004F）和ˇ（\u030C）合成Ǒ（\u004F\u030C）。
这两种表示方法，在视觉和语义上都等价，但是 JavaScript 不能识别。
'\u01D1'==='\u004F\u030C' //false
'\u01D1'.length // 1
'\u004F\u030C'.length // 2
ES6 提供字符串实例的normalize()方法，用来将字符的不同表示方法统一为同样的形式，这称为 Unicode 正规化。
'\u01D1'.normalize() === '\u004F\u030C'.normalize() // true
normalize方法可以接受一个参数来指定normalize的方式，参数的四个可选值如下。
（1）NFC，默认参数，表示“标准等价合成”，返回多个简单字符的合成字符。所谓“标准等价”指的是视觉和语义上的等价。
（2）NFD，表示“标准等价分解”，即在标准等价的前提下，返回合成字符分解的多个简单字符。
（3）NFKC，表示“兼容等价合成”，返回合成字符。所谓“兼容等价”指的是语义上存在等价，但视觉上不等价，比如“囍”和“喜喜”。（这只是用来举例，normalize方法不能识别中文。）
（4）NFKD，表示“兼容等价分解”，即在兼容等价的前提下，返回合成字符分解的多个简单字符。
'\u004F\u030C'.normalize('NFC').length // 1
'\u004F\u030C'.normalize('NFD').length // 2
normalize方法目前不能识别三个或三个以上字符的合成。这种情况下，还是只能使用正则表达式，通过 Unicode 编号区间判断。
参考原文：https://juejin.cn/post/7025400771982131236