バイト順マーク

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

概要[編集]

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

経緯[編集]

UnicodeがはじまったころはアメリカではASCII、ヨーロッパなどではISO-8859、日本ではShift_JISやEUC-JPが主流であり、使用されている符号化方式がUnicodeであることを明確に区別する必要があった。その方法として、先頭のデータにテキスト以外のデータを入れることが発案された。

また、1文字が数バイトに渡るUnicodeでは、エンディアンの違いが認識できないと^[2]、例えばPowerPC Macintoshとx86 MS-DOSとの間で正常にデータの交換ができないため、この先頭バイトにより区別できるようにされた。

使用するべきか否か[編集]

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

UTF-8は文字コードとしてASCIIを前提としたプログラムでもおよそ支障なく動作するように設計されているが、BOMによって正常に処理できなくなる場合がある。Unicodeの規格において、UTF-8においてBOMは容認されるが、必須でも勧められるものでもないとされている^[5]。また、データベースやメモリにロードするデータなど、内部的なデータ形式では、プログラムの性能や効率の観点から普通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
UTF-16	LE	0xFF 0xFE
UTF-16BE		（付加は認められない）
UTF-16LE		（付加は認められない）
UTF-32	BE	0x00 0x00 0xFE 0xFF
UTF-32	LE	0xFF 0xFE 0x00 0x00
UTF-32BE		（付加は認められない）
UTF-32LE		（付加は認められない）
UTF-7		0x2B 0x2F 0x76 ※ （※は次のバイトの値によって異なり、0x38、0x39、0x2B、0x2Fのいずれかがくる）

脚注[編集]

^ “Unicode FAQ”. 2012年7月25日閲覧。
^ UTF-8エンコーディングは1バイトずつ処理するためエンディアンの影響はない。このためテキストファイルや通信データの交換などに用いるのに適している。一方、UTF-16やUTF-32エンコーディングは複数バイトずつ処理するためエンディアンの違いを認識する必要がある。システム内部で使用されていたが、次第にデータ交換でも使用されるようになった。
^ “RFC [https://datatracker.ietf.org/doc/html/rfc3023 3023 - XML Media Types]”. 2012年7月25日閲覧。
^ 8.1. Character Encoding - STD 90 - The JavaScript Object Notation (JSON) Data Interchange Format
^ the Unicode Consortium, Julie D. Allen (2007). The Unicode Standard -- Version 5.0. p. 36. ISBN 0-321-48091-0. "(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"

[1] “Unicode FAQ”. 2012年7月25日閲覧。

[2] UTF-8エンコーディングは1バイトずつ処理するためエンディアンの影響はない。このためテキストファイルや通信データの交換などに用いるのに適している。一方、UTF-16やUTF-32エンコーディングは複数バイトずつ処理するためエンディアンの違いを認識する必要がある。システム内部で使用されていたが、次第にデータ交換でも使用されるようになった。

[3] “RFC [https://datatracker.ietf.org/doc/html/rfc3023 3023 - XML Media Types]”. 2012年7月25日閲覧。

[4] 8.1. Character Encoding - STD 90 - The JavaScript Object Notation (JSON) Data Interchange Format

[5] the Unicode Consortium, Julie D. Allen (2007). The Unicode Standard -- Version 5.0. p. 36. ISBN 0-321-48091-0. "(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"

[1]

[2]

[3]

[4]

[5]

概要[編集]

経緯[編集]

使用するべきか否か[編集]

各符号化形式（符号化スキーム）ごとのバイト順マーク[編集]

関連項目[編集]

脚注[編集]