UTF-16

注意ちゅうい：本ほん页有Unihan新版しんぱん汉字：「𪚥、𤭢」，這些字じ符ふ可能かのう會かい错误显示，詳しょう见Unicode扩展汉字。

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也定義ていぎ了りょう相似そうじ的てき做法。

UTF-16描述

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区く段だん的てき码位來らい對たい輔助平面へいめん的てき字じ符ふ的てき码位進行しんこう編へん碼。

从U+0000至いたりU+D7FF以及从U+E000至いたりU+FFFF的てき码位

第だい一いち个Unicode平面へいめん（码位从U+0000至いたりU+FFFF）包含ほうがん了りょう最さい常用じょうよう的てき字じ符ふ。该平面めん被ひ称しょう为基本多ほんだ语言平面へいめん，缩写为BMP（Basic Multilingual Plane，BMP）。UTF-16与あずかUCS-2编码这个范围内ない的てき码位为16比ひ特とく长的单个码元，数すう值等价于对应的てき码位。BMP中ちゅう的てき这些码位是ぜ仅有的てき可か以在UCS-2中ちゅう表示ひょうじ的てき码位。

从U+10000到いたU+10FFFF的てき码位

辅助平面へいめん（Supplementary Planes）中ちゅう的てき码位，在ざいUTF-16中ちゅう被ひ编码为一いち对16比ひ特とく长的码元（即そく32位い元もと，4字じ節ぶし），称しょう作さく代理だいり对（Surrogate Pair），具体ぐたい方法ほうほう是ぜ：

UTF-16解かい碼

lead \ trail	DC00	DC01	…	DFFF
D800	10000	10001	…	103FF
D801	10400	10401	…	107FF
⋮	⋮	⋮	⋱	⋮
DBFF	10FC00	10FC01	…	10FFFF

1. 码位减去 0x10000，得え到いた的てき值的范围为20比ひ特とく长的 0...0xFFFFF。
2. 高位こうい的てき10比ひ特とく的てき值（值的范围为 0...0x3FF）被ひ加か上じょう 0xD800 得え到いた第だい一个码元或称作高位代理（high surrogate），值的范围是ぜ 0xD800...0xDBFF。由よし于高位い代理だいり比ひ低位ていい代理だいり的てき值要小しょう，所以ゆえん为了避免混淆こんこう使用しよう，Unicode标准现在称しょう高だか位い代理だいり为前ぜん导代理だいり（lead surrogates）。
3. 低位ていい的てき10比ひ特とく的てき值（值的范围也是 0...0x3FF）被ひ加か上じょう 0xDC00 得え到いた第だい二个码元或称作低位代理（low surrogate），现在值的范围是ぜ 0xDC00...0xDFFF。由よし于低位い代理だいり比ひ高位こうい代理だいり的てき值要大だい，所以ゆえん为了避免混淆こんこう使用しよう，Unicode标准现在称しょう低位ていい代理だいり为后きさき尾お代理だいり（trail surrogates）。

上述じょうじゅつ算法さんぽう可か理解りかい为：辅助平面へいめん中ちゅう的てき码位从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与あずか潜在せんざい安全あんぜん漏も洞ほら，它们甚至存在そんざい于广为流行りゅうこう且评价颇高だか的てき应用软件中ちゅう。

从U+D800到いたU+DFFF的てき码位

Unicode标准规定U+D800...U+DFFF的てき值不对应于任何なん字じ符ふ。

但ただし是ぜ在ざい使用しようUCS-2的てき时代，U+D800...U+DFFF内的ないてき值被占うらない用よう，用よう于某些字符ふ的てき映うつ射しゃ。但ただし只ただ要よう不ふ构成代理だいり对，许多UTF-16编码解かい码还是能これよし把わ这些不ふ符合ふごうUnicode标准的てき字じ符ふ映うつ射い正せい确的辨べん识、转换成合なれあい规的码元。按照Unicode标准，这种码元序列じょれつ本来ほんらい应算作さく编码错误。

範はん例れい：

以U+10437编码（𐐷）为例:

1. 0x10437 减去 0x10000，结果为0x00437，二に进制为 0000 0000 0100 0011 0111
2. 分割ぶんかつ它的上じょう10位い值和下か10位い值（使用しよう二に进制）：0000 0000 01 和わ 00 0011 0111
3. 添加てんか 0xD800 到いた上うわ值，以形成けいせい高位こうい：0xD800 + 0x0001 = 0xD801
4. 添加てんか 0xDC00 到いた下しも值，以形成けいせい低位ていい：0xDC00 + 0x0037 = 0xDC37

