【转载】两篇关于字符编码的博文

1.http://www.52rd.com/Blog/Detail_RD.Blog_thieven_4865.html

UTF8和UCS2(2006-11-26 01:17)

谈谈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个字符。

从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。但是由于GB18030有一部分4字节编码，而Windows的代码页只支持单字节和双字节编码，所以这个code page是无法真正使用的。

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)。

我还找了两篇看上去不错的资料，不过因为我开始的疑问都找到了答案，所以就没有看： "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。希望有读者能从中受益。

附录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" content="text/html; charset=ISO8859-1"> 如果原作者使用的代码页和ISO8859-1兼容，就不会出现乱码了。

再说区位码，啊的区位码是1601，写成16进制是0x10,0x01。这和计算机广泛使用的ASCII编码冲突。为了兼容00-7f的ASCII编码，我们在区位码的高、低字节上分别加上A0。这样“啊”的编码就成为B0A1。我们将加过两个A0的编码也称为GB2312编码，虽然GB2312的原文根本没提到这一点。

========================================================

2.http://blog.sina.com.cn/s/blog_958a07d0010136y1.html

字符编码

版本	修订日期	修订内容	修订人
V0.1	2008-12-1	初始化
V1.0	2008-12-11	第一版
V1.1	2008-12-13	First reported
V1.2	2008-12-14	添加ASCII码表
V1.3	2008-12-18	添加code page
V1.4	2008-12-23	添加BOM

1 ASCII

American Standard Code for Information Interchange，美国标准信息交换码。因为计算机只能表示和存储二进制的数据，所以需要对常用的52个字母，阿拉伯数字等字符进行编码，为了便于信息交换，需要一个统一的标准，于是American National Standard Institute(ANSI)制定了这个ASCII码，并于1967年成为美国国家标准，后被ISO(International Standardization Organization)国际标准化组织定为国际标准ISO646。

ASCII属于单字节编码，即使用一个字节(8 bytes)进行编码，因此最多只能表示256个字符。*础的ASCII使用7bits编码，最高位位为0，或者用于奇偶校验。ASCII编码适用于所有的拉丁字母。

0x00 – 0x1F：为控制字符

ASCII编码可以满足美国的拉丁字母需求，但是不能满足其他语种的需求，例如中日韩的象形文字，所以导致下面编码的出现。

具体定义如下：

十六进制	字符	意义	十六进制	字符	意义
0x00	NULL	空字符	0x10
0x01	SOH	Start of head	0x11
0x02	STX	Start of text	0x12
0x03	ETX	End of text	0x13
0x04	EOT	End of Transmission	0x14
0x05	ENQ	Enquiry	0x15
0x06	ACK	Acknowledge	0x16
0x07	BELL	铃声	0x17
0x08	BS	Backspace	0x18
0x09	TAB	Horizontal tab	0x19
0x0A	LF	Line Feed	0x1A
0x0B	VT	Vertical tab	0x1B
0x0C			0x1C
0x0D	CR	Carriage return	0x1D
0x0E	SO	Shift out	0x1E
0x0F	SI	Shift in	0x1F

2 UCS

国际标准ISO 10646定义了通用字符集 (Universal Character Set, UCS)。 UCS是所有其他字符集标准的一个超集。它保证与其他字符集是双向兼容的，就是说，如果你将任何文本字符串翻译到UCS格式，然后再翻译回原编码，你不会丢失任何信息。

UCS 包含了用于表达所有已知语言的字符，不仅包括拉丁语，希腊语，斯拉夫语，希伯来语，阿拉伯语，亚美尼亚语和乔治亚语的描述，还包括中文，日文和韩文这样的象形文字，以及平假名，片假名，孟加拉语，旁遮普语，果鲁穆奇字符(Gurmukhi)，泰米尔语，印.埃纳德语(Kannada)，Malayalam，泰国语，老挝语，汉语拼音(Bopomofo)，Hangul，Devangari，Gujarati，Oriya, Telugu 以及其他数也数不清的语。对于还没有加入的语言, 由于正在研究怎样在计算机中最好地编码它们, 因而最终它们都将被加入。这些语言包括Tibetian, 高棉语, Runic(古代北欧文字), 埃塞俄比亚语, 其他象形文字, 以及各种各样的印-欧语系的语言, 还包括挑选出来的艺术语言比如Tengwar, Cirth 和克林贡语(Klingon). UCS 还包括大量的图形的, 印刷用的, 数学用的和科学用的符号, 包括所有由 TeX, Postscript, MS-DOS，MS-Windows, Macintosh, OCR 字体, 以及许多其他字处理和出版系统提供的字符。

