因此QASCII~码可以表示的最大字W数?56Q其实英文字Wƈ没有那么多，一般只用前128个（最高位?Q，其中包括了控制字W、数字、大写字母和其他一些符?
?br />
而最高位?的另128个字W被成ؓ“扩展ASCII”Q一般用来存放英文的制表W、部分音标字W等{的一些其他符Pq种字符~码规范昄用来处理英文没有什么问题。（实际上也可以用来处理法文、d文等一些其他的西欧字符Q但是不能和英文通用Q，但是面对中文、阿拉伯文之cd杂的文字Q?55个字W显然不够用
于是Q各个国家纷U制定了自己的文字编码规范，其中中文的文字编码规范叫?#8220;GB2312-80”Q它是和ASCII兼容的一U编码规范，其实是利用扩展ASCII没有真正标准化这一点，把一个中文字W用两个扩展ASCII字符来表C?
但是q个Ҏ(gu)有问题，最大的问题是Q中文文字没有真正属于自q~码Q因为扩展ASCII码虽然没有真正的标准化，但是PC里的ASCII码还是有一个事实标准的Q存攄英文制表W）Q所以很多Y件利用这些符h画表根{这L软g用到中文pȝ中，q些表格W就会被误认作中文字Q破坏版面。而且Q统计中英文混合字符串中的字敎ͼ也是比较复杂的，我们必须判断一个ASCII码是否扩展，以及它的下一个ASCII是否扩展Q然后才“?#8221;那可能是一个中文字
?br />
M当时处理中文是很痛苦的。而更痛苦的是GB2312是国家标准，台湾当时有一个Big5~码标准Q很多编码和GB是相同的Q所?#8230;…Q嘿ѝ?
q时候，我们q道，要真正解决中文问题，不能从扩展ASCII的角度入手，也不能仅靠中国一家来解决。而必L一个全新的~码pȝQ这个系l要可以中文、英文、法文、d?#8230;…{等所有的文字l一h考虑Qؓ每个文字都分配一个单独的~码Q这h不会有上面那U现象出现?
于是QUnicode诞生了?
Unicode有两套标准，一套叫UCS-2(Unicode-16)Q用2个字节ؓ字符~码Q另一套叫UCS-4(Unicode-32)Q用4个字节ؓ字符~码?
以目前常用的UCS-2ZQ它可以表示的字W数?^16=65535Q基本上可以容纳所有的Ƨ美字符和绝大部分的亚洲字符
?br />
UTF-8的问题后面会提到 ?br />
在Unicode里，所有的字符被一视同仁。汉字不再?#8220;两个扩展ASCII”Q而是使用“1个Unicode”Q注意，现在的汉字是“一个字W?#8221;了，于是Q拆字、统计字数这些问题也p然而然的解决了
?br />
但是Q这个世界不是理想的Q不可能在一夜之间所有的pȝ都用Unicode来处理字W，所以Unicode在诞生之日，必考虑一个严ȝ问题Q和ASCII字符集之间的不兼定w题?
我们知道QASCII字符是单个字节的Q比?#8220;A”的ASCII?5。而Unicode是双字节的，比如“A”的Unicode?065Q这造成了一个非常大的问题：以前处理ASCII的那套机制不能被用来处理Unicode?
?br />
另一个更加严重的问题是，C语言使用'\0'作ؓ字符串结，而Unicode里恰恰有很多字符都有一个字节ؓ0Q这样一来，C语言的字W串函数无法正常处理UnicodeQ除非把世界上所有用C写的E序以及他们所用的函数库全部换?
?br />
于是Q比Unicode更伟大的东东诞生了，之所以说它更伟大是因为它让Unicode不再存在于纸上，而是真实的存在于我们大家的电(sh)脑中。那是QUTF?br />
UTF= UCS Transformation Format UCS转换格式Q它是将Unicode~码规则和计机的实际编码对应v来的一个规则。现在流行的UTF?U：UTF-8和UTF-16
?br />
其中UTF-16和上面提到的Unicode本n的编码规范是一致的Q这里不多说了。而UTF-8不同Q它定义了一U?#8220;区间规则”Q这U规则可以和ASCII~码保持最大程度的兼容
?br />
UTF-8有点cM于Haffman~码Q它?yu)Unicode~码?0000000-0000007F的字W，用单个字节来表示Q?
00000080-000007FF的字W用两个字节表示
00000800-0000FFFF的字W用3字节表示
因ؓ目前为止Unicode-16规范没有指定FFFF以上的字W，所以UTF-8最多是使用3个字节来表示一个字W。但理论上来_UTF-8最多需要用6字节表示一个字W?
在UTF-8里，英文字符仍然跟ASCII~码一P因此原先的函数库可以l箋使用。而中文的~码范围是在0080-07FF之间Q因此是2个字节表C（但这两个字节和GB~码的两个字节是不同的）Q用专门的Unicode处理cd以对UTF~码q行处理?
下面说说中文的问题?
׃历史的原因，在Unicode之前Q一共存在过3套中文编码标准?
GB2312-80Q是中国大陆使用的国家标准，其中一q码了6763个常用简体汉字。Big5Q是台湾使用的编码标准，~码了台湾用的J体汉字Q大概有8千多个。HKSCSQ是中国香港使用的编码标准，字体也是J体Q但跟Big5有所不同?
q?套编码标准都采用了两个扩展ASCII的方法，因此Q几套编码互不兼容，而且~码区间也各有不?
因ؓ其不兼容性，在同一个系l中同时昄GB和Big5基本上是不可能的。当时的南极星、RichWin{等软gQ在自动识别中文~码、自动显C正编码方面都做了很多努力?br />
他们用了怎样的技术我׃得而知了，我知道好像南极星曄以同屏显C繁中文为卖炏V?
后来Q由于各斚w的原因，国际上又制定了针对中文的l一字符集GBK和GB18030Q其中GBK已经在Windows、Linux{多U操作系l中被实现?
GBK兼容GB2312Qƈ增加了大量不常用汉字Q还加入了几乎所有的Big5中的J体汉字。但是GBK中的J体汉字和Big5中的几乎不兼宏V?
GB18030相当于是GBK的超集，比GBK包含的字W更多。据我所知目前还没有操作pȝ直接支持GB18030?
谈谈Unicode~码Q简要解释UCS、UTF、BMP、BOM{名?br /> q是一程序员写给E序员的味ȝ。所谓趣x指可以比较轻村֜了解一些原来不清楚的概念，增进知识Q类g打RPG游戏的升U。整理这文章的动机是两个问题：
问题一Q?br /> 使用WindowsC本的“另存?#8221;Q可以在GBK、Unicode、Unicode big
endian和UTF-8q几U编码方式间怺转换。同htxt文gQWindows是怎样识别~码方式的呢Q?br />
我很早前发现Unicode、Unicode big endian和UTF-8~码的txt文g的开头会多出几个字节Q分别是FF、FEQUnicodeQ?FE、FFQUnicode big endianQ?EF、BB、BFQUTF-8Q。但q些标记是基于什么标准呢Q?br />
问题二：
最q在|上看到一个ConvertUTF.cQ实CUTF-32、UTF-16和UTF-8q三U编码方式的怺转换。对于Unicode(UCS2)、GBK、UTF-8q些~码方式Q我原来׃解。但q个E序让我有些p涂Q想不v来UTF-16和UCS2有什么关pR?br /> 查了查相兌料，ȝ这些问题弄清楚了，带也了解了一些Unicode的细节。写成一文章，送给有过cM疑问的朋友。本文在写作时尽量做到通俗易懂Q但要求读者知道什么是字节Q什么是十六q制?br />
0、big endian和little endian
big endian和little
endian是CPU处理多字节数的不同方式。例?#8220;?#8221;字的Unicode~码?C49。那么写到文仉ӞI竟是将6C写在前面Q还是将49写在前面Q如果将6C写在前面Q就是big endian。还是将49写在前面Q就是little endian?br />
“endian”q个词出自《格列佛(jng)游记》。小人国的内战就源于吃鸡蛋时是究竟从大头(Big-Endian)敲开q是从小?Little-Endian)敲开Q由此曾发生q六ơ叛乱，其中一个皇帝送了命，另一个丢了王位?br />
我们一般将endian译?#8220;字节?#8221;Q将big endian和little endianUC“大尾”?#8220;尾”?br />
1、字W编码、内码，带介绍汉字~码
字符必须~码后才能被计算机处理。计机使用的缺省编码方式就是计机的内码。早期的计算Z?位的ASCII~码Qؓ了处理汉字，E序员设计了用于体中文的GB2312和用于繁体中文的big5?br />
GB2312(1980q?一共收录了7445个字W，包括6763个汉字和682个其它符受汉字区的内码范围高字节从B0-F7Q低字节从A1-FEQ占用的码位?2*94=6768。其中有5个空位是D7FA-D7FE?br />
GB2312支持的汉字太?995q的汉字扩展规范GBK1.0收录?1886个符P它分为汉字区和图形符号区。汉字区包括21003个字W?000q的GB18030是取代GBK1.0的正式国家标准。该标准收录?7484个汉字，同时q收录了藏文、蒙文、维向ְ文等主要的少数民族文字。现在的PCq_必须支持GB18030Q对嵌入式品暂不作要求。所以手机、MP3一般只支持GB2312?br />
从ASCII、GB2312、GBK到GB18030Q这些编码方法是向下兼容的，卛_一个字W在q些Ҏ(gu)中L有相同的~码Q后面的标准支持更多的字W。在q些~码中，英文和中文可以统一地处理。区分中文编码的Ҏ(gu)是高字节的最高位不ؓ0。按照程序员的称|GB2312、GBK到GB18030都属于双字节字符?
(DBCS)?br />
有的中文Windows的缺省内码还是GBKQ可以通过GB18030升包升U到GB18030。不qGB18030相对GBK增加的字W，普通h是很隄到的Q通常我们q是用GBK指代中文Windows内码?br />
q里q有一些细节：
GB2312的原文还是区位码Q从Z码到内码Q需要在高字节和低字节上分别加上A0?br />
在DBCS中，GB内码的存储格式始l是big endianQ即高位在前?br />
GB2312的两个字节的最高位都是1。但W合q个条g的码位只?28*128=16384个。所以GBK和GB18030的低字节最高位都可能不?。不q这不媄响DBCS字符的解析Q在dDBCS字符时Q只要遇到高位ؓ1的字节，可以将下两个字节作Z个双字节~码Q而不用管低字节的高位是什么?br />
2、Unicode、UCS和UTF
前面提到从ASCII、GB2312、GBK到GB18030的编码方法是向下兼容的。而Unicode只与ASCII兼容Q更准确地说Q是与ISO-8859-1兼容Q，与GB码不兼容。例?#8220;?#8221;字的Unicode~码?C49Q而GB码是BABA?br />
Unicode也是一U字W编码方法，不过它是由国际组l设计，可以容纳全世界所有语a文字的编码方案。Unicode的学?Universal
Multiple-Octet Coded Character Set"Q简UCؓUCS。UCS可以看作?Unicode Character Set"的羃写?br />
Ҏ(gu)l基癄全书(http://zh.wikipedia.org/wiki/)的记载：历史上存在两个试囄立设计Unicode的组l，卛_际标准化l织QISOQ和一个Y件制造商的协会（unicode.orgQ。ISO开发了ISO
10646目QUnicode协会开发了Unicode目?br />
?991q前后，双方都认识到世界不需要两个不兼容的字W集。于是它们开始合q双方的工作成果Qƈ为创立一个单一~码表而协同工作。从Unicode2.0开始，Unicode目采用了与ISO
10646-1相同的字库和字码?br />
目前两个目仍都存在Qƈ独立地公布各自的标准。Unicode协会现在的最新版本是2005q的Unicode
4.1.0。ISO的最新标准是10646-3:2003?br />
UCS规定了怎么用多个字节表C各U文字。怎样传输q些~码Q是由UTF(UCS Transformation Format)规范规定的，常见的UTF规范包括UTF-8、UTF-7、UTF-16?br />
IETF的RFC2781和RFC3629以RFC的一贯风|清晰、明快又不失严}地描qCUTF-16和UTF-8的编码方法。我LC得IETF是Internet Engineering Task Force的羃写。但IETF负责l护的RFC是Internet上一切规范的基础?br />
3、UCS-2、UCS-4、BMP
UCS有两U格式：UCS-2和UCS-4。顾名思义QUCS-2是用两个字节编码，UCS-4是?个字节（实际上只用了31位，最高位必须?Q编码。下面让我们做一些简单的数学游戏Q?br />
UCS-2?^16=65536个码位，UCS-4?^31=2147483648个码位?br />
UCS-4Ҏ(gu)最高位?的最高字节分?^7=128个group。每个group再根据次高字节分?56个plane。每个planeҎ(gu)W?个字节分?56?(rows)Q每行包?56个cells。当然同一行的cells只是最后一个字节不同，其余都相同?br />
group 0的plane 0被称作Basic Multilingual Plane, 即BMP。或者说UCS-4中，高两个字节ؓ0的码位被UCBMP?br /> UCS-4的BMPL前面的两个零字节得CUCS-2。在UCS-2的两个字节前加上两个零字节，得CUCS-4的BMP。而目前的UCS-4规范中还没有M字符被分配在BMP之外?br />
4、UTF~码
UTF-8是?位ؓ单元对UCSq行~码。从UCS-2到UTF-8的编码方式如下：
UCS-2~码(16q制) UTF-8 字节?二进?
0000 - 007F 0xxxxxxx
0080 - 07FF 110xxxxx 10xxxxxx
0800 - FFFF 1110xxxx 10xxxxxx 10xxxxxx
例如“?#8221;字的Unicode~码?C49?C49?800-FFFF之间Q所以肯定要?字节模板了：1110xxxx 10xxxxxx 10xxxxxx。将6C49写成二进制是Q?110 110001 001001Q?用这个比Ҏ(gu)依次代替模板中的xQ得刎ͼ11100110 10110001 10001001Q即E6 B1 89?br />
读者可以用C本测试一下我们的~码是否正确?br />
UTF-16?6位ؓ单元对UCSq行~码。对于小?x10000的UCS码，UTF-16~码q于UCS码对应的16位无W号整数。对于不于0x10000的UCS码，定义了一个算法。不q由于实际用的UCS2Q或者UCS4的BMP必然于0x10000Q所以就目前而言Q可以认为UTF-16和UCS-2基本相同。但UCS-2只是一个编码方案，UTF-16却要用于实际的传输，所以就不得不考虑字节序的问题?br />
5、UTF的字节序和BOM
UTF-8以字节ؓ~码单元Q没有字节序的问题。UTF-16以两个字节ؓ~码单元Q在解释一个UTF-16文本前，首先要弄清楚每个~码单元的字节序。例如收C?#8220;?#8221;的Unicode~码?94EQ?#8220;?#8221;的Unicode~码?E59。如果我们收到UTF-16字节?#8220;594E”Q那么这?#8220;?#8221;q是“?#8221;Q?br />
Unicode规范中推荐的标记字节序的方法是BOM。BOM不是“Bill Of Material”的BOM表，而是Byte Order Mark。BOM是一个有点小聪明的想法：
在UCS~码中有一个叫?ZERO WIDTH NO-BREAK
SPACE"的字W，它的~码是FEFF。而FFFE在UCS中是不存在的字符Q所以不应该出现在实际传输中。UCS规范我们在传输字节流前，先传输字W?ZERO
WIDTH NO-BREAK SPACE"?br />
q样如果接收者收到FEFFQ就表明q个字节是Big-Endian的；如果收到FFFEQ就表明q个字节是Little-Endian的。因此字W?ZERO WIDTH NO-BREAK SPACE"又被UCBOM?br />
UTF-8不需要BOM来表明字节顺序，但可以用BOM来表明编码方式。字W?ZERO WIDTH NO-BREAK SPACE"的UTF-8~码是EF BB BFQ读者可以用我们前面介绍的编码方法验证一下）。所以如果接收者收CEF BB
BF开头的字节，q道这是UTF-8~码了?br />
Windows是使用BOM来标记文本文件的~码方式的?br />
6、进一步的参考资?br /> 本文主要参考的资料?"Short overview of ISO-IEC 10646 and Unicode"
(http://www.nada.kth.se/i18n/ucs/unicode-iso10646-oview.html)?br />
我还找了两篇看上M错的资料Q不q因为我开始的疑问都找C{案Q所以就没有看：
"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)
]]>