16,471
社区成员
发帖
与我相关
我的任务
分享谈谈Unicode编码，简要解释UCS、UTF、BMP、BOM等名词
这是一篇程序员写给程序员的趣味读物。所谓趣味是指可以比较轻松地了解一些原来不清楚的概念，增进知识，类似于打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个字符。2000年的GB18030是取代GBK1.0的正式国家标准。该标准收录了27484个汉字，同时还收录了藏文、蒙文、维吾尔文等主要的少数民族文字。现在的PC平台必须支持GB18030，对嵌入式产品暂不作要求。所以手机、MP3一般只支持GB2312。
从ASCII、GB2312、GBK到GB18030，这些编码方法是向下兼容的，即同一个字符在这些方案中总是有相同的编码，后面的标准支持更多的字符。在这些编码中，英文和中文可以统一地处理。区分中文编码的方法是高字节的最高位不为0。按照程序员的称呼，GB2312、GBK到GB18030都属于双字节字符集 (DBCS)。
有的中文Windows的缺省内码还是GBK，可以通过GB18030升级包升级到GB18030。不过GB18030相对GBK增加的字符，普通人是很难用到的，通常我们还是用GBK指代中文Windows内码。
这里还有一些细节：
GB2312的原文还是区位码，从区位码到内码，需要在高字节和低字节上分别加上A0。
在DBCS中，GB内码的存储格式始终是big endian，即高位在前。
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的最新标准是10646-3:2003。
UCS规定了怎么用多个字节表示各种文字。怎样传输这些编码，是由UTF(UCS Transformation Format)规范规定的，常见的UTF规范包括UTF-8、UTF-7、UTF-16。
IETF的RFC2781和RFC3629以RFC的一贯风格，清晰、明快又不失严谨地描述了UTF-16和UTF-8的编码方法。我总是记不得IETF是Internet Engineering Task Force的缩写。但IETF负责维护的RFC是Internet上一切规范的基础。
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。
读者可以用记事本测试一下我们的编码是否正确。
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)。
我还找了两篇看上去不错的资料，不过因为我开始的疑问都找到了答案，所以就没有看：
"Understanding Unicode A general introduction to the Unicode Standard" (http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&item_id=IWS-Chapter04a)
"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://fmddlmyy.home4u.china.com)。
我是想清楚所有问题后才开始写这篇文章的，原以为一会儿就能写好。没想到考虑措辞和查证细节花费了很长时间，竟然从下午1:30写到9:00。希望有读者能从中受益。
问题一：
使用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个字符。2000年的GB18030是取代GBK1.0的正式国家标准。该标准收录了27484个汉字，同时还收录了藏文、蒙文、维吾尔文等主要的少数民族文字。现在的PC平台必须支持GB18030，对嵌入式产品暂不作要求。所以手机、MP3一般只支持GB2312。
从ASCII、GB2312、GBK到GB18030，这些编码方法是向下兼容的，即同一个字符在这些方案中总是有相同的编码，后面的标准支持更多的字符。在这些编码中，英文和中文可以统一地处理。区分中文编码的方法是高字节的最高位不为0。按照程序员的称呼，GB2312、GBK到GB18030都属于双字节字符集 (DBCS)。
有的中文Windows的缺省内码还是GBK，可以通过GB18030升级包升级到GB18030。不过GB18030相对GBK增加的字符，普通人是很难用到的，通常我们还是用GBK指代中文Windows内码。
这里还有一些细节：
GB2312的原文还是区位码，从区位码到内码，需要在高字节和低字节上分别加上A0。
在DBCS中，GB内码的存储格式始终是big endian，即高位在前。
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的最新标准是10646-3:2003。
UCS规定了怎么用多个字节表示各种文字。怎样传输这些编码，是由UTF(UCS Transformation Format)规范规定的，常见的UTF规范包括UTF-8、UTF-7、UTF-16。
IETF的RFC2781和RFC3629以RFC的一贯风格，清晰、明快又不失严谨地描述了UTF-16和UTF-8的编码方法。我总是记不得IETF是Internet Engineering Task Force的缩写。但IETF负责维护的RFC是Internet上一切规范的基础。
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。
读者可以用记事本测试一下我们的编码是否正确。
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)。
我还找了两篇看上去不错的资料，不过因为我开始的疑问都找到了答案，所以就没有看：
"Understanding Unicode A general introduction to the Unicode Standard" (http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&item_id=IWS-Chapter04a)
"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://fmddlmyy.home4u.china.com)。
我是想清楚所有问题后才开始写这篇文章的，原以为一会儿就能写好。没想到考虑措辞和查证细节花费了很长时间，竟然从下午1:30写到9:00。希望有读者能从中受益。
...全文
请发表友善的回复…
发表回复
糊糊 2005-05-09
- 打赏
- 举报
楼主有没有做过下载html文件的程序啊，我做了一个，把html源代码下载回来，并且显示在Edit里面，结果有好多乱码，但是有的网站下载回来的又能够显示，你说这是怎么回事啊？
测试的网站都是国内的。比如sohu，金山。
测试的网站都是国内的。比如sohu，金山。
糊糊 2005-05-09
- 打赏
- 举报
我想，不必要弄清楚网页文件的charset吧，下载完之后统一转换为Unicode，然后显示可以吗？
还有Windows的Edit控件（还有其他控件），显示文本是使用Unicode吗？
还有Windows的Edit控件（还有其他控件），显示文本是使用Unicode吗？
薛定谔之死猫 2005-05-09
- 打赏
- 举报
mark
tudou614 2005-05-09
- 打赏
- 举报
谢谢楼主的文章，我把故事改编了一下
“endian”这个词出自《格列佛游记》。传说中的小人国的内战就源于该国家的国王下达了一项命令：所有子民吃鸡蛋时必须从小头开始,显然有很多的人宁肯冒杀头之罪都不愿意这样做,就是由于这项荒谬的"圣旨",该国家先后发生过六次叛乱，其中一个皇帝挂了，另一个丢了王位。
好象原来是这样的
“endian”这个词出自《格列佛游记》。传说中的小人国的内战就源于该国家的国王下达了一项命令：所有子民吃鸡蛋时必须从小头开始,显然有很多的人宁肯冒杀头之罪都不愿意这样做,就是由于这项荒谬的"圣旨",该国家先后发生过六次叛乱，其中一个皇帝挂了，另一个丢了王位。
好象原来是这样的
fmddlmyy 2005-05-09
- 打赏
- 举报
乱码的问题一般还是比较容易解决的，只要你清楚网页文件的charset。
将utf-8或ISO-8859-1作为GBK显示，都会产生乱码。
将utf-8或ISO-8859-1作为GBK显示，都会产生乱码。
ahua_liu 2005-05-09
- 打赏
- 举报
mark
Mycro 2005-05-09
- 打赏
- 举报
今天，在文档里看了这篇文章，写得不错。。
fmddlmyy 2005-05-09
- 打赏
- 举报
谢谢tudou614的改编:)
另外我的文章中还有一点不准确的地方，下面是网友在CSDN blog上的回复：
>>>
@ 2005.5.8 15:58 adoal 发表评论
“在DBCS中，GB内码的存储格式始终是big endian，即高位在前”，这种说法并不准确。只有wide char（或者理解为16/32-bit integer）的value才存在endian的概念。而GB之类的编码是multi-otect stream，里面的两个字节并不能理解成一个16位的完整整数。这是wide char和MBCS的重要区别。具体可以阅读Ken Lunde的巨著CJKV Information Processing第3、4章。
>>>
我的回复如下：
>>>
@ 2005.5.9 10:45 fmddlmyy 发表评论
谢谢adoal的指点。你说的是正确的。我的说法是错误的。
GB码确实应该理解为multi-otect stream，而不是一个二进制数。
例如UTF-8编码，用多个字节编码一个字符，这多个字节是指定顺序的字节流，而不存在字节序的问题。
UTF-16编码是多个word来编码一个字符，word的顺序是编码方式指定的。word内部才有字节序的问题。
这个概念，我以前比较模糊，看到你的回复后才想清楚。再次感谢你的指点。
>>>
再次感谢网友adoal的指点。
控件使用什么字符编码，应该与编译时定义DBCS还是UNICODE有关吧。
另外我的文章中还有一点不准确的地方，下面是网友在CSDN blog上的回复：
>>>
@ 2005.5.8 15:58 adoal 发表评论
“在DBCS中，GB内码的存储格式始终是big endian，即高位在前”，这种说法并不准确。只有wide char（或者理解为16/32-bit integer）的value才存在endian的概念。而GB之类的编码是multi-otect stream，里面的两个字节并不能理解成一个16位的完整整数。这是wide char和MBCS的重要区别。具体可以阅读Ken Lunde的巨著CJKV Information Processing第3、4章。
>>>
我的回复如下：
>>>
@ 2005.5.9 10:45 fmddlmyy 发表评论
谢谢adoal的指点。你说的是正确的。我的说法是错误的。
GB码确实应该理解为multi-otect stream，而不是一个二进制数。
例如UTF-8编码，用多个字节编码一个字符，这多个字节是指定顺序的字节流，而不存在字节序的问题。
UTF-16编码是多个word来编码一个字符，word的顺序是编码方式指定的。word内部才有字节序的问题。
这个概念，我以前比较模糊，看到你的回复后才想清楚。再次感谢你的指点。
>>>
再次感谢网友adoal的指点。
控件使用什么字符编码，应该与编译时定义DBCS还是UNICODE有关吧。
糊糊 2005-05-05
- 打赏
- 举报
写的很好,想问的是,怎么用VC做Unicode的软件?
尤其是你的程序是Unicode的,你界面(菜单,提示)使用了中文,但是在英文操作系统上会显示出来吗,是不是乱码?
尤其是你的程序是Unicode的,你界面(菜单,提示)使用了中文,但是在英文操作系统上会显示出来吗,是不是乱码?
surstar 2005-05-05
- 打赏
- 举报
收藏~，这是收藏楼主第2篇了~
fmddlmyy 2005-05-05
- 打赏
- 举报
在天涯的IT视界，有网友指出我说GB18030属于DBCS是错误的。网友的指教是正确的。在这里也贴一下我在天涯的回复，以纠正原文的错误，同时谈谈关于GB18030的一些看法。如果还有什么说得不对的地方，欢迎大家不吝赐教。
这篇文章的本意是介绍UCS的基础知识。在写到汉字编码时，因为这部分我以前比较熟悉，就多写了两句，也没有仔细查证。关于GB18030的一些文字是不正确的。这里就GB18030再做一些说明：
从汉字字汇上说，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有两点描述是不准确的：
1、我说中文Windows的内码可以通过升级到GB18030，事实上中文Windows的内码还是GBK。
2、我说GB18030属于DBCS，事实上GB18030是4字节字符集。
下面再谈谈微软对GB18030问题上的处理：
我之所以会有中文Windows的内码已经升级到GB18030的印象是因为GB18030是中国的强制标准,而微软既提供了GB18030的升级包,我就以为升级后的内码可以支持GB18030。但经过查证发现升级后，Windows内码还是不支持GB18030。
其实NT架构的内核已经是Unicode编码。传统意义的内码是通过code page实现的。例如GBK对应的code page就是CP936。
微软确实为GB18030增加了一个code page：CP54936。但是这个code page是无法真正使用的。无法使用的原因在微软网站上就有详细的解释：
Is GB18030 replacing the Windows Simplified Chinese code page (CP936)?
No, Windows code pages must be either one byte (SBCS) or a mix of one and two bytes (DBCS). This requirement is reflected throughout our code e.g. in data structures, program interfaces, network protocols and applications. The existing code page for Simplified Chinese, CP936, is a double byte code page. GB18030 is a four–byte code page i.e. every character is represented by one, two or four bytes. To replace CP936 with GB18030 would require rewriting much of the system. Even if we were to do this, such a system would not run regular applications nor interoperate with regular Windows.
微软目前的代码只支持DBCS和SBCS，无法支持4字节字符集。这也就是我前面谈到的对DBCS的解析，DBCS通过对高字节最高位的判断区分两字节编码，如果要支持4字节编码，例如8139EF30，就必须全面修改相关代码。微软认为这样的改动即困难又没有意义。
微软的GB18030升级包主要有3点内容：
1、提供了一套支持CJK扩展A的6582个汉字的新字体：新宋体-18030
2、增加了不能使用的code page：CP54936
3、提供了一个有几个4字节编码转换函数的DLL和一个GB18030和Unicode编码的转换程序。
说起这个转换程序，还有一点比较可笑。我用这个转换程序试着转换CJK扩展A的几个字符，源文件的16进制是：
FFFE 0034 0134 0234 0334 0434 0534
这是一个Little-Endian的Unicode文本文件，转换得到的结果是：
8139 EE39 8139 EF30 8139 EF31 8139 EF32 8139 EF33 8139 EF34
事实上，根据GB18030，UCS的0x3400的编码应该是8139EF30。这个转换程序的结果是正确结果-1。
从以上分析可见，微软只是提供了GB18030要求的字汇，根本不能支持GB18030的编码。但微软网站上却是说自己的方案已经 Approved by the Chinese testing agency. 而且微软对GB18030问题的应付显然是很马虎的。连一个很简单的转换程序都有明显的错误。
我对GB18030并没有什么好感，它对CJK扩展A的6582个汉字进行4字节编码，虽然编码设计上有很好的扩展性，但显然没有考虑到如何兼容当前的软件平台。
但GB18030既然是一个国家的强制标准，但在执行时又敷衍了事，而没有明确的说法。这种出尔反尔的做法，实在不是什么光彩的事情。
这篇文章的本意是介绍UCS的基础知识。在写到汉字编码时，因为这部分我以前比较熟悉，就多写了两句，也没有仔细查证。关于GB18030的一些文字是不正确的。这里就GB18030再做一些说明：
从汉字字汇上说，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有两点描述是不准确的：
1、我说中文Windows的内码可以通过升级到GB18030，事实上中文Windows的内码还是GBK。
2、我说GB18030属于DBCS，事实上GB18030是4字节字符集。
下面再谈谈微软对GB18030问题上的处理：
我之所以会有中文Windows的内码已经升级到GB18030的印象是因为GB18030是中国的强制标准,而微软既提供了GB18030的升级包,我就以为升级后的内码可以支持GB18030。但经过查证发现升级后，Windows内码还是不支持GB18030。
其实NT架构的内核已经是Unicode编码。传统意义的内码是通过code page实现的。例如GBK对应的code page就是CP936。
微软确实为GB18030增加了一个code page：CP54936。但是这个code page是无法真正使用的。无法使用的原因在微软网站上就有详细的解释：
Is GB18030 replacing the Windows Simplified Chinese code page (CP936)?
No, Windows code pages must be either one byte (SBCS) or a mix of one and two bytes (DBCS). This requirement is reflected throughout our code e.g. in data structures, program interfaces, network protocols and applications. The existing code page for Simplified Chinese, CP936, is a double byte code page. GB18030 is a four–byte code page i.e. every character is represented by one, two or four bytes. To replace CP936 with GB18030 would require rewriting much of the system. Even if we were to do this, such a system would not run regular applications nor interoperate with regular Windows.
微软目前的代码只支持DBCS和SBCS，无法支持4字节字符集。这也就是我前面谈到的对DBCS的解析，DBCS通过对高字节最高位的判断区分两字节编码，如果要支持4字节编码，例如8139EF30，就必须全面修改相关代码。微软认为这样的改动即困难又没有意义。
微软的GB18030升级包主要有3点内容：
1、提供了一套支持CJK扩展A的6582个汉字的新字体：新宋体-18030
2、增加了不能使用的code page：CP54936
3、提供了一个有几个4字节编码转换函数的DLL和一个GB18030和Unicode编码的转换程序。
说起这个转换程序，还有一点比较可笑。我用这个转换程序试着转换CJK扩展A的几个字符，源文件的16进制是：
FFFE 0034 0134 0234 0334 0434 0534
这是一个Little-Endian的Unicode文本文件，转换得到的结果是：
8139 EE39 8139 EF30 8139 EF31 8139 EF32 8139 EF33 8139 EF34
事实上，根据GB18030，UCS的0x3400的编码应该是8139EF30。这个转换程序的结果是正确结果-1。
从以上分析可见，微软只是提供了GB18030要求的字汇，根本不能支持GB18030的编码。但微软网站上却是说自己的方案已经 Approved by the Chinese testing agency. 而且微软对GB18030问题的应付显然是很马虎的。连一个很简单的转换程序都有明显的错误。
我对GB18030并没有什么好感，它对CJK扩展A的6582个汉字进行4字节编码，虽然编码设计上有很好的扩展性，但显然没有考虑到如何兼容当前的软件平台。
但GB18030既然是一个国家的强制标准，但在执行时又敷衍了事，而没有明确的说法。这种出尔反尔的做法，实在不是什么光彩的事情。
fmddlmyy 2005-05-05
- 打赏
- 举报
NT架构的内核是Unicode的。编译时只要用UNICODE取代DBCS，然后资源中也使用Unicode字符，就可以编译出Unicode程序。所谓英文操作系统只是使用了英文的code page，只要对方有中文字体，就可以正常显示Unicode程序。
不过一般而言的国际化并不是指在所有平台都显示中文，而是指在不同语言环境显示相应的语言。这就需要准备多套资源，并可以自动检测对方的语言，允许动态切换。MSDN中有很好的例子。
不过一般而言的国际化并不是指在所有平台都显示中文，而是指在不同语言环境显示相应的语言。这就需要准备多套资源，并可以自动检测对方的语言，允许动态切换。MSDN中有很好的例子。
loves123 2005-05-04
- 打赏
- 举报
不错，mark！
oyljerry 2005-05-04
- 打赏
- 举报
不错，sp
vcmute 2005-05-04
- 打赏
- 举报
sf,3ks
