**位元組順序記號**（英語：，**BOM**）是位於碼點`U+FEFF`的統一碼字符的名称。當以UTF-16或UTF-32來將UCS/統一碼字符所組成的字串編碼時，這個字符被用來標示其位元組序。它常被用來當做標示文件是以UTF-8、UTF-16或UTF-32編碼的記號。

位元組順序記號通常有幾種涵義：

1. 在16位元和32位元的情況下，文字流的位元組順序。
2. 表示文字流非常有可能是Unicode編碼。
3. 使用的是哪一種Unicode字元編碼。

位元組順序記號的使用是選擇性的。它的存在會干擾那些不希望檔案開頭出現非ASCII字元、但可以用其他方式處理文字流的軟體對於UTF-8的使用。

Unicode可以以8位元、16位元或32位元整數為單位進行編碼。對於16位元和32位元的表示方法，從任意來源接收文本的電腦需要知道整數是以何種位元組順序編碼的。位元組順序記號的編碼方式與文件檔案的其他部分相同，如果它的位元組被調換，就會變成一個非字元的Unicode碼位。因此，訪問文本的過程中，可以透過檢查這頭幾個位元組來確定位元組順序，而不需要文字流本身以外的一些約定或元資料。一般來說，如果有必要，接收資料的電腦會將位元組換成自己的位元組順序，不再需要位元組順序記號進行處理。

每個Unicode編碼（包括Unicode標準以外的編碼，如UTF-7，見下表）的BOM位元組序列都不一樣，而且這些序列都不可能出現在以其他編碼儲存的文字流的開頭。因此，在文字流的開頭放置一個編碼的BOM，可以表明文本是Unicode，並識別所使用的編碼方案。這種對BOM字元的使用被稱為「Unicode簽名」。

使用
--

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

### UTF-8

在UTF-8中，雖然在 Unicode 標準上允許位元組順序記號的存在，但實際上並不一定需要。UTF-8編碼過的位元組順序記號則被用來標示它是UTF-8的文件。它只用來標示一個UTF-8的檔案，而不用來說明位元組順序。但同時，該標準也不建議在有位元組順序記號的情況下將其刪除，以便在不同的編碼之間轉換時不會丟失資訊，並讓依賴位元組順序記號的程式能順利運作。IETF建議，如果一個協議(a)總是使用UTF-8，或者(b)有一些其他方法來表明正在使用的編碼，那麼它「應該禁止使用U+FEFF作為簽名」。
許多視窗程式（包含記事本）會需要添加位元組順序記號到UTF-8檔案，否則將無法正確解析編碼，而出現亂碼。然而，在類Unix系統（大量使用文本文件，用於檔案格式，用於行程間通訊）中，這種做法則不被建議採用。因為它會妨礙到如解譯器腳本開頭的Shebang等的一些重要的碼的正確處理。它亦會影響到無法識別它的程式語言。如gcc會報告源碼檔開頭有無法識別的字符。而在PHP中，如果沒有啟用輸出緩衝（output buffering），它會使得頁面內容開始被送往瀏覽器（即：用戶標頭檔已被送出），這使PHP腳本無法指定用戶標頭檔（HTTP Header）。位元組順序記號在UTF-8中被表示為序列`0xEF 0xBB 0xBF`，對大部分未準備好處理UTF-8的文本編輯器及網頁瀏覽器而言，在ISO-8859-1的環境中則會顯示`ï»¿`。

Unicode標準允許在UTF-8中使用BOM，但並不要求或推薦使用它。位元組順序在UTF-8中沒有任何意義，所以它在UTF-8中的唯一用途是在開始時發出信號，表明文本流是用UTF-8編碼的，或者表明它是從包含可選BOM的文本流轉換到UTF-8的。該標準也不建議在有BOM的情況下將其刪除，以便在不同的編碼之間往返不會丟失信息，並使依賴BOM的代碼繼續工作。 IETF建議，如果一個協議要么(a)總是使用UTF-8，要么(b)有一些其他方法來表明正在使用的編碼，那麼它 "應該禁止使用U+FEFF作為簽名"。