ISO 10646定义了一个 31 位的字符集。然而, 在这巨大的编码空间中, 迄今为止，只分配了前 65534 个码位 (0x0000 到 0xFFFD)。这个 UCS 的 16位子集称为*本多语言面 (Basic Multilingual Plane, BMP)。将被编码在 16 位 BMP 以外的字符都属于非常特殊的字符(比如象形文字), 且只有专家在历史和科学领域里才会用到它们。按当前的计划, 将来也许再也不会有字符被分配到从 0x000000 到 0x10FFFF 这个覆盖了超过 100 万个潜在的未来字符的 21 位的编码空间以外去了。ISO 10646-1 标准第一次发表于 1993 年, 定义了字符集与 BMP 中内容的架构。定义 BMP 以外的字符编码的第二部分 ISO 10646-2 正在准备中, 但也许要过好几年才能完成。新的字符仍源源不断地加入到 BMP 中, 但已经存在的字符是稳定的且不会再改变了。

UCS 不仅给每个字符分配一个代码，而且赋予了一个正式的名字，表示一个 UCS 或 Unicode 值的十六进制数, 通常在前面加上 "U+", 就象 U+0041 代表字符"拉丁大写字母A". UCS 字符 U+0000 到 U+007F 与 US-ASCII(ISO 646) 是一致的, U+0000 到 U+00FF 与 ISO 8859-1(Latin-1) 也是一致的. 从 U+E000 到 U+F8FF, 已经 BMP 以外的大范围的编码是为私用保留的。

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”的缩写。

3 UTF8

UTF8并不算是一种电脑编码，而是一种储存和传送的格式，如前所述，每个Unicode/UCS字符都以 2或4个bytes来储存，看看以下的比较：

以"I am Chinese"为例

用ANSI储存： 12 Bytes

用Unicode/UCS2储存： 24 Bytes + 2 Bytes(header)

用UCS4储存： 48 Bytes + 4 Bytes(header)

以"我是中国人"为例

用ANSI储存： 10 Bytes（GB2312）

用Unicode/UCS2储存： 10 Bytes + 2 Bytes(header)

用UCS4储存： 20 Bytes + 4 Bytes(header)

由此可见直接以Unicode/UCS的原始形式来储存是一种极大的浪费，而且也不利于互联网的传输(中文稍为合算一点^_^)。

有见及此，Unicode/UCS的压缩形式－－UTF8出现了，套用官方网站的首句话『UTF-8 stands for Unicode Transformation Format-8. It is an octet (8-bit) lossless encoding of Unicode characters.』，由于UTF也适用于编码UCS，故亦可称为『UCS transformation formats (UTF)』

UTF8是以8bits即1Bytes为编码的最*本单位，当然也可以有*于16bits和32bits的形式，分别称为UTF16和UTF32，但目前用得不多，而UTF8则被广泛应用在文件储存和网络传输中。

编码原理

先看这个模板：

UCS-4 range (hex.) UTF-8 octet sequence (binary)

0000 0000-0000 007F -- 0xxxxxxx

0000 0080-0000 07FF -- 110xxxxx 10xxxxxx

0000 0800-0000 FFFF -- 1110xxxx 10xxxxxx 10xxxxxx

0001 0000-001F FFFF -- 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx

0020 0000-03FF FFFF -- 111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx

0400 0000-7FFF FFFF -- 1111110x 10xxxxxx ... 10xxxxxx

编码步骤：

1) 首先确定需要多少个8bits(octets)

2) 按照上述模板填充每个octets的高位bits

3) 把字符的bits填充至x中，字符顺序：低位→高位，UTF8顺序：最后一个octet的最末位x→第一个octet最高位x

不知大家看懂了没有，其实不懂也无所谓，反正又不用自己算，程式可以完全代劳。以UTF8格式储存的文件档首标识为EF BB BF。

