华宇拼音输入法论坛

标题: Unicode编码体系及运用 [打印本页]
作者: kingdick    时间: 2007-11-16 13:14
标题: Unicode编码体系及运用
希望紫光能早日支持Unicode！！



　　为争取更多网友关注Unicode，促使紫光华宇公司早日完成支持Unicode的紫光拼音输入法，特借这个帖子发些本人收集的关于Unicode的专业文章。sanwsw。

　　建议：为解决输入和显示GBK字符集之外的汉字，请安装支持Unicode统一码的超大字库和支持Unicode输入法。前者是输入、显示Unicode CJK统一汉字、CJK统一汉字 Ext-A、CJK统一汉字 Ext-B、CJK统一汉字 Ext-C汉字的必需软件，后者有多项选择（海峰五笔、极点五笔、菩提五笔等）。

　　UniFonts54.exe下载

12.png (14.1 KB, 下载次数: 409)

12.png
作者: 關長生    时间: 2007-11-16 13:20
這是大家共同的願望。
據說下一個版本就可以了。

[ 本帖最后由 關長生 于 2008-2-24 23:29 编辑 ]
作者: hzysoft    时间: 2007-11-16 17:18
這個建議我倒是讚同！
作者: ffffccc    时间: 2007-11-16 23:16
弱弱的问一句：支持unicode有什么好处？
作者: givenchan    时间: 2007-11-16 23:19
可以装在任何语言版本的系统里面了
特别是繁体的

我也是知道这一点
作者: kingdick    时间: 2007-11-17 12:41
还有很多特殊符号都是Unicode下的，紫光的自定义短语就无法定义这些符号。
作者: sanwsw    时间: 2007-11-19 13:52
　　这应该是所有汉字输入法的今后努力方向。

中日韩越通用汉字总数（75748个）

字符编码

区位

码位数

实际字数

CJK基本
[4E00-9FFF]
20992

20924

CJK Ext-A
[3400-4DBF]
6592

6582

CJK Ext-B
[20000-2A6DF]
42720

42711

CJK Ext-C
[2A700-2BA7F]
4259

4149

CJK兼容扩展
[2F800-2FA1F]
544

542

CJK部首扩展
[2E80-2EFF]
128

116

CJK康熙部首
[2F00-2FDF]
224

214

CJK笔画
[31C0-31EF]
48

36

CJK兼容
[F900-FAFF]
512

474

合计


76019

75748



