文字编码格式，我总也搞不懂

 

胡说九道 的 UTF8,Unicode 的区别(zt)
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
  用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
  4) 解码的原理一样。
  实例：(留意每个bit的颜色，粗体字为模板内容)
  UCS-4 UTF-8 
  HEX BIN Bytes BIN HEX Bytes 
  0000 000A 00001010 4 00001010 0A 1 
  0000 0099 10011001 4 11000010 10011001 C2 99 2 
  0000 8D99 10001101 10011001 4 11101000 10110110 10011001 E8 B6 99 3 
  不知大家看懂了没有，其实不懂也无所谓，反正又不用自己算，程式可以完全代劳。
  以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的都是些非常少用的文字符号。

Unicode（统一码、万国码、单一码）是一种在计算机上使用的字符编码。它为每种语言中的每个字符设定了统一并且唯一的二进制编码，以满足跨语言、跨平台进行文本转换、处理的要求。1990年开始研发，1994年正式公布。随着计算机工作能力的增强，Unicode也在面世以来的十多年里得到普及。
  Unicode 是基于通用字符集（Universal Character Set）的标准来发展，并且同时也以书本的形式（The Unicode Standard，目前第五版由Addison-Wesley Professional出版，ISBN-10: 0321480910）对外发表。
  2006年6月的最新版本的 Unicode 是 2005年3月31日推出的Unicode 4.1.0 。另外，5.0 Beta已于2005年12月12日推出，以供各会员评价。
