汉字字符集编码查询_刨根究底字符编码之十——Unicode字符集的字符编码方式...

fdff5123c1cda74263d159be32fb2a47.png

一、字符编码方式CEF的选择

1.

由于Unicode字符集非常大(并且作为开放字符集还在不断扩展之中),有些字符的编号(即码点值)需要两个或两个以上字节来表示,而要对这样的编号进行编码,也必须使用两个或两个以上字节。

比如,汉字“严”的Unicode编号以十六进制数表示为4E25,转换成二进制数有15位(100 1110 0010 0101),对“严”这个字符的编号进行编码的话,至少需要2个字节。表示其他更大编号的字符,可能需要3个字节或者4个字节,甚至更多。

2.

这带来两个问题:

一是,如何才能区别Unicode字符和ASCII字符的编码?计算机怎么知道三个字节表示的是一个字符,而不是分别表示三个字符呢?

二是,我们知道,英文字母只用一个字节来编码就够了,而如果Unicode统一硬性规定,每个字符都用两个、三个或四个字节来编码,那么每个英文字母编码的前面都必然有一个、两个到三个字节全是0,这对于存储和传输来说是极大的浪费。

这就涉及到了字符编码方式CEF的选择问题。Unicode字符的编码方式目前最常用的是这三种:UTF-8、UTF-16、UTF-32。在具体介绍这些编码方式之前,需要再次深入了解两个概念——码点(Code Point)与码元(Code Unit)。

二、码点

1.

一个字符集一般可以用一张或多张由多个行和多个列所构成的二维表来表示。

二维表中行与列相交的点,称之为码点(Code Point代码点),也称之为码位(Code position代码位);每个码点分配一个唯一的编号,称之为码点值或码点编号,除开某些特殊区域(比如代理区、专用区)的非字符码点和保留码点,每个码点唯一对应于一个字符。

因此,除开非字符码点和保留码点,码点值(即码点编号)通常来说就是其所对应的字符的编号,所以码点值有时也可以直接称之为字符编号,虽然不够准确,但更为直接。

2.

字符集中所有码点数量的总和,称之为编号空间(Code Space,又被称之为代码空间、编码空间、码点空间、码空间)。

码点值最初用两个字节的十六进制数字表示,比如字母A的Unicode码点值为0041,常写作U+0041,这种形式称为Unicode码点名称,不严格地来讲,也可称之Unicode字符名称(因为存在着非字符码点和保留码点,并非每个码点都分配了字符,所以这种称呼不够准确,不过目前更为普遍)。

3.

后来随着Unicode字符集的不断增补扩大(比如现在的Unicode字符集至少需要21位才能全部表示),码点值也扩展为用三个字节或以上的十六进制数字表示。

例如,ASCII字符集用0~127这连续的128个数字编号分别表示128个字符。GBK字符集使用区位码的方式为每个字符编号,首先定义一个94×94的矩阵,行称为“区”,列称为“位”,然后将所有国标汉字放入矩阵当中,这样每个汉字就可以用唯一的“区位”码来标识了。例如“中”字被放到54区第48位,因此其区位码(字符编号)就是5448。

而目前Unicode标准中,将字符按照一定的类别划分到0~16这17个平面(Plane层面)中,每个平面中拥有2^16 = 65536个码点,因此,目前Unicode字符集所拥有的码点总数,也就是Unicode的编号空间为17*65536=1114112。

f5d15ff2b24557728396b983856d334d.png

注意,网络上的很多文章中,代码点、码点、码点值、码值、代码位、码位、字符码、Unicode码、字符编号、字符编码、编码方案、编码方式、编码格式等等概念经常互相代替混用,让人困惑。

(笨笨阿林原创文章,转载请注明出处)

三、码元

1.

在计算机存储和网络传输时,码点值(即字符编号)被映射到一个或多个码元(Code Unit代码单元、编码单元)

码元可理解为字符编码方式CEF(Character Encoding Form)对码点值进行编码处理时作为一个整体来看待的最小基本单元(或称为最小基本单位)

2.

为什么非要引入“码元”这个概念?或者说,为什么非要强调“码元”这个概念?

码元某种程度上可认为对应于高级语言中的基本数据类型。而高级语言层面的基本数据类型,若要更深入一步地来讲,实质上对应于机器硬件层面(如汇编语言层面)的数据类型byte字节、word字、dword双字等在硬件中的表达与处理机制。

之所以要强调“码元”的概念,是因为字符编码作为一串数字序列,最终还是得通过机器硬件层面的数据类型来表示。

而码元的实质,就是机器硬件层面的数据类型;不同的码元,代表着不同位数的数据类型。当字符编码方案设计人员基于某种考虑(如时间复杂度、空间复杂度等)为某种字符编码方式CEF选择了某种码元时,其实质就是选择了某个位数的数据类型。

数据类型,在机器硬件层面上来看,只有作为一个整体来处理的二进制数字位数上的不同(如byte字节、word字、dword双字等汇编语言的数据类型,都是二进制数字值,只是位数不同而已),而并没有高级语言层面上的数值、布尔、字符等语义的不同,毕竟本质上来讲计算机只“认识”由0和1组成的数字。