• 下表かひょう总结了りょう一起示例的转换过程，颜色指示しじ码点位い如何いか分布ぶんぷ在所ざいしょ述じゅつ的てきUTF-16中ちゅう。由ゆかりUTF-16编码过程中ちゅう加入かにゅう附加ふか位い的てき以黑色しょく显示。

字じ符ふ		普通ふつう二に进制	UTF-16二に进制	UTF-16 十じゅう六ろく进制 字じ符ふ代だい码	UTF-16BE 十じゅう六ろく进制字じ节	UTF-16LE 十じゅう六ろく进制字じ节
$	U+0024	0000 0000 0010 0100	0000 0000 0010 0100	0024	00 24	24 00
€	U+20AC	0010 0000 1010 1100	0010 0000 1010 1100	20AC	20 AC	AC 20
𐐷	U+10437	0001 0000 0100 0011 0111	1101 1000 0000 0001 1101 1100 0011 0111	D801 DC37	D8 01 DC 37	01 D8 37 DC
𤭢	U+24B62	0010 0100 1011 0110 0010	1101 1000 0101 0010 1101 1111 0110 0010	D852 DF62	D8 52 DF 62	52 D8 62 DF

範はん例れい：UTF-16編へん碼程序じょ

假設かせつ要よう將しょうU+64321（16進しん位い）轉成てんせいUTF-16編へん碼。因よし為ため它超過ちょうかU+FFFF，所以ゆえん他た必須ひっす編へん譯やく成なり32位い元もと（4個こbyte）的てき格式かくしき，如下所しょ示しめせ：

V = 0x64321
Vx = V - 0x10000
= 0x54321
= 0101 0100 0011 0010 0001

Vh = 01 0101 0000 // Vx的てき高位こうい部ぶ份的10 bits
Vl = 11 0010 0001 // Vx的てき低位ていい部ぶ份的10 bits
w1 = 0xD800 //結果けっか的てき前まえ16位い元もと初はつ始はじめ值
w2 = 0xDC00 //結果けっか的てき後ご16位い元もと初はつ始はじめ值

w1 = w1 | Vh
= 1101 1000 0000 0000
 |       01 0101 0000
= 1101 1001 0101 0000
= 0xD950

w2 = w2 | Vl
= 1101 1100 0000 0000
 |       11 0010 0001
= 1101 1111 0010 0001
= 0xDF21

所以ゆえん這個字じU+64321最後さいご正確せいかく的てきUTF-16編へん碼應該是：

0xD950 0xDF21

而在小尾おび序じょ中ちゅう最さい后きさき的てき编码应该是ぜ：

0x50D9 0x21DF

因いん為ため這個字じ超過ちょうかU+FFFF所以ゆえん無法むほう用ようUCS-2的てき格式かくしき編へん碼。

16進しん制せい編へん碼範圍はんい	UTF-16表示ひょうじ方法ほうほう（二に進しん制せい）	10進しん制せい碼範圍はんい	字じ節ぶし數量すうりょう
U+0000 - U+FFFF	xxxx xxxx xxxx xxxx - yyyy yyyy yyyy yyyy	0-65535	2
U+10000 - U+10FFFF	1101 10yy yyyy yyyy - 1101 11xx xxxx xxxx	65536-1114111	4

UTF-16比ひ起おこりUTF-8，好こう處しょ在ざい於大おだい部分ぶぶん字じ符ふ都と以固定こてい長ちょう度ど的てき字じ節ぶし（2字じ節ぶし）儲もうか存そん，但ただしUTF-16卻無法相ほうしょう容よう於ASCII編へん碼。

UTF-16的てき編へん碼模式しき

UTF-16的てき大尾たいび序じょ和わ小尾おび序じょ儲もうか存そん形式けいしき都と在ざい用よう。一般いっぱん來らい說せつ，以Macintosh製作せいさく或ある儲もうか存そん的てき文字もじ使用しよう大尾たいび序じょ格式かくしき，以Microsoft或あるLinux製作せいさく或ある儲もうか存そん的てき文字もじ使用しよう小尾こび序じょ格式かくしき。

為ため了りょう弄ろう清楚せいそUTF-16文ぶん件けん的てき大小だいしょう尾お序じょ，在ざいUTF-16文ぶん件けん的てき開ひらき首くび，都會とかい放置ほうち一いち個こU+FEFF字じ符ふ作為さくいByte Order Mark（UTF-16 LE以 FF FE 代表だいひょう，UTF-16 BE以 FE FF 代表だいひょう），以顯示けんじ這個文字もじ檔案是ぜ以UTF-16編へん碼，其中U+FEFF字じ符ふ在ざいUNICODE中ちゅう代表だいひょう的てき意義いぎ是ぜ ZERO WIDTH NO-BREAK SPACE，顧名思おもえ義よし，它是個こ沒ぼつ有ゆう寬ひろし度ど也沒有ゆう斷だん字じ的てき空白くうはく。

以下いか的てき例れい子こ有ゆう四よん個こ字じ符ふ：「朱しゅ」（U+6731）、半角はんかく逗號（U+002C）、「聿」（U+807F）、「𪚥」（U+2A6A5）。

使用しようUTF-16編へん碼的例れい子こ
編へん碼名稱めいしょう	編へん碼次序じょ	編へん碼
		BOM	朱しゅ	,	聿	𪚥
UTF-16 LE	小尾こび序じょ，不ふ含BOM		31 67	2C 00	7F 80	69 D8 A5 DE
UTF-16 BE	大尾たいび序じょ，不ふ含BOM		67 31	00 2C	80 7F	D8 69 DE A5
UTF-16 LE	小尾こび序じょ，包含ほうがんBOM	FF FE	31 67	2C 00	7F 80	69 D8 A5 DE
UTF-16 BE	大尾たいび序じょ，包含ほうがんBOM	FE FF	67 31	00 2C	80 7F	D8 69 DE A5

UTF-16與あずかUCS-2的てき關係かんけい

UTF-16可か看み成なり是ぜUCS-2的てき父ちち集しゅう。在ざい沒ぼつ有ゆう輔助平面へいめん字じ符ふ（surrogate code points）前まえ，UTF-16與あずかUCS-2所しょ指ゆび的てき是ぜ同一どういつ的てき意思いし。但ただし當とう引入輔助平面へいめん字じ符ふ後ご，就稱為ためUTF-16了りょう。現在げんざい若わか有ゆう軟件聲ごえ稱しょう自己じこ支援しえんUCS-2編へん碼，那な其實是ぜ暗くら指ゆび它不能ふのう支援しえん在ざいUTF-16中ちゅう超過ちょうか2位い元もと組ぐみ的てき字じ集しゅう。對たい於小於0x10000的てきUCS碼，UTF-16編へん碼就等とう於UCS碼。

Microsoft Windows操作そうさ系けい统内核かく对Unicode的てき支持しじ

Windows操作そうさ系けい统内核かく中ちゅう的てき字じ符ふ表示ひょうじ为UTF-16小尾こび序じょ，可か以正确处理り、显示以4字じ节存储的字じ符ふ。但ただし是ぜWindows API实际上じょう仅能正せい确处理りUCS-2字じ符ふ，即そく仅以2字じ节存储的，码位小しょう于U+FFFF的てきUnicode字じ符ふ。其根源みなもと是ただしMicrosoft C++语言把わ wchar_t 数かず据すえ类型定てい义为16比ひ特とく的てきunsigned short，这就与一よいち个 wchar_t 型かた变量对应一いち个宽字符ふ、可か以存储一个Unicode字じ符ふ的てき规定相しょう矛盾むじゅん。相反あいはん，Linux平台ひらだい的てきGCC编译器き规定一いち个 wchar_t 是ぜ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字じ符ふ

#include <windows.h>
#include <stdio.h>

int main()
{
	const wchar_t lwc[] = L"𪚥";

	MessageBoxW(NULL, lwc, lwc, MB_OK);

	int i = wcslen(lwc);
	printf("%d\n", i);
	int j = lstrlenW(lwc);
	printf("%d\n", j);

	return 0;
}

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（wchar_t类型）与あずかUTF-8（代だい码页CP_UTF8）之の间的转码。例れい如：

#include <windows.h>
int main() {
	char a1[128], a2[128] = { "Hello" };
	wchar_t w = L'页';
	int n1, n2= 5;
	wchar_t w1[128];
	int m1 = 0;

	n1 = WideCharToMultiByte(CP_UTF8, 0, &w, 1, a1, 128, NULL, NULL);
	m1 = MultiByteToWideChar(CP_UTF8, 0, a2, n2, w1, 128);
}

外部がいぶ連結れんけつ

• Unicode Technical Note #12: UTF-16 for Processing （页面存そん档备份，存そん于互联网档案あん馆）
• A very short algorithm for determining the surrogate pair for any codepoint（页面存そん档备份，存そん于互联网档案あん馆）
• Unicode FAQ: What is the difference between UCS-2 and UTF-16? （页面存そん档备份，存そん于互联网档案あん馆）
• Unicode Character Name Index （页面存そん档备份，存そん于互联网档案あん馆）
• RFC 2781: UTF-16, an encoding of ISO 10646
• java.lang.String documentation, discussing surrogate handling （页面存そん档备份，存そん于互联网档案あん馆）