[编辑本段]Unicode 的编码和实现
  大概来说，Unicode 编码系统可分为编码方式和实现方式两个层次。
  1.编码方式
  Unicode是国际组织制定的可以容纳世界上所有文字和符号的字符编码方案。Unicode用数字0-0x10FFFF来映射这些字符，最多可以容纳1114112个字符，或者说有1114112个码位。码位就是可以分配给字符的数字。UTF-8、UTF-16、UTF-32都是将数字转换到程序数据的编码方案。
  Unicode字符集可以简写为UCS（Unicode Character Set）。早期的Unicode标准有UCS-2、UCS-4的说法。UCS-2用两个字节编码，UCS-4用4个字节编码。UCS-4根据最高位为0的最高字节分成2^7=128个group。每个group再根据次高字节分为256个平面（plane）。每个平面根据第3个字节分为256行 （row），每行有256个码位（cell）。group 0的平面0被称作BMP（Basic Multilingual Plane）。将UCS-4的BMP去掉前面的两个零字节就得到了UCS-2。
  每个平面有2^16=65536个码位。Unicode计划使用了17个平面，一共有17*65536=1114112个码位。在Unicode 5.0.0版本中，已定义的码位只有238605个，分布在平面0、平面1、平面2、平面14、平面15、平面16。其中平面15和平面16上只是定义了两个各占65534个码位的专用区（Private Use Area），分别是0xF0000-0xFFFFD和0x100000-0x10FFFD。所谓专用区，就是保留给大家放自定义字符的区域，可以简写为PUA。
  平面0也有一个专用区：0xE000-0xF8FF，有6400个码位。平面0的0xD800-0xDFFF，共2048个码位，是一个被称作代理区（Surrogate）的特殊区域。代理区的目的用两个UTF-16字符表示BMP以外的字符。在介绍UTF-16编码时会介绍。
  如前所述在Unicode 5.0.0版本中，238605-65534*2-6400-2408=99089。余下的99089个已定义码位分布在平面0、平面1、平面2和平面14上，它们对应着Unicode目前定义的99089个字符，其中包括71226个汉字。平面0、平面1、平面2和平面14上分别定义了52080、3419、43253和337个字符。平面2的43253个字符都是汉字。平面0上定义了27973个汉字。
  2.实现方式
  在Unicode中：汉字“字”对应的数字是23383。在Unicode中，我们有很多方式将数字23383表示成程序中的数据，包括：UTF-8、UTF-16、UTF-32。UTF是“UCS Transformation Format”的缩写，可以翻译成Unicode字符集转换格式，即怎样将Unicode定义的数字转换成程序数据。例如，“汉字”对应的数字是0x6c49和0x5b57，而编码的程序数据是：
  BYTE data_utf8[] = {0xE6, 0xB1, 0x89, 0xE5, 0xAD, 0x97}; // UTF-8编码
  WORD data_utf16[] = {0x6c49, 0x5b57}; // UTF-16编码
  DWORD data_utf32[] = {0x6c49, 0x5b57}; // UTF-32编码
  这里用BYTE、WORD、DWORD分别表示无符号8位整数，无符号16位整数和无符号32位整数。UTF-8、UTF-16、UTF-32分别以BYTE、WORD、DWORD作为编码单位。“汉字”的UTF-8编码需要6个字节。“汉字”的UTF-16编码需要两个WORD，大小是4个字节。“汉字”的UTF-32编码需要两个DWORD，大小是8个字节。根据字节序的不同，UTF-16可以被实现为UTF-16LE或UTF-16BE，UTF-32可以被实现为UTF-32LE或UTF-32BE。下面介绍UTF-8、UTF-16、UTF-32、字节序和BOM。
  UTF-8
  UTF-8以字节为单位对Unicode进行编码。从Unicode到UTF-8的编码方式如下：
  Unicode编码(16进制) ║ UTF-8 字节流(二进制) 
  000000 - 00007F ║ 0xxxxxxx 
  000080 - 0007FF ║ 110xxxxx 10xxxxxx 
  000800 - 00FFFF ║ 1110xxxx 10xxxxxx 10xxxxxx 
  010000 - 10FFFF ║ 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx 
  UTF-8的特点是对不同范围的字符使用不同长度的编码。对于0x00-0x7F之间的字符，UTF-8编码与ASCII编码完全相同。UTF-8编码的最大长度是4个字节。从上表可以看出，4字节模板有21个x，即可以容纳21位二进制数字。Unicode的最大码位0x10FFFF也只有21位。
  例1：“汉”字的Unicode编码是0x6C49。0x6C49在0x0800-0xFFFF之间，使用用3字节模板了：1110xxxx 10xxxxxx 10xxxxxx。将0x6C49写成二进制是：0110 1100 0100 1001， 用这个比特流依次代替模板中的x，得到：11100110 10110001 10001001，即E6 B1 89。
  例2：Unicode编码0x20C30在0x010000-0x10FFFF之间，使用用4字节模板了：11110xxx 10xxxxxx 10xxxxxx 10xxxxxx。将0x20C30写成21位二进制数字（不足21位就在前面补0）：0 0010 0000 1100 0011 0000，用这个比特流依次代替模板中的x，得到：11110000 10100000 10110000 10110000，即F0 A0 B0 B0。
  UTF-16
  UTF-16编码以16位无符号整数为单位。我们把Unicode编码记作U。编码规则如下：
  如果U<0x10000，U的UTF-16编码就是U对应的16位无符号整数（为书写简便，下文将16位无符号整数记作WORD）。 
  如果U≥0x10000，我们先计算U'=U-0x10000，然后将U'写成二进制形式：yyyy yyyy yyxx xxxx xxxx，U的UTF-16编码（二进制）就是：110110yyyyyyyyyy 110111xxxxxxxxxx。 
  为什么U'可以被写成20个二进制位？Unicode的最大码位是0x10ffff，减去0x10000后，U'的最大值是0xfffff，所以肯定可以用20个二进制位表示。例如：Unicode编码0x20C30，减去0x10000后，得到0x10C30，写成二进制是：0001 0000 1100 0011 0000。用前10位依次替代模板中的y，用后10位依次替代模板中的x，就得到：1101100001000011 1101110000110000，即0xD843 0xDC30。
  按照上述规则，Unicode编码0x10000-0x10FFFF的UTF-16编码有两个WORD，第一个WORD的高6位是110110，第二个WORD的高6位是110111。可见，第一个WORD的取值范围（二进制）是11011000 00000000到11011011 11111111，即0xD800-0xDBFF。第二个WORD的取值范围（二进制）是11011100 00000000到11011111 11111111，即0xDC00-0xDFFF。
  为了将一个WORD的UTF-16编码与两个WORD的UTF-16编码区分开来，Unicode编码的设计者将0xD800-0xDFFF保留下来，并称为代理区（Surrogate）：
  D800－DB7F ║ High Surrogates ║ 高位替代 
  DB80－DBFF ║ High Private Use Surrogates ║ 高位专用替代 
  DC00－DFFF ║ Low Surrogates ║ 低位替代
  高位替代就是指这个范围的码位是两个WORD的UTF-16编码的第一个WORD。低位替代就是指这个范围的码位是两个WORD的UTF-16编码的第二个WORD。那么，高位专用替代是什么意思？我们来解答这个问题，顺便看看怎么由UTF-16编码推导Unicode编码。 
  如果一个字符的UTF-16编码的第一个WORD在0xDB80到0xDBFF之间，那么它的Unicode编码在什么范围内？我们知道第二个WORD的取值范围是0xDC00-0xDFFF，所以这个字符的UTF-16编码范围应该是0xDB80 0xDC00到0xDBFF 0xDFFF。我们将这个范围写成二进制：
  1101101110000000 11011100 00000000 - 1101101111111111 1101111111111111
  按照编码的相反步骤，取出高低WORD的后10位，并拼在一起，得到
  1110 0000 0000 0000 0000 - 1111 1111 1111 1111 1111
  即0xe0000-0xfffff，按照编码的相反步骤再加上0x10000，得到0xf0000-0x10ffff。这就是UTF-16编码的第一个WORD在0xdb80到0xdbff之间的Unicode编码范围，即平面15和平面16。因为Unicode标准将平面15和平面16都作为专用区，所以0xDB80到0xDBFF之间的保留码位被称作高位专用替代。
  UTF-32
  UTF-32编码以32位无符号整数为单位。Unicode的UTF-32编码就是其对应的32位无符号整数。
  字节序
  根据字节序的不同，UTF-16可以被实现为UTF-16LE或UTF-16BE，UTF-32可以被实现为UTF-32LE或UTF-32BE。例如：
  Unicode编码 ║ UTF-16LE ║ UTF-16BE ║ UTF32-LE ║ UTF32-BE 
  0x006C49 ║ 49 6C ║ 6C 49 ║ 49 6C 00 00 ║ 00 00 6C 49 
  0x020C30 ║ 43 D8 30 DC ║ D8 43 DC 30 ║ 30 0C 02 00 ║ 00 02 0C 30 
  那么，怎么判断字节流的字节序呢？Unicode标准建议用BOM（Byte Order Mark）来区分字节序，即在传输字节流前，先传输被作为BOM的字符"零宽无中断空格"。这个字符的编码是FEFF，而反过来的FFFE（UTF-16）和FFFE0000（UTF-32）在Unicode中都是未定义的码位，不应该出现在实际传输中。下表是各种UTF编码的BOM：
  UTF编码 ║ Byte Order Mark 
  UTF-8 ║ EF BB BF 
  UTF-16LE ║ FF FE 
  UTF-16BE ║ FE FF 
  UTF-32LE ║ FF FE 00 00 
  UTF-32BE ║ 00 00 FE FF
[编辑本段]非 Unicode 环境
  
  在非 Unicode 环境下，由于不同国家和地区采用的字符集不一致，很可能出现无法正常显示所有字符的情况。微软公司使用了代码页（Codepage）转换表的技术来过渡性的部分解决这一问题，即通过指定的转换表将非 Unicode 的字符编码转换为同一字符对应的系统内部使用的 Unicode 编码。可以在“语言与区域设置”中选择一个代码页作为非 Unicode 编码所采用的默认编码方式，如936为简体中文GBK，950为正体中文Big5（皆指PC上使用的）。在这种情况下，一些非英语的欧洲语言编写的软件和文档很可能出现乱码。而将代码页设置为相应语言中文处理又会出现问题，这一情况无法避免。从根本上说，完全采用统一编码才是解决之道，但目前上无法做到这一点。
  代码页技术现在广泛为各种平台所采用。UTF-7 的代码页是65000，UTF-8 的代码页是65001。
[编辑本段]XML 和 Unicode
  XML及其子集HTML采用UTF-8作为标准字集，理论上我们可以在各种支持XML标准的浏览器上显示任何地区文字的网页，只要电脑本身安装有合适的字体即可。可以利用&#nnn;的格式显示特定的字符。nnn代表该字符的十进制 Unicode 代码。如果采用十六进制代码，在编码之前加上x字符即可。但部分旧版本的浏览器可能无法识别十六进制代码。
  然而部分由于 Unicode 版本发展原因，很多浏览器只能显示 UCS-2 完整字符集也即现在使用的 Unicode 版本中的一个小子集。下表可以检验您的浏览器怎样显示各种各样的 Unicode 代码：
  代码 字符标准名称 (英语) 在浏览器上的显示 
  A&#大写拉丁字母"A" A 
  &#szlig; 小写拉丁字母"Sharp S" ? 
  &#thorn; 小写拉丁字母"Thorn" ? 
  Δ大写希腊字母"Delta" Δ 
  Й 大写斯拉夫字母"Short I" Й 
  ?希伯来字母"Qof" ? 
  ?阿拉伯字母 "Meem" ? 
  ?泰文数字 7 ? 
  ?埃塞俄比亚音节文字"Qha" ? 
  あ日语平假名 "A" あ 
  ア日语片假名 "A" ア 
  叶简体汉字 "叶" 叶 
  叶 繁体汉字 "叶" 叶 
  ?韩国音节文字 " Yeob" ?
