Unicode
(统一码、万国码、单一码)是一种在
计算机
上使用的
字符
编码。它为每种
语言
中的每个字符设定了统一并且唯一的
二进制
编码,以满足跨语言、跨平台进行文本转换、处理的要求。
1990
年开始研发,
1994
年正式公布。随着计算机工作能力的增强,
Unicode
也在面世以来的十多年里得到普及。
2006 年 6月 的最新版本的 Unicode 是 2005年3月31日推出的Unicode 4.1.0 。另外,5.0 Beta已于2005年12月12日推出,以供各会员评价。
2006 年 6月 的最新版本的 Unicode 是 2005年3月31日推出的Unicode 4.1.0 。另外,5.0 Beta已于2005年12月12日推出,以供各会员评价。
Unicode
的编码和实现
大概来说,
Unicode
编码系统可分为
编码方式
和实现方式两个层次。
1. 编码方式
Unicode 的编码方式与 ISO 10646 的 通用字元集( 亦称 [ 通用字符集 ]) ( Universal Character Set , UCS )概念相对应,目前的用于实用的 Unicode 版本对应于 UCS-2 ,使用 16 位的编码空间。也就是每个字符占用 2 个 字节 。这样理论上一共最多可以表示 65,536(2 的 16 次方 ) 个字符。基本满足各种语言的使用。实际上目前版本的 Unicode 尚未填充满这 16 位编码,保留了大量空间作为特殊使用或将来扩展。
上述 16 位 Unicode 字符构成基本多文种平面( Basic Multilingual Plane, 简称 BMP )。最新(但未实际广泛使用)的 Unicode 版本定义了 16 个辅助平面,两者合起来至少需要占据 21 位的编码空间,比 3 字节略少。但事实上辅助平面字符仍然占用 4 字节编码空间,与 UCS-4 保持一致。未来版本会扩充到 ISO 10646-1 实现级别 3 ,即涵盖 UCS-4 的所有字符。 UCS-4 是一个更大的尚未填充完全的 31 位字符集,加上恒为 0 的首位,共需占据 32 位,即 4 字节。理论上最多能表示 2,147,483,648(2 的 31 次方 ) 个字符,完全可以涵盖一切语言所用的符号。
BMP 字符的 Unicode 编码表示为 U+hhhh ,其中每个 h 代表一个 十六进制 数位。与 UCS-2 编码完全相同。对应的 4 字节 UCS-4 编码后两个字节一致,前两个字节的所有位均为 0 。
2. 实现方式
Unicode 的实现方式不同于编码方式。一个字符的 Unicode 编码是确定的。但是在实际传输过程中,由于不同系统平台的设计不一定一致,以及出于节省空间的目的,对 Unicode 编码的实现方式有所不同。 Unicode 的实现方式称为 Unicode 转换格式( Unicode Translation Format ,简称为 UTF )。
例如,如果一个仅包含基本 7 位 ASCII 字符的 Unicode 文件,如果每个字符都使用 2 字节的原 Unicode 编码传输,其第一字节的 8 位始终为 0 。这就造成了比较大的浪费。对于这种情况,可以使用 UTF-8 编码,这是一种变长编码,它将基本 7 位 ASCII 字符仍用 7 位编码表示,占用一个字节(首位补 0 )。而遇到与其他 Unicode 字符混合的情况,将按一定算法转换,每个字符使用 1-3 个字节编码,并利用首位为 0 或 1 进行识别。这样对以 7 位 ASCII 字符为主的西文文档就大大节省了编码长度(具体方案参见 UTF-8 )。类似的,对未来会出现的需要 4 个字节的辅助平面字符和其他 UCS-4 扩充字符, 2 字节编码的 UTF-16 也需要通过一定的算法进行转换。
1. 编码方式
Unicode 的编码方式与 ISO 10646 的 通用字元集( 亦称 [ 通用字符集 ]) ( Universal Character Set , UCS )概念相对应,目前的用于实用的 Unicode 版本对应于 UCS-2 ,使用 16 位的编码空间。也就是每个字符占用 2 个 字节 。这样理论上一共最多可以表示 65,536(2 的 16 次方 ) 个字符。基本满足各种语言的使用。实际上目前版本的 Unicode 尚未填充满这 16 位编码,保留了大量空间作为特殊使用或将来扩展。
上述 16 位 Unicode 字符构成基本多文种平面( Basic Multilingual Plane, 简称 BMP )。最新(但未实际广泛使用)的 Unicode 版本定义了 16 个辅助平面,两者合起来至少需要占据 21 位的编码空间,比 3 字节略少。但事实上辅助平面字符仍然占用 4 字节编码空间,与 UCS-4 保持一致。未来版本会扩充到 ISO 10646-1 实现级别 3 ,即涵盖 UCS-4 的所有字符。 UCS-4 是一个更大的尚未填充完全的 31 位字符集,加上恒为 0 的首位,共需占据 32 位,即 4 字节。理论上最多能表示 2,147,483,648(2 的 31 次方 ) 个字符,完全可以涵盖一切语言所用的符号。
BMP 字符的 Unicode 编码表示为 U+hhhh ,其中每个 h 代表一个 十六进制 数位。与 UCS-2 编码完全相同。对应的 4 字节 UCS-4 编码后两个字节一致,前两个字节的所有位均为 0 。
2. 实现方式
Unicode 的实现方式不同于编码方式。一个字符的 Unicode 编码是确定的。但是在实际传输过程中,由于不同系统平台的设计不一定一致,以及出于节省空间的目的,对 Unicode 编码的实现方式有所不同。 Unicode 的实现方式称为 Unicode 转换格式( Unicode Translation Format ,简称为 UTF )。
例如,如果一个仅包含基本 7 位 ASCII 字符的 Unicode 文件,如果每个字符都使用 2 字节的原 Unicode 编码传输,其第一字节的 8 位始终为 0 。这就造成了比较大的浪费。对于这种情况,可以使用 UTF-8 编码,这是一种变长编码,它将基本 7 位 ASCII 字符仍用 7 位编码表示,占用一个字节(首位补 0 )。而遇到与其他 Unicode 字符混合的情况,将按一定算法转换,每个字符使用 1-3 个字节编码,并利用首位为 0 或 1 进行识别。这样对以 7 位 ASCII 字符为主的西文文档就大大节省了编码长度(具体方案参见 UTF-8 )。类似的,对未来会出现的需要 4 个字节的辅助平面字符和其他 UCS-4 扩充字符, 2 字节编码的 UTF-16 也需要通过一定的算法进行转换。
再如,如果直接使用与
Unicode
编码一致(仅限于
BMP
字符)的
UTF-16
编码,由于每个址都不相同,
Macintosh
机和
PC
机上对字节顺序的理解是不一致的。这时同一字节流可能会被解释为不同内容,如编码为
U+594E
的字符
“
奎
”
同编码为
U+4E59
的
“
乙
”
就可能发生混淆。于是在
UTF-16
编码实现方式中使用了大尾序(
big-endian
)、小尾序(
little-endian
)的概念,以及
BOM
(
Byte Order Mark
)解决方案。(具体方案参见
UTF-16
)
此外
Unicode
的实现方式还包括
UTF-7
、
Punycode
、
CESU-8
、
SCSU
、
UTF-32
等,这些实现方式有些仅在一定的国家和地区使用,有些则属于未来的规划方式。目前通用的实现方式是
UTF-16
小尾序(
BOM
)、
UTF-16
大尾序(
BOM
)和
UTF-8
。在微软公司
Windows XP
操作系统附带的记事本中,
“
另存为
”
对话框可以选择的四种编码方式除去非
Unicode
编码的
ANSI
外,其余三种
“Unicode”
、
“Unicode big endian”
和
“UTF-8”
即分别对应这三种实现方式。
目前辅助平面的工作主要集中在第二和第三平面的中日韩统一表意文字中,因此包括
GBK
、
GB18030
、
Big5
等简体中文、正体
中文
、
日文
、
韩语
以及
越南字喃
的各种编码与
Unicode
的协调性被重点关注。考虑到
Unicode
最终要涵盖所有的字符,从某种意义而言,这些编码方式也可视作
Unicode
的出现于其之前的既成事实的实现方式,如同
ASCII
及其扩展
Latin-1
一样,后两者的字符在
16
位
Unicode
编码空间中的编码第一字节各位全为
0
,第二字节编码与原编码完全一致。但上述东亚语言编码与
Unicode
编码的对应关系要复杂得多。
非
Unicode
环境
在非
Unicode
环境下,由于不同国家和地区采用的字符集不一致,很可能出现无法正常显示所有字符的情况。
微软
公司使用了代码页(
Codepage
)转换表的技术来过渡性的部分解决这一问题,即通过指定的转换表将非
Unicode
的字符编码转换为同一字符对应的系统内部使用的
Unicode
编码。可以在
“
语言与区域设置
”
中选择一个代码页作为非
Unicode
编码所采用的默认编码方式,如
936
为简体中文
GBK
,
950
为正体中文
Big5
(皆指
PC
上使用的)。在这种情况下,一些非英语的欧洲语言编写的软件和文档很可能出现乱码。而将代码页设置为相应语言中文处理又会出现问题,这一情况无法避免。从根本上说,完全采用统一编码才是解决之道,但目前上无法做到这一点。
代码页技术现在广泛为各种平台所采用。 UTF-7 的代码页是 65000 , UTF-8 的代码页是 65001 。
代码页技术现在广泛为各种平台所采用。 UTF-7 的代码页是 65000 , UTF-8 的代码页是 65001 。
显示特定的字符。
nnn
代表该字符的十进制
Unicode
代码。如果采用十六进制代码,在编码
之前加上
x
字符即可。但部分旧版本的浏览器可能无法识别十六进制代码。
然而部分由于 Unicode 版本发展原因,很多浏览器只能显示 UCS-2 完整字符集也即现在使
然而部分由于 Unicode 版本发展原因,很多浏览器只能显示 UCS-2 完整字符集也即现在使
用的
Unicode
版本中的一个小子集。下表可以检验您的浏览器怎样显示各种各样的
Unicode
代
码:
代码 字符标准名称 ( 英语 ) 在浏览器上的显示
A 大写拉丁字母 "A" A
ß 小写 拉丁字母"Sharp S" ß
þ 小写 拉丁字母"Thorn" þ
Δ 大写 希腊 字母 "Delta" Δ
Й 大写 斯拉夫 字母 "Short I" Й
ק 希伯来 字母 "Qof" ק
م 阿拉伯 字母 "Meem" م
๗ 泰文数字 7 ๗
ቐ 埃塞俄比亚 音节文字 "Qha" ቐ
あ 日语平假名 "A" あ
ア 日语 片假名 "A" ア
叶 简体 汉字 " 叶 " 叶
叶 繁体 汉字 " 叶 " 叶
엽 韩国 音节文字 " Yeob" 엽
代码 字符标准名称 ( 英语 ) 在浏览器上的显示
A 大写拉丁字母 "A" A
ß 小写 拉丁字母"Sharp S" ß
þ 小写 拉丁字母"Thorn" þ
Δ 大写 希腊 字母 "Delta" Δ
Й 大写 斯拉夫 字母 "Short I" Й
ק 希伯来 字母 "Qof" ק
م 阿拉伯 字母 "Meem" م
๗ 泰文数字 7 ๗
ቐ 埃塞俄比亚 音节文字 "Qha" ቐ
あ 日语平假名 "A" あ
ア 日语 片假名 "A" ア
叶 简体 汉字 " 叶 " 叶
叶 繁体 汉字 " 叶 " 叶
엽 韩国 音节文字 " Yeob" 엽
输入
Unicode
除了
输入法
外,
操作系统
会提供几种方法输入
Unicode
。像是
Windows 2000
之后的
Windows
系统就提供一个可点击的表。例如在
Microsoft Word
之下,按下
Alt
键不放,输入
0
和某个字符的
Unicode
编码(
十进制
),再松开
Alt
键即可得到该字符,如
Alt + 033865
会得到
Unicode
字符叶。另外按
Alt + X
组合键,
MS Word
也会将光标前面的字符同其十六进制的四位
Unicode
编码进行互相转换。
Unicode 编码表
0000-0FFF 8000-8FFF 10000-10FFF 20000-20FFF 28000-28FFF
1000-1FFF 9000-9FFF 21000-21FFF 29000-29FFF
2000-2FFF A000-AFFF 22000-22FFF 2A000-2AFFF
3000-3FFF B000-BFFF 23000-23FFF
4000-4FFF C000-CFFF 1D000-1DFFF 24000-24FFF 2F000-2FFFF
5000-5FFF D000-DFFF 25000-25FFF
6000-6FFF E000-EFFF 26000-26FFF
7000-7FFF F000-FFFF 27000-27FFF E0000-E0FFF
Unicode 目前已经有 5.0 版本。世界上有一大批计算机、语言学等科学家专门研究 Unicode ,到了现在 Unicode 标准已经不单是一个编码标准,还是记录人类语言文字资料的一个巨大的数据库,同时从事人类文化遗产的发掘和保护工作。
对于中文而言, Unicode 16 编码里面已经包含了 GB18030 里面的所有汉字( 27484 个字),目前 Unicode 标准准备把 康熙字典 的所有汉字放入到 Unicode 32bit 编码中。
简单地说, Unicode 扩展自 ASCII 字元集。在严格的 ASCII 中,每个字元用 7 位元表示,或者电脑上普遍使用的每字元有 8 位元宽;而 Unicode 使用全 16 位元字元集。这使得 Unicode 能够表示世界上所有的书写语言中可能用於电脑通讯的字元、象形文字和其他符号。 Unicode 最初打算作为 ASCII 的补充,可能的话,最终将代替它。考虑到 ASCII 是电脑中最具支配地位的标准,所以这的确是一个很高的目标。
Unicode 影响到了电脑工业的每个部分,但也许会对作业系统和程式设计语言的影响最大。从这方面来看,我们已经上路了。 Windows NT 从底层支援 Unicode (不幸的是, Windows 98 只是小部分支援 Unicode )。先天即被 ANSI 束缚的 C 程式设计语言通过对宽字元集的支援来支援 Unicode 。
Unicode 编码表
0000-0FFF 8000-8FFF 10000-10FFF 20000-20FFF 28000-28FFF
1000-1FFF 9000-9FFF 21000-21FFF 29000-29FFF
2000-2FFF A000-AFFF 22000-22FFF 2A000-2AFFF
3000-3FFF B000-BFFF 23000-23FFF
4000-4FFF C000-CFFF 1D000-1DFFF 24000-24FFF 2F000-2FFFF
5000-5FFF D000-DFFF 25000-25FFF
6000-6FFF E000-EFFF 26000-26FFF
7000-7FFF F000-FFFF 27000-27FFF E0000-E0FFF
Unicode 目前已经有 5.0 版本。世界上有一大批计算机、语言学等科学家专门研究 Unicode ,到了现在 Unicode 标准已经不单是一个编码标准,还是记录人类语言文字资料的一个巨大的数据库,同时从事人类文化遗产的发掘和保护工作。
对于中文而言, Unicode 16 编码里面已经包含了 GB18030 里面的所有汉字( 27484 个字),目前 Unicode 标准准备把 康熙字典 的所有汉字放入到 Unicode 32bit 编码中。
简单地说, Unicode 扩展自 ASCII 字元集。在严格的 ASCII 中,每个字元用 7 位元表示,或者电脑上普遍使用的每字元有 8 位元宽;而 Unicode 使用全 16 位元字元集。这使得 Unicode 能够表示世界上所有的书写语言中可能用於电脑通讯的字元、象形文字和其他符号。 Unicode 最初打算作为 ASCII 的补充,可能的话,最终将代替它。考虑到 ASCII 是电脑中最具支配地位的标准,所以这的确是一个很高的目标。
Unicode 影响到了电脑工业的每个部分,但也许会对作业系统和程式设计语言的影响最大。从这方面来看,我们已经上路了。 Windows NT 从底层支援 Unicode (不幸的是, Windows 98 只是小部分支援 Unicode )。先天即被 ANSI 束缚的 C 程式设计语言通过对宽字元集的支援来支援 Unicode 。
自然,作为程式写作者,我们通常会面对许多繁重的工作。我已试图透过使本书中的所有程式「
Unicode
化」来减轻负担。其含义会随著本章对
Unicode
的讨论而清晰起来。