现在的位置: 首页 > 综合 > 正文

编码发展吏

2012年04月10日 ⁄ 综合 ⁄ 共 8324字 ⁄ 字号 评论关闭

GB2312 字符集

GB2312又称为GB2312-80字符集,全称为《信息交换用汉字编码字符集·基本集》,由原中国国家标准总局发布,198151 施,是中国国家标准的简体中文字符集。它所收录的汉字已经覆盖99.75%的使用频率,基本满足了汉字的计算机处理需要。在中国大陆和新加坡获广泛使用。

GB2312收录简化汉字及一般符号、序号、数字、拉丁字母、日文假名、希腊字母、俄文字母、汉语拼音符号、汉语注音字母,共 7445 个图形字符。其中包括6763个汉字,其中一级汉字3755个,二级汉字3008个;包括拉丁字母、希腊字母、日文平假名及片假名字母、俄语西里尔字母在 内的682个全角字符。

GB2312中对所收汉字进行了分区处理,每区含有94个汉字/符号。这种表示方式也称为区位码。

它是用双字节表示的,两个字节中前面的字节为第一字节,后面的字节为第二字节。习惯上称第一字节为高字节,而称第二字节为低字节高位字节使用了0xA1-0xF7(01-87区的区号加上0xA0)低位字节使用了0xA1-0xFE( 01-94加上0xA0)

GB2312字符集的第一个汉字字为例,它的区号16,位号01,则区位码是1601,在大多数计算机程序中,高字节和低字节分别加0xA0得到程序的汉字处理编码0xB0A1。计算公式是:0xB0=0xA0+16, 0xA1=0xA0+1

GBK字符集
GBK
字符集是GB2312的扩展(K)GBK1.0收录了21886个符号,它分为汉字区和图形符号区,汉字区包括21003个字符。GBK字符集主要扩展了繁体中文字的支持。

BIG5 字符集

BIG5又称大五码或五大码,1984年由台湾财团法人信息工业策进会和五间软件公司宏碁 (Acer)、神通 (MiTAC)、佳佳、零壹 (Zero One)、大众 (FIC)创立,故称大五码Big5的产生,是因为当时台湾不同厂商各自推出不同的编码,如倚天码、IBM PS55、王安码等,彼此不能兼容;另一方面,台湾政府当时尚未推出官方的汉字编码,而中国大陆的GB2312编码亦未有收录繁体中文字。

Big5字符集共收录13,053个中文字,该字符集在中国台湾使用。耐人寻味的是该字符集重复地收录了两个相同的字:”(0xA4610xC94A)”(0xDCD10xDDFC)

Big5使用了双字节储存方法,以两个字节来编码一个字。第一个字节称为高位字节,第二个字节称为低位字节。高位字节的编码范围0xA1-0xF9,低位字节的编码范围0x40-0x7E0xA1-0xFE

尽管Big5内包含一万多个字符,但是没有考虑社会上流通的人名、地名用字、方言用字、化学及生物科等用字,没有包含日文平假名及片假字母。

例如台湾视的异体字,故没有收录字。康熙字典中的一些部首用字()、常见的人名用字() 也没有收录到Big5之中。

GB18030 字符集

GB18030的全称是GB18030-2000《信息交换用汉字编码字符集基本集的扩充》,是我国政府于2000317发布的新的汉字编 码国家标准,2001831后在中国市场上发布的软件必须符合本标准。GB 18030字符集标准的出台经过广泛参与和论证,来自国内外知名信息技术行业的公司,信息产业部和原国家质量技术监督局联合实施。

GB 18030字符集标准解决汉字、日文假名、朝鲜语和中国少数民族文字组成的大字符集计算机编码问题。该标准的字符总编码空间超过150万个编码位,收录了 27484个汉字,覆盖中文、日文、朝鲜语和中国少数民族文字。满足中国大陆、香港、台湾、日本和韩国等东亚地区信息交换多文种、大字量、多用途、统一编 码格式的要求。并且与Unicode 3.0版本兼容,填补Unicode扩展字符字汇统一汉字扩展A”的内容。并且与以前的国家字符编码标准(GB2312GB13000.1)兼容。

