索阅 100例 首 页| 资 讯| 下 载| 论 坛| 博 客| Webinar| 高 校| 专 刊| 会展| EETV| 百科| 问答| 电路图| 工程师手册| Datasheet

EEPW首页 > 百科 > UniCode

UniCode


贡献者:xqh0813    浏览:3483次    创建时间:2009-08-30

在计算机科学领域中,Unicode(统一码、万国码、单一码、标准万国码)是业界的一种标准,它可以使电脑得以呈现世界上数十种文字的系统。Unicode 是基于通用字符集(Universal Character Set)的标准来发展,并且同时也以书本的形式(The Unicode Standard,目前第五版由Addison-Wesley Professional出版,ISBN-10: 0321480910)对外发表。Unicode 包含了超过十万个字符(在西元 2005 年, Unicode 的第十万个字符被采纳且认可成为标准之一)、一组可用以作为视觉参考的代码图表、一套编码方法与一组标准字符编码、一套包含了上标字、下标字等字符特性的列举等。Unicode 在字符集认可的成功,使其得以在电脑软件的国际化与本地化领域中,广泛且具优势的被采用。这标准已在近年来的多种新科技当中被加以采用,包含了可扩展置标语言(XML)、Java编程语言、以及最新的操作系统中。
目录 [隐藏]
1 历史
2 编码和实现
3 编码方式
4 非 Unicode 环境
5 XML与Unicode
6 输入
7 汉字问题
8 编码表
9 相关条目
10 参考资料
UniCode-历史

UNICODE
Unicode 是由于传统的字符编码方式的局限性而产生的,例如 ISO 8859 所定义的字符虽然在不同的国家中广泛地使用,可是在不同国家间却经常出现不相容的情况。很多传统的编码方式都具有一个共通的问题,即其容许电脑进行双语环境式的处理(通常使用拉丁字母以及其本地语言),但却无法同时支援多语言环境式的处理(指可同时处理混合多种语言的情况)。
Unicode 试图将字位(字素,graphemes)与类字位字符加以认定与编码,而非以不同的字形(glyphs)来加以区分。然而在汉字的个案来看,这样方式有时会引起一字多形的认定争议(详见中日韩统一表意文字主题)。
在文字处理方面, Unicode 的功用是为每一个字符提供一个唯一的代码(即一组数字),而不是一种字形。换句话说, Unicode 是将字符以一种抽象的方式来呈现,而将视觉上的演绎工作(例如字体大小、外观形状、字体形态、文体等)留给其他软件来处理,例如网页浏览器或是文字处理器。
为了使 Unicode 与已存在和广泛使用的旧有编码互相兼容,尤其是差不多所有电脑系统都支援的基本拉丁字母部分,所以 Unicode 的首 256 字符仍旧保留给 ISO 8859-1 所定义的字符,使既有的西欧语系文字的转换不需特别考量;另方面因相同的原因,Unicode 把大量相同的字符重复编到不同的字符码中去,使得旧有纷杂的编码方式得以和 Unicode 编码间互相直接转换,而不会遗失任何资讯。举例来说,全角格式区段包含了主要的拉丁字母的全角格式,在中文、日文、以及韩文字形当中,这些字符以全角的方式来呈现,而不以常见的半角形式显示,这对竖排文字和等宽排列文字有重要作用。
在表达一个 Unicode 的字符时,通常会用“U ”然后紧接着一组十六进制的数字来表示这一个字符。在基本多文种平面(Basic Multilingual Plane,简称 BMP)里的所有字符,只要使用四位十六进制数(例如 U 4AE0,共支持六万多个字符)来表示,但在 BMP 以外的字符则需要使用五位或六位十六进制数了。旧版的 Unicode 标准使用相近的标记方法,但却有些微的差异,例如在 Unicode 3.0 里使用“U-”然后紧接着八位数,而“U ”则必须随后紧接着四位数,以表示仅限于代表一个字符单位(code unit),而非字符(code point)。
标准:位于美国加州的 Unicode 组织允许任何愿意支付会员费用的公司或是个人加入,其成员包含了主要的电脑软硬件厂商,例如奥多比系统(Adobe Systems)、苹果公司(Apple)、惠普(HP)、IBM、微软(Microsoft)、全录(Xerox)等。
Unicode 组织在 1991 年首次发布了 The Unicode Standard(ISBN 0-321-18578-1)。 Unicode 的开发结合了国际标准化组织(International Organization for Standardization,简称 ISO )所制定的ISO/IEC 10646,即通用字符集(Universal Character Set,简称 UCS )。Unicode 与 ISO/IEC 10646 在编码的运作原理相同,但 The Unicode Standard 包含了更详尽的实现资讯、涵盖了更细节的主题,诸如字符编码(bitwise encoding)、校对以及呈现等。 The Unicode Standard 也列举了诸多的字符特性,包含了那些必须支援双方向呈现的文字(由左至右或由右至左的文字呈现方向,例如阿拉伯文是由右至左)。 Unicode 与 ISO/IEC 10646 两个标准在术语上的使用有些微的不同。
在西元 2005 年, Unicode 的第十万个字符被输入成为标准之一,其为马来亚拉姆语(Malayalam,印度西南部沿海居民的语言)的 Praslesham(?????????)。
Unicode 截至目前为止历次的版次与发布时间如下:
Unicode 1.0:1991年十月
Unicode 1.0.1:1992年六月
Unicode 1.1:1993年六月
Unicode 2.0:1997年七月
Unicode 2.1:1998年五月
Unicode 2.1.2:1998年五月
Unicode 3.0:1999年九月;涵盖了来自ISO 10646-1的十六位元通用字符集(UCS)基本多文种平面(Bsic Multilingual Plane)
Unicode 3.1:2001年三月;新增从ISO 10646-2定义的辅助平面(Supplementary Planes)
Unicode 3.2:2002年三月
Unicode 4.0:2003年四月
Unicode 4.0.1:2004年三月
Unicode 4.1:2005年三月
Unicode 5.0:2006年七月
Unicode 5.1:2008年四月。
UniCode-编码和实现

