UTF-16
UTF-16是Unicode字符编码五层次模型的第三层：字符编码表（Character Encoding Form，也称为"storage format"）的一种实现方式。即把Unicode字符集的抽象码位映射为16位长的整数（即码元）的-{序列}-，用于数据存储或传递。Unicode字符的码位，需要1个或者2个16位长的码元来表示，因此这是一个变长表示。
UTF是"Unicode/UCS Transformation Format"的首字母缩写，即把Unicode字符转换为某種格式之意。UTF-16正式定義於ISO/IEC 10646-1的附錄C，而RFC2781也定義了相似的做法。
Unicode的编码空间从U+0000到U+10FFFF，共有1,112,064个码位（code point）可用来映射字符。Unicode的编码空间可以划分为17个平面（plane），每个平面包含2（65,536）个码位。17个平面的码位可表示为从U+xx0000到U+xxFFFF，其中xx表示十六进制值从00到10，共计17个平面。第一个平面称为基本多语言平面（Basic Multilingual Plane, BMP），或稱第零平面（Plane 0），其他平面称为辅助平面（Supplementary Planes）。基本多语言平面內，從U+D800到U+DFFF之間的码位區段是永久保留不映射到Unicode字符。UTF-16就利用保留下来的0xD800-0xDFFF区段的码位來對輔助平面的字符的码位進行編碼。
第一个Unicode平面（码位从U+0000至U+FFFF）包含了最常用的字符。该平面被称为基本多语言平面，缩写为"BMP"（Basic Multilingual Plane，BMP）。UTF-16与UCS-2编码这个范围内的码位为16比特长的单个码元，数值等价于对应的码位。BMP中的这些码位是仅有的可以在UCS-2中表示的码位。
辅助平面（Supplementary Planes）中的码位，在UTF-16中被编码为一对16比特长的码元（即32位元，4字節），称作"代理对"（Surrogate Pair），具体方法是：上述算法可理解为：辅助平面中的码位从U+10000到U+10FFFF，共计FFFFF个，即2=1,048,576个，需要20位来表示。如果用两个16位长的整数组成的-{序列}-来表示，第一个整数（称为前导代理）要容纳上述20位的前10位，第二个整数（称为后尾代理）容纳上述20位的后10位。还要能根据16位整数的值直接判明属于前导整数代理的值的范围（2=1024)，还是后尾整数代理的值的范围（也是2=1024）。因此，需要在基本多语言平面中保留不对应于Unicode字符的2048个码位，就足以容纳前导代理与后尾代理所需要的编码空间。这对于基本多语言平面总计65536个码位来说，仅占3.125%。
由于前导代理、后尾代理、BMP中的有效字符的码位，三者互不重叠，搜索是简单的：一个字符编码的一部分不可能与另一个字符编码的不同部分相重叠。这意味着UTF-16是自同步（self-synchronizing）的：可以通过仅检查一个码元来判定给定字符的下一个字符的起始码元。UTF-8也有类似优点，但许多早期的编码模式就不是这样，必须从头开始分析文本才能确定不同字符的码元的边界。
由于最常有的字符都在基本多文种平面中，许多软件处理代理对的部分往往得不到充分的测试。这导致了一些长期的bug与潜在安全漏洞，它们甚至存在于广为流行且评价颇高的应用软件中。
Unicode标准规定U+D800...U+DFFF的值不对应于任何字符。
但是在使用UCS-2的时代，U+D800...U+DFFF内的值被占用，用于某些字符的映射。但只要不构成代理对，许多UTF-16编码解码还是能把这些不符合Unicode标准的字符映射正确的辨识、转换成合规的码元。按照Unicode标准，这种码元序列本来应算作编码错误。
以U+10437编码（𐐷）为例: 假設要將U+64321（16進位）轉成UTF-16編碼。因為它超過U+FFFF，所以他必須編譯成32位元（4個byte）的格式，如下所示：
所以這個字U+64321最後正確的UTF-16編碼應該是： 而在小尾序中最后的编码应该是：
因為這個字超過U+FFFF所以無法用UCS-2的格式編碼。
UTF-16比起UTF-8，好處在於大部分字符都以固定長度的字節（2字節）儲存，但UTF-16卻無法相容於ASCII編碼。
UTF-16的大尾序和小尾序儲存形式都在用。一般來說，以Macintosh製作或儲存的文字使用大尾序格式，以Microsoft或Linux製作或儲存的文字使用小尾序格式。
為了弄清楚UTF-16文件的大小尾序，在UTF-16文件的開首，都會放置一個U+FEFF字符作為Byte Order Mark（UTF-16 LE以 codice_19 代表，UTF-16 BE以 codice_20 代表），以顯示這個文字檔案是以UTF-16編碼，其中U+FEFF字符在UNICODE中代表的意義是 codice_21，顧名思義，它是個沒有寬度也沒有斷字的空白。
以下的例子有四個字符：「朱」（U+6731）、半角逗號（U+002C）、「聿」（U+807F）、「」（U+2A6A5）。
UTF-16可看成是UCS-2的父集。在沒有輔助平面字符（surrogate code points）前，UTF-16與UCS-2所指的是同一的意思。但當引入輔助平面字符後，就稱為UTF-16了。現在若有軟件聲稱自己支援UCS-2編碼，那其實是暗指它不能支援在UTF-16中超過2位元組的字集。對於小於0x10000的UCS碼，UTF-16編碼就等於UCS碼。
Windows操作系统内核中的字符表示为UTF-16小尾序，可以正确处理、显示以4字节存储的字符。但是Windows API实际上仅能正确处理UCS-2字符，即仅以2字节存储的，码位小于U+FFFF的Unicode字符。其根源是Microsoft C++语言把 codice_22 数据类型定义为16比特的unsigned short，这就与一个 codice_22 型变量对应一个宽字符、可以存储一个Unicode字符的规定相矛盾。相反，Linux平台的GCC编译器规定一个 codice_22 是4字节长度，可以存储一个UTF-32字符，宁可浪费了很大的存储空间。下例运行于Windows平台的C++程序可说明此点：
// 此源文件在Windows平台上必须保存为Unicode格式（即UTF-16小尾） // 因为包含的汉字“𪚥”，不能在简体中文版Windows默认的代码页936（即GBK）中表示 // 该汉字在UTF-16小尾序中用4个字节表示 // Windows操作系统能正确显示这样的在UTF-16需用4字节表示的字符 // 但是Windows API不能正确处理这样的在UTF-16需用4字节表示的字符，把它判定为2个UCS-2字符
int main()
Windows 9x系统的API仅支持ANSI字符集，只支持部分的UCS-2转换。1996年发布的Windows NT 4.0的API支持UCS-2。Windows 2000开始，Windows系统API开始支持UTF-16，并支持Surrogate Pair；但许多系统控件比如文本框和label等还不支持surrogate pair表示的字符，会显示成两个字符。Windows 7及更新的系统已经良好地支持了UTF-16，包括Surrogate Pair。
Windows API支持在UTF-16LE（codice_22类型）与UTF-8（代码页CP_UTF8）之间的转码。例如：
int main() {