首先用一个生动的文章来开头,文章已经被转载坏了,所以出处不详,见谅
———————————————————————–文章开始—————————————————————————-
很久很久以前,有一群人,他们决定用8个可以开合的晶体管来组合成不同的状态,以表示世界上的万物。他们看到8个开关状态是好的,于是他们把这称为“字节”。
再后来,他们又做了一些可以处理这些字节的机器,机器开动了,可以用字节来组合出很多状态,状态开始变来变去。他们看到这样是好的,于是它们就这机器称为“计算机”。
开始计算机只在美国用。八位的字节一共有256种不同的状态。
他们把其中的编号从0开始的32种状态分别规定了特殊的用途,一但终端、打印机遇上这些字节被传过来时,就要做一些约定的动作。于是打印机会打印反白的字了(0x1b…),会换行(0x10)了,终端会嘟嘟(0x07)叫了,有色彩(0x1b…)了。他们看到这样很好,于是就把这些0x20以下的字节状态称为“控制码”。他们又把所有的空格、标点符号、数字、大小写字母分别用连续的字节状态表示,一直编到了第127号,这样计算机就可以用不同字节来存储英语的文字了。大家看到这样,都感觉很好,于是大家都把这个方案叫做ANSI的“Ascii”编码(American Standard Code for Information Interchange,美国信息互换标准代码),所有的计算机都用同样的ASCII方案来保存英文文字。
后来,就像建造巴比伦塔一样,世界各地的都开始使用计算机,但是很多国家用的不是英文,他们的字母里有许多是ASCII里没有的,为了可以在计算机保存他们的文字,他们决定采用127号之后的空位来表示这些新的字母、符号,还加入了很多画表格时需要用下到的横线、竖线、交叉等形状,一直把序号编到了最后一个状态255。从128到255这一页的字符集被称“扩展字符集”。从此之后,贪婪的人类再没有新的状态可以用了,美帝国主义可能没有想到还有第三世界国家的人们也希望可以用到计算机吧!
等中国人们得到计算机时,已经没有可以利用的字节状态来表示汉字,况且有6000多个常用汉字需要保存呢。但是这难不倒智慧的中国人民,我们直接不客气地把那些127号之后的奇异符号们取消掉, 规定:两个连续字节表示一个汉字,高字节(前面的一个字节)从0xA1用到0xF7,低字节从0xA1到0xFE,这样我们就可以组合出大约7000多个简体汉字了。在这些编码里,我们还把数学符号、罗马希腊的字母、日文的假名们都编进去了,连在ASCII里本来就有的数字、标点、字母都统统重新编了两个字节长的编码,这就是常说的“全角”字符,而原来在127号以下的那些就叫“半角”字符了。
中国人民看到这样很不错,于是就把这种汉字方案叫做“GB2312”。GB2312是对ASCII的中文扩展。
但是中国的汉字太多了,我们很快就就发现有许多人的人名没有办法在这里打出来,于是我们不得不继续把GB2312没有用到的码位找出来老实不客气地用上。
后来还是不够用,于是干脆不再要求低字节一定是127号之后的内码,只要第一个字节是大于127就固定表示这是一个汉字的开始,不管后面跟的是不是扩展字符集里的内容。结果扩展之后的编码方案被称为GBK标准,GBK包括了GB2312的所有内容,同时又增加了近20000个新的汉字(包括繁体字)和符号。
后来少数民族也要用电脑了,于是我们再扩展,GBK扩成了GB18030,又加了几千个新的少数民族的字。从此之后,中华民族的文化就可以在计算机时代中传承了。
中国的程序员们看到这一系列汉字编码的标准是好的,于是通称他们叫做“DBCS”(Double byte charecter set双字节字符集)。在DBCS系列标准里,单字节字符和双字节字符同时存在,因此他们写的程序为了支持中文处理,必须要注意字串里的每一个字节的值,如果这个值是大于127的,那么就认为一个双字节字符集里的字符出现了。那时候凡是受过加持,会编程的人都要每天念下面这个咒语数百遍:“一个汉字算两个英文字符!一个汉字算两个英文字符……”
但是世界民族之林中,还有很不少用不上电脑的少数民族,他们的文字怎么办?而且各个国家都像中国这样搞出一套自己的编码标准,结果互相之间谁也不懂谁的编码,谁也不支持别人的编码。当时的中国人想让电脑显示汉字,就必须装上一个“汉字系统”,专门用来处理汉字的显示、输入的问题,但是那个台湾的愚昧封建人士写的算命程序就必须加装另一套支持BIG5编码的什么“倚天汉字系统”才可以用。
真是计算机的巴比伦塔命题啊!
正在这时,国际标谁化组织ISO及时出现了,他们决定废了所有的地区性编码方案,重新搞一个包括了地球上所有文化、所有字母和符号的编码来,还打算叫它“Universal Multiple-Octet Coded Character Set”,简称UCS, 俗称“UNICODE”。
UNICODE开始制订时,计算机的存储器容量极大地发展了,空间再也不成为问题了。于是ISO就没有考虑与ANSI兼容的问题,而直接规定必须用两个字节,也就是16位来统一表示所有的字符,由于“半角”英文符号只需要用到低8位,所以其高位永远是0,因此这种大气的方案在保存英文文本时会多浪费一倍的空间。
这时候,从旧社会里走过来的程序员开始发现一个奇怪的现象:他们的strlen函数靠不住了,一个汉字不再是相当于两个字符了,而是一个!是的,从UNICODE开始,无论是半角的英文字母,还是全角的汉字,它们都是统一的“一个字符!”同时,也都是统一的“两个字节”,请注意“字符”和“字节”两个术语的不同。UNICODE的一个字符就是两个字节。一个汉字算两个英文字符的时代已经快过去了。
多种字符集存在时,那些做多语言软件的公司遇上了很大麻烦,他们在区域化软件时不得不也加持那个双字节字符集咒语,还要处处小心不要搞错。UNICODE对于他们来说是一个很好的一揽子解决方案,于是从Windows NT开始,MS趁机把它们的操作系统改了一遍,把所有的核心代码都改成了兼容UNICODE的版本,从这时开始,WINDOWS系统终于无需要加装各种本土语言系统,就可以显示全世界上所有文化的字符了。
但是,UNICODE在制订时没有考虑与任何一种现有的编码方案保持兼容,这使得GBK与UNICODE在汉字的内码编排上完全是不一样的,没有一种简单的算术方法可以把文本内容从一个编码转换到另一种编码,这种转换必须通过查表来进行。
如前所述,UNICODE是用两个字节来表示为一个字符,他总共可以组合出65535不同的字符,这大概已经可以覆盖世界上所有文化的符号。如果还不够也没有关系,ISO已经准备了UCS-4方案,说简单了就是四个字节来表示一个字符,这样我们就可以组合出21亿个不同的字符出来(最高位有其他用途),这大概可以用到银河联邦成立那一天吧!
UNICODE来到时,一起到来的还有计算机网络的兴起,UNICODE如何在网络上传输也是一个必须考虑的问题,于是面向传输的众多UTF(UCS Transfer Format)标准出现了,顾名思义,UTF8就是每次8个位传输数据,而UTF16就是每次16个位,只不过为了传输时的可靠性,从UNICODE到UTF时并不是直接的对应,而是要过一些算法和规则来转换。
受到过网络编程加持的计算机僧侣们都知道,在网络里传递信息时有一个很重要的问题,就是对于数据高低位的解读方式,一些计算机是采用低位先发送的方法,例如我们的INTEL架构,而另一些是采用高位先发送的方式,在网络中交换数据时,为了核对双方对于高低位的认识是否是一致的,采用了一种很简便的方法,就是在文本流的开始时向对方发送一个标志符——如果之后的文本是高位在位,那就发送“FEFF”,反之,则发送“FFFE”。不信你可以用二进制方式打开一个UNICODE或是UTF-X格式的文件,看看开头两个字节是不是这两个字节?
讲到这里,我们再顺便说说一个很著名的奇怪现象:当你在windows的记事本里新建一个文件,输入“联通”两个字之后,保存,关闭,然后再次打开,你会发现这两个字已经消失了,代之的是几个乱码!呵呵,有人说这就是联通之所以拼不过移动的原因。
其实这是因为GB2312编码与UTF8编码产生了编码冲撞的原因。
从网上引来一段从UNICODE到UTF8的转换规则:
Unicode | UTF-8 |
---|---|
0000 - 007F | 0xxxxxxx |
0080 - 07FF | 110xxxxx xxxxxxxx |
0800 - FFFF | 1110xxxx xxxxxxxx xxxxxxxx |
例如“汉”字的Unicode编码是6C49。6C49在0800-FFFF之间,所以肯定要用3字节模板了:1110xxxx 10xxxxxx 10xxxxxx。将6C49写成二进制是:0110 1100 0100 1001,将这个比特流按三字节模板的分段方法分为0110 110001 001001,依次代替模板中的x,得到:1110-0110 10-110001 10-001001,即E6 B1 89,这就是其UTF8的编码。
而当你新建一个文本文件时,记事本的编码默认是ANSI, 如果你在ANSI的编码输入汉字,那么他实际就是GB系列的编码方式,在这种编码下,“联想”的内码是:
c1 | 1100 |
aa | 1010 |
cd | 1100 |
a8 | 1010 |
注意到了吗?第一二个字节、第三四个字节的起始部分的都是“110”和“10”,正好与UTF8规则里的两字节模板是一致的,于是再次打开记事本时,记事本就误认为这是一个UTF8编码的文件,让我们把第一个字节的110和第二个字节的10去掉,我们就得到了“00001 101010”,再把各位对对齐,补上前导的0,就得到了“0000 0000 0110 1010”,不好意思,这是UNICODE的006A,也就是小写的字母“j”,而之后的两字节用UTF8解码之后是0368,这个字符什么也不是。这就是只有“联通”两个字的文件没有办法在记事本里正常显示的原因。
而如果你在“联通”之后多输入几个字,其他的字的编码不见得又恰好是110和10开始的字节,这样再次打开时,记事本就不会坚持这是一个utf8编码的文件,而会用ANSI的方式解读之,这时乱码又不出现了。
好了,终于可以回答NICO的问题了,在数据库里,有n前缀的字串类型就是UNICODE类型,这种类型中,固定用两个字节来表示一个字符,无论这个字符是汉字还是英文字母,或是别的什么。
如果你要测试“abc汉字”这个串的长度,在没有n前缀的数据类型里,这个字串是7个字符的长度,因为一个汉字相当于两个字符。而在有n前缀的数据类型里,同样的测试串长度的函数将会告诉你是5个字符,因为一个汉字就是一个字符。
———————————————————————–文章结束—————————————————————————-
注意:文中某些地方把Unicode和UTF-16当做同一个概念,在winOS中也是如此定义的
以下进行总结和拓展,首先熟悉几个名词
1,ASCII:American Standard Code for Information Interchange, “美国信息交换标准码”
2,Unicode:Universal Multiple-Octet Coded Character Set”,简称 UCS, 俗称 “unicode“
3,UTF(unicode transformation format):unicode转化标准
4,GBK:汉字内码扩展规范,(”国家标准扩展”的拼音简写)
ASCII:长度为一个字节,即8bit,第一位总为0,剩余7位是实际表示内容,所以可以表示2的7次方个字符
UTF-8,UTF-16,UTF-32的区别
我们姑且将字节长度固定的编码称为定长编码,字节长度可变的编码称为变长编码
1,定长编码和变长编码:首先UTF-8和UTF-16都是变长编码,UTF-8字节长度取值范围为(1,2,3,4),UTF-16的字节长度取值范围为(2,4),注意许多程序甚至是语言并没有对UTF-16支持可变字节长度,所以UTF-16在多数环境下是定长编码,即2个字节长度,至于UTF-32就是4个字节长度的定长编码。
说到这里,就有必要说明一下UTF-8作为变长编码的原理了。
UTF-8作为1个字节长度的格式:0xxxxxxx(可以表示2的7次方个字符)
UTF-8作为2个字节长度的格式:110xxxxx 10xxxxxx(可以表示2的11次方个字符)
UTF-8作为3个字节长度的格式:1110xxxx 10xxxxxx 10xxxxxx(可以表示2的16次方个字符)
UTF-8作为4个字节长度的格式:11110xxx 10xxxxxx 10xxxxxx 10xxxxxx(可以表示2的21次方个字符)
其中x表示此位为2进制,如果计算机检测到是以2进制的0开头的UTF-8编码,那么计算机就会讲这一个字节作为一个单元来处理(此时和ASCII编码一致),如果检测到是以110开头的UTF-8编码,那么就会将此字节以及此字节之后的第一个10开头的字节作为一个单元来出来,3个字节长度的UTF-8原理相同,不再多说了,举个栗子。
还是“汉”字,使用UTF-16编码,转化成2进制就是01101100 01001001,将此2进制转化成10进制就是27721,显然不在0-2048(2的11次方)之间 ,那么如果要使用UTF-8进行编码,就必定需要3个字节长度的UTF-8,据以上3个字节长度的UTF-8格式,“汉”字的UTF-8编码应为11100110 10110001 10001001。
2,定长编码效率更高:无论是执行索引操作,还是计算字符数,变长编码的效率都要更低一些。比如定长编码读到内存中之后是一个均匀的整形数组(都用2个字节或者都用4个字节当做一个字符),当需要随机访问任何一个字符的时候,可以直接偏移N个定长距离,但是如果是UTF-8(变长编码),则需要一边判断一边移动
3,占用磁盘空间:当编码中字母占大多数甚至全都是字母和英文符号的时候,UTF-8可以节省更多的空间,因为这个时候英文只需要一个字节的空间,如果是定长的UTF-16或者UTF-32就需要2个字节或者4个字节才可以存储一个英文字母。
当编码中中日韩等字符或者符号更多甚至全都是这些字符的时候,UTF-16显然可以节约更多空间,因为我们已经知道两个字节长度的UTF-8只能表示2的11次方,即2048个字符,但是大多数的中日韩等国家字符不在这个范围之内,所以这些字符就需要3个字节长度的UTF-8,比UTF-16占用更多的空间
4,只有UTF-8可以兼容ASCII,因为只有UTF-8作为一个字节长度的时候和ASCII一致
UTF-16作为变长编码
1,编码格式
2字节长度的UTF-16格式:xxxxxxxx xxxxxxxx (可以表示2的16次方个字符)
4字节长度的UTF-16格式:110110xx xxxxxxxx 110111xx xxxxxxxx(可以表示2的20次方个字符)
2,Big-Endian和Little-Endian
既然说到了这里,就简单说一下大尾小尾
UTF-16和UTF-32分为大端字节序列和小端字节序列,或者是大小尾,一般简写成BE,LE
使用一个网上例子
10进制 | 16进制 | 位数(bits)/字节数(bytes) | BE | LE |
---|---|---|---|---|
168496141 | 0A 0B 0C 0D | 32/4 | 0A 0B 0C 0D | 0D 0C 0B 0A |
3085 | 0C 0D | 16/2 | 0C 0D | 0D 0C |
可以看出,BE就是从左到右插入,而LE是从右到左插入,总结一下,大尾就是编码的高位存放在内存的低地址中,低位存放在内存的高地址中,符合我们的阅读顺序,而小尾正好相反,编码的高位存放在内存的高地址中,低位存放在内存的低地址中,至于内存高低,数值小的内存地址就是低地址,数值大的内存地址就是高地址。
判断一个文件具体是何种编码,可以使用16进制查看改文件,然后根据文件开头判断文件的字符集
文件开头 | 字符集 |
---|---|
EF BB BF | UTF-8 |
FE FF | UTF-16 LE |
FF FE | UTF-16 BE |
FF FE 00 00 | UTF-32 LE |
00 00 FE FF | UTF-32 BE |
最后推荐一篇关于UTF-8的博客
http://utf8everywhere.org/zh-cn