[编辑本段]输入Unicode
  除了输入法外，操作系统会提供几种方法输入Unicode。像是Windows 2000之后的Windows系统就提供一个可点击的表。例如在Microsoft Word或者金山WPS之下，按下 Alt 键不放，输入 0 和某个字符的 Unicode 编码（十进制），再松开 Alt 键即可得到该字符，如Alt + 033865会得到Unicode字符“叶”（繁体）。另外按Alt + X 组合键，MS Word 也会将光标前面的字符同其十六进制的四位 Unicode 编码进行互相转换。
  Unicode 编码表反弹
  0000-0FFF 8000-8FFF 10000-10FFF 20000-20FFF 28000-28FFF 
  1000-1FFF 9000-9FFF 21000-21FFF 29000-29FFF 
  2000-2FFF A000-AFFF 22000-22FFF 2A000-2AFFF 
  3000-3FFF B000-BFFF 23000-23FFF 
  4000-4FFF C000-CFFF 1D000-1DFFF 24000-24FFF 2F000-2FFFF 
  5000-5FFF D000-DFFF 25000-25FFF 
  6000-6FFF E000-EFFF 26000-26FFF 
  7000-7FFF F000-FFFF 27000-27FFF E0000-E0FFF
  Unicode 目前已经有5.0版本。世界上有一大批计算机、语言学等科学家专门研究Unicode，到了现在Unicode标准已经不单是一个编码标准，还是记录人类语言文字资料的一个巨大的数据库，同时从事人类文化遗产的发掘和保护工作。
  对于中文而言，Unicode 16编码里面已经包含了GB18030里面的所有汉字（27484个字），目前Unicode标准准备把康熙字典的所有汉字放入到Unicode 32bit编码中。
  简单地说，Unicode扩展自ASCII字元集。在严格的ASCII中，每个字元用7位元表示，或者电脑上普遍使用的每字元有8位元宽；而Unicode使用全16位元字元集。这使得Unicode能够表示世界上所有的书写语言中可能用於电脑通讯的字元、象形文字和其他符号。Unicode最初打算作为ASCII的补充，可能的话，最终将代替它。考虑到ASCII是电脑中最具支配地位的标准，所以这的确是一个很高的目标。
  Unicode影响到了电脑工业的每个部分，但也许会对作业系统和程序设计语言的影响最大。从这方面来看，我们已经上路了。Windows NT从底层支持Unicode（不幸的是，Windows 98只是小部分支援Unicode）。先天即被ANSI束缚的C程序设计语言通过对宽字元集的支持来支持Unicode。