UTF-8是一種稀疏的編碼，意思是很大一部分可能的字元組合不會產生有效的UTF-8文本。任何其他編碼的二進制資料和文本都可能包含UTF-8無效的字元序列，唯一的例外是當文本純粹由ASCII範圍的字元組成的時候。因為所有的現代編碼都使用ASCII範圍的位元組來表示ASCII字元，所以無論發出這些位元組的系統打算使用什麼編碼，純ASCII的文本都可以被安全地解釋為UTF-8。由於這些考慮，使用啟發式的分析方法可以很有把握地檢測出文件是否使用UTF-8，而不需要加入BOM。
另一方面，微軟的編譯器和解釋器，以及許多Microsoft Windows上的軟體，如記事本，都將BOM視為一個必要的神奇數字，而不是使用啟發式分析法。這些工具在將文本保存為UTF-8時添加了BOM，並且只有在BOM存在或是文件只包含ASCII字元時才能解釋UTF-8。Windows PowerShell（截至5.1版本）在保存UTF-8的XML文件檔時，會添加一個BOM。然而，PowerShell Core 6在一些cmdlets上增加了一個-Encoding開關，稱為「utf8NoBOM」，這樣就可以在沒有BOM的情況下保存文件檔。Google文件在將文件檔轉換為純文本文件以供下載時也會添加BOM。

### UTF-16

在UTF-16中，位元組順序記號被放置為檔案或文字串流的第一個字符，以標示在此檔案或文字串流中，以所有十六位元為單位的字碼的端序（位元組順序）。如果試圖用錯誤的位元組順序來讀取這個流，位元組將被調換，從而產生字元`U+FFFE`，這個字元被Unicode定義為「非字元」，不應該出現在文本中。例如，值為`U+FFFE`的碼位被保證將不會被指定成一個統一碼字元。這意味著`0xFF`、`0xFE`將只能被解釋成小端序中的`U+FEFF`（因為不可能是大端序中的`U+FFFE`）。

* 如果十六位元單位被表示成大端序，這位元組順序記號字符在序列中將呈現`0xFE`，其後跟著`0xFF`（其中的`0x`用來標示十六進位）。
* 如果十六位元單位使用小端序，這個位元組序列為`0xFF`，其後接著`0xFE`。

這兩個序列都不是有效的UTF-8，所以它們的出現表明該文件不是用UTF-8編碼的。

對於網際網路號碼分配局註冊的字元集UTF-16BE和UTF-16LE，不應該使用位元組順序記號標記，因為這些字元集的名稱已經決定了位元組順序。如果在這樣的文本串流中的任何地方遇到`U+FEFF`，將被解釋為一個「零寬度無斷點空間」。

如果沒有位元組順序記號，可以透過搜索ASCII字元（即與0x20-0x7E範圍內的字節相鄰的0位元組，還有CR和LF的0x0A和0x0D）來猜測該文本是否為UTF-16及其位元組順序。大量的（即遠遠高於隨機）相同的順序是UTF-16的一個非常好的指示，而0是在偶數還是奇數位元組中表明了位元組的順序。然而，這依然可能會導致假陽性和假陰性。

Unicode標準的一致性條款D98（第3.10節）規定：「UTF-16編碼方案可以以BOM開始，也可以不以BOM開始。然而，當沒有BOM時，在沒有高層協議的情況下，UTF-16編碼方案的位元組順序是大端序。」是否有更高層次的協議是可以解釋的。例如，在一台本地位元組順序為小端序的電腦上的文件，可能被默認為是以UTF-16LE編碼。因此，大端序的推定被廣泛地忽略了。在HTML5中使用的W3C/WHATWG編碼標準規定，標記為「utf-16」或「utf-16le」的內容將被解釋為小端序，「以處理部署的內容」。然而，如果出現了位元組順序記號，那麼該記號將被視為「比其他任何東西都更有權威性」。

將UTF-16解釋為基於位元組的編碼的程式可能會顯示出亂七八糟的字元，但是ASCII字元會被識別出來，因為UTF-16表示的低字元與ASCII代碼相同，因此會顯示相同的字元。0的上字元可以顯示為無、空白、句號，或其他一些不變的字形。

### UTF-32

雖然位元組順序記號亦可以用於UTF-32，但這個編碼很少用於傳輸，其規則如同UTF-16。

小端序UTF-32的BOM等同小端序UTF-16的BOM圖案後面加上一個NUL字元，這是一個不尋常的例子，即BOM在兩種不同的編碼中是相同的形式。使用BOM來識別編碼的程序員必須分辨文件是UTF-32編碼還是單純以NUL作為第一個字元。

不同編碼的位元組順序記號的表示
---------------

| 編碼 | 表示（十六進位） | 表示（十進位） |
| --- | --- | --- |
| 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（英语：） | `DD 73 66 73` | `221 115 102 115` |
| Unicode标准压缩方案（英语：） | `0E FE FF` | `14 254 255` |
| BOCU-1（英语：） | `FB EE 28` *及可能跟隨著*`FF` | `251 238 40` *及可能跟隨著*`255` |
| GB-18030 | `84 31 95 33` | `132 49 149 51` |

另見
--

* 左至右符號
* 右至左符號

參考文獻
----