效率

　　从上述编码原理中得出的结论是：

1.每个英文字母、数字所占的空间为1 Byte；

2.泛欧语系、斯拉夫语字母占2 Bytes；

3.汉字占3 Bytes。

由此可见UTF8对英文来说是个非常诱人的方案，但对中文来说则不太合算，无论用ANSI还是 Unicode/UCS2来编码都只用2 Bytes，但用UTF8则需要3 Bytes。

以下是一些统计资料，显示用UTF8来储存文件每个字符所需的平均字节：　1.拉丁语系平均用1.1 Bytes；

2.希腊文、俄文、阿拉伯文和希伯莱文平均用1.7 Bytes；

3.其他大部份文字如中文、日文、韩文、Hindi(北印度语)用约3 Bytes；　　4.用超过4 Bytes的都是些非常少用的文字符号。

4 中文编码

4.1 GB2312

GB2312码是中华人民共和国国家汉字信息交换用编码，全称《信息交换用汉字编码字符集——*本集》，由国家标准总局发布，1981年5月1日实施，通行于大陆。新加坡等地也使用此编码。

在国标GD2312 —80中规定，所有的国标汉字及符号分配在一个94行、94列的方阵中，方阵的每一行称为一个“区”，编号为01区到94区，每一列称为一个“位”，编号为01位到94位，方阵中的每一个汉字和符号所在的区号和位号组合在一起形成的四个阿拉伯数字就是它们的“区位码”。区位码的前两位是它的区号，后两位是它的位号(使用Big Edian编码，高字节在前)。用区位码就可以唯一地确定一个汉字或符号，反过来说，任何一个汉字或符号也都对应着一个唯一的区位码。例如：汉字“母”字的区位码是3624，表明它在方阵的36区24位，问号“?”的区位码为0331，则它在03区3l位。在这94*94的区位中，其中：

01-09区为符号、数字区

10-15区空白区

16-87区为汉字区

88-94区空白区

在汉字区分为两级：第一级是常用汉字计3755个，置于16-55区，按汉语拼音字母/笔形顺序排列；第二级汉字是次常用汉字计3008个，置于56-87区，按部首/笔画顺序排列。故而GB2312最多能表示6763个汉字。

汉字的区码和位码取值都在01~94之间，如果直接使用区位码作为机器内码的话，就会与ASCII码混淆。为了避免这个冲突，需要避开*本ASCII码中的控制码 (00H~1FH)，还需与*本ASCII码中的字符相区别。为了实现这两点，可以先在区码和位码分别加上20H，在此*础上再加80H(此处“H”表示前两位数字为十六进制数)。经过这些处理，用机内码表示一个汉字需要占两个字节，分别称为高位字节和低位字节，这两位字节的机内码按如下规则表示：

高位字节 = 区码 + 20H + 80H(或区码 + A0H)

低位字节 = 位码 + 20H + 80H(或位码 + AOH)

由于汉字的区码与位码的取值范围的十六进制数均为01H~5EH(即十进制的01~94)，所以汉字的高位字节与低位字节的取值范围则为A1H~FEH(即十进制的161~254)。

例如，汉字“啊”的区位码为1601，区码和位码分别用十六进制表示即为1001H，它的机内码的高位字节为B0H，低位字节为A1H，机内码就是B0A1H。

4.2 GBK

GB2312只收录了6763个汉字，因此许多以前很少使用的生僻字没有收录，现在这些字也许变得流行了，例如：***的“*”字，未收入GB2312-80，现在大陆的报业出刊只得使用（金+容）、（金容）、（左金右容）等来表示，形式不一而同，这使得表示、存储、输入、处理都非常不方便。

GBK：汉字国标扩展码,*本上采用了原来GB2312-80所有的汉字及码位，并涵盖了原Unicode中所有的汉字20902，总共收录了883个符号， 21003个汉字及提供了1894个造字码位。 Microsoft简体版中文Windows 95就是以GBK为内码，又由于GBK同时也涵盖了Unicode所有CJK汉字，所以也可以和Unicode做一一对应。

P- Windows3.2和苹果OS就是以GB2312为*本汉字编码， Windows 95/98则以GBK为*本汉字编码、但兼容支持GB2312。

