小城镇建设网站参考文献,wordpress缩略图设置,公司制作网站需要,wordpress查看jquery版本号UTF-8
UTF-8#xff08;8-bit Unicode Transformation Format#xff09;是一种针对Unicode的可变长度字符编码#xff0c;也是一种前缀码。它可以用一至四个字节对Unicode字符集中的所有有效编码点进行编码#xff0c;属于Unicode标准的一部分#xff0c;最初由肯汤普逊…UTF-8
UTF-88-bit Unicode Transformation Format是一种针对Unicode的可变长度字符编码也是一种前缀码。它可以用一至四个字节对Unicode字符集中的所有有效编码点进行编码属于Unicode标准的一部分最初由肯·汤普逊和罗布·派克提出。[2][3]由于较小值的编码点一般使用频率较高直接使用Unicode编码效率低下大量浪费内存空间。UTF-8就是为了解决向后兼容ASCII码而设计Unicode中前128个字符使用与ASCII码相同的二进制值的单个字节进行编码而且字面与ASCII码的字面一一对应这使得原来处理ASCII字符的软件无须或只须做少部分修改即可继续使用。因此它逐渐成为电子邮件、网页及其他存储或发送文字优先采用的编码方式。
自2009年以来UTF-8一直是万维网的最主要的编码形式对所有而不仅是Unicode范围内的编码并由WHATWG宣布为强制性的“适用于所有事物(for all things)”[4]截止到2019年11月 在所有网页中UTF-8编码应用率高达94.3%其中一些仅是ASCII编码因为它是UTF-8的子集而在排名最高的1000个网页中占96。[5] 第二热门的多字节编码方式Shift JIS和GB 2312分别具有0.3和0.2的占有率。[6][7][1]Internet邮件联盟 Internet Mail Consortium, IMC建议所有电子邮件程序都能够使用UTF-8展示和创建邮件[8] W3C建议UTF-8作为XML文件和HTML文件的默认编码方式。[9]互联网工程工作小组IETF要求所有互联网协议都必须支持UTF-8编码[10]。互联网邮件联盟IMC建议所有电子邮件软件都支持UTF-8编码。[11]
历史
1992年初为建立良好的字节串编码系统以供多字节字符集使用开始了一个正式的研究。ISO/IEC 10646的初稿中有一个非必须的附录名为UTF。当中包含了一个供32比特的字符使用的字节串编码系统。这个编码方式的性能并不令人满意但它提出了将0-127的范围保留给ASCII以兼容旧系统的概念。
1992年7月X/Open委员会XoJIG开始寻求一个较佳的编码系统。Unix系统实验室USL的Dave Prosser为此提出了一个编码系统的建议。它具备可更快速实现的特性并引入一项新的改进。其中7比特的ASCII符号只代表原来的意思所有多字节序列则会包含第8比特的符号也就是所谓的最高有效比特。
1992年8月这个建议由IBMX/Open的代表流传到一些感兴趣的团体。与此同时贝尔实验室九号项目操作系统工作小组的肯·汤普逊对这编码系统作出重大的修改让编码可以自我同步使得不必从字符串的开首读取也能找出字符间的分界。1992年9月2日肯·汤普逊和罗勃·派克一起在美国新泽西州一架餐车的餐桌垫上描绘出此设计的要点。接下来的日子Pike及汤普逊将它实现并将这编码系统完全应用在九号项目当中及后他将有关成果反馈X/Open。
1993年1月25-29日的在圣地亚哥举行的USENIX会议首次正式介绍UTF-8。
自1996年起微软的CABMS Cabinet规格在UTF-8标准正式落实前就明确容许在任何地方使用UTF-8编码系统。但有关的编码器实际上从来没有实现这方面的规格。
结构
UTF-8使用一至六个字节为每个字符编码尽管如此2003年11月UTF-8被RFC 3629重新规范只能使用原来Unicode定义的区域U0000到U10FFFF也就是说最多四个字节
128个US-ASCII字符只需一个字节编码Unicode范围由U0000至U007F。 带有附加符号的拉丁文、希腊文、西里尔字母、亚美尼亚语、希伯来文、阿拉伯文、叙利亚文及它拿字母则需要两个字节编码Unicode范围由U0080至U07FF。 其他基本多文种平面BMP中的字符这包含了大部分常用字如大部分的汉字使用三个字节编码Unicode范围由U0800至UFFFF。 其他极少使用的Unicode 辅助平面的字符使用四至六字节编码Unicode范围由U10000至U1FFFFF使用四字节Unicode范围由U200000至U3FFFFFF使用五字节Unicode范围由U4000000至U7FFFFFFF使用六字节。 对上述提及的第四种字符而言UTF-8使用四至六个字节来编码似乎太耗费资源了。但UTF-8对所有常用的字符都可以用三个字节表示而且它的另一种选择UTF-16编码对前述的第四种字符同样需要四个字节来编码所以要决定UTF-8或UTF-16哪种编码比较有效率还要视所使用的字符的分布范围而定。不过如果使用一些传统的压缩系统比如DEFLATE则这些不同编码系统间的的差异就变得微不足道了。若顾及传统压缩算法在压缩较短文字上的效果不大可以考虑使用Unicode标准压缩格式SCSU。
描述
Unicode与UTF-8的转换 目前有好几份关于UTF-8详细规格的文件但这些文件在定义上有些许的不同
RFC 3629 / STD 632003这份文件制定了UTF-8是标准的互联网协议元素 第四版The Unicode Standard§3.9§3.102003 ISO/IEC 10646-1:2000附加文件D2000 它们取代了以下那些被淘汰的定义
ISO/IEC 10646-1:1993修正案2附加文件R1996 第二版The Unicode Standard附录A1996 RFC 20441996 RFC 22791998 第三版The Unicode Standard§2.32000及勘误表#1UTF-8 Shortest Form2000 Unicode Standard附加文件#27: Unicode 3.12001 事实上所有定义的基本原理都是相同的它们之间最主要的不同是支持的字符范围及无效输入的处理方法。
Unicode字符的比特被分割为数个部分并分配到UTF-8的字节串中较低的比特的位置。在U0080的以下字符都使用内含其字符的单字节编码。这些编码正好对应7比特的ASCII字符。在其他情况有可能需要多达4个字符组来表示一个字符。这些多字节的最高有效比特会设置成1以防止与7比特的ASCII字符混淆并保持标准的字节主导字符串运作顺利。
代码范围
十六进制 标量值scalar value 二进制 UTF-8 二进制十六进制 注释 000000 - 00007F 128个代码 00000000 00000000 0zzzzzzz 0zzzzzzz00-7F ASCII字符范围字节由零开始 七个z 七个z 000080 - 0007FF 1920个代码 00000000 00000yyy yyzzzzzz 110yyyyyC0-DF 10zzzzzz80-BF 第一个字节由110开始接着的字节由10开始 三个y二个y六个z 五个y六个z 000800 - 00D7FF 00E000 - 00FFFF 61440个代码 [Note 1] 00000000 xxxxyyyy yyzzzzzz 1110xxxxE0-EF 10yyyyyy 10zzzzzz 第一个字节由1110开始接着的字节由10开始 四个x四个y二个y六个z 四个x六个y六个z 010000 - 10FFFF 1048576个代码 000wwwxx xxxxyyyy yyzzzzzz 11110wwwF0-F7 10xxxxxx 10yyyyyy 10zzzzzz 将由11110开始接着的字节由10开始 三个w二个x四个x四个y二个y六个z 三个w六个x六个y六个z Note 1 Unicode在范围D800-DFFF中不存在任何字符基本多文种平面中约定了这个范围用于UTF-16扩展标识辅助平面两个UTF-16表示一个辅助平面字符。当然任何编码都是可以被转换到这个范围但在unicode中他们并不代表任何合法的值。 例如希伯来语字母alephא的Unicode代码是U05D0按照以下方法改成UTF-8
它属于U0080到U07FF区域这个表说明它使用双字节110yyyyy 10zzzzzz. 十六进制的0x05D0换算成二进制就是101-1101-0000. 这11位数按顺序放入y部分和z部分11010111 10010000. 最后结果就是双字节用十六进制写起来就是0xD7 0x90这就是这个字符alephא的UTF-8编码。 所以开始的128个字符US-ASCII只需一字节接下来的1920个字符需要双字节编码包括带附加符号的拉丁字母希腊字母西里尔字母科普特语字母亚美尼亚语字母希伯来文字母和阿拉伯字母的字符。基本多文种平面中其余的字符使用三个字节剩余字符使用四个字节。
根据这种方式可以处理更大数量的字符。原来的规范允许长达6字节的序列可以覆盖到31位通用字符集原来的极限。尽管如此2003年11月UTF-8被RFC 3629重新规范只能使用原来Unicode定义的区域U0000到U10FFFF。根据这些规范以下字节值将无法出现在合法UTF-8序列中
编码二进制 编码十六进制 注释 1100000x C0, C1 过长编码双字节序列的头字节但码点 127 1111111x FE, FF 无法达到7或8字节序列的头字节 111110xx 1111110x F8, F9, FA, FB, FC, FD 被RFC 3629规范5或6字节序列的头字节 11110101 1111011x F5, F6, F7 被RFC 3629规范码点超过10FFFF的头字节 UTF-8编码字节含义 对于UTF-8编码中的任意字节B如果B的第一位为0则B独立的表示一个字符(ASCII码) 如果B的第一位为1第二位为0则B为一个多字节字符中的一个字节(非ASCII字符) 如果B的前两位为1第三位为0则B为两个字节表示的字符中的第一个字节 如果B的前三位为1第四位为0则B为三个字节表示的字符中的第一个字节 如果B的前四位为1第五位为0则B为四个字节表示的字符中的第一个字节 因此对UTF-8编码中的任意字节根据第一位可判断是否为ASCII字符根据前二位可判断该字节是否为一个字符编码的第一个字节根据前四位如果前两位均为1可确定该字节为字符编码的第一个字节并且可判断对应的字符由几个字节表示根据前五位如果前四位为1可判断编码是否有错误或数据传输过程中是否有错误。
设计UTF-8的理由
UTF-8的设计有以下的多字符组序列的特质
单字节字符的最高有效比特永远为0。 多字节序列中的首个字符组的几个最高有效比特决定了序列的长度。最高有效位为110的是2字节序列而1110的是三字节序列如此类推。 多字节序列中其余的字节中的首两个最高有效比特为10。 UTF-8的这些特质保证了一个字符的字节序列不会包含在另一个字符的字节序列中。这确保了以字节为基础的部分字符串比对sub-string match方法可以适用于在文字中搜索字或词。有些比较旧的可变长度8位编码如Shift JIS没有这个特质故字符串比对的算法变得相当复杂。虽然这增加了UTF-8编码的字符串的信息冗余但是利多于弊。另外资料压缩并非Unicode的目的所以不可混为一谈。即使在发送过程中有部分字节因错误或干扰而完全丢失还是有可能在下一个字符的起点重新同步令受损范围受到限制。
另一方面由于其字节序列设计如果一个疑似为字符串的序列被验证为UTF-8编码那么我们可以有把握地说它是UTF-8字符串。一段两字节随机序列碰巧为合法的UTF-8而非ASCII的几率为32分1。对于三字节序列的几率为256分1对更长的序列的几率就更低了。
UTF-8的编码方式 UTF-8是UNICODE的一种变长度的编码表达方式《一般UNICODE为双字节指UCS2》它由肯·汤普逊Ken Thompson于1992年建立现在已经标准化为RFC 3629。UTF-8就是以8位为单元对UCS进行编码而UTF-8不使用大尾序和小尾序的形式每个使用UTF-8存储的字符除了第一个字节外其余字节的头两个比特都是以10开始使文字处理器能够较快地找出每个字符的开始位置。
但为了与以前的ASCII码兼容ASCII为一个字节因此UTF-8选择了使用可变长度字节来存储Unicode
注意不论是Unicode (Table 3.7) [12]还是ISO 10646 (10.2 UTF-8) [13]目前都只规定了最高码位是0x10FFFF的字符的编码。下表中表示大于0x10FFFF的UTF-8编码是不符合标准的。
Unicode 和 UTF-8 之间的转换关系表 ( x 字符表示码点占据的位 ) 码点的位数 码点起值 码点终值 字节序列 Byte 1 Byte 2 Byte 3 Byte 4 Byte 5 Byte 6 7 U0000 U007F 1 0xxxxxxx 11 U0080 U07FF 2 110xxxxx 10xxxxxx 16 U0800 UFFFF 3 1110xxxx 10xxxxxx 10xxxxxx 21 U10000 U1FFFFF 4 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx 26 U200000 U3FFFFFF 5 111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 31 U4000000 U7FFFFFFF 6 1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 在ASCII码的范围用一个字节表示超出ASCII码的范围就用字节表示这就形成了我们上面看到的UTF-8的表示方法这样的好处是当UNICODE文件中只有ASCII码时存储的文件都为一个字节所以就是普通的ASCII文件无异读取的时候也是如此所以能与以前的ASCII文件兼容。 大于ASCII码的就会由上面的第一字节的前几位表示该unicode字符的长度比如110xxxxx前三位的二进制表示告诉我们这是个2BYTE的UNICODE字符1110xxxx是个三位的UNICODE字符依此类推xxx的位置由字符编码数的二进制表示的位填入。越靠右的x具有越少的特殊意义。只用最短的那个足够表达一个字符编码数的多字节串。注意在多字节串中第一个字节的开头1的数目就是整个串中字节的数目。 ASCII字母继续使用1字节存储重音文字、希腊字母或西里尔字母等使用2字节来存储而常用的汉字就要使用3字节。辅助平面字符则使用4字节。
在UTF-8BOM格式文件的开首很多时都放置一个UFEFF字符UTF-8以EF,BB,BF代表以显示这个文本文件是以UTF-8编码。
UTF-8的特性 UTF-8图表说明 UTF-8 最小码位 0000 最大码位 10FFFF 每字节所占位数 8 bits Byte order N/A 每个字符最小字节数 1 每个字符最大字节数 4 UCS字符U0000到U007FASCII被编码为字节0x00到0x7FASCII兼容这也意味着只包含7位ASCII字符的文件在ASCII和UTF-8两种编码方式下是一样的。 所有U007F的UCS字符被编码为一个多个字节的串每个字节都有标记位集。因此ASCII字节0x00-0x7F不可能作为任何其他字符的一部分。 表示非ASCII字符的多字节串的第一个字节总是在0xC0到0xFD的范围里并指出这个字符包含多少个字节。多字节串的其余字节都在0x80到0xBF范围里这使得重新同步非常容易并使编码无国界且很少受丢失字节的影响。 可以编入所有可能的231个UCS代码 UTF-8编码字符理论上可以最多到6个字节长然而16位BMP字符最多只用到3字节长。 Bigendian UCS-4字节串的排列顺序是预定的。 字节0xFE和0xFF在UTF-8编码中从未用到同时UTF-8以字节为编码单元它的字节顺序在所有系统中都是一様的没有字节序的问题也因此它实际上并不需要BOM。 与UTF-16或其他Unicode编码相比对于不支持Unicode和XML的系统UTF-8更不容易造成问题。 UTF-8编码的优点 总体来说在Unicode字符串中不可能由码点数量决定显示它所需要的长度或者显示字符串之后在文本缓冲区中光标应该放置的位置组合字符、变宽字体、不可打印字符和从右至左的文字都是其归因。
所以尽管在UTF-8字符串中字符数量与码点数量的关系比UTF-32更为复杂在实际中很少会遇到有不同的情形。
更详细的说UTF-8编码具有以下几点优点
ASCII是UTF-8的一个子集。因为一个纯ASCII字符串也是一个合法的UTF-8字符串所以现存的ASCII文本不需要转换。为传统的扩展ASCII字符集设计的软件通常可以不经修改或很少修改就能与UTF-8一起使用。 使用标准的面向字节的排序例程对UTF-8排序将产生与基于Unicode代码点排序相同的结果。尽管这只有有限的有用性因为在任何特定语言或文化下都不太可能有仍可接受的文字排列顺序。 UTF-8和UTF-16都是可扩展标记语言文档的标准编码。所有其它编码都必须通过显式或文本声明来指定。[1]页面存档备份存于互联网档案馆 任何面向字节的字符串搜索算法都可以用于UTF-8的数据只要输入仅由完整的UTF-8字符组成。但是对于包含字符记数的正则表达式或其它结构必须小心。 UTF-8字符串可以由一个简单的算法可靠地识别出来。就是一个字符串在任何其它编码中表现为合法的UTF-8的可能性很低并随字符串长度增长而减小。举例说字符值C0,C1,F5至FF从来没有出现。为了更好的可靠性可以使用正则表达式来统计非法过长和替代值可以查看W3 FAQ: Multilingual Forms 页面存档备份存于互联网档案馆上的验证UTF-8字符串的正则表达式。 与UCS-2的比较ASCII转换成UCS-2在编码前插入一个0x0。用这些编码会含括一些控制符比如或 ‘/’这在UNIX和一些C函数中将会产生严重错误。因此可以肯定UCS-2不适合作为Unicode的外部编码也因此诞生了UTF-8。
UTF-8 编码的缺点
编写不良的解析器 如果一个 UTF-8 解析器写得很差并且与当前标准的版本不兼容那么它接收到一些伪 UTF-8 时会将其转换成看似正确实则错误的 Unicode 输出。处理八位表示的校验例程可能遗漏一些信息。
不利于正则表达式检索 正则表达式可以进行很多高级的英文模糊检索。例如[a-h]表示 a 到 h 间所有字母。
同样 GBK 编码的中文也可以这样利用正则表达式比如在只知道一个字的读音而不知道怎么写的情况下也可用正则表达式检索因为 GBK 编码是按读音排序的。但是 Unicode 汉字不是按读音排序的所以不利于用正则表达式检索。虽然正则表达式检索并未考虑中文的多音字但是由于中文的多音字数量不多不少多音字还是同音不同调类型的多音字所以大多数情况下正则表达式检索是还可以接受的。不过 Unicode 汉字按部首排序因此在只知道一个字的部首而不知道如何发音的情况下UTF-8 可用正则表达式检索而 GBK 不行。
可能无法用旧的 C 语言函数库读写 由于UTF-8在编码中可能有着空字符null characterU0000这会导致C语言函示库以及其延伸的程序解析失败因为这些旧有的程序库使用这个字符来标记字符串的结束。然而之所以说“可能”是因为这个字符是控制字符理论上不会出现在 XML 等纯文本文件中。当万不得已要使用空字符的时候可能的解决方法是考虑使用 Java 的变种UTF-8 ——使用 0xc0 0x80 来编码空字符。
其他
UTF-8 的 ASCII 字符只占用一个字节比较节省空间但是更多字符的 UTF-8 编码占用的空间就要多出1/2特别是中文、日文和韩文CJK这样的方块文字它们大多需要三个字节。
UTF-8的派生物 Windows 虽然不是标准但许多Windows程序包括Windows记事本在UTF-8编码的文件的开首加入一段字节串EF BB BF。这是字节顺序记号UFEFF的UTF-8编码结果。对于没有预期要处理UTF-8的文本编辑器和浏览器会显示成ISO-8859-1字符串。
Posix系统 Posix系统明确不建议使用字节序掩码EF BB BF。[14]因为很多文本文件期望以 “#!”Shebang开头指示要运行的程序。Linux系统选择使用Unicode规范形式Normalization Form CNFC即优先使用预组装字符precomposed character而非组合字符序列combining character sequence。
2002年9月发布的Red Hat Linux 8.0才开始正式把大多数区域设置的默认编码设为UTF-8。此前是各种语言的但字节编码为主。2004年9月SuSE Linux 9.1开始缺省编码迁移为UTF-8。
字符串处理时使用UTF-8或locale依赖的多字节编码情形比使用C语言wchar_t的宽字符固定宽度编码要慢1至2个数量级。[14]
Java 在通常用法下Java程序语言在通过InputStreamReader和OutputStreamWriter读取和写入串的时候支持标准UTF-8。但是Java也支持一种非标准的变体UTF-8供对象的序列化Java本地界面和在class文件中的嵌入常数时使用的modified UTF-8。
变种UTF-8 标准和变种的UTF-8有两个不同点。第一空字符null characterU0000使用双字节的0xc0 0x80而不是单字节的0x00。这保证了在已编码字符串中没有嵌入空字节。因为C语言等语言程序中单字节空字符是用来标志字符串结尾的。当已编码字符串放到这样的语言中处理一个嵌入的空字符将把字符串一刀两断。
第二个不同点是基本多文种平面之外字符的编码的方法。在标准UTF-8中这些字符使用4字节形式编码而在修正的UTF-8中这些字符和UTF-16一样首先表示为代理对surrogate pairs然后再像CESU-8那样按照代理对分别编码。这样修正的原因更是微妙。Java中的字符为16位长因此一些Unicode字符需要两个Java字符来表示。语言的这个性质盖过了Unicode的增补平面的要求。尽管如此为了要保持良好的向后兼容、要改变也不容易了。这个修正的编码系统保证了一个已编码字符串可以一次编为一个UTF-16码而不是一次一个Unicode码点。不幸的是这也意味着UTF-8中需要4字节的字符在变种UTF-8中变成需要6字节。
因为变种UTF-8并不是UTF-8所以用户在交换信息和使用互联网的时候需要特别注意不要误把变种UTF-8当成UTF-8数据。
Mac OS X 参见统一码等价性 Mac OS X操作系统使用统一码正规形式中的分解式标准等价canonically decomposed Unicode在文件系统中使用UTF-8编码进行文件命名这做法通常被称为UTF-8-MAC。分解式标准等价中预组合字符是被禁止使用的必须以组合字符取代。
这种方法使分类变得非常简单但是会搞混那些使用预组合字符为标准、组合字符用来显示特殊字符的软件。Mac系统的这种NFD数据是统一码正规形式Unicode normalization的一种格式。而其他系统包括Windows和Linux使用统一码规范的NFC形式也是W3C标准使用的形式。所以通常NFD数据必须转换成NFC才能被其他平台或者网络使用。
苹果开发者专区有关于此问题的讨论Apple QA 1173 页面存档备份存于互联网档案馆。
MySQL MySQL字符编码集中有两套UTF-8编码实现“utf8”和“utf8mb4”其中“utf8”是一个字最多占据3字节空间的编码实现而“utf8mb4”则是一个字最多占据4字节空间的编码实现也就是UTF-8的完整实现。这是由于MySQL在4.1版本开始支持UTF-8编码当时参考UTF-8草案版本为RFC 2279时为2003年并且在同年9月限制了其实现的UTF-8编码的空间占用最多为3字节而UTF-8正式形成标准化文档RFC 3629是其之后。限制UTF-8编码实现的编码空间占用一般被认为是考虑到数据库文件设计的兼容性和读取最优化但实际上并没有达到目的而且在UTF-8编码开始出现需要存入非基本多文种平面的Unicode字符例如emoji字符时导致无法存入由于3字节的实现只能存入基本多文种平面内的字符。直到2010年在5.5版本推出“utf8mb4”来代替、“utf8”重命名为“utf8mb3”并调整“utf8”为“utf8mb3”的别名并不建议使用旧“utf8”编码以此修正遗留问题。[15][16][17][18]