1. ↑ . Unicode.org.  [2017-01-28]. （原始内容存档于2021-05-02）.
2. ↑   (PDF). The Unicode Consortium.  [2021-06-16]. （原始内容存档 (PDF)于2021-05-07）.
3. ↑   (PDF): 36.  [2009-03-29]. （原始内容存档 (PDF)于2021-04-22）. Table 2-4. The Seven Unicode Encoding Schemes
4. ↑   (PDF): 36.  [2008-11-30]. （原始内容存档 (PDF)于2021-04-22）. Use of a BOM is neither required nor recommended for UTF-8, but may be encountered in contexts where UTF-8 data is converted from other encoding forms that use a BOM or where the BOM is used as a UTF-8 signature
5. ↑ .  [2008-03-29]. （原始内容存档于2012-09-01）.
6. ↑ . Unicode.org.  [2012-07-14]. （原始内容存档于2019-06-16）.
7. ↑ . Bugs.sun.com.  [2017-01-28]. （原始内容存档于2017-12-19）.
8. ↑  Yergeau, Francois. UTF-8, a transformation format of ISO 10646. IETF. November 2003 [May 15, 2014]. RFC 3629.
9. ↑  Alf P. Steinbach.. 2011  [24 March 2012]. （原始内容存档于2012-03-22）. However, since the C++ source code was encoded as UTF-8 without BOM (as is usual in Linux), the Visual C++ compiler erroneously assumed that the source code was encoded as Windows ANSI.
10. ↑ . Encoding Standard. WHATWG.  [2021-06-17]. （原始内容存档于2015-02-04）.
11. ↑ . Encoding Standard. WHATWG.  [2021-06-17]. （原始内容存档于2015-02-04）.

外部連結
----

* Unicode FAQ: *UTF-8, UTF-16, UTF-32 & BOM*（页面存档备份，存于）
* The Unicode Standard, chapter 2.6 *Encoding Schemes*（页面存档备份，存于）
* The Unicode Standard, chapter 2.13 *Special Characters and Noncharacters*, section *Byte Order Mark（BOM）*（页面存档备份，存于）
* The Unicode Standard, chapter 16.8 *Specials*, section *Byte Order Mark (BOM): U+FEFF*（页面存档备份，存于）

|  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| 

| * 
* 论
* 编
Unicode |
| --- |
|  |
| Unicode | 
* 統一碼聯盟
* 通用字符集
* Unicode

 |
|  |
| 码位 | 
* Unicode區段
* 通用字元集字元（英语：）
* Unicode字元特性（英语：）
* Unicode字符平面映射
* 私人使用区

 |
|  |
| 字符 | 

|  |  |
| --- | --- |
| 通用字元集字元（英语：） | 
* 位元組順序記號
* Combining Grapheme Joiner（英语：）
* 左至右符號及右至左符號
* 軟連字符（英语：）
* 变体
* 連詞字符
* 零宽连字
* 零宽不连字
* 零宽空格

 |
|  |
| 列表 | 
* Unicode字符列表
* 中日韓統一表意文字
* 組合字符
* Unicode中的重覆字符（英语：）
* Unicode數字
* Unicode收录的文字
* 空格
* Unicode符號
* 全形和半形

 |

 |
|  |
| 處理 | 

|  |  |
| --- | --- |
| 演算法 | 
* 雙向文稿
* 統一碼定序演算法
	+ ISO 14651（英语：）
* Unicode等價性
* 变体序列
* 國際表意文字核心

 |
|  |
| Unicode編碼比較（英语：） | 
* 統一碼二進制有序壓縮
* UTF-16的八位元相容編碼方案
* Punycode
* 統一碼標準壓縮方案
* UTF-1
* UTF-7
* UTF-8
* UTF-16
* UTF-32
* UTF-EBCDIC（英语：）

 |

 |
|  |
| 組合字符 | 
* 組合字符
* Unicode相容字符
* Unicode中的重覆字符（英语：）
* Unicode等價性
* 同形字
* 预组字符
	+ Unicode拉丁文預組字符列表
* Z-变体
* 变体序列
* 区域指示符
* 菲茨派屈克度量

 |
|  |
| 使用 | 
* 国际化域名
* Unicode與電子郵件（英语：）
* Unicode字型
* Unicode與HTML（英语：）
	+ XML与HTML字符实体引用列表
	+ 字符值引用
* Unicode输入法
* 國際表意文字核心

 |
|  |
| 相關標準 | 
* 通用當地數據儲存庫 ‎
* GB 18030
* ISO/IEC 8859
* ISO 15924

 |
|  |
| 相關主題 | 
* Unicode
* CSUR
* 表意文字小組
* 國際統一碼部件
* 漢字統一化（英语：）
* 惡搞RFC#4042（UTF-9 / UTF-18）

 |
|  |
| 

