Unicode是一个字符集,旨在收录全世界的每个字符,并为这些字符统一编码。
编码方式:
- 将世上所有字符按一定的依据,分为17个大的组别。官方话语里将每一个组别称为一个平面(plane)。
- 每个平面上有
2^16 = 65536
个位置,依次编号0000
-FFFF
,理论上可以用来保存65536
个字符。 - 这17个平面分别为 0~16号平面,用16进制数分别表示为
0
-10
。这样世上的每一个字符就有了一个编号。如:
编号U+0000
表示第一平面(0号平面)的第一个字符(注意不是U+00000
)
编号U+1FFFF
表示第二平面(1号平面)的最后一个字符
某个字符的统一编号叫做这个字符的 码点或码位(code point) - 0号平面称为基本多文种平面,包含了各种语言最常用的字符。如其
4E00-9FFF
段为中日韩统一表意文字。每个平面的基本信息如下图:
实现方式
Unicode只提供了字符集和每个字符的编码,但在计算机中每个字符的Unicode编码如何存储,先后产生了多种不同的实现方式,如目前流行的UTF-8。
UTF-8
是一种变长的编码方式,使用1-6个字节来保存字符的Unicode编码("8"是指表示一个字符最少需要8个比特位)。意思就是说表示某个字符的二进制串可能是1字节、2字节、3字节、...6字节。如:
字符a
的Unicode编码为U+0061
,也就是0号平面的第97个字符。计算机只需要存下它的序号97,即:0000 0000 0110 0001
的有效部分110 0001
,用1字节即可存储。
但是如果一个字符如ř
,U+0159
,二进制为0000 0001 0101 1001
,其有效部分是9位,那该如何表示呢?自然最少要两个字节。如果简单粗暴的直接用0000 0001 0101 1001
表示,又会带来其他麻烦,比如:当遇到一个连续的二进制串 0110 0001 0000 0001 0101 1001
,原想表达的是ař
,可机器怎么知道你是0110 0001,0000 0001 0101 1001
而不是0110 0001,0000 0001, 0101 1001
。所以这就需要有一种手段告诉机器,哪几个字节是用来一起表示一个字符的。utf8的方式是在每个字节前加固定标识:
- 单个字节标识一个字符的,其首位固定为 0
- n个字节标识一个字符的,其首字节以n个1接一个0开头,该字符剩下的字节以10开头
- 除去标识部分剩下的比特位,才是真正可用来有效部分的(所以不妨称为有效位)
即(其中x是有效比):
单字节字符: 0xxxxxxx
二字节字符: 110xxxxx 10xxxxxx
三字节字符: 1110xxxx 10xxxxxx 10xxxxxx
...
最初美国人制定了ascii字符集,共128个字符,一个字节最多能表示2^8=256个字符,而它只需要用128个,用 00000000~01111111就能表示完。所以最初的ascii编码是0xxxxxxx的形式,有最高位的 0是浪费着没用的。后来西欧各国利用高位未用的 0,把自己的字符也加进去了,如法语中的 é 编码为10000010,也是一个字节就能表示一个字符,这就是扩展后的ascii码。
注意到utf8里要求单字节字符的第一位是0,这意味着,在 utf8里 ascii拓展后的西欧各国的字符不会再是单字节了,拓展前的美国人最常用的字符,仍然还是单字节。
若n(n>1)个字节表示一个字符,除去标识部分后,有效位位数是5n+1
以汉字“赵”为例,详细说明其编码转换过程。
- 由
'赵'.charCodeAt(); //36265
可以得到,“赵”的码点为U+8d75
,转化成二进制就是1000 1101 0111 0101
。那么需要存储的就是16个比特位,根据5n+1,得出需要3个字节。所以“赵”的utf8编码格式是:
1110xxxx 10xxxxxx 10xxxxxx
在占位符上填入'赵'的二进制码点,得到赵的utf8编码:
11101000 10110101 10110101
UTF-16
utf16和utf8很像,也是变长编码,"16"是指表示一个字符最少需要16个比特位。其表示字符只有2字节、4字节两种情况:
二字节:xxxxxxxx xxxxxxxx
四字节:110110xx xxxxxxxx 110111xx xxxxxxxx
当字符为0号平面上的字符时,直接用其码点是二进制码表示。如:
“赵” U+8d75
用 1000 1101 0111 0101
表示。
当字符不是0号平面上的字符时, 转换算法如下:
以汉字“𧅄" U+27144为例,
- 码点减去 0x10000,得到 17144
-
转换成二进制 得到
0001 0111 0001 0100 0100
-
把上步得到的20个比特位,按110110xx xxxxxxxx 110111xx xxxxxxxx格式填入
得到11011000 01011100
11011101 01000100
其前两个字节 11011000 01011100 = 55388,所以'𧅄'.charCodeAt(0) === 55388
值得一提的是,js内部使用的是utf16储存字符(JavaScript 引擎内部是自由的使用 UCS-2 或者 UTF-16。大多数引擎使用的是 UTF-16),1个字符2个字节,并规定2个字节的length为1,所以'赵'.length === 1
,0号平面以外的字符,如'𧅄'.length === 2
UTF-32
能找到的详细介绍utf-32的资料太少了,以下内容出自 wiki
UTF-32是32位Unicode转换格式(Unicode Transformation Formats, 或UTF)的缩写。UTF-32是一种用于编码Unicode的协定,该协定使用32位比特对每个Unicode码位进行编码(但前导比特数必须为零,故仅能表示221个Unicode码位)。与其他可变长度的Unicode转换格式(UTF)相比,UTF-32编码长度是固定的,UTF-32中的每个32位值代表一个Unicode码位,并且与该码位的数值完全一致。
只能根据最后一句话 "UTF-32中的每个32位值代表一个Unicode码位,并且与该码位的数值完全一致。",推测其编码实现应该就是直接将码点转换成32位二进制码。
如:“赵” U+8d75
,00000000 00000000 01001101 01110101
字节序 (Endianness)
在计算机中,对多个字节的二进制数如何存储,不同架构的cpu有不同的处理方式。分为以下两种处理方式:
- Big-Endian(大端序)就是高位字节排放在内存的低地址端,低位字节排放在内存的高地址端。换言之,先从内存中读取到的字节,是高位。即高位在前。
- Little-Endian(小端序)就是低位字节排放在内存的低地址端,高位字节排放在内存的高地址端。简言之,低位在前。
如有二进制数 10101011 00110011 (0xab33),其高位字节是ab,低位字节是33。
假设有低位地址0x0000,高位地址0x0001。
0x0000存放ab,0x0001存放33,就是大端序;
0x0000存放33,0x0001存放ab,就是小端序。
假如某台机器,其使用的是小端序。它的读和写都是小端序,它就无需考虑字节序问题,程序总能正常运行。但是当它和另外一台机器交流时,就需要考虑字节序问题。
比如一台小端序的机器,打开了一个大端序编码的文本文件,如果不做任何处理,读取内容就会出问题。
所以文本文件,在生成的时候,会在文本文件头部加上一个标识,表明其字节序(以及其实现方式:utf8 / utf16 / utf32)。
比如,当读取一个文本时,如果读到的开头字节是FE FF,则说明这是一个utf16编码的文本,且是大端序。其标识(BOM ,Byte Order Mark,字节顺序标记)具体对应规则如下图:
现在来一个实例看一下:
我本地有个文本文件:
image.png
可以看到原始状态是utf8编码的,点击图中右下角的红框,将其转化为UTF-16BE
image.png
然后用node的fs读一下文件:
image.png
发现其开头二字节是FF FE,对照上表,完全符合。
需要说明的是,虽然utf8/16/32前面都有这个标识,但实际上utf8是不存在字节序问题的,这是因为utf8的基本处理长度是一个字节。原因如下:
由前面的utf8的编码实现方式可知,每个字节的开头只能是三种情况:
- 0开头,如0xxxxxxx,表明这个字符只有一个字节
- 10开头,如10xxxxxx,表明这个字符有n个字节,且本字节不是第一个字节
- 1...10开头,如1110,表明这个字符有3个字节,且本字节是第一个字节
现在有文本,"你好a"。假设其utf8编码是:
110xxxxx 10xxxxxx
(你),1110xxxx 10xxxxxx 10xxxxxx
(好),0xxxxxxx
(a),共6字节长。
如果是大端序存储,则读取到的数据为:
110xxxxx 10xxxxxx,1110xxxx 10xxxxxx 10xxxxxx,0xxxxxxx
如果是小端序存储,则读取到的数据为:
10xxxxxx 110xxxxx,10xxxxxx 10xxxxxx 1110xxxx,0xxxxxxx
读取某字符的首字节时,其开头:
如果是0开头,知道这个字符只有这一个字节,可以解析。
如果是10开头,知道这是小端序,只需要继续往下读,读到1..10开头的字节时,这个字符结束,可以解析。
如果是1110开头,知道这是大端序,知道这个字符是3个字节,再读两个字节即可解析。
所以,utf8不是不存在字节序问题,而是它自己能判断。
utf16就不一样了,如中文“啊”,00110011 00101010,简记为554A。
以小端序编码会存为 4A55,当一台大端序的机器读取时,就会认为其码点是 u+4A55。此时因为没有信息告诉机器,需要纠正为u+554A,就会解析成其他字符。
utf32也是同样的道理。
网友评论