文件编码格式

从文件编码的方式来看，文件可分为ASCII码文件和二进制码文件两种。

ASCII文件也称为文本文件，这种文件在磁盘中存放时每个字符对应一个字节，用于存放对应的ASCII码。例如，数5678的存储形式为：
ASC码： 　00110101 00110110 00110111 00111000
　　　　　↓ 　　　　↓　　　　↓ 　　　↓
十进制码： 5　　　　　6　　　　7　　　　8 共占用4个字节。ASCII码文件可在屏幕上按字符显示， 例如源程序文件就是ASCII文件，用DOS命令TYPE可显示文件的内容。 由于是按字符显示，因此能读懂文件内容。

二进制文件是按二进制的编码方式来存放文件的。 例如， 数5678的存储形式为： 00010110 00101110只占二个字节。二进制文件虽然也可在屏幕上显示，但其内容无法读懂。C系统在处理这些文件时，并不区分类型，都看成是字符流，按字节进行处理。输入输出字符流的开始和结束只由程序控制而不受物理符号(如回车符)的控制。 因此也把这种文件称作“流式文件”。

UCS-2编码(16进制)	UTF-8 字节流(二进制)
0000 - 007F	0xxxxxxx
0080 - 07FF	110xxxxx 10xxxxxx
0800 - FFFF	1110xxxx 10xxxxxx 10xxxxxx

问题一：

使用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的编码方式如下：

例如“汉”字的Unicode编码是6C49。6C49在0800-FFFF之间，所以肯定要用3字节模板了：1110xxxx10xxxxxx10xxxxxx。将6C49写成二进制是：0110 110001 001001， 用这个比特流依次代替模板中的x，得到：111001101011000110001001，即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)。

我还找了两篇看上去不错的资料，不过因为我开始的疑问都找到了答案，所以就没有看：

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://fmddlmyy.home4u.china.com)。

我是想清楚所有问题后才开始写这篇文章的，原以为一会儿就能写好。没想到考虑措辞和查证细节花费了很长时间，竟然从下午1:30写到9:00。希望有读者能从中受益。

 

附：ASCII编码

 

目前计算机中用得最广泛的字符集及其编码，是由美国国家标准局(ANSI)制定的ASCII码（American Standard Code for Information Interchange，美国标准信息交换码），它已被国际标准化组织（ISO）定为国际标准，称为ISO 646标准。适用于所有拉丁文字字母，ASCII码有7位码和8位码两种形式。
因为1位二进制数可以表示2（1）=2种状态：0、1；而2位二进制数可以表示2（2）=4种状态：00、01、10、11；依次类推，7位二进制数可以表示2（7）=128种状态，每种状态都唯一地编为一个7位的二进制码，对应一个字符（或控制码），这些码可以排列成一个十进制序号0～127。所以，7 位ASCII码是用七位二进制数进行编码的，可以表示128个字符。
第0～32号及第127号(共34个)是控制字符或通讯专用字符，如控制符：LF（换行）、CR（回车）、FF（换页）、DEL（删除）、BS（退格)、BEL（振铃）等；通讯专用字符：SOH（文头）、EOT（文尾）、ACK（确认）等；

第33～126号(共94个)是字符，

其中第48～57号为0～9十个阿拉伯数字；

65～90号为26个大写英文字母，

97～122号为26个小写英文字母，

其余为一些标点符号、运算符号等。

Decimal Octal Hex Binary Value

------- ----- *--- ------ -----

000 000 000 00000000 NUL (Null char.)

001 001 001 00000001 SOH (Start of Header)发送文件首

002 002 002 00000010 STX (Start of Text)文本开始

003 003 003 00000011 ETX (End of Text)文本尾

004 004 004 00000100 EOT (End of Transmission)发送结束

005 005 005 00000101 ENQ (Enquiry)

006 006 006 00000110 ACK (Acknowledgment)确认

007 007 007 00000111 BEL (Bell)蜂鸣

008 010 008 00001000 BS (Backspace)退格

009 011 009 00001001 HT (Horizontal Tab)

010 012 00A 00001010 LF (Line Feed)换行

011 013 00B 00001011 VT (Vertical Tab)

012 014 00C 00001100 FF (Form Feed)换页

013 015 00D 00001101 CR (Carriage Return)回车

014 016 00E 00001110 SO (Shift Out)SHIFT 松开

015 017 00F 00001111 SI (Shift In)按下

016 020 010 00010000 DLE (Data Link Escape)清除

017 021 011 00010001 DC1 (XON) (Device Control 1)

018 022 012 00010010 DC2 (Device Control 2)

019 023 013 00010011 DC3 (XOFF)(Device Control 3)

020 024 014 00010100 DC4 (Device Control 4)

021 025 015 00010101 NAK (Negative Acknowledgement)

022 026 016 00010110 SYN (Synchronous Idle)

023 027 017 00010111 ETB (End of Trans. Block)

024 030 018 00011000 CAN (Cancel)

025 031 019 00011001 EM (End of Medium)

026 032 01A 00011010 SUB (Substitute)

027 033 01B 00011011 ESC (Escape)退出