[编辑本段]为什么使用Unicode？
  基本上，计算机只是处理数字。它们指定一个数字，来储存字母或其他字符。在创造Unicode之前，有数百种指定这些数字的编码系统。没有一个编码可以包含足够的字符：例如，单单欧州共同体就[1][2]需要好几种不同的编码来包括所有的语言。即使是单一种语言，例如英语，也没有哪一个编码可以适用于所有的字母，标点符号，和常用的技术符号。这些编码系统也会互相冲突。也就是说，两种编码可能使用相同的数字代表两个不同的字符，或使用不同的数字代表相同的字符。任何一台特定的计算机（特别是服务器）都需要支持许多不同的编码，但是，不论什么时候数据通过不同的编码或平台之间，那些数据总会有损坏的危险。 

GBK: 汉字国标扩展码,基本上采用了原来GB2312-80所有的汉字及码位，并涵盖了原Unicode中所有的汉字20902，总共收录了883个符号， 21003个汉字及提供了1894个造字码位。 Microsoft简体版中文Windows 95就是以GBK为内码，又由于GBK同时也涵盖了Unicode所有CJK汉字，所以也可以和Unicode做一一对应。
  GB码，全称是GB2312-80《信息交换用汉字编码字符集 基本集》，1980年发布，是中文信息处理的国家标准，在大陆及海外使用简体中文的地区（如新加坡等）是强制使用的唯一中文编码。P-Windows3.2和苹果OS就是以GB2312为基本汉字编码， Windows 95/98则以GBK为基本汉字编码、但兼容支持GB2312。GB码共收录6763个简体汉字、682个符号，其中汉字部分：一级字3755，以拼音排序，二级字3008，以偏旁排序。该标准的制定和应用为规范、推动中文信息化进程起了很大作用。
  GBK编码是中国大陆制订的、等同于UCS的新的中文编码扩展国家标准。GBK工作小组于1995年10月，同年12月完成GBK规范。该编码标准兼容GB2312，共收录汉字21003个、符号883个，并提供1894个造字码位，简、繁体字融于一库。
  GBK码对字库中偏移量的计算公式为：
  [(GBKH-0xB0)*0x5E+(GBKL-0xA1)]*(汉字离散后每个汉字点阵所占用的字节)

由http://www.cppblog.com/AutomateProgram/archive/2010/03/26/110567.html收藏，比较好。


unicode、utf-8、ansi的故事


原文地址：http://blog.csdn.net/iscandy/archive/2009/02/02/3859219.aspx
很久很久以前，有一群人，他们决定用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的方式解读之，这时乱码又不出现了。


相互转换：
原文地址:http://club.topsage.com/thread-670150-1-1.html
Ansi、Unicode、UTF-8字符串之间的转换和写入文本文件


Ansi字符串我们最熟悉，英文占一个字节，汉字2个字节，以一个\0结尾，常用于txt文本文件
Unicode字符串，每个字符(汉字、英文字母)都占2个字节，以2个连续的\0结尾，NT操作系统内核用的是这种字符串，常被定义为typedef unsigned short wchar_t;所以我们有时常会见到什么char*无法转换为unsigned short*之类的错误，其实就是unicode
UTF8 是 Unicode一种压缩形式，英文A在unicode中表示为0x0041，老外觉得这种存储方式太浪费，因为浪费了50%的空间，于是就把英文压缩成1 个字节，成了utf8编码，但是汉字在utf8中占3个字节，显然用做中文不如ansi合算，这就是中国的网页用作ansi编码而老外的网页常用utf8 的原因。
UTF8在还游戏里运用的很广泛，比如WOW的lua脚本等