正因为如此,字符编码方案设计人员在设计字符编码方式CEF时,必然要选择一种机器硬件层面上某个位数的数据类型(如byte字节、word字、dword双字等)来表示,不是选择这个位数的数据类型,就是选择那个位数的数据类型。当然这种选择会基于各种考虑,比如时间复杂度、空间复杂度等,不过一旦选择了某种数据类型,其所选择的数据类型位数上的不同,同时也就体现为了码元位数上的不同。

所以,不同位数的码元,实质上是机器硬件层面上不同位数的数据类型。(而机器硬件层面上为什么要设计不同位数的多种数据类型出来,这是另一个话题了,有兴趣可参看有关硬件方面的专著。)

3.

由于数据类型有单字节与多字节之分,所以码元也有单字节与多字节之分;而多字节数据类型由于历史的原因,存在着字节序的大端序(Big-Endian)与小端序(Little-Endian)之分,因此多字节码元也存在着大端序与小端序之分(具体详见前文中有关字节序的解释;注意,单字节数据类型是没有字节序的问题的,所以单字节码元也就没有字节序问题)。

这就是之所以要强调“码元”这个概念的关键原因。

4.

对字符编号(即字符码点值)进行编码的具体实现方式——字符编码方式CEF,就是由一个或多个码元这样的最小基本单元构成的。

最常用的码元是8位(即1字节)的单字节码元,另外还有16位(即2字节)和32位(即4字节)两种多字节码元,分别相当于汇编语言中的byte字节、word字、dword双字,以及C++中的无符号整型BYTE、WORD、DWORD。

(注: 在VC++6.0中,这三种数据类型的定义分别为:

   typedef unsigned char BYTE; // 1个字节

   typedef unsigned short WORD; // 2个字节

   typedef unsigned long DWORD; // 4个字节)

(笨笨阿林原创文章,转载请注明出处)

5.

于是,三种码元对应就有了Unicode字符编号的三种UTF编码方式(即Unicode码转换格式Unicode Transformation Format,或称通用字符集转换格式UCS Transformation Format):

   UTF-8,即8-bit Unicode/UCS Transformation Format;

   UTF-16,即16-bit Unicode/UCS Transformation Format;

   UTF-32,即32-bit Unicode/UCS Transformation Format。

或者反过来说,Unicode字符编号的三种UTF编码方式(UTF-8、UTF-16、UTF-32)分别采用了不同的码元(单字节、双字节、四字节)来编码。

a27b56b2c14033784e2352a27f25a03c.png

例如,“汉字”这两个中文字符的Unicode字符编号是0x6C49和0x5B57,其三种UTF编码在VC++6.0中可按如下定义进行“模拟”:

5c88ae4d5a0600633083b284f96a41d6.png

6.

注意,这里之所以说是“模拟”,其中的一个重要原因,如前文所述,从本质上来讲机器硬件层面上的所有数据类型,只存在着被视作一个整体来处理的比特序列(即二进制序列)的位数不同之分,不存在着高级语言层面上数据类型的数值、字符串、布尔值等的语义不同之分。

因此,机器硬件层面上的数据类型与高级语言层面上的数据类型,严格来讲,在含义上还是有着很大不同的。当然,高级语言层面上的数据类型最终还是会被转化为机器硬件层面上的数据类型,毕竟计算机只“认识”由0和1所组成的比特流。(可同时参见前文中有关字节序的解释)

7.

这里用BYTE、WORD、DWORD分别表示无符号8位整数、无符号16位整数和无符号32位整数;因而UTF-8、UTF-16、UTF-32可认为分别以BYTE、WORD、DWORD作为码元。

“汉字”这两个中文字符的UTF-8编码需要六个BYTE(共6个单字节码元),大小是6个字节;UTF-16编码需要两个WORD(共2个双字节码元),大小是4个字节;UTF-32编码需要两个DWORD(共2个四字节码元),大小是8个字节。

由于多字节数据类型的数据在计算机存取时存在一个字节序的问题,因此,UTF-16、UTF-32这两种编码方式所编码出来的逻辑意义上的多字节码元序列,在映射为物理意义上的字节序列时,字节序列的字节序因系统平台的不同而不同。

前面已经多次强调过了,这里再次特别强调一下:由单字节数据类型所组成的多字节数据是不存在字节序的问题的。因此,采用单字节码元进行编码的UTF-8编码,虽然ASCII字符为单字节编码,而非ASCII字符却是多字节编码的,但却并不存在字节序问题,这是跟同样为多字节编码、但却采用多字节码元的UTF-16、UTF-32编码的不同之处。详见下表所列。

     Unicode字符集三大编码方式(UTF-8、UTF-16、UTF-32)比较一览表

1f7ae00c60b6fed8242db7cdaeca062a.png

(笨笨阿林原创文章,转载请注明出处)

【预告:下一篇将重点讲解UTF-8编码方式与字节序标记(BOM),敬请关注!

上一篇:刨根究底字符编码之九--字符编码方案的演变与字节序 - 知乎专栏

下一篇:刨根究底字符编码之十一--UTF-8编码方式与字节序标记BOM - 知乎专栏

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值