UNICODE
大概来说,Unicode 编码系统可分为编码方式和实现方式两个层次。
编码方式:Unicode 的编码方式与 ISO 10646 的通用字符集(Universal Character Set,UCS)概念相对应,目前实际应用的 Unicode 版本对应于 UCS-2,使用16位的编码空间。也就是每个字符占用2个字节。这样理论上一共最多可以表示 216 即 65536 个字符。基本满足各种语言的使用。实际上目前版本的 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字节。理论上最多能表示 231 个字符,完全可以涵盖一切语言所用的符号。
BMP 字符的 Unicode 编码表示为 U hhhh,其中每个 h 代表一个十六进制数位。与 UCS-2 编码完全相同。对应的4字节 UCS-4 编码后两个字节一致,前两个字节的所有位均为0。
关于 Unicode 和 ISO 10646 及 UCS 的详细关系 ,请参看通用字符集。
实现方式:Unicode 的实现方式不同于编码方式。一个字符的 Unicode 编码是确定的。但是在实际传输过程中,由于不同系统平台的设计不一定一致,以及出于节省空间的目的,对 Unicode 编码的实现方式有所不同。Unicode 的实现方式称为Unicode转换格式(Unicode Translation Format,简称为 UTF)。

UNICODE
例如,如果一个仅包含基本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 的编码方式与 ISO 10646的通用字符集(Universal Character Set,UCS)概念相对应,目前实际应用的 Unicode 版本对应于 UCS-2,使用16位的编码空间。也就是每个字符占用2个字节。这样理论上一共最多可以表示 216 即 65536 个字符。基本满足各种语言的使用。实际上目前版本的 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字节。理论上最多能表示 231 个字符,完全可以涵盖一切语言所用的符号。
BMP 字符的 Unicode 编码表示为 U+hhhh,其中每个 h 代表一个十六进制数位。与 UCS-2 编码完全相同。对应的4字节 UCS-4 编码后两个字节一致,前两个字节的所有位均为0。
UniCode-非 Unicode 环境
在非 Unicode 环境下,由于不同国家和地区采用的字符集不一致,很可能出现无法正常显示所有字符的情况。微软公司使用了代码页(Codepage)转换表的技术来过渡性的部分解决这一问题,即通过指定的转换表将非 Unicode 的字符编码转换为同一字符对应的系统内部使用的 Unicode 编码。可以在“语言与区域设置”中选择一个代码页作为非 Unicode 编码所采用的默认编码方式,如936为简体中文GBK,950为正体中文Big5(皆指PC上使用的)。在这种情况下,一些非英语的欧洲语言编写的软件和文档很可能出现乱码。而将代码页设置为相应语言中文处理又会出现问题,这一情况无法避免。从根本上说,完全采用统一编码才是解决之道,但目前尚无法做到这一点。
代码页技术现在广泛为各种平台所采用。UTF-7 的代码页是65000,UTF-8 的代码页是65001。
UniCode-XML与Unicode

XML
XML及其子集HTML采用UTF-8作为标准字集,理论上我们可以在各种支持XML标准的浏览器上显示任何地区文字的网页,只要电脑本身安装有合适的字体即可。可以利用&#nnn;的格式显示特定的字符。nnn代表该字符的十进制 Unicode 代码。如果采用十六进制代码,在编码之前加上x字符即可。但部分旧版本的浏览器可能无法识别十六进制代码。
过去电脑编码的8位标准,使每个国家都只按国家使用的字符而编定各自的编码系统;而对于部份字符系统比较复杂的语言,如越南语,又或者东亚国家的大型字符集,都不能在8位的环境下好好显示。连自己的语言也未必可以好好显示的话,就更惶论显示其他国家的文字了。然而,现在于HTML和XML,我们可以利用&#nnn;的格式显示特定的字符。nnn代表该字符的十进位Unicode代码。如果想采用十六进位代码的话,要在编码之前加上x字符。
只是最近才有在文本中对十六进制的支持,那么旧版本的浏览器显示那些字符或许可能有问题-大概首先会遇到的一个问题只是在对于大于8位Unicode字符的显示。解决这个问题的普遍做法仍然是将其中的十六进制码转换成一个十进制码(例如:用?代替?)。
也有一些字符集标准将一些常用的标志存放在字符内码外面,那么你可能使用象—这样的文本标志来表示一个长划(—)的情况,即使它的字符内码已经被使用,这些标准也不包含那个字符。
然而部分由于Unicode版本发展原因,很多浏览器只能显示UCS-2完整字符集,也即现在使用的Unicode版本中的一个小子集。下表可以检验您的浏览器怎样显示各种各样的Unicode代码:



如果您认为本词条还有待完善,需要补充新内容或修改错误内容,请编辑词条     查看历史版本

开放分类

参考资料

贡献者
xqh0813    


本词条在以下词条中被提及:

关于本词条的评论共:(0条)
匿名不能发帖!请先 [ 登陆 ]