作者: sanwsw    时间: 2007-11-20 00:01
标题: 谈谈Unicode编码（转帖）
谈谈Unicode编码
——简释UCS、UTF、BMP、BOM等名词
fmddlmyy
这是一篇程序员写给程序员的趣味读物。所谓趣味是指可以比较轻松地了解一些原来不清楚的概念，增进知识，类似于打RPG游戏的升级。整理这篇文章的动机是两个问题：
问题一：
使用Windows记事本的“另存为”，可以在GBK、Unicode、Unicode big endian和UTF-8这几种编码方式间相互转换。同样是txt文件，Windows是怎样识别编码方式的呢？
我很早前就发现Unicode、Unicode big endian和UTF-8编码的txt文件的开头会多出几个字节，分别是FF、FE（Unicode）,FE、FF（Unicode big endian）,EF、BB、BF（UTF-8）。但这些标记是基于什么标准呢？
问题二：
最近在网上看到一个ConvertUTF.c，实现了UTF-32、UTF-16和UTF-8这三种编码方式的相互转换。对于Unicode(UCS2)、GBK、UTF-8这些编码方式，我原来就了解。但这个程序让我有些糊涂，想不起来UTF-16和UCS2有什么关系。
查了查相关资料，总算将这些问题弄清楚了，顺带也了解了一些Unicode的细节。写成一篇文章，送给有过类似疑问的朋友。本文在写作时尽量做到通俗易懂，但要求读者知道什么是字节，什么是十六进制。
0、big endian和little endian
big endian和little endian是CPU处理多字节数的不同方式。例如“汉”字的Unicode编码是6C49。那么写到文件里时，究竟是将6C写在前面，还是将49写在前面？如果将6C写在前面，就是big endian。如果将49写在前面，就是little endian。
“endian”这个词出自《格列佛游记》。小人国的内战就源于吃鸡蛋时是究竟从大头(Big-Endian)敲开还是从小头(Little-Endian)敲开，由此曾发生过六次叛乱，一个皇帝送了命，另一个丢了王位。
我们一般将endian翻译成“字节序”，将big endian和little endian称作“大尾”和“小尾”。
1.字符编码、内码，顺带介绍汉字编码
字符必须编码后才能被计算机处理。计算机使用的缺省编码方式就是计算机的内码。早期的计算机使用7位的ASCII编码，为了处理汉字，程序员设计了用于简体中文的GB2312和用于繁体中文的big5。
GB2312(1980年)一共收录了7445个字符，包括6763个汉字和682个其它符号。汉字区的内码范围高字节从B0-F7，低字节从A1-FE，占用的码位是72*94=6768。其中有5个空位是D7FA-D7FE。
GB2312支持的汉字太少。1995年的汉字扩展规范GBK1.0收录了21886个符号，它分为汉字区和图形符号区。汉字区包括21003个字符。
从ASCII、GB2312到GBK，这些编码方法是向下兼容的，即同一个字符在这些方案中总是有相同的编码，后面的标准支持更多的字符。在这些编码中，英文和中文可以统一地处理。区分中文编码的方法是高字节的最高位不为0。按照程序员的称呼，GB2312、GBK都属于双字节字符集 (DBCS)。
2000年的GB18030是取代GBK1.0的正式国家标准。该标准收录了27484个汉字，同时还收录了藏文、蒙文、维吾尔文等主要的少数民族文字。从汉字字汇上说，GB18030在GB13000.1的20902个汉字的基础上增加了CJK扩展A的6582个汉字（Unicode码0x3400-0x4db5），一共收录了27484个汉字。
CJK就是中日韩的意思。Unicode为了节省码位，将中日韩三国语言中的文字统一编码。GB13000.1就是ISO/IEC 10646-1的中文版，相当于Unicode 1.1。
GB18030的编码采用单字节、双字节和4字节方案。其中单字节、双字节和GBK是完全兼容的。4字节编码的码位就是收录了CJK扩展A的6582个汉字。 例如：UCS的0x3400在GB18030中的编码应该是8139EF30，UCS的0x3401在GB18030中的编码应该是8139EF31。
微软提供了GB18030的升级包，但这个升级包只是提供了一套支持CJK扩展A的6582个汉字的新字体：新宋体-18030，并不改变内码。Windows 的内码仍然是GBK。
这里还有一些细节：
·
GB2312的原文还是区位码，从区位码到内码，需要在高字节和低字节上分别加上A0。
·
对于任何字符编码，编码单元的顺序是由编码方案指定的，与endian无关。例如GBK的编码单元是字节，用两个字节表示一个汉字。 这两个字节的顺序是固定的，不受CPU字节序的影响。UTF-16的编码单元是word（双字节），word之间的顺序是编码方案指定的，word内部的字节排列才会受到endian的影响。后面还会介绍UTF-16。
·
GB2312的两个字节的最高位都是1。但符合这个条件的码位只有128*128=16384个。所以GBK和GB18030的低字节最高位都可能不是1。不过这不影响DBCS字符流的解析：在读取DBCS字符流时，只要遇到高位为1的字节，就可以将下两个字节作为一个双字节编码，而不用管低字节的高位是什么。
2.Unicode、UCS和UTF
前面提到从ASCII、GB2312、GBK到GB18030的编码方法是向下兼容的。而Unicode只与ASCII兼容（更准确地说，是与ISO-8859-1兼容），与GB码不兼容。例如“汉”字的Unicode编码是6C49，而GB码是BABA。
Unicode也是一种字符编码方法，不过它是由国际组织设计，可以容纳全世界所有语言文字的编码方案。Unicode的学名是"Universal Multiple-Octet Coded Character Set"，简称为UCS。UCS可以看作是"Unicode Character Set"的缩写。
根据维基百科全书(http://zh.wikipedia.org/wiki/)的记载：历史上存在两个试图独立设计Unicode的组织，即国际标准化组织（ISO）和一个软件制造商的协会（unicode.org）。ISO开发了ISO 10646项目，Unicode协会开发了Unicode项目。
在1991年前后，双方都认识到世界不需要两个不兼容的字符集。于是它们开始合并双方的工作成果，并为创立一个单一编码表而协同工作。从Unicode2.0开始，Unicode项目采用了与ISO 10646-1相同的字库和字码。
目前两个项目仍都存在，并独立地公布各自的标准。Unicode协会现在的最新版本是2005年的Unicode 4.1.0。ISO的最新标准是ISO 10646-3:2003。
UCS只是规定如何编码，并没有规定如何传输、保存这个编码。例如“汉”字的UCS编码是6C49，我可以用4个ascii数字来传输、保存这个编码；也可以用utf-8编码:3个连续的字节E6 B1 89来表示它。关键在于通信双方都要认可。UTF-8、UTF-7、UTF-16都是被广泛接受的方案。UTF-8的一个特别的好处是它与ISO-8859-1完全兼容。UTF是“UCS Transformation Format”的缩写。
IETF的RFC2781和RFC3629以RFC的一贯风格，清晰、明快又不失严谨地描述了UTF-16和UTF-8的编码方法。我总是记不得IETF是Internet Engineering Task Force的缩写。但IETF负责维护的RFC是Internet上一切规范的基础。
2.1.内码和code page
目前Windows的内核已经支持Unicode字符集，这样在内核上可以支持全世界所有的语言文字。但是由于现有的大量程序和文档都采用了某种特定语言的编码，例如GBK，Windows不可能不支持现有的编码，而全部改用Unicode。
Windows使用代码页(code page)来适应各个国家和地区。code page可以被理解为前面提到的内码。GBK对应的code page是CP936。微软也为GB18030定义了code page：CP54936。
3.UCS-2、UCS-4、BMP
UCS有两种格式：UCS-2和UCS-4。顾名思义，UCS-2就是用两个字节编码，UCS-4就是用4个字节（实际上只用了31位，最高位必须为0）编码。下面让我们做一些简单的数学游戏：
UCS-2有2^16=65536个码位，UCS-4有2^31=2147483648个码位。
UCS-4根据最高位为0的最高字节分成2^7=128个group。每个group再根据次高字节分为256个plane。每个plane根据第3个字节分为256行 (rows)，每行包含256个cells。当然同一行的cells只是最后一个字节不同，其余都相同。
group 0的plane 0被称作Basic Multilingual Plane, 即BMP。或者说UCS-4中，高两个字节为0的码位被称作BMP。
将UCS-4的BMP去掉前面的两个零字节就得到了UCS-2。在UCS-2的两个字节前加上两个零字节，就得到了UCS-4的BMP。而目前的UCS-4规范中还没有任何字符被分配在BMP之外。
4.UTF编码
UTF-8就是以8位为单元对UCS进行编码。从UCS-2到UTF-8的编码方式如下：
UCS-2编码(16进制)
UTF-8 字节流(二进制)
0000 - 007F
0xxxxxxx
0080 - 07FF
110xxxxx 10xxxxxx
0800 - FFFF
1110xxxx 10xxxxxx 10xxxxxx
例如“汉”字的Unicode编码是6C49。6C49在0800-FFFF之间，所以肯定要用3字节模板了：1110xxxx 10xxxxxx 10xxxxxx。将6C49写成二进制是：0110 110001 001001， 用这个比特流依次代替模板中的x，得到：11100110 10110001 10001001，即E6 B1 89。
读者可以用记事本测试一下我们的编码是否正确。需要注意，UltraEdit在打开utf-8编码的文本文件时会自动转换为UTF-16，可能产生混淆。你可以在设置中关掉这个选项。更好的工具是Hex Workshop。
UTF-16以16位为单元对UCS进行编码。对于小于0x10000的UCS码，UTF-16编码就等于UCS码对应的16位无符号整数。对于不小于0x10000的UCS码，定义了一个算法。不过由于实际使用的UCS2，或者UCS4的BMP必然小于0x10000，所以就目前而言，可以认为UTF-16和UCS-2基本相同。但UCS-2只是一个编码方案，UTF-16却要用于实际的传输，所以就不得不考虑字节序的问题。
5.UTF的字节序和BOM
UTF-8以字节为编码单元，没有字节序的问题。UTF-16以两个字节为编码单元，在解释一个UTF-16文本前，首先要弄清楚每个编码单元的字节序。例如“奎”的Unicode编码是594E，“乙”的Unicode编码是4E59。如果我们收到UTF-16字节流“594E”，那么这是“奎”还是“乙”？
Unicode规范中推荐的标记字节顺序的方法是BOM。BOM不是“Bill Of Material”的BOM表，而是Byte Order Mark。BOM是一个有点小聪明的想法：
在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。
UTF-8不需要BOM来表明字节顺序，但可以用BOM来表明编码方式。字符"ZERO WIDTH NO-BREAK SPACE"的UTF-8编码是EF BB BF（读者可以用我们前面介绍的编码方法验证一下）。所以如果接收者收到以EF BB BF开头的字节流，就知道这是UTF-8编码了。
Windows就是使用BOM来标记文本文件的编码方式的。
6.进一步的参考资料
本文主要参考的资料是 "Short overview of ISO-IEC 10646 and Unicode" (http://www.nada.kth.se/i18n/ucs/unicode-iso10646-oview.html)。
我还找了两篇看上去不错的资料，不过因为我开始的疑问都找到了答案，所以就没有看：
1.
"Understanding Unicode A general introduction to the Unicode Standard" (http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&item_id=IWS-Chapter04a)
2.
"Character set encoding basics Understanding character set encodings and legacy encodings" (http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&item_id=IWS-Chapter03)
我写过UTF-8、UCS-2、GBK相互转换的软件包，包括使用Windows API和不使用Windows API的版本。以后有时间的话，我会整理一下放到我的个人主页上(http://www.fmddlmyy.cn)。
我是想清楚所有问题后才开始写这篇文章的，原以为一会儿就能写好。没想到考虑措辞和查证细节花费了很长时间，竟然从下午1:30写到9:00。希望有读者能从中受益。
附录1 再说说区位码、GB2312、内码和代码页
有的朋友对文章中这句话还有疑问：
“GB2312的原文还是区位码，从区位码到内码，需要在高字节和低字节上分别加上A0。”
我再详细解释一下：
“GB2312的原文”是指国家1980年的一个标准《中华人民共和国国家标准 信息交换用汉字编码字符集 基本集 GB 2312-80》。这个标准用两个数来编码汉字和中文符号。第一个数称为“区”，第二个数称为“位”。所以也称为区位码。1-9区是中文符号，16-55区是一级汉字，56-87区是二级汉字。现在Windows也还有区位输入法，例如输入1601得到“啊”。（这个区位输入法可以自动识别16进制的GB2312和10进制的区位码，也就是说输入B0A1同样会得到“啊”。）
内码是指操作系统内部的字符编码。早期操作系统的内码是与语言相关的。现在的Windows在系统内部支持Unicode，然后用代码页适应各种语言，“内码”的概念就比较模糊了。微软一般将缺省代码页指定的编码说成是内码。
内码这个词汇，并没有什么官方的定义，代码页也只是微软这个公司的叫法。作为程序员，我们只要知道它们是什么东西，没有必要过多地考证这些名词。
Windows中有缺省代码页的概念，即缺省用什么编码来解释字符。例如Windows的记事本打开了一个文本文件，里面的内容是字节流：BA、BA、D7、D6。Windows应该去怎么解释它呢？
是按照Unicode编码解释、还是按照GBK解释、还是按照BIG5解释，还是按照ISO8859-1去解释？如果按GBK去解释，就会得到“汉字”两个字。按照其它编码解释，可能找不到对应的字符，也可能找到错误的字符。所谓“错误”是指与文本作者的本意不符，这时就产生了乱码。
答案是Windows按照当前的缺省代码页去解释文本文件里的字节流。缺省代码页可以通过控制面板的区域选项设置。记事本的另存为中有一项ANSI，其实就是按照缺省代码页的编码方法保存。
Windows的内码是Unicode，它在技术上可以同时支持多个代码页。只要文件能说明自己使用什么编码，用户又安装了对应的代码页，Windows就能正确显示，例如在HTML文件中就可以指定charset。
有的HTML文件作者，特别是英文作者，认为世界上所有人都使用英文，在文件中不指定charset。如果他使用了0x80-0xff之间的字符，中文Windows又按照缺省的GBK去解释，就会出现乱码。这时只要在这个html文件中加上指定charset的语句，例如：
<meta http-equiv="Content-Type" c>
如果原作者使用的代码页和ISO8859-1兼容，就不会出现乱码了。
再说区位码，啊的区位码是1601，写成16进制是0x10,0x01。这和计算机广泛使用的ASCII编码冲突。为了兼容00-7f的ASCII编码，我们在区位码的高、低字节上分别加上A0。这样“啊”的编码就成为B0A1。我们将加过两个A0的编码也称为GB2312编码，虽然GB2312的原文根本没提到这一点。
作者: sanwsw    时间: 2007-11-20 00:11
浅谈文字编码和Unicode（节选）

fmddlmyy

　　我曾经写过一篇《谈谈Unicode编码，简要解释UCS、UTF、BMP、BOM等名词》（以下简称《谈谈Unicode编码》），在网上流传较广，我也收到不少朋友的反馈。本文探讨《谈谈Unicode编码》中未介绍或介绍较少的代码页、Surrogates等问题，补充一些Unicode资料，顺带介绍一下我最近编写的一个Unicode工具：UniToy。本文虽然是前文的补充，但在写作上尽量做到独立成篇。
　　标题中的“浅谈”是对自己的要求，我希望文字能尽量浅显易懂。但本文还是假设读者知道字节、16进制，了解《谈谈Unicode编码》中介绍过的字节序和Unicode的基本概念。
　　0 UniToy
　　UniToy是我编写的一个小工具。通过UniToy，我们可以全方位、多角度地查看Unicode，了解Unicode和语言、代码页的关系，完成一些文字编码的相关工作。本文的一些内容是通过UniToy演示的。大家可以从我的网站（www.fmddlmyy.cn）下载UniToy的演示版本。
　　1 文字的显示
　　1.1 发生了什么？
　　我们首先以Windows为例来看看文字显示过程中发生了什么。用记事本打开一个文本文件，可以看到文件包含的文字：

　　如果我们用UltraEdit或Hex Workshop查看这个文件的16进制数据，可以看到：

　　我们看到：文件“例子GBK.txt”有10个字节，依次是“D7 D6 B7 FB BA CD B1 E0 C2 EB”，这就是记事本从文件中读到的内容。记事本是用来打开文本文件的，所以它会调用Windows的文本显示函数将读到的数据作为文本显示。Windows首先将文本数据转换到它内部使用的编码格式：Unicode，然后按照文本的Unicode去字体文件中查找字体图像，最后将图像显示到窗口上。总结一下前面的分析，文字的显示应该是这样的：
·
　　步骤1：文字首先以某种编码保存在文件中。
·
　　步骤2：Windows将文件中的文字编码映射到Unicode。
·
　　步骤3：Windows按照Unicode在字体文件中查找字体图像，画到窗口上。
所谓编码就是用数字表示字符，例如用D7D6表示“字”。当然，编码还意味着约定，即大家都认可。从《谈谈Unicode编码》中，我们知道Unicode也是一种文字编码，它的特殊性在于它是由国际组织设计，可以容纳全世界所有语言文字。而我们平常使用的文字编码通常是针对一个区域的语言、文字设计，只支持特定的语言文字。例如：在上面的例子中，文件“例子GBK.txt”采用的就是GBK编码。

　　如果上述3个步骤中任何一步发生了错误，文字就不能被正确显示，例如：
·
　　错误1：如果弄错了编码，例如将Big5编码的文字当作GBK编码，就会出现乱码。


　　…………
　　…………

　　这是一篇关于Unicode的专业文章，原文分上、下两篇，将其合并为Word文档后共计27页。有兴趣者下载附件，或到文章提及的作者网站浏览。
浅谈文字编码和Unicode.rar (349.19 KB, 下载次数: 3989)

[ 本帖最后由 sanwsw 于 2007-11-20 00:13 编辑 ]
作者: ZXD4G    时间: 2007-11-20 10:22
很不错的文章，如果高级用户能了解一些有关汉字信息化的知识，将对文字输入、存储、转换等过程或产生的实体等一系列内容，会有一个上台阶的认识，在应用过程中遭遇的困惑，部分也能迎刃而解或更加容易找到症结。
作者: sanwsw    时间: 2007-11-24 20:26
　　CJK统一表意文字.PDF、CJK统一表意文字 EXT-A.PDF、CJK统一表意文字 EXT-B.PDF这三个文档，均可从Unicode官方网站下载，点 击 下 载 。
　　CJK统一表意文字EXT-C正式版本尚未出来，据孙海峰博士统计，已经提交的CJK统一表意文字EXT-C方案共4149个汉字，但Unicode官方网站还没有PDF文档提供下载。经一番努力，终制成“CJK-ExtC.PDF”文档。点 击 下 载 。　　

作者: sanwsw    时间: 2007-11-25 19:45
　　Unicode在Word中的简单运用
　　Unicode统一码知识对于非专业人员来说有点冷僻，但其与任何一个使用Word的人都密切相关。
　　①你在文字录入过程中是如何快速输入平方、立方符号的？那么4次方、5次方呢？你可以这样输入：
　　在按住Alt的同时在小键盘处输入0178则可输入平方符号，在按住Alt的同时在小键盘处输入0179则可输入立方符号。其他自己摸索。摸索方法参见Word中插入菜单的“符号”。

　　②假设你在工作中频繁用到某个GBK字符集内的生僻汉字（当然也可用固顶方式实现一劳永逸），尽管知道读音，但在紫光拼音的单字排列里比较考后，你可以记住该字的Unicode内码，则可快速输入。
　　a.从汉字到汉字Unicode内码：将光标定位到该汉字右侧，按组合键ALT+X，则可将该汉字转换成该汉字的Unicode内码。
　　b.从汉字Unicode内码到汉字：将光标定位到Unicode内码右侧，按组合键ALT+X，则可将该汉字Unicode内码转换成汉字。

　　上述两例就是Unicode在Word中的具体应用。掌握这两条后，从网页上、电子字典、词典上复制到生僻汉字，即使不知读音，即可用这种方法顺利输入。当然，要想在电脑上显示Unicode支持的所有汉字，得安装孙海峰博士制作的供网络免费下载使用的UniFonts5.3。我在本坛多次推广，有人还怀疑我在做广告。^_^^_^

作者: fengchun    时间: 2007-12-17 17:09
原来这里有这个帖子，拜读了
作者: shardineblog    时间: 2007-12-19 18:11
期待支持Unicode的版本早日出现。。。
作者: maks    时间: 2008-1-18 12:42
学习了，一直不懂这个问题
作者: sanwsw    时间: 2008-2-25 11:17

1.完整的CJK Unicode范围（5.0版）：各有关PDF文档下载地址

2.Unicode漢字碼表网址：点击进入。

3.Unicode字符表网址：点击进入。
作者: hzysoft    时间: 2009-2-19 21:11
非常只专业，我等之辈定当努力学习汉字知识
作者: hgzyyl    时间: 2009-3-25 23:52
CJK基本库和扩展库 有多少标准？
作者: 乖三毛    时间: 2009-3-26 11:59
标题: 回复 1# 的帖子
看一下这篇文章 这里有更通俗的各种编码方式的介绍

http://hi.baidu.com/suruiqiang/b ... 3dfdc1a6ef3f1d.html
作者: hgzyyl    时间: 2009-3-26 14:52
百度空间 | 百度首页 | 登录                  三毛博客qq:510784518 有志者事竟成，破釜沉舟，百二秦关终属楚 苦心人天不负，卧薪尝胆，三千越甲可吞吴 主页博客相册|个人档案 |好友   查看文章   
各种字符编码方式详解及由来(ANSI,UNICODE,UTF-8,GB2312,GBK)2009-01-03 00:45一直对字符的各种编码方式懵懵懂懂，什么ANSI UNICODE UTF-8 GB2312 GBK DBCS UCS……是不是看的很晕，假如您细细的阅读本文你一定可以清晰的理解他们。Let's go!

很久很久以前，有一群人，他们决定用8个可以开合的晶体管来组合成不同的状态，以表示世界上的万物。他们看到8个开关状态是好的，于是他们把这称为"字节"。
再后来，他们又做了一些可以处理这些字节的机器，机器开动了，可以用字节来组合出很多状态，状态开始变来变去。他们看到这样是好的，于是它们就这机器称为"计算机"。

开始计算机只在美国用。八位的字节一共可以组合出256(2的8次方)种不同的状态。
他们把其中的编号从0开始的32种状态分别规定了特殊的用途，一但终端、打印机遇上约定好的这些字节被传过来时，就要做一些约定的动作。遇上00x10, 终端就换行，遇上0x07, 终端就向人们嘟嘟叫，例好遇上0x1b, 打印机就打印反白的字，或者终端就用彩色显示字母。他们看到这样很好，于是就把这些0x20以下的字节状态称为"控制码"。
他们又把所有的空格、标点符号、数字、大小写字母分别用连续的字节状态表示，一直编到了第127号，这样计算机就可以用不同字节来存储英语的文字了。大家看到这样，都感觉很好，于是大家都把这个方案叫做 ANSI 的"Ascii"编码（American Standard Code for Information Interchange，美国信息互换标准代码）。当时世界上所有的计算机都用同样的ASCII方案来保存英文文字。
后来，就像建造巴比伦塔一样，世界各地的都开始使用计算机，但是很多国家用的不是英文，他们的字母里有许多是ASCII里没有的，为了可以在计算机保存他们的文字，他们决定采用127号之后的空位来表示这些新的字母、符号，还加入了很多画表格时需要用下到的横线、竖线、交叉等形状，一直把序号编到了最后一个状态255。从128到255这一页的字符集被称"扩展字符集"。从此之后，贪婪的人类再没有新的状态可以用了，美帝国主义可能没有想到还有第三世界国家的人们也希望可以用到计算机吧！
等中国人们得到计算机时，已经没有可以利用的字节状态来表示汉字，况且有6000多个常用汉字需要保存呢。但是这难不倒智慧的中国人民，我们不客气地把那些127号之后的奇异符号们直接取消掉, 规定：一个小于127的字符的意义与原来相同，但两个大于127的字符连在一起时，就表示一个汉字，前面的一个字节（他称之为高字节）从0xA1用到0xF7，后面一个字节（低字节）从0xA1到0xFE，这样我们就可以组合出大约7000多个简体汉字了。在这些编码里，我们还把数学符号、罗马希腊的字母、日文的假名们都编进去了，连在 ASCII 里本来就有的数字、标点、字母都统统重新编了两个字节长的编码，这就是常说的"全角"字符，而原来在127号以下的那些就叫"半角"字符了。
中国人民看到这样很不错，于是就把这种汉字方案叫做 "GB2312"。GB2312 是对 ASCII 的中文扩展。
但是中国的汉字太多了，我们很快就就发现有许多人的人名没有办法在这里打出来，特别是某些很会麻烦别人的国家领导人。于是我们不得不继续把 GB2312 没有用到的码位找出来老实不客气地用上。
后来还是不够用，于是干脆不再要求低字节一定是127号之后的内码，只要第一个字节是大于127就固定表示这是一个汉字的开始，不管后面跟的是不是扩展字符集里的内容。结果扩展之后的编码方案被称为 GBK 标准，GBK 包括了 GB2312 的所有内容，同时又增加了近20000个新的汉字（包括繁体字）和符号。
后来少数民族也要用电脑了，于是我们再扩展，又加了几千个新的少数民族的字，GBK 扩成了 GB18030。从此之后，中华民族的文化就可以在计算机时代中传承了。
中国的程序员们看到这一系列汉字编码的标准是好的，于是通称他们叫做 "DBCS"（Double Byte Charecter Set 双字节字符集）。在DBCS系列标准里，最大的特点是两字节长的汉字字符和一字节长的英文字符并存于同一套编码方案里，因此他们写的程序为了支持中文处理，必须要注意字串里的每一个字节的值，如果这个值是大于127的，那么就认为一个双字节字符集里的字符出现了。那时候凡是受过加持，会编程的计算机僧侣们都要每天念下面这个咒语数百遍：
"一个汉字算两个英文字符！一个汉字算两个英文字符……"

因为当时各个国家都像中国这样搞出一套自己的编码标准，结果互相之间谁也不懂谁的编码，谁也不支持别人的编码，连大陆和台湾这样只相隔了150海里，使用着同一种语言的兄弟地区，也分别采用了不同的 DBCS 编码方案——当时的中国人想让电脑显示汉字，就必须装上一个"汉字系统"，专门用来处理汉字的显示、输入的问题，但是那个台湾的愚昧封建人士写的算命程序就必须加装另一套支持 BIG5 编码的什么"倚天汉字系统"才可以用，装错了字符系统，显示就会乱了套！这怎么办？而且世界民族之林中还有那些一时用不上电脑的穷苦人民，他们的文字又怎么办？
真是计算机的巴比伦塔命题啊！
正在这时，大天使加百列及时出现了——一个叫 ISO （国际标谁化组织）的国际组织决定着手解决这个问题。他们采用的方法很简单：废了所有的地区性编码方案，重新搞一个包括了地球上所有文化、所有字母和符号的编码！他们打算叫它"Universal Multiple-Octet Coded Character Set"，简称 UCS, 俗称 "UNICODE"。
UNICODE 开始制订时，计算机的存储器容量极大地发展了，空间再也不成为问题了。于是 ISO 就直接规定必须用两个字节，也就是16位来统一表示所有的字符，对于ascii里的那些“半角”字符，UNICODE 包持其原编码不变，只是将其长度由原来的8位扩展为16位，而其他文化和语言的字符则全部重新统一编码。由于"半角"英文符号只需要用到低8位，所以其高8位永远是0，因此这种大气的方案在保存英文文本时会多浪费一倍的空间。
这时候，从旧社会里走过来的程序员开始发现一个奇怪的现象：他们的strlen函数靠不住了，一个汉字不再是相当于两个字符了，而是一个！是的，从 UNICODE 开始，无论是半角的英文字母，还是全角的汉字，它们都是统一的"一个字符"！同时，也都是统一的"两个字节"，请注意"字符"和"字节"两个术语的不同，“字节”是一个8位的物理存贮单元，而“字符”则是一个文化相关的符号。在UNICODE 中，一个字符就是两个字节。一个汉字算两个英文字符的时代已经快过去了。
从前多种字符集存在时，那些做多语言软件的公司遇上过很大麻烦，他们为了在不同的国家销售同一套软件，就不得不在区域化软件时也加持那个双字节字符集咒语，不仅要处处小心不要搞错，还要把软件中的文字在不同的字符集中转来转去。UNICODE 对于他们来说是一个很好的一揽子解决方案，于是从 Windows NT 开始，MS 趁机把它们的操作系统改了一遍，把所有的核心代码都改成了用 UNICODE 方式工作的版本，从这时开始，WINDOWS 系统终于无需要加装各种本土语言系统，就可以显示全世界上所有文化的字符了。
但是，UNICODE 在制订时没有考虑与任何一种现有的编码方案保持兼容，这使得 GBK 与UNICODE 在汉字的内码编排上完全是不一样的，没有一种简单的算术方法可以把文本内容从UNICODE编码和另一种编码进行转换，这种转换必须通过查表来进行。
如前所述，UNICODE 是用两个字节来表示为一个字符，他总共可以组合出65535不同的字符，这大概已经可以覆盖世界上所有文化的符号。如果还不够也没有关系，ISO已经准备了UCS-4方案，说简单了就是四个字节来表示一个字符，这样我们就可以组合出21亿个不同的字符出来（最高位有其他用途），这大概可以用到银河联邦成立那一天吧！

UNICODE 来到时，一起到来的还有计算机网络的兴起，UNICODE 如何在网络上传输也是一个必须考虑的问题，于是面向传输的众多 UTF（UCS Transfer Format）标准出现了，顾名思义，UTF8就是每次8个位传输数据，而UTF16就是每次16个位，只不过为了传输时的可靠性，从UNICODE到UTF时并不是直接的对应，而是要过一些算法和规则来转换。
受到过网络编程加持的计算机僧侣们都知道，在网络里传递信息时有一个很重要的问题，就是对于数据高低位的解读方式，一些计算机是采用低位先发送的方法，例如我们PC机采用的 INTEL 架构，而另一些是采用高位先发送的方式，在网络中交换数据时，为了核对双方对于高低位的认识是否是一致的，采用了一种很简便的方法，就是在文本流的开始时向对方发送一个标志符——如果之后的文本是高位在位，那就发送"FEFF"，反之，则发送"FFFE"。不信你可以用二进制方式打开一个UTF-X格式的文件，看看开头两个字节是不是这两个字节？

讲到这里，我们再顺便说说一个很著名的奇怪现象：当你在 windows 的记事本里新建一个文件，输入"联通"两个字之后，保存，关闭，然后再次打开，你会发现这两个字已经消失了，代之的是几个乱码！呵呵，有人说这就是联通之所以拼不过移动的原因。
其实这是因为GB2312编码与UTF8编码产生了编码冲撞的原因。
从网上引来一段从UNICODE到UTF8的转换规则：

Unicode
UTF-8

0000 - 007F
0xxxxxxx

0080 - 07FF
110xxxxx 10xxxxxx

0800 - FFFF
1110xxxx 10xxxxxx 10xxxxxx

例如"汉"字的Unicode编码是6C49。6C49在0800-FFFF之间，所以要用3字节模板：1110xxxx 10xxxxxx 10xxxxxx。将6C49写成二进制是：0110 1100 0100 1001，将这个比特流按三字节模板的分段方法分为0110 110001 001001，依次代替模板中的x，得到：1110-0110 10-110001 10-001001，即E6 B1 89，这就是其UTF8的编码。
而当你新建一个文本文件时，记事本的编码默认是ANSI, 如果你在ANSI的编码输入汉字，那么他实际就是GB系列的编码方式，在这种编码下，"联通"的内码是：
c1 1100 0001
aa 1010 1010
cd 1100 1101
a8 1010 1000
注意到了吗？第一二个字节、第三四个字节的起始部分的都是"110"和"10"，正好与UTF8规则里的两字节模板是一致的，于是再次打开记事本时，记事本就误认为这是一个UTF8编码的文件，让我们把第一个字节的110和第二个字节的10去掉，我们就得到了"00001 101010"，再把各位对齐，补上前导的0，就得到了"0000 0000 0110 1010"，不好意思，这是UNICODE的006A，也就是小写的字母"j"，而之后的两字节用UTF8解码之后是0368，这个字符什么也不是。这就是只有"联通"两个字的文件没有办法在记事本里正常显示的原因。
而如果你在"联通"之后多输入几个字，其他的字的编码不见得又恰好是110和10开始的字节，这样再次打开时，记事本就不会坚持这是一个utf8编码的文件，而会用ANSI的方式解读之，这时乱码又不出现了。

好了，终于可以回答NICO的问题了，在数据库里，有n前缀的字串类型就是UNICODE类型，这种类型中，固定用两个字节来表示一个字符，无论这个字符是汉字还是英文字母，或是别的什么。
如果你要测试"abc汉字"这个串的长度，在没有n前缀的数据类型里，这个字串是7个字符的长度，因为一个汉字相当于两个字符。而在有n前缀的数据类型里，同样的测试串长度的函数将会告诉你是5个字符，因为一个汉字就是一个字符。


类别：技术收录 | 添加到搜藏 | 浏览(289) | 评论 (2)  上一篇：百度贴吧发贴机    下一篇：解决Inet控件(Internet Transfer... 最近读者： 登录后，您就出现在这里。         
    『枫の传说』 gujin170 张朝宣 sinoshaw ghos丶t KuntaKimp 历又 xlrtx  
网友评论：1
eee2356eee  2009-01-21 18:40 | 回复 好东西！终于明白这几个编码之间的关系了！ 学习！学习！  
2
张朝宣  2009-03-11 17:29 | 回复   
     发表评论：姓　名：     注册 | 登录 *姓名最长为50字节
   
网址或邮箱：  (选填)
   
内　容： 插入表情  ▼ 闪光字


  
   
验证码：  
看不清?  
      取消回复

      

&copy;2009 Baidu
作者: HESHILIE    时间: 2009-7-31 11:23
康熙字典一共收录汉字：47035个字
--------------------------------------------------
　　　　　　中日韩越通用汉字字符（75814个）
CJK基本　　　[4E00-9FFF]　　　20992码位　实际20924字
CJK扩展A　　 [3400-4DBF]　　　6592码位　 实际6582字
CJK扩展B　　 [20000 -2A6DF]　 42720码位　实际42711字
CJK扩展C　　 [ 2A700-2B 73F]　4159码位　 实际4149字
CJK兼容扩展  [ 2F800-2FA 1F]　544码位　　实际542字
CJK部首扩展  [2E80-2EFF]　　　128码位　　实际115字
CJK康熙部首  [ 2F00-2FDF]　　 224码位　　实际214字
CJK笔画　　  [ 31C0-31EF]　　 48码位　　 实际36字
CJK兼容      [F900-FAFF]　　　512个码位　实际474字
--------------------------------------------------

　　见7楼，总数已有变化。sanwsw

中日韩越通用汉字字符（75814个）.jpg (253.56 KB, 下载次数: 183)

中日韩越通用汉字字符（75814个）

中日韩越通用汉字字符（75814个）
作者: sanwsw    时间: 2009-11-15 17:07
关于Unicode内码，又找到fmddlmyy写的几篇文章，一并贴出。鉴于文章较长，图文并排，就以doc文档附件上传。
GB18030编码研究以及GBK、GB18030与Unicode的映射.rar (13.82 KB, 下载次数: 859)

Unicode、GB2312、GBK和GB18030中的汉字.rar (47.7 KB, 下载次数: 961)

从GB2313-标准字符集、GBK-大字符集到GB18030-超大字符集.rar (6.23 KB, 下载次数: 1113)





欢迎光临 华宇拼音输入法论坛 (http://bbs.pinyin.thunisoft.com/) Powered by Discuz! X3.2