本页使用了标题或全文手工转换

字节顺序标记

维基百科,自由的百科全书
跳转至: 导航搜索

字节顺序标记英语:byte-order markBOM)是位于码点U+FEFF统一码字符的名称。当以UTF-16UTF-32来将UCS/统一码字符所组成的字符串编码时,这个字符被用来标示其字节序。它常被用来当做标示文件是以UTF-8UTF-16UTF-32编码的记号。

使用[编辑]

字符U+FEFF如果出现在字节流的开头,则用来标识该字节流的字节序,是高位在前还是低位在前。如果它出现在字节流的中间,则表达零宽度非换行空格的意义,用户看起来就是一个空格。从Unicode3.2开始,U+FEFF只能出现在字节流的开头,只能用于标识字节序,就如它的名称——字节序标记——所表示的一样;除此以外的用法已被舍弃。取而代之的是,使用U+2060来表达零宽度无断空白。

UTF-16中,字节顺序标记被放置为文件或字符串流的第一个字符,以标示在此文件或字符串流中,以所有十六比特为单位的字码的尾序(字节顺序)。

  • 如果十六比特单位被表示成大尾序,这字节顺序标记字符在序列中将呈现0xFE,其后跟着0xFF(其中的0x用来标示十六进制)。
  • 如果十六比特单位使用小尾序,这个字节序列为0xFF,其后接着0xFE

而统一码中,值为U+FFFE的码位被保证将不会被指定成一个统一码字符。这意味着0xFF0xFE将只能被解释成小尾序中的U+FEFF(因为不可能是大尾序中的U+FFFE)。

UTF-8则没有字节顺序的议题。UTF-8编码过的字节顺序标记则被用来标示它是UTF-8的文件。它只用来标示一个UTF-8的文件,而不用来说明字节顺序。[1]许多视窗程序(包含记事本)会添加字节顺序标记到UTF-8文件。然而,在类Unix系统(大量使用文本文件,用于文件格式,用于进程间通信)中,这种作法则不被建议采用。因为它会妨碍到如解译器脚本开头的Shebang等的一些重要的码的正确处理。它亦会影响到无法识别它的编程语言。如gcc会报告源码档开头有无法识别的字符。而在PHP中,如果没有激活输出缓冲(output buffering),它会使得页面内容开始被送往浏览器(即:用户头文件已被提交),这使PHP脚本无法指定用户头文件(HTTP Header)。字节顺序标记在UTF-8中被表示为序列EF BB BF,对大部分未准备好处理UTF-8的文本编辑器网页浏览器而言,在ISO-8859-1的环境中则会显示

虽然字节顺序标记亦可以用于UTF-32,但这个编码很少用于传输,其规则如同UTF-16。对于已于IANA注册的字符集UTF-16BE、UTF-16LE、UTF-32BE和UTF-32LE等来说,不可使用字节顺序标记。文档开头的U+FEFF会被解释成一个(已舍弃的)"零宽度无断空白",因为这些字符集的名字已决定了其字节顺序。对于已注册字符集UTF-16和UTF-32来说,一个开头的U+FEFF则用来表示字节顺序。

不同编码的字节顺序标记的表示[编辑]

编码 表示(十六进制 表示(十进制
UTF-8 EF BB BF 239 187 191
UTF-16大端序 FE FF 254 255
UTF-16小端序 FF FE 255 254
UTF-32(大端序) 00 00 FE FF 0 0 254 255
UTF-32(小端序) FF FE 00 00 255 254 0 0
UTF-7 2B 2F 76和以下的一个字节:[ 38 | 39 | 2B | 2F ] 43 47 118和以下的一个字节:[ 56 | 57 | 43 | 47 ]
UTF-1 F7 64 4C 247 100 76
UTF-EBCDIC英语UTF-EBCDIC DD 73 66 73 221 115 102 115
Unicode标准压缩方案英语Standard Compression Scheme for Unicode 0E FE FF 14 254 255
BOCU-1英语Binary_Ordered_Compression_for_Unicode FB EE 28 及可能跟随着FF 251 238 40 及可能跟随着255
GB-18030 84 31 95 33 132 49 149 51

另见[编辑]

参考文献[编辑]

  1. ^ FAQ - UTF-8, UTF-16, UTF-32 & BOM: Can a UTF-8 data stream contain the BOM character (in UTF-8 form)? If yes, then can I still assume the remaining UTF-8 bytes are in big-endian order?. [2008-03-29]. 

外部链接[编辑]