位元組順序記號

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

位元組順序記號英语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 ]
en:UTF-1 F7 64 4C 247 100 76
en:UTF-EBCDIC DD 73 66 73 221 115 102 115
en:Standard Compression Scheme for Unicode 0E FE FF 14 254 255
en:BOCU-1 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]. 

外部連結[编辑]