使用位元組順序標記
Unicode 文字檔可能以數種格式編碼，包括UTF-8、UTF-16和UTF-32。 這些格式都可以加上位元組順序標記（BOM），指出文字寫入時所使用的位元組順序。 下表列出可用的位元組順序標記。 對於UTF-8，位元組順序標記是選擇性的，因為位元元元可能只有一個順序。 對於UTF-16和UTF-32，需要位元組順序標記，因為這些格式會區分位元組順序。
注意
位元組順序標記不是選取文字位元組順序的控制字元。
| 位元組順序符號 | 描述 |
|---|---|
| EF BB BF | UTF-8 |
| FF FE | UTF-16，小端 |
| FE FF | UTF-16， big endian |
| FF FE 00 00 | UTF-32，小端 |
| 00 00 FE FF | UTF-32，big-endian |
注意
舊版Microsoft產品使用 Windows-1252 或 UCS-2（固定的 UTF-16），小端位元組順序為 “Unicode”。 針對新的應用程式，建議使用UTF-8。
在理想情況下，所有 Unicode 文字只會遵循一組位元組排序規則。 不過，這是不可能的，因為微控制器在最小顯著位元組的位置上不同。 Intel 和 MIPS 處理器會先放置最不重要的位元組，而摩托羅拉處理器（以及所有位元組反轉 Unicode 檔案）則將其放在最後一個位置。 只有一組位元組排序規則，一種類型的微控制器的使用者每次純文本檔讀取或寫入時，都會強制交換位元組順序，即使檔案從未根據不同的微控制器傳輸至另一個操作系統也一樣。
指定位元組順序的慣用位置是在檔案標頭中，但文本檔沒有標頭。 因此，Unicode 已將字元 （U+FEFF） 和非字元 （U+FFFE） 定義為位元組順序標記。 它們是彼此的鏡像位元元影像。
由於一般非 Unicode 文字文件開頭的序列 U+FEFF 非常罕見，因此它可以做為隱含標記或簽章，將檔案識別為 Unicode 檔案。 讀取 Unicode 和非 Unicode 文字檔的應用程式應該使用此序列的存在作為檔案最有可能是 Unicode 檔案的指標。 比較這項技術與使用 MS-DOS EOF 標記終止文本檔。
當應用程式在文本檔開頭找到U+FEFF時，通常會以 Unicode 檔案的形式處理檔案，不過它可以執行進一步啟發學習檢查以進行驗證。 這類檢查可以像測試一樣簡單，以找出低階位元組的變化是否遠高於高階位元組的變化。 例如，如果 ASCII 文字轉換成 Unicode 文字，則每秒位元組為 0。 此外，檢查換行字元和歸位字元 （U+000A 和 U+000D）以及偶數或奇數檔案大小，可以提供檔案本質的強指標。
當應用程式在文本檔開頭找到U+FFFE時，它會將它解譯為表示檔案是位元組反轉 Unicode 檔案。 應用程式可以交換位元組的順序，或提醒用戶發生錯誤。
由於在任何代碼頁中找不到 Unicode 位元組順序標記字元，因此如果數據轉換成 ANSI，就會消失。 與其他 Unicode 字元不同，轉換時不會以預設字元取代它。 如果在檔案中間找到位元組順序標記，就不會將它解譯為 Unicode 字元，而且不會影響文字輸出。
注意
純文本檔案中的 Unicode 值 U+FFFF 不合法，而且無法在應用程式之間傳遞。 它保留給應用程式的私人使用。
相關主題