028 034 01C 00011100 FS (File Separator)

029 035 01D 00011101 GS (Group Separator)

030 036 01E 00011110 RS (Request to Send)(Record Separator)

031 037 01F 00011111 US (Unit Separator)

032 040 020 00100000 SP (Space)空格

033 041 021 00100001 ! (exclamation mark)

034 042 022 00100010 " (double quote)

035 043 023 00100011 # (number sign)

036 044 024 00100100 $ (dollar sign)

037 045 025 00100101 % (percent)

038 046 026 00100110 & (ampersand)

039 047 027 00100111 ' (single quote)

040 050 028 00101000 ( (left/opening parenthesis)

041 051 029 00101001 ) (right/closing parenthesis)

042 052 02A 00101010 * (asterisk)

043 053 02B 00101011 + (plus)

044 054 02C 00101100 , (comma)

045 055 02D 00101101 - (minus or dash)

046 056 02E 00101110 . (dot)

047 057 02F 00101111 / (forward slash)

048 060 030 00110000 0

049 061 031 00110001 1

050 062 032 00110010 2

051 063 033 00110011 3

052 064 034 00110100 4

053 065 035 00110101 5

054 066 036 00110110 6

055 067 037 00110111 7

056 070 038 00111000 8

057 071 039 00111001 9

058 072 03A 00111010 : (colon)

059 073 03B 00111011 ; (semi-colon)

060 074 03C 00111100 < (less than)

061 075 03D 00111101 = (equal sign)

062 076 03E 00111110 > (greater than)

063 077 03F 00111111 ? (question mark)

064 100 040 01000000 @ (AT symbol)

065 101 041 01000001 A

066 102 042 01000010 B

067 103 043 01000011 C

068 104 044 01000100 D

069 105 045 01000101 E

070 106 046 01000110 F

071 107 047 01000111 G

072 110 048 01001000 H

073 111 049 01001001 I

074 112 04A 01001010 J

075 113 04B 01001011 K

076 114 04C 01001100 L

077 115 04D 01001101 M

078 116 04E 01001110 N

079 117 04F 01001111 O

080 120 050 01010000 P

081 121 051 01010001 Q

082 122 052 01010010 R

083 123 053 01010011 S

084 124 054 01010100 T

085 125 055 01010101 U

086 126 056 01010110 V

087 127 057 01010111 W

088 130 058 01011000 X

089 131 059 01011001 Y

090 132 05A 01011010 Z

091 133 05B 01011011 [ (left/opening bracket)

092 134 05C 01011100 \ (back slash)

093 135 05D 01011101 ] (right/closing bracket)

094 136 05E 01011110 ^ (caret/cirumflex)

095 137 05F 01011111 _ (underscore)

096 140 060 01100000 `

097 141 061 01100001 a

098 142 062 01100010 b

099 143 063 01100011 c

100 144 064 01100100 d

101 145 065 01100101 e

102 146 066 01100110 f

103 147 067 01100111 g

104 150 068 01101000 h

105 151 069 01101001 i

106 152 06A 01101010 j

107 153 06B 01101011 k

108 154 06C 01101100 l

109 155 06D 01101101 m

110 156 06E 01101110 n

111 157 06F 01101111 o

112 160 070 01110000 p

113 161 071 01110001 q

114 162 072 01110010 r

115 163 073 01110011 s

116 164 074 01110100 t

117 165 075 01110101 u

118 166 076 01110110 v

119 167 077 01110111 w

120 170 078 01111000 x

121 171 079 01111001 y

122 172 07A 01111010 z

123 173 07B 01111011 { (left/opening brace)

124 174 07C 01111100 | (vertical bar)

125 175 07D 01111101 } (right/closing brace)

126 176 07E 01111110 ~ (tilde)

127 177 07F 01111111 DEL (delete)

字母和数字的 ASCII 码的记忆是非常简单的。我们只要记住了一个字母或数字的 ASCII 码（例如记住 A 为 65 ， 0 的 ASCII 码为 48 ），知道相应的大小写字母之间差 32 ，就可以推算出其余字母、数字的 ASCII 码。
虽然标准 ASCII 码是 7 位编码，但由于计算机基本处理单位为字节（ 1byte = 8bit ），所以一般仍以一个字节来存放一个 ASCII 字符。每一个字节中多余出来的一位（最高位）在计算机内部通常保持为 0 （在数据传输时可用作奇偶校验位）。
由于标准 ASCII 字符集字符数目有限，在实际应用中往往无法满足要求。为此，国际标准化组织又制定了 ISO2022 标准，它规定了在保持与 ISO646 兼容的前提下将 ASCII 字符集扩充为 8 位代码的统一方法。 ISO 陆续制定了一批适用于不同地区的扩充 ASCII 字符集，每种扩充 ASCII 字符集分别可以扩充 128 个字符，这些扩充字符的编码均为高位为 1 的 8 位代码（即十进制数 128~255 ），称为扩展 ASCII 码。

 

 

 

本文转至：http://www.cnblogs.com/joeblackzqq/archive/2011/04/11/2012005.html