下面来说一下转换，主要用代码来说明吧


写文件我用了CFile类，其实用FILE*之类的也是一样，写文件和字符串什么类别没有关系，硬件只关心数据和长度


Ansi转Unicode


介绍2种方法


   1. void CConvertDlg::OnBnClickedButtonAnsiToUnicode()
   2. {
   3.     // ansi to unicode
   4.     char* szAnsi = "abcd1234你我他";
   5.     //预转换，得到所需空间的大小
   6.     int wcsLen = ::MultiByteToWideChar(CP_ACP, NULL, szAnsi, strlen(szAnsi), NULL, 0);
   7.     //分配空间要给'\0'留个空间，MultiByteToWideChar不会给'\0'空间
   8.     wchar_t* wszString = new wchar_t[wcsLen + 1];
   9.     //转换
  10.     ::MultiByteToWideChar(CP_ACP, NULL, szAnsi, strlen(szAnsi), wszString, wcsLen);
  11.     //最后加上'\0'
  12.     wszString[wcsLen] = '\0';
  13.     //unicode版的MessageBox API
  14.     ::MessageBoxW(GetSafeHwnd(), wszString, wszString, MB_OK);
  15.


  16.     //接下来写入文本
  17.     //写文本文件，头2个字节0xfeff，低位0xff写在前
  18.     CFile cFile;
  19.     cFile.Open(_T("1.txt"), CFile::modeWrite | CFile::modeCreate);
  20.     //文件开头
  21.     cFile.SeekToBegin();
  22.     cFile.Write("\xff\xfe", 2);
  23.     //写入内容
  24.     cFile.Write(wszString, wcsLen * sizeof(wchar_t));
  25.     cFile.Flush();
  26.     cFile.Close();
  27.     delete[] wszString;
  28.     wszString =NULL;
  29.


  30.




  31.     //方法2
  32.     //设置当前地域信息，不设置的话，使用这种方法，中文不会正确显示
  33.     //需要#include<locale.h>
  34.     setlocale(LC_CTYPE, "chs");
  35.     wchar_t wcsStr[100];
  36.     //注意下面是大写S，在unicode中，代表后面是ansi字符串
  37.     //swprintf是sprintf的unicode版本
  38.     //格式的前面要加大写L，代表是unicode
  39.     swprintf(wcsStr, L"%S", szAnsi);
  40.     ::MessageBoxW(GetSafeHwnd(), wcsStr, wcsStr, MB_OK);
  41.


  42. }


复制代码


Unicode转Ansi
也是2种方法


   1. void CConvertDlg::OnBnClickedButtonUnicodeToAnsi()
   2. {
   3.     // unicode to ansi
   4.     wchar_t* wszString = L"abcd1234你我他";
   5.     //预转换，得到所需空间的大小，这次用的函数和上面名字相反
   6.     int ansiLen = ::WideCharToMultiByte(CP_ACP, NULL, wszString, wcslen(wszString), NULL, 0, NULL, NULL);
   7.     //同上，分配空间要给'\0'留个空间
   8.     char* szAnsi = new char[ansiLen + 1];
   9.     //转换
  10.     //unicode版对应的strlen是wcslen
  11.     ::WideCharToMultiByte(CP_ACP, NULL, wszString, wcslen(wszString), szAnsi, ansiLen, NULL, NULL);
  12.     //最后加上'\0'
  13.     szAnsi[ansiLen] = '\0';
  14.     //Ansi版的MessageBox API
  15.     ::MessageBoxA(GetSafeHwnd(), szAnsi, szAnsi, MB_OK);
  16.


  17.     //接下来写入文本
  18.     //写文本文件，ANSI文件没有BOM
  19.     CFile cFile;
  20.     cFile.Open(_T("1.txt"), CFile::modeWrite | CFile::modeCreate);
  21.     //文件开头
  22.     cFile.SeekToBegin();
  23.     //写入内容
  24.     cFile.Write(szAnsi, ansiLen * sizeof(char));
  25.     cFile.Flush();
  26.     cFile.Close();
  27.     delete[] szAnsi;
  28.     szAnsi =NULL;
  29.


  30.




  31.     //方法2
  32.     //和上面一样有另一种方法
  33.     setlocale(LC_CTYPE, "chs");
  34.     char szStr[100];
  35.     //注意下面是大写，在ansi中，代表后面是unicode字符串
  36.     //sprintf
  37.     sprintf(szStr, "%S", wszString);
  38.     ::MessageBoxA(GetSafeHwnd(), szStr, szStr, MB_OK);
  39. }


