单位 内网网站建设,文安做网站,工程公司,手机搭建本地网站一、UTF-8编码方式
1.
接下来将分别介绍Unicode字符集的三种编码方式#xff1a;UTF-8、UTF-16、UTF-32。这里先介绍应用最为广泛的UTF-8。
为满足基于ASCII、面向字节的字符处理的需要#xff0c;Unicode标准中定义了UTF-8编码方式。UTF-8应该是目前应用最广泛的一种Unic…一、UTF-8编码方式
1.
接下来将分别介绍Unicode字符集的三种编码方式UTF-8、UTF-16、UTF-32。这里先介绍应用最为广泛的UTF-8。
为满足基于ASCII、面向字节的字符处理的需要Unicode标准中定义了UTF-8编码方式。UTF-8应该是目前应用最广泛的一种Unicode编码方式(但不是最早面世的UTF-16要早于UTF-8面世)。
由于UTF-16对于ASCII字符也必须使用两个字节(因为是16位码元)进行编码存储和处理效率相对低下并且由于ASCII字符经过UTF-16编码后得到的两个字节高字节始终是0x00很多C语言的函数都将此字节视为字符串末尾从而导致无法正确解析文本。
因此UTF-16一开始推出的时候就遭到很多西方国家的抵制大大影响了Unicode的推行。于是后来又设计了UTF-8编码方式才解决了这些问题。
2.
UTF-8的码元由8位单字节组成在UTF-8中因为码元较小的缘故Unicode码点值被映射到一个、两个、三个或四个码元换言之UTF-8使用一个至四个8位单字节码元的序列来表示Unicode字符。因此UTF-8是一种使用单字节码元的变宽(即变长或不定长)码元序列的编码方式。
UTF-8编码方式对所有ASCII码点值(0x00~0x7F)具有透明性。所谓透明性具体指的是在U0000到U007F范围内(十进制为0~127)的Unicode码点值亦即ASCII字符的Unicode码点值被直接转换为UTF-8单一字节码元0x00~0x7F与ASCII码没有区别。
并且0x00~0x7F不会出现在UTF-8编码的非ASCII字符的首字节与非首字节的任意一个字节中(非ASCII字符的UTF-8编码为由两个或两个以上的单字节码元所组成的码元序列)这样就保证了与早已应用广泛且已成为工业标准的ASCII编码的完全兼容且避免了歧义同时纠错能力也强。 笨笨阿林原创文章转载请注明出处
3.
UTF-8同其他的多字节码元编码方式相比具有以下优点
a) UTF-8的编码空间足够大未来Unicode新标准收录更多字符UTF-8也能适应因此不会再出现UTF-16那样的尴尬。
(注这里所指的编码空间并不是前文所提到的编号空间Code Space编号空间属于编号字符集CCS里的概念而编码空间属于字符编码方式CEF里的概念两者不能等同这里的编码空间可理解为编码方式的未来可扩展性、高适应性详见后文《UTF-8究竟是怎么编码的——UTF-8的编码算法介绍》以及《UTF-16究竟是怎么编码的——UTF-16的编码算法介绍》)
b) UTF-8是变长编码(准确地说是变长码元序列而码元本身是固定长度为8位单字节的也就是说UTF-8采用的是单字节码元)比如一个字节足以容纳所有的ASCII码字符就用一个字节来存储不必在高位补0以浪费更多的字节来存储因此在英语作为国际语言的现实情况下UTF-8因其ASCII字符的单字节编码这一特性可节省大量存储空间。
c) UTF-8完全直接兼容ASCII码而非不完全间接兼容。
d) UTF-8的码元序列的第一个字节指明了后面所跟的字节的数目(即带有前缀码)这对字节流的前向解析非常有效(详见后面的附文《UTF-8是怎么编码的——UTF-8的编码算法介绍》)。
e) 也因为UTF-8编码带有前缀码所以容错性好即使在传输过程中发生局部的字节错误比如即便丢失、增加、改变了某些字节也不会导致所有后续字符全部错乱这样传递性、连锁性的错误问题(否则若存在错误传递性、连锁性的话一旦中间某些字节出错则必须丢弃从出错点开始到结尾的所有编码字节比如GB码、UTF-32码就是如此)因此很容易重新同步具有很强的鲁棒性(即健壮性)。
f) 由于UTF-8编码没有状态从UTF-8字节流的任意位置开始可以有效地找到一个字符的起始位置字符边界很容易界定、检测出来所以具有很好的“自同步性”。
g) UTF-8已经成为互联网所采用的字符编码方式的事实标准。
h) UTF-8是字节顺序无关的(因为采用的是单字节码元而非像UTF-16、UTF-32采用的是多字节码元)它的字节顺序在所有系统中都是一样的其码元序列与字节序列相同因此它实际上并不需要字节顺序标记BOM(Byte-Orde Mark)虽然Windows系统经常“多此一举”地加上BOM。有关字节序标记BOM的介绍见下文
字节序问题在进行信息交换时会带来不小的麻烦。如果字节序未协商好将导致乱码若协商结果为双方一个采用大端一个采用小端则必然有一方要进行大小端转换性能损失不可避免(字节序的大小端问题其实不像看起来那么简单有时会涉及硬件、操作系统、上层应用软件多个层次可能会导致多次转换详见前文中有关字节序Byte-Orde的介绍)。
i) 字节FE(二进制为1111 1110)和FF(二进制为1111 1111)在UTF-8编码中永远不会出现(因为UTF-8编码方式中每个字节只能以0、110、1110、11110或10开头详见后文介绍)。因此可以用称之为零宽度不中断空格(ZERO WIDTH NO-BREAK SPACE)的字符(Unicode字符名称为UFEFF)作为字节顺序标记BOM来标明UTF-16或UTF-32文本的字节序。
(注Windows系统中BOM有时也用在UTF-8编码的文本文件的开头虽然UTF-8编码并不存在字节序问题但Windows却用BOM来表明该文本文件的编码格式为UTF-8这看起来有点“多此一举”其具体原因详见后文)
j) UTF-8编码可以通过屏蔽位和移位操作快速读写。
k) 字符串比较时strcmp()和wcscmp()的返回结果相同因此使排序变得更加容易。
4.
UTF-8编码方式也并非完美无缺大致上有如下缺点
a) 无法根据字符数直接判断出UTF-8文本的字节数因为UTF-8是一种变长编码方式(码元虽然固定为8位单字节但码元序列是变长的可能是单个码元共8位比如ASCII字符也可能是两个码元共16位、三个码元共24位、四个码元共32位等)。因此无论是计算字符数还是执行索引操作效率都不高。
b) 需要用2个字节编码那些在扩展ASCII(即EASCII)字符集中只需1个字节编码的扩展字符。
c) 以8位单字节码元编码的UTF-8字符会被Email网关过滤因为Internet上的信息传输最初设计为7位ASCII码字符(ASCII仅用到了1个字节的低7位)的传输。因此产生了UTF-7编码(类似于同样为Email传输而设计的Base64编码或quoted-printable编码由于Base64编码或quoted-printable编码各有其不足因此又设计了UTF-7编码)。
d) UTF-8在它的表示中使用值100xxxxx的几率超过50%而现存的实现如ISO 2022、4873、6429和8859编码系统会把它错认为是C1控制码。因此产生了UTF-7.5编码。
笨笨阿林原创文章转载请注明出处 二、字节序标记BOM 1.
在将逻辑形式的码元序列(或可称之为逻辑编码)映射为物理形式的字节序列(或可称之为物理编码)时因系统平台的差异存在一个字节序(Byte-Order字节顺序)的问题。而字节序问题的存在导致在某些场合下需要对文本字符所采用的字节序予以明确说明。Unicode/UCS规范中所推荐的用于说明字节序的方法是使用BOM字节序标记(Byte-Order Mark字节顺序标记)。
字节序标记BOM采用的是Unicode码点值为FEFF(十进制为65279二进制为1111 1110 1111 1111)的字符因此BOM实际上可认为是该字符(UFEFF)的别名。
最初字符UFEFF如果出现在字节流的开头则用来标识该字节流的字节序——是高位在前还是低位在前如果它出现在字节流的中间则表达为该字符的原义——零宽度不中断空格(ZERO WIDTH NO-BREAK SPACE零宽度无断空白)。该字符名义上是个空格实际上是零宽度的即相当于是不可见也不可打印字符(平常使用较多的是ASCII空格字符是非零宽度的需要占用一个字符的宽度因此为可见不可打印字符)。
不过从Unicode 3.2开始UFEFF只能出现在字节流的开头且只能用于标识字节序就如它的别名——字节序标记——所表示的意思一样除此以外的用法已被舍弃。取而代之的是使用U2060来表示零宽度不中断空格。
2.
如果UTF-16编码的字节序列为大端序则该字节序标记在字节流的开头呈现为0xFE 0xFF若字节序列为小端序则该字节序标记在字节流的开头呈现为0xFF 0xFE。如果UTF-32编码的字节序列为大端序则该字节序标记在字节流的开头呈现为0x00 0x00 0xFE 0xFF若字节序列为小端序则该字节序标记在字节流的开头呈现为0xFF 0xFE 0x00 0x00。
需要特别注意的是UTF-8编码本身并不存在字节序的问题但仍然有可能会用到BOM——有时被用来标示某文本是UTF-8编码格式的文本。再强调一遍在UFT-8编码格式的文本中如果添加了BOM则只用它来标示该文本是由UTF-8编码方式编码的而不用来说明字节序因为UTF-8编码根本就不存在字节序问题。
3.
许多Windows程序(包含记事本)会添加BOM到UTF-8编码格式的文件中(至于为什么要添加BOM可参看后续《微软跟联通有仇》一文)。然而在类Unix系统中这种作法则不被建议采用。
因为它会影响到无法识别它的编程语言如gcc会报告源码文件开头有无法识别的字符而在PHP中如果没有激活输出缓冲(output buffering)的话则它会使得页面内容开始被送往浏览器(即http header头被提交)从而使PHP脚本无法再指定http header头。
对于已在IANA注册的字符编码(实际为字符编码模式CES)UTF-16BE、UTF-16LE、UTF-32BE和UTF-32LE等来说不可使用BOM因为其名称本身已决定了其字节顺序。而对于已注册的字符编码UTF-16和UTF-32来说则必须在文本开头使用BOM。
4.
不同编码的字节序列中所使用的字节序标记BOM本身的字节序列呈现 笨笨阿林原创文章转载请注明出处 三、小结
1.
由于UTF-8编码方式以一个字节(8位)作为码元属于单字节码元在计算机处理、存储和传输时不存在字节序问题(字节序问题只跟多字节码元有关)因此避免了平台依赖性跨平台兼容性好。
它相对于其他编码方式对英语更为友好同样也对计算机语言(如C、Java、C#、JavaScript、PHP、HTML等)更为友好。它在处理ASCII等常用字符集时很少会比UTF-16低效。
2.
所以UTF-8是较为平衡、较为理想的Unicode编码方式。虽然Windows平台由于历史的原因API缺乏对UTF-8的原生支持(Windows原生支持的是UTF-16因为UTF-16早于UTF-8面世)导致UTF-8推出后的早期使用不广但目前是应用最为广泛的三大UTF编码方式之一。
因此应该尽量使用UTF-8(准确地说应该尽量使用UTF-8 without BOM即不带字节顺序标记BOM的UTF-8)。
笨笨阿林原创文章转载请注明出处 未完待续 【预告本《刨根究底字符编码》系列的下一篇将重点剖析UTF-8究竟是怎么编码的(即UTF-8的编码算法介绍)敬请关注】
