（十二）UTF-16编码方式
UTF-16编码方式源于UCS-2(Universal Character Set coded in 2 octets、2-byte Universal Character Set)。而UCS-2，是早期遗留下来的历史产物。
UCS-2将字符编号直接映射为字符编码(CEF，而非CES，详见前文中对现代字符编码模型的解释)，亦即字符编号就是字符编码，中间没有经过特别的编码算法转换。因此，从现代字符编码模型的角度来看的话，此时并没有将编号字符集CCS与字符编码方式CEF作严格区分，既可以将UCS-2看作是编号字符集CCS中的字符编号，也可以看作是字符编码方式CEF中的字符编码。
后来，随着Unicode联盟与ISO/IEC就创建全球统一的单一通用字符集进行合作，Unicode字符集与UCS字符集逐渐相互融合，两者最终基本保持了一致。
这之后，Unicode逐渐占据了主导地位，并引入了UTF-16编码方式。为什么要引入UTF-16编码方式呢？
前文已经介绍过了，Unicode字符集(CCS)到目前为止定义了包括1个基本平面BMP和16个增补平面SP在内的共17个平面。
每个平面的码点数量为2^16=65536个，因此17个平面的码点总数为共6553617=1114112个。其中，基本平面码点为65536个(码点编号范围为0x0000~0xFFFF)，增补平面码点为1114112-65536=6553616=1048576个(码点编号范围为0x10000~0x10FFFF)。
很明显，简单地用一个16位码元肯定无法表示所有17个平面的这么多码点(因为2^16=65536，而码点总数为65536*17=1114112)。而UCS-2，正是用两个字节共16位来表示一个字符的。为支持字符编号超过U+FFFF的增补字符，扩展势在必行。
UCS因而又提出了UCS-4，即用四个字节共32位来表示一个字符(此时UCS-4同样既可认为是编号字符集CCS中的字符编号，也可认为是字符编码方式CEF中的字符编码)。但码元也因此从16位扩展到了32位。
而Unicode却提出了不同的扩展方式——代理机制。具体而言，就是为了能以一个统一的16位码元同时编码基本平面以及增补平面中的字符码点编号，Unicode设计引入了UTF-16编码方式，并且通过代理机制实现了扩展。
UTF-16编码方式的引入，从现代字符编码模型的角度来看的话，彻底将编号字符集CCS与字符编码方式CEF作了严格区分。也就是说，在UTF-16编码方式中，编号字符集CCS中的字符编号与字符编码方式CEF中的字符编码不再仅仅是简单的直接映射关系。
具体来说，就是Unicode字符集基本平面BMP中的字符(大致相当于UCS字符集中的UCS-2字符，但必须除开U+D800~U+DFFF这一在Unicode字符集BMP中称之为代理码点的部分)，仍然是直接映射关系，亦即这部分字符的字符编号与字符编码是等同的。
但Unicode字符集增补平面中的字符(大致相当于UCS字符集UCS-4字符中除开UCS-2字符的部分，因为广义上的UCS-4字符实际上包含了UCS-2字符，当然狭义上的UCS-4字符不包括UCS-2字符)，却不是直接映射关系，而是必须通过代理机制这一编码算法的转换，亦即这部分字符的字符编号与字符编码不是等同的。
因此，在Unicode引入了UTF-16编码方式之后，站在现代字符编码模型的角度上来看的话，再将UCS-2和UCS-4直接称之为字符编码方式CEF已不是很合适，更多的应该是编号字符集CCS中的概念(当然，在了解其历史原因之后，将UCS-2和UCS-4同时理解为编号字符集CCS和字符编码方式CEF也未尝不可)；而若将UCS-2等同于UTF-16，将UCS-4等同于UTF-32(后文会有介绍)，显然也是不合适的。
UTF-16中的所谓代理机制，实际上就是用两个对应于基本平面BMP代理区(Surrogate Zone)中的码点编号的16位码元来表示一个增补平面码点，这两个用来表示一个增补平面码点的特殊16位码元被称之为代理对(Surrogate Pair)（解释详见后文《UTF-16究竟是如何编码的——UTF-16的编码算法详解》）
UTF-16编码方式及其代理机制是在Unicode 2.0中为支持字符编号超过U+FFFF的增补字符而引入的，于是从此就由UCS-2的等宽(16位)码元序列编码方式(如前文所述，从现代字符编码模型的角度来看的话，UCS-2更多是的编号字符集CCS中的概念，但考虑到其历史原因，称之为字符编码方式CEF亦未尝不可，下同，不再赘述)，变成了UTF-16的变宽(16位或32位)码元序列编码方式。不过，码元依然保持了16位不变。
UCS-2所编码的字符集中的U+D800~U+DFFF这部分代理码点除外的话，UTF-16所编码的字符集可看成是UCS-2所编码的字符集的父集。
在没有引入增补平面字符之前，UTF-16与UCS-2(U+D800~U+DFFF这部分代理码点除外)的编码完全相同。但当引入增补平面字符后，UTF-16与UCS-2的编码就不完全相同了(事实上，由于UCS-2只有两个字节，根本无法编码增补平面字符)。
现在若有软件声称自己支持UCS-2编码，那相当于是在暗示其仅支持UCS字符集或Unicode字符集中的基本平面字符，而不能支持增补平面字符。
所以说，UTF-16是变长编码方式，每个字符编码为16位或32位；而UCS-2是定长编码方式，每个字符编码固定为16位。但两者的码元却都是16位的（而UTF-32和狭义的UCS-4的码元都是32位的）。
另外，UTF-16中，大部分汉字采用两个字节编码，少量不常用汉字采用四个字节编码。
Windows 2000及之后的版本是支持UTF-16的，之前的Windows NT/95/98/ME是只支持UCS-2的。
作为逻辑意义上的UTF-16编码(码元序列)，由于历史的原因，在映射为物理意义上的字节序列时，分为UTF-16BE(Big Endian)、UTF-16LE(Little Endian)两种情况。比如，“ABC”这三个字符的UTF-16编码(码元序列)为：00 41 00 42 00 43；其对应的各种字节序列如下：
Windows从NT时代开始就采用了UTF-16编码方式，很多流行的编程平台，例如.Net、Java、Qt还有Mac下的Cocoa等都是使用UTF-16作为基础的字符编码。例如代码中的字符串，在内存中相应的字节流就是UTF-16字节序列的。（注意，UTF-16编码在Windows环境中被误用为“widechar”和“Unicode”的同义词）
UTF-16一方面使用变长码元序列的编码方式，相较于定长码元序列的UTF-32算法更复杂(甚至比同样是变长码元序列的UTF-8也更为复杂，因为引入了独特的代理对这样的代理机制)；另一方面仍然占用过多字节，比如ASCII字符也同样需要占用两个字节，相较于UTF-8更浪费空间和带宽。
因此，UTF-16在Unicode字符集的三大编码方式(UTF-8、UTF-16、UTF-32)中表现较为糟糕。它的存在是历史原因造成的，引起了很多混乱。不过由于其推出时间最早，已被应用于大量环境中，目前虽然不被推荐使用，但长期来看，作为程序人员都不得不与之打交道。因而，对于其具体的编码算法的了解是十分必要的，本系列文章的下一篇将详细介绍其复杂的编码算法(主要是代理编码算法)。
（十三）UTF-16究竟是怎么编码的
首先要注意的是，代理Surrogate是专属于UTF-16编码方式的一种机制，UTF-8和UTF-32是不用代理的。
如前文所述，为了让UTF-16能继续编码基本平面后面的增补平面中的码点值，于是扩展了UTF-16编码方式。
具体的扩展方法就是为其增加了代理机制，用两个对应于基本平面码点(即BMP代理区中的码点)的16位码元来表示一个增补平面码点，这两个用来表示一个增补平面码点的特殊16位码元就被称为“代理对”。
如果要用简单的一句话来概括，就是——所有大于0xFFFF的码点值(即增补平面码点编号，范围为0x10000~0x10FFFF，十进制为65536~1114111；注意，0xFFFF是十六位二进制数的最大值的十六进制表示)要编码成UTF-16编码方式的话，就必须使用代理机制(也就是用代理对来表示)。
在UTF-16编码方式中，被合起来称为“代理对”的这两个16位码元就其中的任一单个码元而言，其实就直接对应于基本平面BMP中的某一个码点(即BMP中每一个码点的值必然对应于一个16位码元的值，因为基本平面中的码点总数为2^16=65536个，而16位码元能表示的值也等于2^16=65536个)。
这样一来，就产生了冲突：某个UTF-16码元到底是用于表示基本平面字符的码元，还是用于表示增补平面字符的代理对中的代理码元？
因此，为避免冲突，这些被用作“代理”的任一码元所对应的码点在基本平面中均未定义字符，即均没有指定字符。且形成“代理对”的两个码元所对应的码点其编号必定是连续的。
“代理”的真实含义或许就在于此：用两个基本平面中未定义字符的连续码点合起来“代为署理”增补平面中的码点。
因此，基本平面中这些用作“代理”的码点区域就被称之为“代理区(Surrogate Zone)”，其码点编号范围为0xD800~0xDFFF(十进制55296~57343)，共2048个码点。
增补平面一共有16个平面(即第2平面~第17平面)，码点编号范围为0x10000~0x10FFFF(十进制为65536~1114111，码点总数为1048576个)。用两个代理码元表示，第一个码元的取值范围为0xD800~0xDBFF(二进制为1101 1000 0000 0000 ~ 1101 1011 1111 1111，十进制为55296 ~ 56319)，第二个码元的取值范围为0xDC00~0xDFFF(二进制为1101 1100 0000 0000 ~ 1101 1111 1111 1111，十进制为56320 ~ 57343)。
因此，增补平面的第一个码点的编号0x10000其UTF-16编码就是0xD800 0xDC00(即0x10000经UTF-16编码后的码元序列为0xD800 0xDC00)，其余类推。展现为二进制形式后如下：
====代理码元1==== ====代理码元2====
1101 10pp ppxx xxxx 1101 11xx xxxx xxxx
其中代理码元1中的110110、代理码元2中的110111是定数，p、x是变数。去掉定数后组合起来就是pppp xxxx xxxx xxxx xxxx，共20位(2^20=1048576)，刚好能够表示增补平面中的全部码点(0x10000~0x10FFFF，共1048576个)。其中pppp共4位，表示16个增补平面之一的编号(2^4=16)；紧接着的16位x表示某个增补平面内的某个码点(2^16=65536，而65536*16=1048576)。
按照上面的编码方式，代理对里面的两个代理码元分别称之为高16位代理码元(或称为lead surrogates引导代理、前导代理)，和低16位代理码元(或称为trail surrogates尾随代理、后尾代理)。
由于引导代理和尾随代理的值分别在0xD800~0xDBFF(十进制为55296 ~ 56319)之间和0xDC00~0xDFFF(十进制为56320 ~ 57343)之间，所以首尾两个代理总共可以组合出(56319-55296+1)*(57343-56320+1)=1048576个代理对，也就是总共可以表示1048576个增补码点，而目前Unicode标准所确定的16个增补平面的码点总和也就是65536*16=1048576个。
从增补平面的码点值通过基本平面中的代理对编码为增补平面字符的码元序列的具体算法如下：
1） 增补平面中的码点值(0x10000~0x10FFFF，二进制为0001 0000 0000 0000 0000~1 0000 1111 1111 1111 1111，对应的码点名称为U+10000~U+10FFFF)减去0x10000(二进制为0001 0000 0000 0000 0000)，可得到20位长的比特组(值的范围为0x00000~0xFFFFF，二进制为0000 0000 0000 0000 0000 ~ 1111 1111 1111 1111 1111)；
2）将得到的20位长的比特组分拆为两部分：高位10比特和低位10比特；
3）20位长的比特组中的高位10比特(值的范围为0x000~0x3FF，二进制为00 0000 0000~11 1111 1111)加上0xD800(二进制为1101 1000 0000 0000)，得到第一个代理码元即引导代理(值的范围是0xD800~0xDBFF，二进制为1101 1000 0000 0000 ~ 1101 1011 1111 1111)；
4）20位长的比特组中的低位10比特(值范围也是0x000~0x3FF，二进制为00 0000 0000~11 1111 1111)加上0xDC00(二进制为1101 1100 0000 0000)，得到第二个代理码元即尾随代理(值的范围是0xDC00~0xDFFF，二进制为1101 1100 0000 0000 ~ 1101 1111 1111 1111)；
5）将引导代理与尾随代理按前后顺序组合在一起成为“代理对”，就得到了增补平面字符的码元序列。
例如，增补平面中码点值为10437(码点名称为U+10437)的字符(?)：
1）0x10437减去0x10000，结果为0x00437，二进制为0000 0000 0100 0011 0111。
2）分拆成高10位值和低10位值两部分：0000000001(即0x0001)及0000110111(即0x0037)。
3）添加0xD800到高位值，以形成高位的引导代理：0xD800 + 0x0001 = 0xD801(二进制为1101 1000 0000 0001)。
4）添加0xDC00到低位值，以形成低位的尾随代理：0xDC00 + 0x0037 = 0xDC37(二进制为1101 1100 0011 0111)。
5）将高位的引导代理与低位的尾随代理按前后顺序组合在一起成为“代理对”，就得到了增补平面字符?(码点名称为U+10437)的码元序列：1101 1000 0000 0001 1101 1100 0011 0111。
下表总结了该转换。不同的颜色表示码点值是如何被分布到UTF-16码元序列中的，而由UTF-16编码过程中加入的代理附加位则以不同的红色(亮红色与暗红色)显示：
显然，增补平面中的码点值从0x10000到0x10FFFF，共计0xFFFFF + 0x1个，即1,048,576个，刚好也就是需要20位来表示(2^20=1,048,576)。如果用两个16位长的码元组成的序列来表示，意味着引导代理要容纳上述20位中的前10位，尾随代理要容纳上述20位中的后10位。
另外，还要能够根据每个16位码元来直接判断该码元到底是属于引导代理(标志位为前6位11 0110，还剩下10位，因此总个数为2^10=1024个)，还是属于尾随代理(标志位为前6位11 0111，也剩下10位，因此总个数也是2^10=1024个)。
为避免冲突，因此需要在基本多语言平面BMP中保留未定义Unicode字符的1024+1024=2048个码点，就可以容纳引导代理与尾随代理所需要的编号空间(码点空间、代码空间)，也就是16个增补平面所需要的编号空间，共计1024*1024=2^20=1048576个码点。这BMP中的2048个码点对于BMP总计65536个码点来说，仅占3.125%(2048/65536=0.03125)。
在UTF-16编码方式中，引导代理的后面应该是一个尾随代理，而尾随代理的前面就应该是一个引导代理；不能出现一个引导代理的后面是一个非代理的普通UTF-16码元的情况，也不能出现一个引导代理的后面还是一个引导代理的情况。
UTF-16文本(字符串)的最后一个码元不能是引导代理，不允许出现一个尾随代理的前面是一个尾随代理的情况，也不允许出现一个尾随代理的前面是一个非代理的普通UTF-16码元的情况；UTF-16文本(字符串)的第一个码元不能是尾随代理。
而单独的一个代理码元(不管是引导代理还是尾随代理)是不合法的，代理必须以一个“引导代理＋尾随代理”编码对(即代理对)的形式出现。
UTF-16的这种“代理对”编码规则保证了文本处理程序能够正确地访问和处理包括了基本平面和增补平面在内的全部UTF-16码元序列，并消除了基本平面字符和增补平面字符之间发生冲突的可能性。
因为引导代理和尾随代理码元被各自规定在一个特定范围内取值，所以很简单的一个原则就是：凡是在代理编码范围内的码元就是“代理”增补平面SP字符的“代理码元”，否则就是“基本平面BMP字符的码元”。由于BMP中的字符码元和代理码元分别在各自独立的编码范围内进行编码，所以对于一个符合格式规范的UTF-16码元来讲，它必须满足以下三个条件之一：
-非代理码元(BMP字符码元)必须避开代理码元所占用的范围0xD800~0xDFFF(二进制为1101 1000 0000 0000 ~ 1101 1111 1111 1111，共2048个)；
-引导代理必须是代理对中的第一个码元；
-尾随代理必须是代理对中的第二个码元。
在处理UTF-16文本时，为了确保文本数据的完整性，绝对不能把任意一个代理从代理对中拆出来，也不能在代理对中间插入另一个字符的码元或码元序列。
在UTF-16编码方式里面，一个Unicode字符码点值由一个或两个16位码元编码。所以，如果想在一个UTF-16码元序列里面判断某个码元是属于哪个字符的话，就需要检查那个码元的值，然后根据码元的类型(是否具有代理标志位)决定是否还需要向前或向后检查一个相邻的码元的值(可以不必理会除了前后相邻的两个码元之外的其他码元)。
由于引导代理、尾随代理、BMP字符码元，三者互不重叠，搜索就很简单，这意味着UTF-16具有“自同步”(self-synchronizing)性：通过仅检查一个码元就可以判断当前字符的下一个字符的起始码元，每个字符码元的边界很明确；同时，还具有“非传递”性：单独的一个UTF-16码元出错涉及的只是一个字符，不会传递到文本的其他部分去，因此，即使文本中某些字符数据遭到破坏，其影响也只是局部性的。
UTF-8也有类似优点。但许多早期的编码方式就不是自同步的，比如大多数的多字节编码标准如GBK、Big5等，必须从头开始分析文本才能确定不同字符的码元的边界；也不具有非传递性，局部字符数据被破坏，很可能传递到整个文件，导致整个文件无法正确显示。
因此，UTF-8和UTF-16编码方式所具有的“自同步性”、“非传递性”等特点除了增强抗干扰能力外，也提供了随机访问的能力。
由于在大多数的文本数据中，代理对(增补字符码元序列)出现的概率是很小的，很多情况下处理的还是非代理码元(即BMP字符码元)，导致许多软件处理代理对的部分往往得不到充分的测试。这导致了一些长期的bug与潜在安全漏洞，甚至广为流行、得到良好评价的优秀软件也是如此。
因此，虽然编程时同时考虑文本中可能出现的不同存储长度的字符(BMP有效字符是单16位编码，即单码元编码；增补字符是双16位编码，即双码元编码)并相应做出不同的处理，会比单纯只考虑16位编码在性能上要逊色一些。但实际上，现有的遵循定长16位编码规范但不能处理代理对的程序只需做很小的一点修改就可以同时处理BMP有效字符和增补字符的编码了。
另外，需要特别注意的是，虽然Unicode标准规定BMP代理区(U+D800~,lll.,lllllllU+DFFF)的码点值不对应于任何字符，即未作定义，但是在使用UCS-2的时代，U+D800~U+DFFF是被定义了的，也就是已经用于某些字符了。不过，只要不是恰好构成了代理对，许多程序还是能把这些不匹配Unicode标准的字符码元正确地辨识、转换成合规的码元。这种由历史原因造成的码元序列按现在的Unicode标准来看，应算作是编码错误。