复制代码


Unicode转UTF8


   1. void CConvertDlg::OnBnClickedButtonUnicodeToU8()
   2. {
   3.     // unicode to UTF8
   4.     wchar_t* wszString = L"abcd1234你我他";
   5.     //预转换，得到所需空间的大小，这次用的函数和上面名字相反
   6.     int u8Len = ::WideCharToMultiByte(CP_UTF8, NULL, wszString, wcslen(wszString), NULL, 0, NULL, NULL);
   7.     //同上，分配空间要给'\0'留个空间
   8.     //UTF8虽然是Unicode的压缩形式，但也是多字节字符串，所以可以以char的形式保存
   9.     char* szU8 = new char[u8Len + 1];
  10.     //转换
  11.     //unicode版对应的strlen是wcslen
  12.     ::WideCharToMultiByte(CP_UTF8, NULL, wszString, wcslen(wszString), szU8, u8Len, NULL, NULL);
  13.     //最后加上'\0'
  14.     szU8[u8Len] = '\0';
  15.     //MessageBox不支持UTF8,所以只能写文件
  16.


  17.     //接下来写入文本
  18.     //写文本文件，UTF8的BOM是0xbfbbef
  19.     CFile cFile;
  20.     cFile.Open(_T("1.txt"), CFile::modeWrite | CFile::modeCreate);
  21.     //文件开头
  22.     cFile.SeekToBegin();
  23.     //写BOM，同样低位写在前
  24.     cFile.Write("\xef\xbb\xbf", 3);
  25.     //写入内容
  26.     cFile.Write(szU8, u8Len * sizeof(char));
  27.     cFile.Flush();
  28.     cFile.Close();
  29.     delete[] szU8;
  30.     szU8 =NULL;
  31.


  32. }


复制代码


UTF8转UNICODE


   1. void CConvertDlg::OnBnClickedButtonU8ToUnicode()
   2. {
   3.     //UTF8 to Unicode
   4.     //由于中文直接复制过来会成乱码，编译器有时会报错，故采用16进制形式
   5.     char* szU8 = "abcd1234\xe4\xbd\xa0\xe6\x88\x91\xe4\xbb\x96\x00";
   6.     //预转换，得到所需空间的大小
   7.     int wcsLen = ::MultiByteToWideChar(CP_UTF8, NULL, szU8, strlen(szU8), NULL, 0);
   8.     //分配空间要给'\0'留个空间，MultiByteToWideChar不会给'\0'空间
   9.     wchar_t* wszString = new wchar_t[wcsLen + 1];
  10.     //转换
  11.     ::MultiByteToWideChar(CP_UTF8, NULL, szU8, strlen(szU8), wszString, wcsLen);
  12.     //最后加上'\0'
  13.     wszString[wcsLen] = '\0';
  14.     //unicode版的MessageBox API
  15.     ::MessageBoxW(GetSafeHwnd(), wszString, wszString, MB_OK);
  16.


  17.     //写文本同ansi to unicode
  18. }


复制代码


Ansi转换utf8和utf8转换Ansi就是上面2个的结合，把unicode作为中间量，进行2次转换即可

有点看不懂，以后慢慢看吧。