计算机编码方式总结
2017-08-10 14:18
573 查看
ASCII(American Standard Code for Information Interchange,美国信息交换标准代码)是基于拉丁字母的一套电脑编码系统,主要用于显示现代英语和其他西欧语言。它是现今最通用的单字节编码系统,并等同于国际标准ISO/IEC
646。
所有数据在计算机中存储都是二进制,美国标准信息交换代码是由美国国家标准学会(American
National Standard Institute , ANSI )制定的,标准的单字节字符编码方案,用于基于文本的数据。起它最初是美国国家标准,供不同计算机在相互通信时用作共同遵守的西文字符编码标准,它已被国际标准化组织(International
Organization for Standardization, ISO)定为国际标准,称为ISO 646标准。适用于所有拉丁文字字母。
Ascii使用7位或8位表示128或者256个可能的字符,标准ascii码又叫基础ascii码,使用7
位二进制数(剩下的1位二进制为0)来表示所有的大写和小写字母,数字0
到9、标点符号, 以及在美式英语中使用的特殊控制字符 。0~31及127(共33个)是控制字符或通信专用字符(其余为可显示字符),如控制符:LF(换行)、CR(回车)、FF(换页)、DEL(删除)、BS(退格)、BEL(响铃)等;通信专用字符:SOH(文头)、EOT(文尾)、ACK(确认)等;ASCII值为8、9、10
和13
分别转换为退格、制表、换行和回车字符。它们并没有特定的图形显示,但会依不同的应用程序,而对文本显示有不同的影响。
32~126(共95个)是字符(32是空格),其中48~57为0到9十个阿拉伯数字。
65~90为26个大写英文字母,97~122号为26个小写英文字母,其余为一些标点符号、运算符号等。
在标准ASCII中,其最高位(b7)用作奇偶校验位?再看。
后128个称为扩展ASCII码。许多基于x86的系统都支持使用扩展(或“高”)ASCII。扩展ASCII
码允许将每个字符的第8
位用于确定附加的128
个特殊符号字符、外来语字母和图形符号。
GB 2312:信息交换用汉字编码字符集
《信息交换用汉字编码字符集》是由中国国家标准总局1980年发布,标准号是GB 2312-1980。GB 2312或GB
2312-80是一个简体中文字符集的中国国家标准,全称为《信息交换用汉字编码字符集·基本集》,又称为GB0。
对于人名、古汉语等方面出现的罕用字,GB 2312不能处理,这导致了后来GBK及GB
18030汉字字符集的出现。
GB2312编码适用于汉字处理、汉字通信等系统之间的信息交换,通行于中国大陆;新加坡等地也采用此编码。中国大陆几乎所有的中文系统和国际化的软件都支持GB
2312。
基本集共收入汉字6763个和非汉字图形字符682个。整个字符集分成94个区,每区有94个位。每个区位上只有一个字符,因此可用所在的区和位来对汉字进行编码,称为区位码。
把换算成十六进制的区位码加上2020H,就得到国标码。国标码加上8080H,就得到常用的计算机机内码。1995年又颁布了《汉字编码扩展规范》(GBK)。
GBK与GB 2312-1980国家标准所对应的内码标准兼容,同时在字汇一级支持ISO/IEC10646-1和GB
13000-1的全部中、日、韩(CJK)汉字,共计20902字。
信息交换用汉字编码字符集和汉字输入编码之间的关系是,根据不同的汉字输入法,通过必要的设备向计算机输入汉字的编码,计算机接收后,先转换成信息交换用汉字编码字符,这时计算机就可以识别并处理;汉字输出是先把机内码转成汉字编码,再发送到输出设备。
分区表示:
GB 2312中对所收汉字进行了“分区”处理,每区含有94个汉字/符号。这种表示方式也称为区位码。
01-09区为特殊符号。
16-55区为一级汉字,按拼音排序。
56-87区为二级汉字,按部首/笔画排序。
10-15区及88-94区则未有编码。
每个字符的区号和位号组合起来就是该汉字的区位码,区位码一般
用10进制数来表示,如1601就表示16区1位,对应的字符是“啊”。在区位码的区号和位号上分别加上0xA0就得到了GB2312编码。“啊”字是GB2312中的第一个汉字,它的区位码就是1601。它把0xA0+16=0xB0,0xA0+1=0xA1,得出它的编码0xB0A1。
字节结构:
在使用GB2312的程序中,通常采用EUC储存方法,以便兼容于ASCII。浏览器编码表上的“GB2312”,通常都是指“EUC-CN”表示法。
每个汉字及符号以两个字节来表示。第一个字节称为“高位字节”(也称“区字节)”,第二个字节称为“低位字节”(也称“位字节”)。
“高位字节”使用了0xA1-0xF7(把01-87区的区号加上0xA0),“低位字节”使用了0xA1-0xFE(把01-94加上
0xA0)。 由于一级汉字从16区起始,汉字区的“高位字节”的范围是0xB0-0xF7,“低位字节”的范围是0xA1-0xFE,占用的码位是
72*94=6768。其中有5个空位是D7FA-D7FE。
例如“啊”字编码为0xB0A1,以两个字节,0xB0(第一个字节)
0xA1(第二个字节)储存。区位码=区号+位号(与高低字节对比:0xB0=0xA0+16,0xA1=0xA0+1)。
因此GB2312的编码范围为0xA1A1-0xFEFE,去掉未定义的区域之后可以理解为实际编码范围是0xA1A1-0xF7FE。
EUC-CN可以理解为GB2312的别名,和GB2312完全相同。
区位码更应该认为是字符集的定义,定义了所收录的字符和字符位置,而GB2312及EUC-CN是实际计算机环境中支持这 种字符集的编码。HZ和ISO-2022-CN是对应区位码字符集的另外两种编码,都是用7位编码空间来支持汉字。区位码和GB2312编码的关系有点像
Unicode和UTF-8。
GBK:
GBK即汉字内码扩展规范,K为扩展的汉语拼音中"扩"字的声母。英文全称Chinese
Internal Code Specification。GBK编码标准兼容GB2312,共收录汉字21003个、符号883个,并提供1894个造字码位,简、繁体字融于一库。GB2312码是中华人民共和国国家汉字信息交换用编码,全称《信息交换用汉字编码字符集--基本集》,1980年由国家标准总局发布。基本集共收入汉字6763个和非汉字图形字符682个,通行于中国大陆。新加坡等地也使用此编码。GBK是对GB2312-80的扩展,也就是CP936字码表
(Code Page 936)的扩展(之前CP936和GB
2312-80一模一样)。
编码方式:
字符有一字节和双字节编码,00–7F范围内是一位,和ASCII保持一致,此范围内严格上说有96个字符和32个控制符号。
之后的双字节中,前一字节是双字节的第一位。总体上说第一字节的范围是81–FE(也就是不含80和FF),第二字节的一部分领域在40–7E,其他领域在80–FE。
GBK的整体编码范围是为0x8140-0xFEFE,不包括低字节是0×7F的组合。高字节范围是0×81-0xFE,低字节范围是0x40-7E和0x80-0xFE。
低字节是0x40-0x7E的GBK字符有一定特殊性,因为这些字符占用了ASCII码的位置,这样会给一些系统带来麻烦。
有些系统中用0x40-0x7E中的字符(如“|”)做特殊符号,在定位这些符号时又没有判断这些符号是不是属于某个
GBK字符的低字节,这样就会造成错误判断。在支持GB2312的环境下就不存在这个问题。需要注意的是支持GBK的环境中小于0x80的某个字节未必就
是ASCII符号;另外就是最好选用小于0×40的ASCII符号做一些特殊符号,这样就可以快速定位,且不用担心是某个汉字的另一半。Big5编码中也存在相应问题。
CP936和GBK的有些许差别,绝大多数情况下可以把CP936当作GBK的别名。
GB18030
GB18030编码向下兼容GBK和GB2312,兼容的含义是不仅字符兼容,而且相同字符的编码也相同。GB18030收录了所有Unicode3.1中的字符,包括中国少数民族字符,GBK不支持的韩文字符等等,也可以说是世界大多民族的文字符号都被收录在内。
GBK和GB2312都是双字节等宽编码,如果算上和ASCII兼容所支持的单字节,也可以理解为是单字节和双字节混合的变长编码。GB18030编码是变长编码,有单字节、双字节和四字节三种方式。
GB18030的单字节编码范围是0x00-0x7F,完全等同与ASCII;双字节编码的范围和GBK相同,高字节是0x81-0xFE,低字节
的编码范围是0x40-0x7E和0x80-FE;四字节编码中第一、三字节的编码范围是0x81-0xFE,二、四字节是0x30-0x39。
Windows中CP936代码页使用0x80来表示欧元符号,而在GB18030编码中没有使用0x80编码位,用其他位置来表示欧元符号。这可以理解为是GB18030向下兼容性上的一点小问题;也可以理解为0x80是CP936对GBK的扩展,而GB18030只是和GBK兼容良好。
BIG5
Big5是双字节编码,高字节编码范围是0x81-0xFE,低字节编码范围是0x40-0x7E和0xA1-0xFE。和GBK相比,少了低字节是0x80-0xA0的组合。0x8140-0xA0FE是保留区域,用于用户造字区。
Big5收录的汉字只包括繁体汉字,不包括简体汉字,一些生僻的汉字也没有收录。GBK收录的日文假名字符、俄文字符Big5也没有收录。因为Big5当中收录的字符有限,因此有很多在Big5基础上扩展的编码,如倚天中文系统。Windows系统上使用的代码页CP950也可以理解为是对Big5的扩展,在Big5的基础上增加了7个汉字和一些符号。Big5编码对应的字符集是GBK字符集的子集,也就是说Big5收录的字符是GBK收录字符的一部分,但相同字符的编码不同。
因为Big5也占用了ASCII的编码空间(低字节所使用的0x40-0x7E),所以Big5编码在一些环境下存在和GBK编码相同的问题,即低字节范围为0x40-0x7E的字符有可能会被误处理,尤其是低字节是0x5C("/")和0x7C("|")的字符。可以参考GBK一节相应说明。
尽管有些区别,大多数情况下可以把CP950当作Big5的别名。
ISO-8859-1:
ISO-8859-1编码是单字节编码,向下兼容ASCII,其编码范围是0x00-0xFF,0x00-0x7F之间完全和ASCII一致,0x80-0x9F之间是控制字符,0xA0-0xFF之间是文字符号。
ISO-8859-1收录的字符除ASCII收录的字符外,还包括西欧语言、希腊语、泰语、阿拉伯语、希伯来语对应的文字符号。欧元符号出现的比较晚,没有被收录在ISO-8859-1当中。
因为ISO-8859-1编码范围使用了单字节内的所有空间,在支持ISO-8859-1的系统中传输和存储其他任何编码的字节流都不会被抛弃。换言之,把其他任何编码的字节流当作ISO-8859-1编码看待都没有问题。这是个很重要的特性,MySQL数据库默认编码是Latin1就是利用了这个特性。ASCII编码是一个7位的容器,ISO-8859-1编码是一个8位的容器。
Latin1是ISO-8859-1的别名,有些环境下写作Latin-1。
UCS-2和UTF-16
Unicode组织和ISO组织都试图定义一个超大字符集,目的是要涵盖所有语言使用的字符以及其他学科使用的一些特殊符号,这个字符集就是通用字符集(UCS,Universal
Character Set)。这两个组织经过协调,虽然在各自发展,但定义的字符位置是完全一致的。ISO相应的标准是ISO 10646。Unicode和ISO
10646都在不断的发展过程中,所以会有不同的版本号来标明不同的发展阶段,每个Unicode版本号都能找到相对应的ISO 10646版本号。
ISO 10646标准定义了一个31位的字符集。前两个字节的位置(0x0000-0xFFFD)被称为基本多语言面(Basic
Multilingual Plane, BMP) ,超出两个字节的范围称作辅助语言面。BMP基本包括了所有语言中绝大多数字符,所以只要支持BMP就可以支持绝大多数场合下的应用。Unicode
3.0对应的字符集在BMP范围内。
UCS字符集为每个字符分配了一个位置,通常用“U”再加上某个字符在UCS中位置的16进制数作为这个字符的UCS表示,例如“U+0041”表示字符“A”。UCS字符U+0000到U+00FF与ISO-8859-1完全一致。
UCS-2、UTF-16是UCS字符集(或者说是Unicode字符集)实际应用中的具体编码方式。UCS-2是两个字节的等宽编码,因为只是使用了两个字节的编码空间,所以只能对BMP中的字符做编码。UTF-16是变长编码,用两个字节对BMP内的字符编码,用4个字节对超出BMP范围的辅助平面内的字符作编码。
UCS-2不同于GBK和Big5,它是真正的等宽编码,每个字符都使用两个字节,这个特性在字符串截断和字符数计算时非常方便。
UTF-16是UCS-2的超集,UTF-16编码的两字节编码方式完全和UCS-2相同,也就是说在BMP的框架内UCS-2完全等同与UTF-16。实际情况当中常常把UCS-16当作UCS-2的别名。
UCS-2和UTF-16在存储和传输时会使用两种不同的字节序,分别是big endian和little
endian[1] (大尾和小尾)。例如“啊”(U+554A)用big endian表示就是0x554A,用little
endian表示就是0x4A55。UCS-2和UTF-16默认的字节序是big
endian方式。在传输过程中为了说明字节序需要在字节流前加上BOM(Byte order Mark),0xFEFF表示是big
endian,0xFFFE表示是little endian。UCS-2BE、UCS-2LE是实际应用中使用的编码名称,对应着big
endian和little endian,UTF-16BE、UTF-16LE也是如此。因为默认是BE字节序,所以可以把UCS-2当做是UCS-2BE的别名。
在UCS编码中有一个叫做“ZERO WIDTH NO-BREAK SPACE”的字符,它的编码是U+FEFF,是个没有实际意义的字符。UCS规范建议我们在传输字节流前,先传输字符“ZERO
WIDTH NO-BREAK SPACE”,如果传输的ZERO WIDTH NO-BREAK SPACE是0xFEFF就说明是big
endian,反之就是little endian。
UCS-2和UTF-16也可以理解为和ASCII以及ISO-8859-1兼容,在ASCII编码或者ISO-8859-1编码的每个字节前加上0x00,就得到相应字符的UCS-2编码。
UCS-2和UTF-16中会使用0x00作为某个字符编码的一部分,某些系统会把0x00当作字符串结束的标志,在处理UCS-2或UTF-16编码时会出现问题。
UTF-8:
UTF-8是UCS字符集的另一种编码方式,UTF-16的每个单元是两个字节(16位),而UTF-8的每个单元是一个字节(8位)。UTF-16中用一个或两个双字节表示一个字符,UTF-8中用一个或几个单字节表示一个字符。
可以认为UTF-8编码是根据一定规律从UCS-2转换得到的,从UCS-2到UTF-8之间有以下转换关系:
UCS-2 UTF-8
U+0000 - U+007F 0xxxxxxx
U+0080 - U+07FF 110xxxxx 10xxxxxx
U+0800 - U+FFFF 1110xxxx 10xxxxxx 10xxxxxx
例如“啊”字的UCS-2编码是0x554A,对应的二进制是0101 0101
0100 1010,转成UTF-8编码之后的二进制是1110 0101 10 010101 10 001010,对应的十六进制是0xE5958A。
UCS-4也是一种UCS字符集的编码方式,是使用4个字节的等宽编码,可以用UCS-4来表示BMP之外的辅助面字符。UCS-2中每两个字节前再加上0x0000就得到了BMP字符的UCS-4编码。从UCS-4到UTF-8也存在转换关系,根据这种转换关系,UTF-8最多可以使用六个字节来编码UCS-4。根据UTF-8的生成规律和UCS字符集的特性,可以看到UTF-8具有的特性:UTF-8完全和ASCII兼容,也就是说ASCII对应的字符在UTF-8中和ASCII编码完全一致。范围在0x00-0x7F之内的字符一定是ASCII字符,不可能是其他字符的一部分。GBK和Big5都存在的缺陷在UTF-8中是不存在的。
大于U+007F的UCS字符,在UTF-8编码中至少是两个字节。
UTF-8中的每个字符编码的首字节总在0x00-0xFD之间(不考虑UCS-4支持的情况,首字节在0x00-0xEF之间)。根据首字节就可以判断之后连续几个字节。
非首字节的其他字节都在0x80-0xBF之间;0xFE和0xFF在UTF-8中没有被用到。
GBK编码中的汉字字符都在UCS-2中的范围都在U+0800 - U+FFFF之间,所以每个GBK编码中的汉字字符的UTF-8编码都是3个字节。但GBK中包含的其他字符的UTF-8编码就不一定是3个字节了,如GBK中的俄文字符。
在UTF-8的编码的传输过程中即使丢掉一个字节,根据编码规律也很容易定位丢掉的位置,不会影响到其他字符。在其他双字节编码中,一旦损失一个字节,就会影响到此字节之后的所有字符。从这点可以看出UTF-8编码非常适合作为传输编码。
646。
所有数据在计算机中存储都是二进制,美国标准信息交换代码是由美国国家标准学会(American
National Standard Institute , ANSI )制定的,标准的单字节字符编码方案,用于基于文本的数据。起它最初是美国国家标准,供不同计算机在相互通信时用作共同遵守的西文字符编码标准,它已被国际标准化组织(International
Organization for Standardization, ISO)定为国际标准,称为ISO 646标准。适用于所有拉丁文字字母。
Ascii使用7位或8位表示128或者256个可能的字符,标准ascii码又叫基础ascii码,使用7
位二进制数(剩下的1位二进制为0)来表示所有的大写和小写字母,数字0
到9、标点符号, 以及在美式英语中使用的特殊控制字符 。0~31及127(共33个)是控制字符或通信专用字符(其余为可显示字符),如控制符:LF(换行)、CR(回车)、FF(换页)、DEL(删除)、BS(退格)、BEL(响铃)等;通信专用字符:SOH(文头)、EOT(文尾)、ACK(确认)等;ASCII值为8、9、10
和13
分别转换为退格、制表、换行和回车字符。它们并没有特定的图形显示,但会依不同的应用程序,而对文本显示有不同的影响。
32~126(共95个)是字符(32是空格),其中48~57为0到9十个阿拉伯数字。
65~90为26个大写英文字母,97~122号为26个小写英文字母,其余为一些标点符号、运算符号等。
在标准ASCII中,其最高位(b7)用作奇偶校验位?再看。
后128个称为扩展ASCII码。许多基于x86的系统都支持使用扩展(或“高”)ASCII。扩展ASCII
码允许将每个字符的第8
位用于确定附加的128
个特殊符号字符、外来语字母和图形符号。
GB 2312:信息交换用汉字编码字符集
《信息交换用汉字编码字符集》是由中国国家标准总局1980年发布,标准号是GB 2312-1980。GB 2312或GB
2312-80是一个简体中文字符集的中国国家标准,全称为《信息交换用汉字编码字符集·基本集》,又称为GB0。
对于人名、古汉语等方面出现的罕用字,GB 2312不能处理,这导致了后来GBK及GB
18030汉字字符集的出现。
GB2312编码适用于汉字处理、汉字通信等系统之间的信息交换,通行于中国大陆;新加坡等地也采用此编码。中国大陆几乎所有的中文系统和国际化的软件都支持GB
2312。
基本集共收入汉字6763个和非汉字图形字符682个。整个字符集分成94个区,每区有94个位。每个区位上只有一个字符,因此可用所在的区和位来对汉字进行编码,称为区位码。
把换算成十六进制的区位码加上2020H,就得到国标码。国标码加上8080H,就得到常用的计算机机内码。1995年又颁布了《汉字编码扩展规范》(GBK)。
GBK与GB 2312-1980国家标准所对应的内码标准兼容,同时在字汇一级支持ISO/IEC10646-1和GB
13000-1的全部中、日、韩(CJK)汉字,共计20902字。
信息交换用汉字编码字符集和汉字输入编码之间的关系是,根据不同的汉字输入法,通过必要的设备向计算机输入汉字的编码,计算机接收后,先转换成信息交换用汉字编码字符,这时计算机就可以识别并处理;汉字输出是先把机内码转成汉字编码,再发送到输出设备。
分区表示:
GB 2312中对所收汉字进行了“分区”处理,每区含有94个汉字/符号。这种表示方式也称为区位码。
01-09区为特殊符号。
16-55区为一级汉字,按拼音排序。
56-87区为二级汉字,按部首/笔画排序。
10-15区及88-94区则未有编码。
每个字符的区号和位号组合起来就是该汉字的区位码,区位码一般
用10进制数来表示,如1601就表示16区1位,对应的字符是“啊”。在区位码的区号和位号上分别加上0xA0就得到了GB2312编码。“啊”字是GB2312中的第一个汉字,它的区位码就是1601。它把0xA0+16=0xB0,0xA0+1=0xA1,得出它的编码0xB0A1。
字节结构:
在使用GB2312的程序中,通常采用EUC储存方法,以便兼容于ASCII。浏览器编码表上的“GB2312”,通常都是指“EUC-CN”表示法。
每个汉字及符号以两个字节来表示。第一个字节称为“高位字节”(也称“区字节)”,第二个字节称为“低位字节”(也称“位字节”)。
“高位字节”使用了0xA1-0xF7(把01-87区的区号加上0xA0),“低位字节”使用了0xA1-0xFE(把01-94加上
0xA0)。 由于一级汉字从16区起始,汉字区的“高位字节”的范围是0xB0-0xF7,“低位字节”的范围是0xA1-0xFE,占用的码位是
72*94=6768。其中有5个空位是D7FA-D7FE。
例如“啊”字编码为0xB0A1,以两个字节,0xB0(第一个字节)
0xA1(第二个字节)储存。区位码=区号+位号(与高低字节对比:0xB0=0xA0+16,0xA1=0xA0+1)。
因此GB2312的编码范围为0xA1A1-0xFEFE,去掉未定义的区域之后可以理解为实际编码范围是0xA1A1-0xF7FE。
EUC-CN可以理解为GB2312的别名,和GB2312完全相同。
区位码更应该认为是字符集的定义,定义了所收录的字符和字符位置,而GB2312及EUC-CN是实际计算机环境中支持这 种字符集的编码。HZ和ISO-2022-CN是对应区位码字符集的另外两种编码,都是用7位编码空间来支持汉字。区位码和GB2312编码的关系有点像
Unicode和UTF-8。
GBK:
GBK即汉字内码扩展规范,K为扩展的汉语拼音中"扩"字的声母。英文全称Chinese
Internal Code Specification。GBK编码标准兼容GB2312,共收录汉字21003个、符号883个,并提供1894个造字码位,简、繁体字融于一库。GB2312码是中华人民共和国国家汉字信息交换用编码,全称《信息交换用汉字编码字符集--基本集》,1980年由国家标准总局发布。基本集共收入汉字6763个和非汉字图形字符682个,通行于中国大陆。新加坡等地也使用此编码。GBK是对GB2312-80的扩展,也就是CP936字码表
(Code Page 936)的扩展(之前CP936和GB
2312-80一模一样)。
编码方式:
字符有一字节和双字节编码,00–7F范围内是一位,和ASCII保持一致,此范围内严格上说有96个字符和32个控制符号。
之后的双字节中,前一字节是双字节的第一位。总体上说第一字节的范围是81–FE(也就是不含80和FF),第二字节的一部分领域在40–7E,其他领域在80–FE。
GBK的整体编码范围是为0x8140-0xFEFE,不包括低字节是0×7F的组合。高字节范围是0×81-0xFE,低字节范围是0x40-7E和0x80-0xFE。
低字节是0x40-0x7E的GBK字符有一定特殊性,因为这些字符占用了ASCII码的位置,这样会给一些系统带来麻烦。
有些系统中用0x40-0x7E中的字符(如“|”)做特殊符号,在定位这些符号时又没有判断这些符号是不是属于某个
GBK字符的低字节,这样就会造成错误判断。在支持GB2312的环境下就不存在这个问题。需要注意的是支持GBK的环境中小于0x80的某个字节未必就
是ASCII符号;另外就是最好选用小于0×40的ASCII符号做一些特殊符号,这样就可以快速定位,且不用担心是某个汉字的另一半。Big5编码中也存在相应问题。
CP936和GBK的有些许差别,绝大多数情况下可以把CP936当作GBK的别名。
GB18030
GB18030编码向下兼容GBK和GB2312,兼容的含义是不仅字符兼容,而且相同字符的编码也相同。GB18030收录了所有Unicode3.1中的字符,包括中国少数民族字符,GBK不支持的韩文字符等等,也可以说是世界大多民族的文字符号都被收录在内。
GBK和GB2312都是双字节等宽编码,如果算上和ASCII兼容所支持的单字节,也可以理解为是单字节和双字节混合的变长编码。GB18030编码是变长编码,有单字节、双字节和四字节三种方式。
GB18030的单字节编码范围是0x00-0x7F,完全等同与ASCII;双字节编码的范围和GBK相同,高字节是0x81-0xFE,低字节
的编码范围是0x40-0x7E和0x80-FE;四字节编码中第一、三字节的编码范围是0x81-0xFE,二、四字节是0x30-0x39。
Windows中CP936代码页使用0x80来表示欧元符号,而在GB18030编码中没有使用0x80编码位,用其他位置来表示欧元符号。这可以理解为是GB18030向下兼容性上的一点小问题;也可以理解为0x80是CP936对GBK的扩展,而GB18030只是和GBK兼容良好。
BIG5
Big5是双字节编码,高字节编码范围是0x81-0xFE,低字节编码范围是0x40-0x7E和0xA1-0xFE。和GBK相比,少了低字节是0x80-0xA0的组合。0x8140-0xA0FE是保留区域,用于用户造字区。
Big5收录的汉字只包括繁体汉字,不包括简体汉字,一些生僻的汉字也没有收录。GBK收录的日文假名字符、俄文字符Big5也没有收录。因为Big5当中收录的字符有限,因此有很多在Big5基础上扩展的编码,如倚天中文系统。Windows系统上使用的代码页CP950也可以理解为是对Big5的扩展,在Big5的基础上增加了7个汉字和一些符号。Big5编码对应的字符集是GBK字符集的子集,也就是说Big5收录的字符是GBK收录字符的一部分,但相同字符的编码不同。
因为Big5也占用了ASCII的编码空间(低字节所使用的0x40-0x7E),所以Big5编码在一些环境下存在和GBK编码相同的问题,即低字节范围为0x40-0x7E的字符有可能会被误处理,尤其是低字节是0x5C("/")和0x7C("|")的字符。可以参考GBK一节相应说明。
尽管有些区别,大多数情况下可以把CP950当作Big5的别名。
ISO-8859-1:
ISO-8859-1编码是单字节编码,向下兼容ASCII,其编码范围是0x00-0xFF,0x00-0x7F之间完全和ASCII一致,0x80-0x9F之间是控制字符,0xA0-0xFF之间是文字符号。
ISO-8859-1收录的字符除ASCII收录的字符外,还包括西欧语言、希腊语、泰语、阿拉伯语、希伯来语对应的文字符号。欧元符号出现的比较晚,没有被收录在ISO-8859-1当中。
因为ISO-8859-1编码范围使用了单字节内的所有空间,在支持ISO-8859-1的系统中传输和存储其他任何编码的字节流都不会被抛弃。换言之,把其他任何编码的字节流当作ISO-8859-1编码看待都没有问题。这是个很重要的特性,MySQL数据库默认编码是Latin1就是利用了这个特性。ASCII编码是一个7位的容器,ISO-8859-1编码是一个8位的容器。
Latin1是ISO-8859-1的别名,有些环境下写作Latin-1。
UCS-2和UTF-16
Unicode组织和ISO组织都试图定义一个超大字符集,目的是要涵盖所有语言使用的字符以及其他学科使用的一些特殊符号,这个字符集就是通用字符集(UCS,Universal
Character Set)。这两个组织经过协调,虽然在各自发展,但定义的字符位置是完全一致的。ISO相应的标准是ISO 10646。Unicode和ISO
10646都在不断的发展过程中,所以会有不同的版本号来标明不同的发展阶段,每个Unicode版本号都能找到相对应的ISO 10646版本号。
ISO 10646标准定义了一个31位的字符集。前两个字节的位置(0x0000-0xFFFD)被称为基本多语言面(Basic
Multilingual Plane, BMP) ,超出两个字节的范围称作辅助语言面。BMP基本包括了所有语言中绝大多数字符,所以只要支持BMP就可以支持绝大多数场合下的应用。Unicode
3.0对应的字符集在BMP范围内。
UCS字符集为每个字符分配了一个位置,通常用“U”再加上某个字符在UCS中位置的16进制数作为这个字符的UCS表示,例如“U+0041”表示字符“A”。UCS字符U+0000到U+00FF与ISO-8859-1完全一致。
UCS-2、UTF-16是UCS字符集(或者说是Unicode字符集)实际应用中的具体编码方式。UCS-2是两个字节的等宽编码,因为只是使用了两个字节的编码空间,所以只能对BMP中的字符做编码。UTF-16是变长编码,用两个字节对BMP内的字符编码,用4个字节对超出BMP范围的辅助平面内的字符作编码。
UCS-2不同于GBK和Big5,它是真正的等宽编码,每个字符都使用两个字节,这个特性在字符串截断和字符数计算时非常方便。
UTF-16是UCS-2的超集,UTF-16编码的两字节编码方式完全和UCS-2相同,也就是说在BMP的框架内UCS-2完全等同与UTF-16。实际情况当中常常把UCS-16当作UCS-2的别名。
UCS-2和UTF-16在存储和传输时会使用两种不同的字节序,分别是big endian和little
endian[1] (大尾和小尾)。例如“啊”(U+554A)用big endian表示就是0x554A,用little
endian表示就是0x4A55。UCS-2和UTF-16默认的字节序是big
endian方式。在传输过程中为了说明字节序需要在字节流前加上BOM(Byte order Mark),0xFEFF表示是big
endian,0xFFFE表示是little endian。UCS-2BE、UCS-2LE是实际应用中使用的编码名称,对应着big
endian和little endian,UTF-16BE、UTF-16LE也是如此。因为默认是BE字节序,所以可以把UCS-2当做是UCS-2BE的别名。
在UCS编码中有一个叫做“ZERO WIDTH NO-BREAK SPACE”的字符,它的编码是U+FEFF,是个没有实际意义的字符。UCS规范建议我们在传输字节流前,先传输字符“ZERO
WIDTH NO-BREAK SPACE”,如果传输的ZERO WIDTH NO-BREAK SPACE是0xFEFF就说明是big
endian,反之就是little endian。
UCS-2和UTF-16也可以理解为和ASCII以及ISO-8859-1兼容,在ASCII编码或者ISO-8859-1编码的每个字节前加上0x00,就得到相应字符的UCS-2编码。
UCS-2和UTF-16中会使用0x00作为某个字符编码的一部分,某些系统会把0x00当作字符串结束的标志,在处理UCS-2或UTF-16编码时会出现问题。
UTF-8:
UTF-8是UCS字符集的另一种编码方式,UTF-16的每个单元是两个字节(16位),而UTF-8的每个单元是一个字节(8位)。UTF-16中用一个或两个双字节表示一个字符,UTF-8中用一个或几个单字节表示一个字符。
可以认为UTF-8编码是根据一定规律从UCS-2转换得到的,从UCS-2到UTF-8之间有以下转换关系:
UCS-2 UTF-8
U+0000 - U+007F 0xxxxxxx
U+0080 - U+07FF 110xxxxx 10xxxxxx
U+0800 - U+FFFF 1110xxxx 10xxxxxx 10xxxxxx
例如“啊”字的UCS-2编码是0x554A,对应的二进制是0101 0101
0100 1010,转成UTF-8编码之后的二进制是1110 0101 10 010101 10 001010,对应的十六进制是0xE5958A。
UCS-4也是一种UCS字符集的编码方式,是使用4个字节的等宽编码,可以用UCS-4来表示BMP之外的辅助面字符。UCS-2中每两个字节前再加上0x0000就得到了BMP字符的UCS-4编码。从UCS-4到UTF-8也存在转换关系,根据这种转换关系,UTF-8最多可以使用六个字节来编码UCS-4。根据UTF-8的生成规律和UCS字符集的特性,可以看到UTF-8具有的特性:UTF-8完全和ASCII兼容,也就是说ASCII对应的字符在UTF-8中和ASCII编码完全一致。范围在0x00-0x7F之内的字符一定是ASCII字符,不可能是其他字符的一部分。GBK和Big5都存在的缺陷在UTF-8中是不存在的。
大于U+007F的UCS字符,在UTF-8编码中至少是两个字节。
UTF-8中的每个字符编码的首字节总在0x00-0xFD之间(不考虑UCS-4支持的情况,首字节在0x00-0xEF之间)。根据首字节就可以判断之后连续几个字节。
非首字节的其他字节都在0x80-0xBF之间;0xFE和0xFF在UTF-8中没有被用到。
GBK编码中的汉字字符都在UCS-2中的范围都在U+0800 - U+FFFF之间,所以每个GBK编码中的汉字字符的UTF-8编码都是3个字节。但GBK中包含的其他字符的UTF-8编码就不一定是3个字节了,如GBK中的俄文字符。
在UTF-8的编码的传输过程中即使丢掉一个字节,根据编码规律也很容易定位丢掉的位置,不会影响到其他字符。在其他双字节编码中,一旦损失一个字节,就会影响到此字节之后的所有字符。从这点可以看出UTF-8编码非常适合作为传输编码。
ASCII-》标准表
Bin(二进制) | Oct(八进制) | Dec(十进制) | Hex(十六进制) | 缩写/字符 | 解释 |
0000 0000 | 0 | 0 | 00 | NUL(null) | 空字符 |
0000 0001 | 1 | 1 | 01 | SOH(start of headline) | 标题开始 |
0000 0010 | 2 | 2 | 02 | STX (start of text) | 正文开始 |
0000 0011 | 3 | 3 | 03 | ETX (end of text) | 正文结束 |
0000 0100 | 4 | 4 | 04 | EOT (end of transmission) | 传输结束 |
0000 0101 | 5 | 5 | 05 | ENQ (enquiry) | 请求 |
0000 0110 | 6 | 6 | 06 | ACK (acknowledge) | 收到通知 |
0000 0111 | 7 | 7 | 07 | BEL (bell) | 响铃 |
0000 1000 | 10 | 8 | 08 | BS (backspace) | 退格 |
0000 1001 | 11 | 9 | 09 | HT (horizontal tab) | 水平制表符 |
0000 1010 | 12 | 10 | 0A | LF (NL line feed, new line) | 换行键 |
0000 1011 | 13 | 11 | 0B | VT (vertical tab) | 垂直制表符 |
0000 1100 | 14 | 12 | 0C | FF (NP form feed, new page) | 换页键 |
0000 1101 | 15 | 13 | 0D | CR (carriage return) | 回车键 |
0000 1110 | 16 | 14 | 0E | SO (shift out) | 不用切换 |
0000 1111 | 17 | 15 | 0F | SI (shift in) | 启用切换 |
0001 0000 | 20 | 16 | 10 | DLE (data link escape) | 数据链路转义 |
0001 0001 | 21 | 17 | 11 | DC1 (device control 1) | 设备控制1 |
0001 0010 | 22 | 18 | 12 | DC2 (device control 2) | 设备控制2 |
0001 0011 | 23 | 19 | 13 | DC3 (device control 3) | 设备控制3 |
0001 0100 | 24 | 20 | 14 | DC4 (device control 4) | 设备控制4 |
0001 0101 | 25 | 21 | 15 | NAK (negative acknowledge) | 拒绝接收 |
0001 0110 | 26 | 22 | 16 | SYN (synchronous idle) | 同步空闲 |
0001 0111 | 27 | 23 | 17 | ETB (end of trans. block) | 结束传输块 |
0001 1000 | 30 | 24 | 18 | CAN (cancel) | 取消 |
0001 1001 | 31 | 25 | 19 | EM (end of medium) | 媒介结束 |
0001 1010 | 32 | 26 | 1A | SUB (substitute) | 代替 |
0001 1011 | 33 | 27 | 1B | ESC (escape) | 换码(溢出) |
0001 1100 | 34 | 28 | 1C | FS (file separator) | 文件分隔符 |
0001 1101 | 35 | 29 | 1D | GS (group separator) | 分组符 |
0001 1110 | 36 | 30 | 1E | RS (record separator) | 记录分隔符 |
0001 1111 | 37 | 31 | 1F | US (unit separator) | 单元分隔符 |
0010 0000 | 40 | 32 | 20 | (space) | 空格 |
0010 0001 | 41 | 33 | 21 | ! | 叹号 |
0010 0010 | 42 | 34 | 22 | " | 双引号 |
0010 0011 | 43 | 35 | 23 | # | 井号 |
0010 0100 | 44 | 36 | 24 | $ | 美元符 |
0010 0101 | 45 | 37 | 25 | % | 百分号 |
0010 0110 | 46 | 38 | 26 | & | 和号 |
0010 0111 | 47 | 39 | 27 | ' | 闭单引号 |
0010 1000 | 50 | 40 | 28 | ( | 开括号 |
0010 1001 | 51 | 41 | 29 | ) | 闭括号 |
0010 1010 | 52 | 42 | 2A | * | 星号 |
0010 1011 | 53 | 43 | 2B | + | 加号 |
0010 1100 | 54 | 44 | 2C | , | 逗号 |
0010 1101 | 55 | 45 | 2D | - | 减号/破折号 |
0010 1110 | 56 | 46 | 2E | . | 句号 |
00101111 | 57 | 47 | 2F | / | 斜杠 |
00110000 | 60 | 48 | 30 | 0 | 数字0 |
00110001 | 61 | 49 | 31 | 1 | 数字1 |
00110010 | 62 | 50 | 32 | 2 | 数字2 |
00110011 | 63 | 51 | 33 | 3 | 数字3 |
00110100 | 64 | 52 | 34 | 4 | 数字4 |
00110101 | 65 | 53 | 35 | 5 | 数字5 |
00110110 | 66 | 54 | 36 | 6 | 数字6 |
00110111 | 67 | 55 | 37 | 7 | 数字7 |
00111000 | 70 | 56 | 38 | 8 | 数字8 |
00111001 | 71 | 57 | 39 | 9 | 数字9 |
00111010 | 72 | 58 | 3A | : | 冒号 |
00111011 | 73 | 59 | 3B | ; | 分号 |
00111100 | 74 | 60 | 3C | < | 小于 |
00111101 | 75 | 61 | 3D | = | 等号 |
00111110 | 76 | 62 | 3E | > | 大于 |
00111111 | 77 | 63 | 3F | ? | 问号 |
01000000 | 100 | 64 | 40 | @ | 电子邮件符号 |
01000001 | 101 | 65 | 41 | A | 大写字母A |
01000010 | 102 | 66 | 42 | B | 大写字母B |
01000011 | 103 | 67 | 43 | C | 大写字母C |
01000100 | 104 | 68 | 44 | D | 大写字母D |
01000101 | 105 | 69 | 45 | E | 大写字母E |
01000110 | 106 | 70 | 46 | F | 大写字母F |
01000111 | 107 | 71 | 47 | G | 大写字母G |
01001000 | 110 | 72 | 48 | H | 大写字母H |
01001001 | 111 | 73 | 49 | I | 大写字母I |
01001010 | 112 | 74 | 4A | J | 大写字母J |
01001011 | 113 | 75 | 4B | K | 大写字母K |
01001100 | 114 | 76 | 4C | L | 大写字母L |
01001101 | 115 | 77 | 4D | M | 大写字母M |
01001110 | 116 | 78 | 4E | N | 大写字母N |
01001111 | 117 | 79 | 4F | O | 大写字母O |
01010000 | 120 | 80 | 50 | P | 大写字母P |
01010001 | 121 | 81 | 51 | Q | 大写字母Q |
01010010 | 122 | 82 | 52 | R | 大写字母R |
01010011 | 123 | 83 | 53 | S | 大写字母S |
01010100 | 124 | 84 | 54 | T | 大写字母T |
01010101 | 125 | 85 | 55 | U | 大写字母U |
01010110 | 126 | 86 | 56 | V | 大写字母V |
01010111 | 127 | 87 | 57 | W | 大写字母W |
01011000 | 130 | 88 | 58 | X | 大写字母X |
01011001 | 131 | 89 | 59 | Y | 大写字母Y |
01011010 | 132 | 90 | 5A | Z | 大写字母Z |
01011011 | 133 | 91 | 5B | [ | 开方括号 |
01011100 | 134 | 92 | 5C | \ | 反斜杠 |
01011101 | 135 | 93 | 5D | ] | 闭方括号 |
01011110 | 136 | 94 | 5E | ^ | 脱字符 |
01011111 | 137 | 95 | 5F | _ | 下划线 |
01100000 | 140 | 96 | 60 | ` | 开单引号 |
01100001 | 141 | 97 | 61 | a | 小写字母a |
01100010 | 142 | 98 | 62 | b | 小写字母b |
01100011 | 143 | 99 | 63 | c | 小写字母c |
01100100 | 144 | 100 | 64 | d | 小写字母d |
01100101 | 145 | 101 | 65 | e | 小写字母e |
01100110 | 146 | 102 | 66 | f | 小写字母f |
01100111 | 147 | 103 | 67 | g | 小写字母g |
01101000 | 150 | 104 | 68 | h | 小写字母h |
01101001 | 151 | 105 | 69 | i | 小写字母i |
01101010 | 152 | 106 | 6A | j | 小写字母j |
01101011 | 153 | 107 | 6B | k | 小写字母k |
01101100 | 154 | 108 | 6C | l | 小写字母l |
01101101 | 155 | 109 | 6D | m | 小写字母m |
01101110 | 156 | 110 | 6E | n | 小写字母n |
01101111 | 157 | 111 | 6F | o | 小写字母o |
01110000 | 160 | 112 | 70 | p | 小写字母p |
01110001 | 161 | 113 | 71 | q | 小写字母q |
01110010 | 162 | 114 | 72 | r | 小写字母r |
01110011 | 163 | 115 | 73 | s | 小写字母s |
01110100 | 164 | 116 | 74 | t | 小写字母t |
01110101 | 165 | 117 | 75 | u | 小写字母u |
01110110 | 166 | 118 | 76 | v | 小写字母v |
01110111 | 167 | 119 | 77 | w | 小写字母w |
01111000 | 170 | 120 | 78 | x | 小写字母x |
01111001 | 171 | 121 | 79 | y | 小写字母y |
01111010 | 172 | 122 | 7A | z | 小写字母z |
01111011 | 173 | 123 | 7B | { | 开花括号 |
01111100 | 174 | 124 | 7C | | | 垂线 |
01111101 | 175 | 125 | 7D | } | 闭花括号 |
01111110 | 176 | 126 | 7E | ~ | 波浪号 |
01111111 | 177 | 127 | 7F | DEL (delete) | 删除 |
相关文章推荐
- 【C++】中文编码方式总结
- 计算机中数据的编码方式
- python 编码方式总结
- 非接触IC卡中typeA卡和typeB卡的区别--总结,二者的调制方式和编码方式不同
- 计算机中二进制数据的编码方式,整理了两篇他人的博客
- nodeJS读写文件中文乱码问题整理及计算机文件编码方式科普
- 计算机编码 - 更易懂的打开方式
- java字符编码方式总结
- java字符编码方式总结
- java学习总结(06,05.16)计算机对数据的储存方式以及原码反码补码的概念
- java字符编码方式总结
- 关于java下的明确编码方式的文件读写操作总结
- Unicode,UTF-8等编码方式的小总结
- 编码方式总结
- 中文编码方式总结
- 获取计算机中所以编码方式
- 计算机编码方式
- Ajax方式提交表单的常见编码类型总结
- 计算机中数值的编码方式
- 关于CAD各个版本使用编码方式的总结: