Unicode编码，基础：它为世界上所有的文字系统的每个字符单位分配一个唯一的整数，该整数介于0~1114111之间，在Unicode术语中称为代码点（code point）。
和其它字符编码几乎没有任何不同（例如ASCII）。
不同在于ASCII将每个索引映射为唯一的二进制表示，但Unicode允许多个不同二进制编码的代码点。
不同的编码在要求存储的字符串数量和操作速度之间进行权衡。
目前最流行的Unicode编码方式有：UTF-8,UTF-16,UTF-32。
Unicode根据历史的数据，错误的估算了代码点的容易范围。
最初，认为只需要216代码点，所以产生了UCS-2，其为16位编码的原始标准。一个代码点可以容纳16位的数字，简单的方法是将代码点与其编码元素一对一地映射起来，这称为一个代码单元(code unit)。
UCS-2是由独立的16位的代码单元组成，每个代码单元对应一个单独的Unicode代码点。这种编码方法的主要好处在于索引字符串是一种代码小的，固定时间的操作。获取某个字符串的第n个代码点只是简单简单地选取数组的第n个16位元素。
下面示例：
这个字符串，里面的每个字符由最初的16位范围中的代码点组成。对于Unicode字符串，代码点和编码元素能完全匹配。
JS字符串采用这16位编码每一个元素。如果还保持20世纪90年代初的做法，JS字符串的每个元素还是对应一个单独的代码点。
Unicode从216扩展到了220个代码点。新增加后的范围被组织为17个大小为216代码点的子范围。
第一个子范围，称为基本多文种平面，包含最初的216个代码点。余下的16个范围称为辅助平面。
一旦代码点的范围扩展了，UCS-2就变得过时了。它需要通过扩展来表示这些附加的代码点。基替代者UTF-16和它类似。
UTF-16采用代理对表示附加的代码点。一对16位的代码单元共同编码一个等于或大于216的代码点。（有点乱，是这样吧。一个代理对等于两个16位的代码单元。一个代码单元是代码点与其编码元素一对一地映射。）
举个例子:
高音谱号“
”的代码点为U+1D11E（代码点数119070的Unicode的惯用16进制写法）
其由UTF-16格式的代码单元0xd834和0xddle共同表示。可以通过合并这两个代码单元选择的位来对代码点进行解码。（这种编码保证了这些代理对绝不会与有效的BMP代码点混淆，甚至从字符串中间的某个位置进行搜索，也可以随时识别一个代理对。）
由于UTF-16的每个代码点编码需要一个或两个16位的代码单元，因此UTF-16是一种可变长度的编码。
- 长度为n的字符串在内存中的大小变化基于字符串特定的代码点。
- 查找字符串中的第n个代码点不再是一个固定时间的操作。
- 搜索需要从字符串的开始进行。
当Unicode扩大规模时，JS已经采用了16位的字符串元素。字符串属性和方法都是基于代码单元层级，而不是代码点层级。
所以每当字符串包含辅助平面中的代码点时，js将每个代码点表示为两个元素而不是一个（一对UTF-16代理对的代码点）
一个js字符串的元素是一个16位的代码单元。
提取字符串的某个字符得到的是代码单元，而不是代码点。
正则表达式也工作于代码单元层级。其单字符模式（“.”）匹配一个单一的代码单元。
JS内置的字符串数据类型工作于代码单元层级，但这并不能阻止一些API意识到代码点和代理对。一些标准的ECMAScript库正确地处理了代理对。
URI操作函数：sendcodeURI,decodeURI,encodeURIComponent和decodeURIComponent。
提示
- js字符串是由16位的代码单元组成，而不是由Unicode代码点组成。
- js使用两个代码单元表示216及其以上的Unicode代码点。这两个代码单元被称为代理对。
- 代理对甩开了字符串元素计数，length,charAt,charCodeAt方法及正则表达式模式受到了影响。
- 使用第三方的库编写可识别代码点的字符串操作。
- 每当使用一个含有字符串操作的库时，都需要查阅该库文档，看好像处理代码点的整个范围。
后记
这节看得我很蒙B，整不太懂，我平时的工作环境中，也没有遇到过这方面的BUG。
页面编码是utf-8或gbk的，是否可以不用考虑上面说的？
现在只是知道在内存的存储过程中，每种情况对应的存储方式。
再想进一步的，可以自己再去网上找资料看了。
进一步阅读
网上找了几个写这方面的文章，有兴趣自己去读吧。
-
简单几句话总结Unicode，UTF-8和UTF-16
-
Unicode(UTF-8, UTF-16)令人混淆的概念
- 为什么 UTF-8 编码比 UTF-16 编码应用更广泛？
-
UTF-8 GBK UTF8 GB2312 之间的区别和关系