コンテンツにスキップ

バイト順マーク

出典: フリー百科事典『ウィキペディア(Wikipedia)』

バイト順マーク (バイトじゅんマーク、: byte order mark) 、バイトオーダーマークあるいはBOM(ボム)は、Unicode符号化形式で符号化したテキストの先頭につける数バイトのデータ。元にUnicodeで符号化されていることおよび符号化の種類の判別に使用する。

概要

[編集]

プログラムがテキストデータを読み込む時、その先頭の数バイトからそのデータがUnicodeで表現されていること、また符号化形式(エンコーディング)としてどれを使用しているかを判別できるようにしたものである。[1]

経緯

[編集]

Unicodeが開発された当初は、アメリカではASCII、ヨーロッパなどではISO-8859、日本ではShift_JISEUC-JPといった他の文字コードが主流であり、使用されている符号化方式がUnicodeのものであることを明示する必要があった。また、Unicodeの符号化方式は複数あり、特にUTF-16やUTF-32にはそれぞれエンディアンが異なる2種類があるため、符号化方式同士を区別する必要があった。その方法として、先頭のデータにテキスト以外のデータを入れることが発案された。

使用するべきか否か

[編集]

実際にBOMを使用すべきか、あるいは使用すべきでないかは、Unicodeを利用したより上位の仕様によって定められることがある。"XML Media Types" (RFC 3023) では、XMLをUTF-16で符号化する場合は先頭のBOMを必須とし、またXMLを解釈するソフトウェアでは、先頭にBOMがあった場合はxml宣言における<?xml encoding="..."?>の指定よりも優先してエンコーディングを判別すべきとしている[2]JSONの場合は、ネットワークで送信する場合はBOMを付けてはならないとしている[3]

UTF-8は文字コードとしてASCIIを前提としたプログラムでもおよそ支障なく動作するように設計されているが、BOMによって正常に処理できなくなる場合がある。Unicodeの規格において、UTF-8においてBOMは容認されるが、必須でも勧められるものでもないとされている[4]。また、データベースやメモリにロードするデータなど、内部的なデータ形式では、プログラムの性能や効率の観点から普通BOMは用いられない。

BOMによってUnicodeのテキストデータが他のUnicode符号化形式や、BOMのバイト表現(UTF-7を除く)に符号位置に該当する文字のない日本語の文字コードから正確に区別をすることができる一方で、0xFEに"þ"、0xFFに"ÿ"が割り当てられているISO/IEC 8859-1に対しては、この2文字が先頭にくる文章を誤ってUnicodeと判断してしまう問題がある。

各符号化形式(符号化スキーム)ごとのバイト順マーク

[編集]
符号化形式(符号化スキーム) エンディアンの区別 バイト順マーク (BOM)
UTF-8 0xEF 0xBB 0xBF
UTF-16 BE 0xFE 0xFF
LE 0xFF 0xFE
UTF-16BE (付加は認められない)
UTF-16LE (付加は認められない)
UTF-32 BE 0x00 0x00 0xFE 0xFF
LE 0xFF 0xFE 0x00 0x00
UTF-32BE (付加は認められない)
UTF-32LE (付加は認められない)
UTF-7 0x2B 0x2F 0x76 ※ (※は次のバイトの値によって異なり、0x38、0x39、0x2B、0x2Fのいずれかがくる)

関連項目

[編集]

ゼロ幅ノーブレークスペース - U+FEFF の文字

脚注

[編集]
  1. ^ Unicode FAQ”. 2012年7月25日閲覧。
  2. ^ RFC 3023 XML Media Types(2001年1月)
  3. ^ 8.1. Character Encoding - STD 90 - The JavaScript Object Notation (JSON) Data Interchange Format
  4. ^ the Unicode Consortium, Julie D. Allen (2007). The Unicode Standard -- Version 5.0. p. 36. ISBN 0-321-48091-0. https://www.unicode.org/versions/Unicode5.0.0/ch02.pdf. "(from Chapter 2:General Structure) 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"