编码方法:
GB 18030
标准采用单字节、双字节和四字节三种方式对字符编码。单字节部分使用0×007F(对应于ASCII码的相应码)。双字节部分,首字节 码从0×810×FE,尾字节码位分别是0×400×7E0×800×FE。四字节部分采用GB/T 11383未采用的0×300×39作为对双字节编码扩充的后缀,这样扩充的四字节编码,其范围为0×813081300×FE39FE39。其中第 一、三个字节编码码位均为0×810×FE,第二、四个字节编码码位均为0×300×39

按照程序员的称呼,GB2312GBKGB18030都属于双字节字符集 (DBCS)

接着是国际通用的unicode字符集

Unicode字符集(简称为UCS

1.名称的由来

Unicode字符集编码是(Universal Multiple-Octet Coded Character Set 通用多八位编码字符集的简称,支持世界上超过650种语言的国际字符集。Unicode允许在同一服务器上混合使用不同语言组的不同语言。它是由一个名为 Unicode 学术学会(Unicode Consortium)的机构制订的字符编码系统,支持现今世界各种不同语言的书面文本的交换、处理及显示。该编码于1990年开始研发,1994年正式 公布,最新版本是2005331Unicode 4.1.0Unicode是一种在计算机上使用的字符编码。它为每种语言中的每个字符设定了统一并且唯一的二进制编码,以满足跨语言、跨平台进行文本转 换、处理的要求。

2.编码方法

Unicode 标准始终使用十六进制数字,而且在书写时在前面加上前缀“U+”,例如字母“A”的编码为 004116 。所以“A”的编码书写为“U+0041”

3UTF-8 编码
UTF-8
Unicode的其中一个使用方式。 UTF Unicode Translation Format,即把Unicode转做某种格式的意思。

UTF-8便于不同的计算机之间使用网络传输不同语言和编码的文字,使得双字节的Unicode能够在现存的处理单字节的系统上正确传输。

UTF-8使用可变长度字节来储存 Unicode字符,例如ASCII字母继续使用1字节储存,重音文字、希腊字母或西里尔字母等使用2字节来储存,而常用的汉字就要使用3字节。辅助平面字符则使用4字节。

4UTF-16 UTF-32 编码
UTF-32
UTF-16 UTF-8 Unicode 标准的编码字符集的字符编码方案,UTF-16 使用一个或两个未分配的 16 位代码单元的序列对 Unicode 代码点进行编码;UTF-32 即将每一个 Unicode 代码点表示为相同值的 32 位整数

通过一个问题了解unicode编码

问题:使用Windows记事本的另存为,可以在ANSIGBKUnicodeUnicode big endianUTF-8这几种编码方式间相互转换。同样是txt文件,Windows怎样识别编码方式的呢?
我很早前就发现UnicodeUnicode big endianUTF-8编码的txt文件的开头会多出几个字节,分别是FFFEUnicode,FEFFUnicode big endian,EFBBBFUTF-8)。但这些标记是基于什么标准呢?

答案:

ANSI字符集定义:ASCII字符集,以及由此派生并兼容的字符集,如:GB2312,正式的名称为MBCS(Multi-Byte Chactacter System,多字节字符系统),通常也称为ANSI字符集。

UNICODE UTF8UTF16

由于每种语言都制定了自己的字符集,导致最后存在的各种字符集实在太多,在国际交流中要经常转换字符集非常不便。因此,产生了Unicode字符集,它固定使用16 bits(两个字节)来表示一个字符,共可以表示65536个字符
标准的 Unicode 称为UTF-16(UTF:UCS Transformation Format )。后来为了双字节的Unicode能够在现存的处理单字节的系统上正确传输,出现了UTF-8,使用类似MBCS的方式对Unicode进行编码。 (Unicode字符集有多种编码形式)
例如"连通"两个字的Unicode标准编码UTF-16 (big endian)为:DE 8F1A 90
而其UTF-8编码为:E8 BF 9E E9 80 9A

当一个软件打开一个文本时,它要做的第一件事是决定这个文本究竟是使用哪种字符集的哪种编码保存的。软件一般采用三种方式来决定文本的字符集和编码:
检测文件头标识,提示用户选择,根据一定的规则猜测
最标准的途径是检测文本最开头的几个字节,开头字节 Charset/encoding,如下表:
EF BB BF UTF-8
FE FF UTF-16/UCS-2, little endian
FF FE UTF-16/UCS-2, big endian
FF FE 00 00 UTF-32/UCS-4, little endian.
00 00 FE FF UTF-32/UCS-4, big-endian.

1big endianlittle endian
big endian
little endianCPU处理多字节数的不同方式。例如字的Unicode编码是6C49。那么写到文件里时,究竟是将6C写在前面,还是将49写在前 面?如果将6C写在前面,就是big endian。还是将49写在前面,就是little endian
“endian”
这个词出自《格列佛游记》。小人国的内战就源于吃鸡蛋时是究竟从大头(Big-Endian)敲开还是从小头(Little-Endian)敲开,由此曾发生过六次叛乱,其中一个皇帝送了命,另一个丢了王位。
我们一般将endian翻译成字节序,将big endianlittle endian称作大尾小尾

2、字符编码、内码,顺带介绍汉字编码
字符必须编码后才能被计算机处理。计算机使用的缺省编码方式就是计算机的内码。早期的计算机使用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
ASCIIGB2312GBKGB18030,这些编码方法是向下兼容的,即同一个字符在这些方案中总是有相同的编码,后面的标准支 持更多的字符。在这些编码中,英文和中文可以统一地处理。区分中文编码的方法是高字节的最高位不为0。按照程序员的称呼,GB2312GBK GB18030都属于双字节字符集 (DBCS)
有的中文Windows的缺省内码还是GBK,可以通过GB18030级包升级到GB18030。不过GB18030相对GBK增加的字符,普通人是很难用到的,通常我们还是用GBK指代中文Windows内码。
这里还有一些细节:
GB2312
的原文还是区位码,从区位码到内码,需要在高字节和低字节上分别加上A0
DBCS中,GB内码的存储格式始终是big endian,即高位在前。
GB2312
的两个字节的最高位都是1。但符合这个条件的码位只有128*128=16384个。所以GBKGB18030的低字节最高位都可 能不是1。不过这不影响DBCS字符流的解析:在读取DBCS字符流时,只要遇到高位为1的字节,就可以将下两个字节作为一个双字节编码,而不用管低字节 的高位是什么。

3UnicodeUCSUTF(UCS Transformation Format)
前面提到从ASCIIGB2312GBKGB18030的编码方法是向下兼容的。而Unicode只与ASCII兼容(更准确地说,是与ISO-8859-1兼容),与GB码不兼容。例如字的Unicode编码是6C49,而GB码是BABA

UCS规定了怎么用多个字节表示各种文字。而怎样传输这些编码,是由UTF(UCS Transformation Format)规范规定的!常见的UTF规范包括UTF-8UTF-7UTF-16

4UTF的字节序和BOM
UTF-8
以字节为编码单元,没有字节序的问题。UTF-16以两个字节为编码单元,在解释一个UTF-16文本前,首先要弄清楚每个编码单元的 字节序。例如收到一个Unicode编码是594EUnicode编码是4E59。如果我们收到UTF-16字节流“594E”,那么 这是还是
Unicode
规范中推荐的标记字节顺序的方法是BOMBOM不是“Bill Of Material”BOM表,而是Byte Order MarkBOM是一个有点小聪明的想法:
UCS编码中有一个叫做"ZERO WIDTH NO-BREAK SPACE"的字符,它的编码是FEFF。而FFFEUCS中是不存在的字符,所以不应该出现在实际传输中。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来标记文本文件的编码方式的。

写到这里对编码有了大致的了解了,就可以理解网上一些文章的话了,比如有一篇很流行的文章《URL编码与SQL注射》里面有一段是这么说的:

其实url编码就是一个字符ascii码的十六进制。不过稍微有些变动,需要在前面加上“%”。比如“\”,它的ascii码是9292的十六 进制是5c,所以“\”url编码就是%5c。那么汉字的url编码呢?很简单,看例子:ascii码是-17670,十六进制是BAFA url编码是“%BA%FA”。呵呵,知道怎么转换的了吧。

这得从ASCII说起,扩展的ASCII字符集采用8bit255个字符显然不够用,于是各个国家纷纷制定了自己的文字编码规范,其中中文的文字 编码规范叫做“GB2312-80”(就是GB2312),它是和ASCII兼容的一种编码规范,其实就是用扩展ASCII没有真正标准化这一点,把一个 中文字符用两个扩展ASCII字符来表示。文中说的的中文ASCII码实际上就是简体中文的编码2312GB!它把ASCII又扩充了一个字节,由于高位 的第一位是0,所以会出现负数的形式,url编码就是将汉字的这个GB2312编码转化成UTF-8的编码并且每8位即一个字节前面加上%符号表示。

那为何UTF-8是进行网络的规范传输编码呢?

Unicode里,所有的字符被一视同仁。汉字不再使用两个扩展ASCII”,而是使用“1Unicode”,注意,现在的汉字是一个字 了,于是,拆字、统计字数这些问题也就自然而然的解决了。但是,这个世界不是理想的,不可能在一夜之间所有的系统都使用Unicode来处理字符,所 Unicode在诞生之日,就必须考虑一个严峻的问题:和ASCII字符集之间的不兼容问题。

我们知道,ASCII字符是单个字节的,比如“A”ASCII65。而Unicode是双字节的,比如“A”Unicode0065,这就造成了一个非常大的问题:以前处理ASCII的那套机制不能被用来处理Unicode

另一个更加严重的问题是,C语言使用'\0'作为字符串结尾,而Unicode里恰恰有很多字符都有一个字节为0,这样一来,C语言的字符串函数将无法正常处理Unicode,除非把世界上所有用C写的程序以及他们所用的函数库全部换掉

于是,比Unicode更伟大的东东诞生了,之所以说它更伟大是因为它让Unicode不再存在于纸上,而是真实的存在于我们大家的电脑中。那就是:UTF

UTF= UCS Transformation Format UCS转换格式,它是将Unicode编码规则和计算机的实际编码对应起来的一个规则。现在流行的UTF2种:UTF-8UTF-16

其中UTF-16和上面提到的Unicode本身的编码规范是一致的,这里不多说了。而UTF-8不同,它定义了一种区间规则,这种规则可以 ASCII编码保持最大程度的兼容,这样做的好处是压缩了字符在西欧一些国家的内存消耗,减少了不必要的资源浪费,这在实际应用中是非常有必要的。

UTF-8有点类似于Haffman编码,它将Unicode编码为:
00000000-0000007F
的字符,用单个字节来表示;

00000080-000007FF的字符用两个字节表示 (中文的编码范围)

00000800-0000FFFF的字符用3字节表示

因为目前为止Unicode-16规范没有指定FFFF以上的字符,所以UTF-8最多是使用3个字节来表示一个字符。但理论上来说,UTF-8最多需要用6字节表示一个字符。

UTF-8里,英文字符仍然跟ASCII编码一样,因此原先的函数库可以继续使用。而中文的编码范围是在0080-07FF之间,因此是2个字节表示(但这两个字节和GB编码的两个字节是不同的)。

看看编码之多:ANSI,AscII,GB2312,GBK,BIG5,GB18030,Unicode,UCS(就是unicodeUtf-8,utf-16,utf-32 整整10种编码~,算是够复杂了
可是这还仅仅是个开始,应用方面变化无穷,不过现在看到这些东西起码再不会头大了!呼呼~

哦,漏了一个加密的base64编码。

什么是Base64

按照RFC2045的定义,Base64被定义为:Base64内容传送编码被设计用来把任意序列的8位字节描述为一种不易被人直接识别的形式。 The Base64 Content-Transfer-Encoding is designed to represent arbitrary sequences of octets in a form that need not be humanly readable.

为什么要使用Base64

在设计这个编码的时候,我想设计人员最主要考虑了3个问题:
1.
是否加密?
2.
加密算法复杂程度和效率
3.
如何处理传输?

加密是肯定的,但是加密的目的不是让用户发送非常安全的Email。这种加密方式主要就是防君子不防小人。即达到一眼望去完全看不出内容即可。
基于这个目的加密算法的复杂程度和效率也就不能太大和太低。和上一个理由类似,MIME协议等用于发送Email的协议解决的是如何收发 Email,而并不是如何安全的收发Email。因此算法的复杂程度要小,效率要高,否则因为发送Email而大量占用资源,路就有点走歪了。

但是,如果是基于以上两点,那么我们使用最简单的恺撒法即可,为什么Base64看起来要比恺撒法复杂呢?这是因为在Email的传送过程中,由 于历史原因,Email只被允许传送ASCII字符,即一个8位字节的低7位。因此,如果您发送了一封带有非ASCII字符(即字节的最高位是1)的 Email通过有历史问题的网关时就可能会出现问题。网关可能会把最高位置为0!很明显,问题就这样产生了!因此,为了能够正常的传送Email,这 个问题就必须考虑!所以,单单靠改变字母的位置的恺撒之类的方案也就不行了。关于这一点可以参考RFC2046
基于以上的一些主要原因产生了Base64编码。

抱歉!评论已关闭.