Unicode（统一码、万国码、单一码）是计算机科学领域里的一项业界标准，包括字符集、编码方案等。
Unicode 是为了解决传统的字符编码方案的局限而产生的，它为每种语言中的每个字符设定了统一并且唯一的二进制编码，以满足跨语言、跨平台进行文本转换、处理的要求。1990年开始研发，1994年正式公布。
起源
因为计算机只能处理数字，如果要处理文本，就必须先把文本转换为数字才能处理。最早的计算机在设计时采用8个比特（bit）作为一个字节（byte）。一个字节能表示的最大的整数就是255（2^8-1=255），而ASCII编码，占用65- 122用来表示大小写英文字母、数字和一些符号，这个编码表被称为ASCII编码，比如大写字母A的编码是65，小写字母z的编码是122。
如果要表示中文，显然一个字节是不够的，至少需要两个字节，而且还不能和ASCII编码冲突，所以，中国制定了GB2312编码，用来把中文编进去。
类似的，日文和韩文等其他语言也有这个问题。为了统一所有文字的编码，Unicode应运而生。Unicode把所有语言都统一到一套编码里，这样就不会再有乱码问题了。
Unicode通常用两个字节表示一个字符，原有的英文编码从单字节变成双字节，只需要把高字节全部填为0就可以。
因为Python的诞生比Unicode标准发布的时间还要早，所以最早的Python只支持ASCII编码，普通的字符串’ABC’在Python内部都是ASCII编码的。
Unicode 是为了解决传统的字符编码方案的局限而产生的，例如ISO 8859所定义的字符虽然在不同的国家中广泛地使用，可是在不同国家间却经常出现不兼容的情况。很多传统的编码方式都有一个共同的问题，即容许电脑处理双语环境（通常使用拉丁字母以及其本地语言），但却无法同时支持多语言环境（指可同时处理多种语言混合的情况）。
Unicode 编码包含了不同写法的字，如“ɑ/a”、“户/户/戸”。然而在汉字方面引起了一字多形的认定争议。
在文字处理方面，统一码为每一个字符而非字形定义唯一的代码（即一个整数）。换句话说，统一码以一种抽象的方式（即数字）来处理字符，并将视觉上的演绎工作（例如字体大小、外观形状、字体形态、文体等）留给其他软件来处理，例如网页浏览器或是文字处理器。
几乎所有电脑系统都支持基本拉丁字母，并各自支持不同的其他编码方式。Unicode为了和它们相互兼容，其首256字符保留给ISO 8859-1所定义的字符，使既有的西欧语系文字的转换不需特别考量；并且把大量相同的字符重复编到不同的字符码中去，使得旧有纷杂的编码方式得以和Unicode编码间互相直接转换，而不会丢失任何信息。举例来说，全角格式区段包含了主要的拉丁字母的全角格式，在中文、日文、以及韩文字形当中，这些字符以全角的方式来呈现，而不以常见的半角形式显示，这对竖排文字和等宽排列文字有重要作用。
在表示一个Unicode的字符时，通常会用“U+”然后紧接着一组十六进制的数字来表示这一个字符。在基本多文种平面（英文为 Basic Multilingual Plane，简写 BMP。它又简称为“零号平面”, plane 0）里的所有字符，要用四位十六进制数（例如U+4AE0，共支持六万多个字符）；在零号平面以外的字符则需要使用五位或六位十六进制数了。旧版的Unicode标准使用相近的标记方法，但却有些微的差异：在Unicode 3.0里使用“U-”然后紧接着八位数，而“U+”则必须随后紧接着四位数。
作用
能够使计算机实现跨语言、跨平台的文本转换及处理。
层次
Unicode 编码系统，可分为编码方式和实现方式两个层次。
方式
Unicode是国际组织制定的可以容纳世界上所有文字和符号的字符编码方案。目前的Unicode字符分为17组编排，0x0000 至 0x10FFFF，每组称为平面（Plane），而每平面拥有65536个码位，共1114112个。然而目前只用了少数平面。UTF-8、UTF-16、UTF-32都是将数字转换到程序数据的编码方案。
通用字符集（Universal Character Set, UCS）是由ISO制定的ISO 10646（或称ISO/IEC 10646）标准所定义的标准字符集。 UCS-2用两个字节编码，UCS-4用4个字节编码。
历史上存在两个独立的尝试创立单一字符集的组织，即国际标准化组织（ISO）和多语言软件制造商组成的统一码联盟。前者开发的 ISO/IEC 10646 项目，后者开发的统一码项目。因此最初制定了不同的标准。
1991年前后，两个项目的参与者都认识到，世界不需要两个不兼容的字符集。于是，它们开始合并双方的工作成果，并为创立一个单一编码表而协同工作。从Unicode 2.0开始，Unicode采用了与ISO 10646-1相同的字库和字码；ISO也承诺，ISO 10646将不会替超出U+10FFFF的UCS-4编码赋值，以使得两者保持一致。两个项目仍都存在，并独立地公布各自的标准。但统一码联盟和ISO/IEC JTC1/SC2都同意保持两者标准的码表兼容，并紧密地共同调整任何未来的扩展。在发布的时候，Unicode一般都会采用有关字码最常见的字型，但ISO 10646一般都尽可能采用Century字型。
国际标准化组织（ISO）
UCS-4根据最高位为0的最高字节分成2^7=128个组（group）。每个group再根据次高字节分为256个平面（plane）。每个平面根据第3个字节分为256行 （row），每行有256个码位（cell）。group 0的平面0被称作BMP（Basic Multilingual Plane）。如果UCS-4的前两个字节为全零，那么将UCS-4的BMP去掉前面的两个零字节就得到了UCS-2。每个平面有256 * 256=65536个码位。
多语言软件制造商组成的统一码联盟
Unicode计划使用了17个平面，一共有17×65536=1114112个码位。在Unicode 5.0.0版本中，已定义的码位只有238605个，分布在平面0、平面1、平面2、平面14、平面15、平面16。其中平面15和平面16上只是定义了两个各占65534个码位的专用区（Private Use Area），分别是0xF0000-0xFFFFD和0x100000-0x10FFFD。所谓专用区，就是保留给大家放自定义字符的区域，可以简写为PUA。
平面0也有一个专用区：0xE000-0xF8FF，有6400个码位。平面0的0xD800-0xDFFF，共2048个码位，是一个被称作代理区（Surrogate）的特殊区域。代理区的目的用两个UTF-16字符表示BMP以外的字符。在介绍UTF-16编码时会介绍。
如前所述在Unicode 5.0.0版本中，238605-65534*2-6400-2048=99089。余下的99089个已定义码位分布在平面0、平面1、平面2和平面14上，它们对应着Unicode定义的99089个字符，其中包括71226个汉字。平面0、平面1、平面2和平面14上分别定义了52080、3419、43253和337个字符。平面2的43253个字符都是汉字。平面0上定义了27973个汉字。
在Unicode中：汉字“字”对应的数字是23383（十进制），十六进制表示为5B57。在Unicode中，我们有很多方式将数字23383表示成程序中的数据，包括：UTF-8、UTF-16、UTF-32。
UTF- Unicode字符集转换格式
UTF是“Unicode Transformation Format”的缩写，可以翻译成Unicode字符集转换格式，即怎样将Unicode定义的数字转换成程序数据。
例如，“汉字”对应的数字是0x6c49和0x5b57，而编码的程序数据是：
char data_utf8[] = { 0xE6,0xB1,0x89,0xE5,0xAD,0x97 }; // UTF-8编码
char16_t data_utf16[] = { 0x6C49,0x5B57 }; // UTF-16编码
char32_t data_utf32[] = { 0x00006C49,0x00005B57 }; // UTF-32编码这里用char、char16_t、char32_t分别表示无符号8位整数，无符号16位整数和无符号32位整数。
UTF-8、UTF-16、UTF-32分别以 char、char16_t、char32_t 作为编码单位。（注： char16_t 和 char32_t 是 C++ 11 标准新增的关键字。如果你的编译器不支持 C++ 11 标准，请改用 unsigned short 和 unsigned long。）
“汉字”的UTF-8编码需要6个字节。“汉字”的UTF-16编码需要两个char16_t，大小是4个字节。“汉字”的UTF-32编码需要两个char32_t，大小是8个字节。根据字节序的不同，UTF-16可以被实现为UTF-16LE或UTF-16BE，UTF-32可以被实现为UTF-32LE或UTF-32BE。
下面介绍UTF-8、UTF-16、UTF-32、字节序和BOM。
UTF-8
UTF-8以字节为单位对Unicode进行编码。从Unicode到UTF-8的编码方式如下：
Unicode编码(十六进制)UTF-8 字节流(二进制)
000000-00007F0xxxxxxx
000080-0007FF110xxxxx 10xxxxxx
000800-00FFFF1110xxxx 10xxxxxx 10xxxxxx
010000-10FFFF11110xxx 10xxxxxx 10xxxxxx 10xxxxxx
UTF-8的特点是对不同范围的字符使用不同长度的编码。对于0x00-0x7F之间的字符，UTF-8编码与ASCII编码完全相同。UTF-8编码的最大长度是4个字节。从上表可以看出，4字节模板有21个x，即可以容纳21位二进制数字。Unicode的最大码位0x10FFFF也只有21位。
例1：“汉”字的Unicode编码是0x6C49。0x6C49在0x000800-0x00FFFF之间，使用3字节模板：1110xxxx 10xxxxxx 10xxxxxx。将0x6C49写成二进制是：0110 1100 0100 1001， 用这个比特流依次代替模板中的x，得到：11100110 10110001 10001001，即E6 B1 89。
例2：Unicode编码0x20C30在0x010000-0x10FFFF之间，使用4字节模板：11110xxx 10xxxxxx 10xxxxxx 10xxxxxx。将0x20C30写成21位二进制数字（不足21位就在前面补0）：0 0010 0000 1100 0011 0000，用这个比特流依次代替模板中的x，得到：11110000 10100000 10110000 10110000，即F0 A0 B0 B0。
UTF-16
UTF-16编码以16位无符号整数为单位。我们把Unicode编码记作U。
编码规则如下：
如果U<0x10000，U的UTF-16编码就是U对应的16位无符号整数（为书写简便，下文将16位无符号整数记作WORD）。
如果U≥0x10000，我们先计算U'=U-0x10000，然后将U'写成二进制形式：yyyy yyyy yyxx xxxx xxxx，U的UTF-16编码（二进制）就是：110110yy yyyyyyyy 110111xx xxxxxxxx。
为什么U’可以被写成20个二进制位？
Unicode的最大码位是0x10FFFF，减去0x10000后，U’的最大值是0xFFFFF，所以肯定可以用20个二进制位表示。例如：Unicode编码0x20C30，减去0x10000后，得到0x10C30，写成二进制是：0001 0000 1100 0011 0000。用前10位依次替代模板中的y，用后10位依次替代模板中的x，就得到：11011000 01000011 11011100 00110000，即0xD843 0xDC30。
按照上述规则，Unicode编码0x10000-0x10FFFF的UTF-16编码有两个WORD，第一个WORD的高6位是110110，第二个WORD的高6位是110111。可见，第一个WORD的取值范围（二进制）是11011000 00000000到11011011 11111111，即0xD800-0xDBFF。 第二个WORD的取值范围（二进制）是11011100 00000000到11011111 11111111，即0xDC00-0xDFFF。
为了将一个WORD的UTF-16编码与两个WORD的UTF-16编码区分开来，Unicode编码的设计者将0xD800-0xDFFF保留下来，并称为代理区（Surrogate）：
高位替代就是指这个范围的码位是两个WORD的UTF-16编码的第一个WORD。低位替代就是指这个范围的码位是两个WORD的UTF-16编码的第二个WORD。
那么，高位专用替代是什么意思？我们来解答这个问题，顺便看看怎么由UTF-16编码推导Unicode编码。
如果一个字符的UTF-16编码的第一个WORD在0xDB80到0xDBFF之间，那么它的Unicode编码在什么范围内？我们知道第二个WORD的取值范围是0xDC00-0xDFFF，所以这个字符的UTF-16编码范围应该是0xDB80 0xDC00 到 0xDBFF 0xDFFF。我们将这个范围写成二进制：
11011011 10000000 11011100 00000000 - 11011011 11111111 11011111 11111111
11011011 10000000 11011100 00000000 - 11011011 11111111 11011111 11111111
按照编码的相反步骤，取出高低WORD的后10位，并拼在一起，得到
1110 0000 0000 0000 0000 - 1111 1111 1111 1111 1111
即0xe0000-0xfffff，按照编码的相反步骤再加上0x10000，得到0xf0000-0x10ffff。 这个范围是怎么来的，可以看上面对应部分，截图如下。
这就是UTF-16编码的第一个WORD在0xdb80到0xdbff之间的Unicode编码范围，即平面15和平面16。因为Unicode标准将平面15和平面16都作为专用区，所以0xDB80到0xDBFF之间的保留码位被称作高位专用替代。
UTF-32
UTF-32编码以32位无符号整数为单位。Unicode的UTF-32编码就是其对应的32位无符号整数。
字节序
字节序有两种，分别是“大端”（Big Endian, BE）和“小端”（Little Endian, LE）。
根据字节序的不同，UTF-16可被实现为UTF-16LE或UTF-16BE，UTF-32可被实现为UTF-32LE或UTF-32BE。例如：
Unicode标准建议用BOM（Byte Order Mark）来区分字节序，即在传输字节流前，先传输被作为BOM的字符“零宽无中断空格”。这个字符的编码是FEFF，而反过来的FFFE（UTF-16）和 FFFE0000（UTF-32）在Unicode中都是未定义的码位，不应该出现在实际传输中。
下表是各种UTF编码的BOM：
BOM（Byte Order Mark）
BOM（Byte Order Mark），字节顺序标记，出现在文本文件头部，Unicode编码标准中用于标识文件是采用哪种格式的编码。
在UCS 编码中有一个叫做 “Zero Width No-Break Space” ，中文译名作“零宽无间断间隔”的字符，它的编码是 FEFF。而 FFFE 在 UCS 中是不存在的字符，所以不应该出现在实际传输中。UCS 规范建议我们在传输字节流前，先传输字符 “Zero Width No-Break Space”。这样如果接收者收到 FEFF，就表明这个字节流是 Big-Endian 的；如果收到FFFE，就表明这个字节流是 Little- Endian 的。因此字符 “Zero Width No-Break Space” （“零宽无间断间隔”）又被称作 BOM。
如何区分呢？ 我们可以这样记忆
FEFF FE < FF，大的在后面所以是Big-Endian 大端字节序，
FFFE FF > FE，小的在后面所以是Little- Endian 小端字节序
UTF-8 不需要 BOM 来表明字节顺序，但可以用 BOM 来表明编码方式。字符 “Zero Width No-Break Space” 的 UTF-8 编码是 EF BB BF。所以如果接收者收到以 EF BB BF 开头的字节流，就知道这是 UTF-8编码了。Windows 就是使用 BOM 来标记文本文件的编码方式的。
字符U+FEFF如果出现在字节流的开头，则用来标识该字节流的字节序，是高位在前还是低位在前。如果它出现在字节流的中间，则表达零宽度非换行空格的意义，用户看起来就是一个空格。从Unicode3.2开始，U+FEFF只能出现在字节流的开头，只能用于标识字节序，就如它的名称——字节序标记——所表示的一样；除此以外的用法已被舍弃。取而代之的是，使用U+2060来表达零宽度无断空白。
类似WINDOWS自带的记事本等软件，在保存一个以UTF-8编码的文件时，会在文件开始的地方插入三个不可见的字符（0xEF 0xBB 0xBF，即BOM）。它是一串隐藏的字符，用于让记事本等编辑器识别这个文件是否以UTF-8编码。对于一般的文件，这样并不会产生什么麻烦。但对于 PHP来说，BOM是个大麻烦。
PHP并不会忽略BOM，所以在读取、包含或者引用这些文件时，会把BOM作为该文件开头正文的一部分。根据嵌入式语言的特点，这串字符将被直接执行（显示）出来。由此造成即使页面的 top padding 设置为0，也无法让整个网页紧贴浏览器顶部，因为在html一开头有这3个字符呢！
不同编码的字节顺序标记的表示
分布
Unicode 到目前为止所定义的十七个平面中，第0平面(BMP)最为重要，其编码分布如下：
注：中文范围 4E00-9FA5：CJK 统一表意符号 (CJK Unified Ideographs)
0000-007F：C0控制符及基本拉丁文 (C0 Control and Basic Latin)
0080-00FF：C1控制符及拉丁文补充-1 (C1 Control and Latin 1 Supplement)
0100-017F：拉丁文扩展-A (Latin Extended-A)
0180-024F：拉丁文扩展-B (Latin Extended-B)
0250-02AF：国际音标扩展 (IPA Extensions)
02B0-02FF：空白修饰字母 (Spacing Modifiers)
0300-036F：结合用读音符号 (Combining Diacritics Marks)
0370-03FF：希腊文及科普特文 (Greek and Coptic)
0400-04FF：西里尔字母(Cyrillic)
0500-052F：西里尔字母补充 (Cyrillic Supplement)
0530-058F：亚美尼亚语 (Armenian)
0590-05FF：希伯来文 (Hebrew)
0600-06FF：阿拉伯文 (Arabic)
0700-074F：叙利亚文 (Syriac)
0750-077F：阿拉伯文补充 (Arabic Supplement)
0780-07BF：马尔代夫语 (Thaana)
07C0-07FF：西非书面语言 (N'Ko)
0800-085F：阿维斯塔语及巴列维语(Avestan and Pahlavi)
0860-087F：Mandaic
0880-08AF：撒马利亚语 (Samaritan)
0900-097F：天城文书 (Devanagari)
0980-09FF：孟加拉语 (Bengali)
0A00-0A7F：锡克教文 (Gurmukhi)
0A80-0AFF：古吉拉特文 (Gujarati)
0B00-0B7F：奥里亚文 (Oriya)
0B80-0BFF：泰米尔文 (Tamil)
0C00-0C7F：泰卢固文 (Telugu)
0C80-0CFF：卡纳达文 (Kannada)
0D00-0D7F：德拉维族语 (Malayalam)
0D80-0DFF：僧伽罗语 (Sinhala)
0E00-0E7F：泰文 (Thai)
0E80-0EFF：老挝文 (Lao)
0F00-0FFF：藏文 (Tibetan)
1000-109F：缅甸语 (Myanmar)
10A0-10FF：格鲁吉亚语(Georgian)
1100-11FF：朝鲜文 (Hangul Jamo)
1200-137F：埃塞俄比亚语 (Ethiopic)
1380-139F：埃塞俄比亚语补充 (Ethiopic Supplement)
13A0-13FF：切罗基语 (Cherokee)
1400-167F：统一加拿大土著语音节 (Unified Canadian Aboriginal Syllabics)
1680-169F：欧甘字母 (Ogham)
16A0-16FF：如尼文(Runic)
1700-171F：塔加拉语 (Tagalog)
1720-173F：Hanunóo
1740-175F：Buhid
1760-177F：塔格班瓦文(Tagbanwa)
1780-17FF：高棉语 (Khmer)
1800-18AF：蒙古文 (Mongolian)
18B0-18FF：Cham
1900-194F：Limbu
1950-197F：德宏泰语 (Tai Le)
1980-19DF：新傣仂语 (New Tai Lue)
19E0-19FF：高棉语记号 (Kmer Symbols)
1A00-1A1F：Buginese
1A20-1A5F：Batak
1A80-1AEF：Lanna
1B00-1B7F：巴厘语 (Balinese)
1B80-1BB0：巽他语 (Sundanese)
1BC0-1BFF：Pahawh Hmong
1C00-1C4F：雷布查语(Lepcha)
1C50-1C7F：桑塔利文(Ol Chiki)
1C80-1CDF：曼尼普尔语(Meithei/Manipuri)
1D00-1D7F：语音学扩展 (Phonetic Extensions)
1D80-1DBF：语音学扩展补充 (Phonetic Extensions Supplement)
1DC0-1DFF：结合用读音符号补充 (Combining Diacritics Marks Supplement)
1E00-1EFF：拉丁文扩充附加 (Latin Extended Additional)
1F00-1FFF：希腊语扩充 (Greek Extended)
2000-206F：常用标点(General Punctuation)
2070-209F：上标及下标 (Superscripts and Subscripts)
20A0-20CF：货币符号 (Currency Symbols)
20D0-20FF：组合用记号 (Combining Diacritics Marks for Symbols)
2100-214F：字母式符号 (Letterlike Symbols)
2150-218F：数字形式 (Number Form)
2190-21FF：箭头 (Arrows)
2200-22FF：数学运算符 (Mathematical Operator)
2300-23FF：杂项工业符号 (Miscellaneous Technical)
2400-243F：控制图片 (Control Pictures)
2440-245F：光学识别符 (Optical Character Recognition)
2460-24FF：封闭式字母数字 (Enclosed Alphanumerics)
2500-257F：制表符 (Box Drawing)
2580-259F：方块元素 (Block Element)
25A0-25FF：几何图形 (Geometric Shapes)
2600-26FF：杂项符号 (Miscellaneous Symbols)
2700-27BF：印刷符号 (Dingbats)
27C0-27EF：杂项数学符号-A (Miscellaneous Mathematical Symbols-A)
27F0-27FF：追加箭头-A (Supplemental Arrows-A)
2800-28FF：盲文点字模型 (Braille Patterns)
2900-297F：追加箭头-B (Supplemental Arrows-B)
2980-29FF：杂项数学符号-B (Miscellaneous Mathematical Symbols-B)
2A00-2AFF：追加数学运算符 (Supplemental Mathematical Operator)
2B00-2BFF：杂项符号和箭头 (Miscellaneous Symbols and Arrows)
2C00-2C5F：格拉哥里字母(Glagolitic)
2C60-2C7F：拉丁文扩展-C (Latin Extended-C)
2C80-2CFF：古埃及语 (Coptic)
2D00-2D2F：格鲁吉亚语补充 (Georgian Supplement)
2D30-2D7F：提非纳文 (Tifinagh)
2D80-2DDF：埃塞俄比亚语扩展 (Ethiopic Extended)
2E00-2E7F：追加标点 (Supplemental Punctuation)
2E80-2EFF：CJK 部首补充 (CJK Radicals Supplement)
2F00-2FDF：康熙字典部首 (Kangxi Radicals)
2FF0-2FFF：表意文字描述符 (Ideographic Description Characters)
3000-303F：CJK 符号和标点 (CJK Symbols and Punctuation)
3040-309F：日文平假名 (Hiragana)
30A0-30FF：日文片假名 (Katakana)
3100-312F：注音字母 (Bopomofo)
3130-318F：朝鲜文兼容字母 (Hangul Compatibility Jamo)
3190-319F：象形字注释标志 (Kanbun)
31A0-31BF：注音字母扩展 (Bopomofo Extended)
31C0-31EF：CJK 笔画 (CJK Strokes)
31F0-31FF：日文片假名语音扩展 (Katakana Phonetic Extensions)
3200-32FF：封闭式 CJK 文字和月份 (Enclosed CJK Letters and Months)
3300-33FF：CJK 兼容 (CJK Compatibility)
3400-4DBF：CJK 统一表意符号扩展 A (CJK Unified Ideographs Extension A)
4DC0-4DFF：易经六十四卦符号 (Yijing Hexagrams Symbols)
4E00-9FBF：CJK 统一表意符号 (CJK Unified Ideographs)
A000-A48F：彝文音节 (Yi Syllables)
A490-A4CF：彝文字根 (Yi Radicals)
A500-A61F：Vai
A660-A6FF：统一加拿大土著语音节补充 (Unified Canadian Aboriginal Syllabics Supplement)
A700-A71F：声调修饰字母 (Modifier Tone Letters)
A720-A7FF：拉丁文扩展-D (Latin Extended-D)
A800-A82F：Syloti Nagri
A840-A87F：八思巴字 (Phags-pa)
A880-A8DF：Saurashtra
A900-A97F：爪哇语 (Javanese)
A980-A9DF：Chakma
AA00-AA3F：Varang Kshiti
AA40-AA6F：Sorang Sompeng
AA80-AADF：Newari
AB00-AB5F：越南傣语 (Vi?t Thái)
AB80-ABA0：Kayah Li
AC00-D7AF：朝鲜文音节 (Hangul Syllables)
D800-DBFF：High-half zone of UTF-16
DC00-DFFF：Low-half zone of UTF-16
E000-F8FF：自行使用区域 (Private Use Zone)
F900-FAFF：CJK 兼容象形文字 (CJK Compatibility Ideographs)
FB00-FB4F：字母表达形式 (Alphabetic Presentation Form)
FB50-FDFF：阿拉伯表达形式A (Arabic Presentation Form-A)
FE00-FE0F：变量选择符 (Variation Selector)
FE10-FE1F：竖排形式 (Vertical Forms)
FE20-FE2F：组合用半符号 (Combining Half Marks)
FE30-FE4F：CJK 兼容形式 (CJK Compatibility Forms)
FE50-FE6F：小型变体形式 (Small Form Variants)
FE70-FEFF：阿拉伯表达形式B (Arabic Presentation Form-B)
FF00-FFEF：半型及全型形式 (Halfwidth and Fullwidth Form)
FFF0-FFFF：特殊 (Specials)
环境
在非 Unicode 环境下，由于不同国家和地区采用的字符集不一致，很可能出现无法正常显示所有字符的情况。微软公司使用了代码页(Codepage)转换表的技术来过渡性的部分解决这一问题，即通过指定的转换表将非 Unicode 的字符编码转换为同一字符对应的系统内部使用的 Unicode 编码。可以在“语言与区域设置”中选择一个代码页作为非 Unicode 编码所采用的默认编码方式，如936为简体中文GBK，950为繁体中文Big5（皆指PC上使用的）。
在这种情况下，一些非英语的欧洲语言编写的软件和文档很可能出现乱码。而将代码页设置为相应语言中文处理又会出现问题，这一情况无法避免。从根本上说，完全采用统一编码才是解决之道，但是Windows操作系统由于历史遗留原因尚无法做到这一点。
代码页技术广泛为各种平台所采用。UTF-7 的代码页是65000，UTF-8 的代码页是65001。
字集
XML及其子集HTML采用UTF-8作为标准字集，理论上我们可以在各种支持XML标准的浏览器上显示任何地区文字的网页，只要电脑本身安装有合适的字体即可。可以利用&#nnn;的格式显示特定的字符。nnn代表该字符的十进制 Unicode 代码。如果采用十六进制代码，在编码之前加上x字符即可。但部分旧版本的浏览器可能无法识别十六进制代码。
然而部分由于Unicode 版本发展原因，很多浏览器只能显示UCS-2 完整字符集也即日常使用的Unicode 版本中的一个小子集。
使用
为什么使用Unicode其实原因很简单，因为Unicode比ANSI好用。 自从Windows2K开始，Win的系统内核开始完全支持并完全应用Unicode编写，所有ANSI字符在进入底层前，都会被相应的API转换成Unicode。所以，如果你一开始就使用Unicode，则可以减少转换的用时和RAM开销。 对于JAVA/.NET等这些“新”的语言来说，内置的字符串所使用的字符集已经完全是Unicode。最重要的是，世界上大多数程序用的字符集都是Unicode，因为Unicode有利于程序国际化和标准化。
简史
1990年开始研发，1994年正式公布。随着计算机工作能力的增强，Unicode也在面世以来的十多年里得到普及。
Unicode6.3版已发布(2013年11月)。在Unicode联盟网站上可以查看完整的6.3的核心规范。
Unicode定义了大到足以代表人类所有可读字符的字符集。
Java语言就用到了Unicode编码，从而实现了该语言的国际通用性。
Unicode截至目前为止，共发布了以下多个版本：
Unicode 1.0：1991年10月
Unicode 1.0.1：1992年6月
Unicode 1.1：1993年6月
Unicode 2.0：1997年7月
Unicode 2.1：1998年5月
Unicode 2.1.2：1998年5月
Unicode 3.0：1999年9月；涵盖了来自ISO 10646-1的十六比特通用字符集（UCS）
基本多文种平面（Basic Multilingual Plane）
Unicode 3.1：2001年3月；新增从ISO 10646-2定义的辅助平面（Supplementary Planes）
Unicode 3.2：2002年3月
Unicode 4.0：2003年4月
Unicode 4.0.1：2004年3月
Unicode 4.1：2005年3月
Unicode 5.0：2006年7月
Unicode 5.1：2008年4月
Unicode 5.2：2009年10月
Unicode 6.0：2010年10月
Unicode 6.1：2012年1月31日
Unicode 6.2：2012年9月
Unicode 6.3：2013年11月19日
Unicode 7.0：2014年6月15日
Unicode 8.0：2015年6月17日
Unicode 9.0：2016年6月22日
Unicode 10.0：2017年6月18日
Unicode 11.0：2018年6月5日
Unicode 12.1.0 2019年5月7号
688