|  Unicode收录的文字 |
| --- |
|  |
| 收录文字 | 
* 組合字符
* 附加符号
* 标点符号
* 空格
* Unicode數字

 |
|  |
| 現代文字 | 
* Adlam alphabet（英语：）
* 阿拉伯文字
	+ 阿拉伯語附加符號（英语：）
* 亞美尼亞字母
* 巴厘字母
* 巴姆穆文字
* 巴塔克文（英语：）
* 孟加拉文
* 注音符號
* 盲文
* 布希德文
* 缅文
* 加拿大原住民音節文字
* Chakma alphabet（英语：）
* 占語字母
* Cherokee syllabary（英语：）
* 中日韓統一表意文字
* 西里尔字母
* 德瑟雷特文（英语：）
* 天城文
* 吉茲字母
* 格鲁吉亚字母
* 希腊字母
* 古吉拉特文
* Gunjala Gondi Lipi（英语：）
* 古木基文
* 諺文
* 哈乃斐羅興亞文字
* 朝鮮漢字
* Hanunó'o alphabet（英语：）
* 希伯来字母
	+ 希伯來語附加符號（英语：）
* 平假名
* 爪哇字母
* 日本汉字
* 卡納達文
* 片假名
* Kayah Li alphabet（英语：）
* 高棉文
* 寮文字
* Unicode中的拉丁字母
* 绒巴文
* Limbu alphabet（英语：）
* 老傈僳文
* 布吉斯文（英语：）
* 馬拉雅拉姆文
* Gondi writing（英语：）
* Mende Kikakui script（英语：）
* Medefaidrin（英语：）
* 柏格理苗文
* 传统蒙古文
* Mro people（英语：）
* 西非書面字母
* 西双版纳傣文
* Prachalit Nepal alphabet（英语：）
* 女书
* Ol Chiki alphabet（英语：）
* 奧里亞文
* Osage alphabet（英语：）
* 奧斯曼亞字母
* Pahawh Hmong（英语：）
* Pau Cin Hau（英语：）
* Rejang alphabet（英语：）
* Samaritan alphabet（英语：）
* Saurashtra alphabet（英语：）
* 蕭伯納字母
* 僧伽羅文
* 索拉僧平字母
* Sundanese alphabet（英语：）
* Sylheti Nagari（英语：）
* 敘利亞字母
* Tagbanwa alphabet（英语：）
* 德宏傣文
* 老傣文
* 傣黯語
* 泰米爾文
* 泰卢固文
* 它拿字母
* 泰文字
* 藏文
* 提非納文字
* 底罗仆多文
* Vai syllabary（英语：）
* Warang Citi（英语：）
* 彝文

 |
|  |
| 古代文字 | 
* 阿洪姆文
* 安納托利亞象形文字（英语：）
* 古北阿拉伯文（英语：）
* 阿維斯陀文（英语：）
* Bassa alphabet（英语：）
* 梵文（英语：）
* 婆罗米文
* 卡里亞文（英语：）
* 高加索阿爾巴尼亞字母（英语：）
* 科普特字母
* 楔形文字
* 塞浦路斯音節文字
* 多格拉語
* 圣书体
* 爱尔巴桑
* 格拉哥里字母
* 哥德字母
* 古兰塔文
* Hatran alphabet（英语：）
* 阿拉米字母
* 巴列維文
* 安息语
* 凱提文
* 佉卢文
* Khojki（英语：）
* Khudabadi script（英语：）
* 线形文字A
* 线形文字B
* 呂西亞字母（英语：）
* Lydian alphabet（英语：）
* Mahajani（英语：）
* 望加錫文（英语：）
* Mandaic alphabet（英语：）
* 摩尼字母
* 象雄语
* Meithei script（英语：）
* 麥羅埃字母
* 馬拉地文（英语：）
* 木爾坦文（英语：）
* 納巴泰字母
* 歐甘字母
* 古匈牙利字母
* 古意大利字母
* 古彼爾姆文
* 古波斯楔形文字
* 粟特字母
* 突厥字母
* 帕米瑞拉文字（英语：）
* 八思巴字母
* 腓尼基字母
* 巴列維文字
* 盧恩字母
* 夏拉達文
* 悉曇文字
* 粟特字母
* 南阿拉伯字母
* 索永布字母
* 贝贝因字母
* 塔卡里文字（英语：）
* 西夏文
* 乌加里特字母
* 札那巴札尔方形字母

 |
|  |
| 標記文字 | 
* 杜普洛伊速記（英语：）
* 薩頓手語譜寫

 |
|  |
| 符號 | 
* Unicode中的宗教與政治符號（英语：）
* 货币符号
* Unicode中的數學運算子與符號（英语：）
* Unicode中的音标符号
* 表情图标

 |

 |

 |