GBK编码是中国大陆制订的、等同于UCS的新的中文编码扩展国家标准。GBK工作小组于1995年10月，同年12月完成GBK规范。该编码标准兼容GB2312，共收录汉字21003个、符号883个，并提供1894个造字码位，简、繁体字融于一库。

总体编码范围为8140-FEFE之间，首字节在81-FE之间，尾字节在40-FE之间，剔除XX7F一条线。

GBK共收入21886个汉字和图形符号，包括：

* GB2312中的全部汉字、非汉字符号。

* BIG5中的全部汉字。

* 与ISO 10646相应的国家标准GB13000中的其它CJK汉字，以上合计20902个汉字。

* 其它汉字、部首、符号，共计984个。

GBK编码区分三部分：

汉字区　包括

GBK/2：OXBOA1-F7FE, 收录GB2312汉字6763个，按原序排列；

GBK/3：OX8140-AOFE，收录CJK汉字6080个；

GBK/4：OXAA40-FEAO，收录CJK汉字和增补的汉字8160个。

图形符号区　包括

GBK/1：OXA1A1-A9FE，除GB2312的符号外，还增补了其它符号

GBK/5：OXA840-A9AO，扩除非汉字区。

用户自定义区

即GBK区域中的空白区，用户可以自己定义字符。

GBK码对字库中偏移量的计算公式为：

[(GBKH-0xB0)*0x5E+(GBKL-0xA1)]*(汉字离散后每个汉字点阵所占用的字节)

4.3 GB18030

GB18030 是最新的汉字编码字符集国家标准, 向下兼容 GBK 和 GB2312 标准。 GB18030 编码是一二四字节变长编码。一字节部分从 0x0~0x7F 与 ASCII 编码兼容。二字节部分, 首字节从 0x81~0xFE, 尾字节从 0x40~0x7E 以及 0x80~0xFE, 与 GBK标准*本兼容。四字节部分, 第一字节从 0x81~0xFE, 第二字节从 0x30~0x39, 第三和第四字节的范围和前两个字节分别相同。四字节部分覆盖了从 0x0080 开始, 除去二字节部分已经覆盖的所有 Unicode 3.1 码位。也就是说, GB18030 编码在码位空间上做到了与 Unicode 标准一一对应,这一点与 UTF-8 编码类似。

4.4 Big 5

BIG5是通行于台湾、香港地区的一个繁体字编码方案。虽然存在一些瑕疵，但广泛应用于电脑行业，尤其是互联网中，从而成为一种事实上的行业标准。

1983年10月，台湾国家科学委员会、教育部国语推行委员会、中央标准局、行政院共同制定了《通用汉字标准交换码》，后经修订于1992年5月公布，更名为《中文标准交换码》，BIG5是台湾资讯工业策进会根据以上标准制定的编码方案。

BIG5码是双字节编码方案，其中第一个字节的值在OxAO-OxFE之间，第二个字节在Ox40-Ox7E和OxA1-OxFE之间。

BIG5收录13461个汉字和符号，包括：

* 符号408个，编码位置A140-A3BE

* 常用字5401个，编码位置A440-C67E，包括台湾教育部颁布的《常用国字标准字体表》的全部汉字4808个，台湾教科书常用字587个，异体字6个。

* 次常用字7652个，编码位置C940-F9D5,包括台湾教育部颁布的《次常用国字标准字体表》的全部汉字6341个，《罕用国字标准字体表》中使用频率较高的字1311个。

5 细节

在双字节编码中，GB内码的存储格式始终是big endian，即高位在前。
GB2312的两个字节的最高位都是1。但符合这个条件的码位只有128 * 128=16384个。所以GBK和GB18030的低字节最高位都可能不是1。不过这不影响 DBCS字符流的解析：在读取DBCS字符流时，只要遇到高位为1的字节，就可以将下两个字节作为一个双字节编码，而不用管低字节的高位是什么。
从ASCII、GB2312、GBK到GB18030的编码方法是向下兼容

6 BOM

所谓的BOM是指字节序标志（Byte Order Mark），是为了区分big还是little字节序的，在UCS 编码中有一个叫做"ZERO WIDTH NO-BREAK SPACE"的字符，它的编码是FFFE。而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编码了。