[36] [DFN[[RUBY[[CODE(charname)@en[[[BOM]]]]][ボム]]]] ([DFN[[CODE(charname)@en[[[BYTE ORDER MARK]]]]]]) は、 [[Unicode]] 系[[文字コード]]による[[文字列]]の先頭に付与する特定の[[バイト列]]です。 [63] [DFN[[CODE[U+FEFF]]]] [DFN[[CODE(charname)@en[ZERO WIDTH NO-BREAK SPACE]]]] ([DFN[[CODE(charname)@en[ZWNBSP]]]]) は、 [[改行]]禁止を表す[[零幅文字]]です。 [REFS[ - [41] 文字情報 ]REFS] [37] [[BOM]] は [[Unicode]] 系[[文字コード]]である [[UCS-2]]、[[UCS-4]]、 [[UTF-8]]、[[UTF-16]]、[[UTF-32]] などに存在します。それぞれの[[文字コード]]における [CODE(char)[[[U+FEFF]]]] [CODE(charname)@en[[[ZERO WIDTH NO-BREAK SPACE]]]] [[文字]]に対応する[[バイト列]]を[[文字列]]の先頭に置くことで、 [[エンディアン]]やどの[[文字コード]]を使っているかを識別できます。 [38] [[BOM]] は、その[[バイト列]]によって表される[[文字列]]の一部ではないので、 [[バイト列]]から[[文字列]]への変換で除去されるべきものです。本来の[[文字]]としての [CODE(charname)@en[[[ZERO WIDTH NO-BREAK SPACE]]]] を使いたいことはほとんどありませんが、 先頭に [CODE(char)[[[U+FEFF]]]] を2つ並べると1つ目は [[BOM]]、2つ目は [CODE(charname)@en[[[ZERO WIDTH NO-BREAK SPACE]]]] とみなされます。 ;; [39] [[BOM]] は[[バイト列]]の先頭でのみ使われます。途中では使うことができません。 ;; [40] [[BOM]] は必須ではありません。 * 代替 [54] [[BOM]] は [[UTF-16]] の衰退と [[UTF-8]] への統一により不要となり、 あまり使われなくなりました。 [55] [CODE(charname)@en[ZWNBSP]] は [[BOM]] との混同を避けるため、使われなくなりました。 元の用法ではかわりに [CODE(charname)@en[WORD JOINER]] が使われています。 * 仕様書 [REFS[ - [99] [CITE[[[The Unicode Standard]], Version 13.0 - ch02.pdf]], [TIME[2020-03-09T17:53:32.000Z]], [TIME[2020-12-20T09:45:33.849Z]] - [62] [CITE[The Unicode Standard, Version 13.0 - ch23.pdf]], [TIME[2020-03-09T17:53:52.000Z]], [TIME[2020-12-09T10:59:29.820Z]] - [72] [CITE[The Unicode Standard, Version 13.0 - ch23.pdf]], [TIME[2020-03-09T17:53:52.000Z]], [TIME[2020-12-14T11:10:22.507Z]] ]REFS] * 意味 [73] [CODE(charname)@en[BOM]] は、 [[Unicode文字列]]を表す[[バイト列]]の先頭で用いて、 [[文字コード]]が [[Unicode]] であることを示し、 しかも具体的にどの[[バイト順]]の[[符号化]] (または [[UTF-8]]) であるか区別できるように示すものであります。 [SRC[>>72]] * 構文 [74] [CODE(charname)@en[BOM]] は、 各[[文字コード]]において、 [CODE[U+FEFF]] を表す[[バイト列]]です。 [75] [[Unicode]] では次の[[バイト列]]とされています。 [SRC[>>72]] - [76] [[UTF-8]]: 0xEF 0xBB 0xBF - [77] [[UTF-16]] [[大エンディアン]]: 0xFE 0xFF - [78] [[UTF-16]] [[小エンディアン]]: 0xFF 0xFE - [79] [[UTF-32]] [[大エンディアン]]: 0x00 0x00 0xFE 0xFF - [80] [[UTF-32]] [[小エンディアン]]: 0xFF 0xFE 0x00 0x00 - [89] [[SCSU]]: 0x0E 0xFE 0xFF - [90] [[BOCU-1]]: 0xFB 0xEE 0x28 - [91] [[UTF-7]]: 0x2B 0x2F 0x76 0x38 または 0x2B 0x2F 0x76 0x39 または 0x2B 0x2F 0x76 0x2B または 0x2B 0x2F 0x76 0x2F - [92] [[UTF-EBCDIC]]: 0xDD 0x73 0x66 0x73 [81] 各[[プロトコル]]は必ずしもこのすべてを認めてはいません。 例えば [[Web]] は [[UTF-8]] と [[UTF-16]] の3種類のみ対応しています。 [SEE[ [[復号][復号 (符号化)]] ]] [95] 古い実装は、 0x00 0x00 0xFE 0xFF と 0xFF 0xFE 0x00 0x00 を [CODE[U-7FFFFFFF]] まであった昔の [[UCS-4]] と解釈することがあります。 同様に 0xEF 0xBB 0xBF を昔の [[UTF-8]] と解釈することがあります。 [96] 一部の実装は、 0xFE 0xFF 0x00 0x00 を [CODE[X-ISO-10646-UCS-4-3412]]、 0x00 0x00 0xFF 0xFE を [CODE[X-ISO-10646-UCS-4-2143]] と解釈するようです。 [97] 理屈上は [[GB 18030]] でも [CODE(charname)@en[BOM]] を使えるはずですが、 実例があるかは不明です。 ;; [98] [[UTF-7]] が何通りもあるのは、続きの[[バイト列]]と共に [[Base64]] [[符号化]]した先頭部分だからです。 -*-*- [82] [CODE[U+FFFE]] が[[非文字]]とされており、 [[情報交換]]される [[Unicode文字列]]には含まれないことになっています。 そこで先頭に現れるとすれば [CODE[U+FEFF]] だと仮定して判定できます。 ;; [102] [[非文字]]は[[実装依存]]の方法で使うことができます。 外部との[[情報交換]]に用いない特定の実装で用いる[[文字列]]なら、 [CODE[U+FFFE]] が含まれる可能性はあります。 その可能性がある場合には、 [CODE(charname)@en[BOM]] を使わない[[実装依存]]の方法で[[文字符号化]]を決定しなければなりません。 [83] [N[0xBB]], [N[0xBF]], [N[0xEF]], [N[0xFE]], [N[0xFF]] は、 [[ISO/IEC 8859-1]], [[Windows-1252]], [[MacRoman]], [[Adobe Standard Encoding]], [[EBCDIC]] といった既存の[[文字コード]]で使われることはあるものの、 この組み合わせでは出現する可能性が低いとされています。 [SRC[>>72]] ;; [103] しかも[[文字列]]の先頭に来る可能性はかなり低いと考えられます。 -*-*- [86] [CODE(charname)@en[BOM]] が使われる場合、 当該[[Unicode文字列]]を表現する[[バイト列]]は、 当然、 [CODE(charname)@en[BOM]] を表す[[バイト列]]の長さの分、長くなります。 変換するソフトウェアは、 変換結果を格納する[[バッファー]]の長さの決定に注意が必要となります。 [87] [CODE(charname)@en[BOM]] を使う場合、 [[空文字列]]を表す[[バイト列]]の長さが [N[0]] ではなくなります。 [[バイト列]]としての長さ判定をもって[[文字列]]の指定の有無を判定するようなプログラムは意図通りに動作しません。 [88] [CODE(charname)@en[BOM]] を使った (または使われている可能性がある) [[Unicode文字列]]の連結は、 単純な[[バイト列]]の連結とは異なることに注意が必要です。 * BOM と符号化ラベル [53] [[Web]] ([[Encoding Standard]]) では、[[符号化ラベル]]と [[BOM]] の両方が存在する場合、[[BOM]] が優先されることになっています。 [SEE[ [[復号][復号 (符号化)]] ]] * BOM の処理 [59] 現在では普通[[文字コード]]は [[UTF-8]] です。 [[UTF-8]] で出力する[[ソフトウェア]]は、 [[BOM]] を[[生成]]するべきではありません。 今となっては [[BOM]] は使う意味がなく、 かえって混乱のもとになります。 [60] [[バイト列]]を解釈する[[ソフトウェア]]は、 [[文字コード]]の[[復号]]の規定に基づき、適宜 [[BOM]] を無視しなければなりません。 その場合先頭の [N[0xFEFF]] は [CODE(charname)@en[BOM]] 解釈しなければなりません [SRC[>>72]]。 もはや [[BOM]] に意味がないとはいえ、 既に [[BOM]] がついたデータが大量に生成されていますし、 未だに [[BOM]] がついたデータを生成するソフトウェアが残っていますから、 すべてのソフトウェアは [[BOM]] のあるデータに対応しなければならないのです。 [SEE[ 具体的には [[UTF-8]] などの[[復号]]を参照 ]] [61] [CODE(charname)@en[BOM]] は[[バイト列]]から[[文字列]]に変換する時点で除去する[RUBYB[べき][should]]です [SRC[>>72]]。 [[文字列]]を操作する[[ソフトウェア]]は [CODE(charname)@en[BOM]] に対応する必要はありませんし、 むしろ何もしてはいけません。 ([[プログラミング言語]]の[[文字列型]]は、 [[文字列]]なので、 操作する[[プログラム]]は [CODE(charname)@en[BOM]] を意識しなくて構いません。) -*-*- [93] [CITE[The Unicode Standard]] に示された [CODE(charname)@en[BOM]] の[[バイト列]] (>>75) のうち、 [[BOCU-1]] と [[UTF-7]] のものは、 それ以後の[[バイト列]]の解釈に影響が出てしまうので、 すべて含めて一体として[[文字列]]に変換して、 その先頭の [N[0xFEFF]] を除去する必要があります。 [SRC[>>72]] [94] それ以外の[[文字コード]]の [CODE(charname)@en[BOM]] の[[バイト列]]は、 [[バイト列]]として除去し、 それ以降の[[バイト列]]だけ[[文字列]]に変換することができます。 [SRC[>>72]] * 文字 [CODE(charname)@en[ZWNBSP]] [64] [[文字]]として現れる [CODE[U+FEFF]] の意味は、 [CODE(charname)@en[WORD JOINER]] と同じです。 [SRC[>>62]] すなわち、 それと前後の[[文字]]との間で原則[[改行]]が禁止されることを示します。 [SEE[ [CODE(charname)@en[WORD JOINER]] ]] [65] [[Unicode 3.2]] までこの機能には [CODE(charname)@en[ZWNBSP]] を使うことになっていましたが、 [CODE(charname)@en[BOM]] としての方が使われるようになったため、 [CODE(charname)@en[WORD JOINER]] が追加されたとされます。 [SRC[>>62]] 故に [[Unicode 3.2]] までとの互換性のためを除き、 [CODE[U+FEFF]] を [CODE(charname)@en[ZWNBSP]] として使用しないこととされています [SRC[>>72]]。 [[文字の名前]]が [[byte order mark]] でなく [CODE(charname)@en[ZERO WIDTH NO-BREAK SPACE]] であるのは、 [[歴史的理由]]であるとされます [SRC[>>72]] [WEAK[([[文字の名前]]の変更は認められていません)]]。 [68] 理屈の上では[[バイト列]]の先頭にあるのが [CODE(charname)@en[BOM]]、 [[文字列]]の任意の位置に現れ得るのが [CODE(charname)@en[ZWNBSP]] と明確に区別し得ますし、 [CODE(charname)@en[BOM]] が認識されなかった場合でも目に見えない[[零幅文字]]なので害はない、 というのが当初これに2つの意味を持たせた設計思想だったのでしょう。 実際にはことはそううまく進まず、 [N[0xFEFF]] の扱いには混乱がありました。 それで結局別の[[符号位置]]を用意することになったようです。 [CITE[The Unicode Standard]] は、 [CODE(charname)@en[BOM]] が入った[[ファイル]]を連結すると途中に [N[0xFEFF]] が入ってしまうが、 [CODE(charname)@en[ZWNBSP]] と [CODE(charname)@en[BOM]] の2つの意味があるので [N[0xFEFF]] を無条件に除去できないことを、 設計の失敗として挙げています [SRC[>>72]]。 [66] 新しいテキストでは [CODE[U+2060]] [CODE(charname)@en[WORD JOINER]] を使うことが[RUBYB[強く推奨][strongly preferred]] [SRC[>>62, >>72]] ([RUBYB[べき][should]] [SRC[>>72]]) されます。 [SRC[>>62, >>72]] [67] [[実装]]は、 [[後方互換性]]のため、 [CODE[U+FEFF]] にも対応し続ける[RUBYB[べき][should]]です。 [SRC[>>62]] [85] [CODE(charname)@en[BOM]] が使われる場合に先頭の [CODE(charname)@en[ZWNBSP]] を表すためには、 先頭に [N[0xFEFF]] が2つ現れることになります。 [SRC[>>72]] -*-*- [84] 「[[UTF-16BE]]」, 「[[UTF-16LE]]」 のように[[バイト順]]が明示されている場合や、 [[文字列]]を扱う [[API]] や[[データベース]]などで[[バイト順]]が既知である場合には、 [N[0xFEFF]] は [CODE(charname)@en[BOM]] ではなく [CODE(charname)@en[ZWNBSP]] と解釈します。 [SRC[>>72]] [69] [CODE(charname)@en[DOCS]] によって [[ISO/IEC 10646]] に切り替えられた直後の [N[0xFEFF]] がどう解釈されるべきかは不明です。 [SEE[ [[ISO/IEC 10646におけるエスケープシーケンス]] ]] * 文脈 [100] [[PDF]] 中の [[UTF-16BE]] 文字列の先頭には、 [CODE(charname)@en[BOM]] を書きます。 [105] [[ReliableTXT]] の先頭には [CN[BOM]] を書きます。 [108] [[ZIP]] では使いません。 [SEE[ [[ZIPの文字コード]] ]] [101] 関連: [[HTMLにおける文字コード]], [[XMLにおける文字コード]], [[JSONにおける文字コード]] * 関連 [70] [CODE(charname)@en[ZWSP]], [CODE(charname)@en[NBSP]] とは挙動が違います。 [71] [[爆発]]はしません。 * 歴史 ** ISO/IEC 10646 における BOM [1] [[ISO/IEC10646]] には「byte order mark」という言葉は出てきません ([[UnicodeStandard]] には出てきます)。 10646 は [ABBR[BOM] [Byte order mark]] のことを、「[ABBR[[[UCS]]]] を識別する『signature』」と呼んでいます。 ISO/IEC 10646-1:2000 附属書 H (参考) The use of “signatures” to identify UCS に説明があります。 > This annex describes a convention for the identification of features of the UCS, by the use of "signatures" within data streams of coded characters. The convention makes use of the character ZERO WIDTH NO-BREAK SPACE, and is applied by a certain class of applications. なんだそーです。使いたけりゃ使えば? 的で結構さめてます。 引用部の後の方の記述によると、 ,UCS-2 signature ,FEFF ,UCS-4 signature ,0000 FEFF ,UTF-8 signature ,EF BB BF ,UTF-16 signature ,FEFF ってことですが、別に [ABBR[UCS]]-2/4, [ABBR[UTF]]-8/16 を区別できるのが 嬉しいのじゃなくて、その名の通りバイト順を区別できるのが嬉しいんです。 - UCS-2/UTF-16BE: FEFF - UCS-2/UTF-16LE: FFFE - UCS-4/UTF-32BE: 0000 FEFF - UCS-4/UTF-32LE: FFFE 0000 このように、[[エンディアン]]が識別できるんです。素晴らしいでしょ? :-) だから [[UTF-8]] ではこんなの要らんのですが、一貫性かなんかのために、 つけようというのが当世風。対応してない応用からすると頭にゴミです。 おまけに、 [ABBR[UTF]]-8 の最大の特徴であった [ABBR[[[ASCII]]]] との互換性を ぶっ飛ばしてしまいます。 [CODE(char)[ZERO WIDTH NO-BREAK SPACE]] ([CODE(char)[[ABBR[ZWNBSP]]]]) が [CODE(char)[U+FEFF]] に置いてあって、 [CODE(char)[U+FFFE]] が「not a character」になってるのは偶然じゃありません。 [CODE(char)[[ABBR[BOM]]]] に使うためにわざわざこう配置したんです。 で、あとから [CODE(char)[[ABBR[BOM]]]] ありなし問題云々で [CODE(char)[U+FEFF]] を [CODE(char)[[ABBR[ZWNBSP]]]] 本来(?)の役目に使うことが出来ない状況になってしまった [WEAK[(ほんとか?)]] もんですから、 [CODE(char)[ZERO WIDTH NON-JOINER]] [WEAK[(だっけ?)]] とかを別に追加することになったとか。 (そして追加されたとか。) しょーもない話ですなあ。 ** BOM は必須ですか? [3] '''質問''': > BOMって本来必須なものだと思っていたのですけど、そうでもないんですね [INS[( No.148-13)]] [2] はい。 >>1 にあるように、原則として必要ありません。 ただし、 [ABBR[[[UCS]]]] を使用する場面などによって、その場面で使用する規格などが [ABBR[BOM]] を使わなければならないと規定していること'''も'''あります。 その場合はもちろん必須になります。 ** UTF-8 と UTF-8n [4] '''質問''': [[UTF-8]] の名前に [CODE[UTF-8]] と [CODE[UTF-8n]] があるようなのですが、どう違うのですか。 [5] まずはっきりさせておかないといけないこととして、 [CODE[UTF-8n]] という名前はあまり知られていません。ですから、 [CODE[UTF-8]] と [CODE[UTF-8n]] にはっきり使い分けがあるのかというと、そうでもありません。 [6] [CODE[UTF-8n]] という名前を提案しているのは、 [[UnicodeConsortium]] のそれなりに偉い人 (誰かは忘れた。) のようです。 しかも、その人の文章 (どこにあったか忘れた。 [[dW]] かなあ。) では、使い分けが当然であるかのように書いてあります。 しかし、 Unicode や [ABBR[ISO]]/[ABBR[IEC]] 10646 の規格票を見ても、そんなことは全然書いてありません。 つまり、両者を使い分ける提案はありますが、標準化団体や世間で受け入れられているものではありません。 また、受け入れられるけはいもありません。 [7] さて、回答ですが、使い分けを提案している人は、 [CODE[UTF-8n]] を [ABBR[BOM]] なしの UTF-8 に、 [CODE[UTF-8]] を [ABBR[BOM]] ありの UTF-8 に使おうと言っています。 [9] しかし実際には [CODE[UTF-8]] という名前は [ABBR[BOM]] なしに対して呼ばれることが多いです。 (最近は [ABBR[BOM]] ありに対して言うことも多くなってきたようです。 [WEAK[(とはいえ、統計は無いので感覚的に、です。)]]) [8] >>9 のような状況でどうして >>7 のような定義を提案しているのかですが、おそらく [ABBR[BOM]] ありを普及させたい意図があるのでしょう。 [10] なお、 [ABBR[[[IETF]]]] [[charset]] 名 ([ABBR[[[MIME]]]] ([[電子メイル]]) や [ABBR[[[HTTP]]]] で使われる。) では [CODE(charset)[UTF-8]] だけを定義していて、その内容は [ABBR[BOM]] はあっても無くてもいい、というものです。 - [14] [WEAK[2004-02-17 05:00:41 +00:00]] ''[[naruse]]'': 結構UTF-8Nって使う人は多いように思いますよ。UNIX系で最初の一行で処理を決めるとき(#!なんちゃら)、BOMがあるとエラーになってしまうため、UTF-8Nでないといけないのです。 [15] >>14 Windows のメモ帳の影響がどれくらいのものかはわかりませんが、 基本的には今も昔も [ABBR[BOM]] なしの UTF-8 がずっと多いと思います。 ここで問題にされているのは、そのような話ではなくて、 BOM なし/ありの UTF-8 をそれぞれどのような名前で呼ぶかですよね。 - BOM があってもなくても、どちらも (またはどちらかわからない状態を) [CODE[UTF-8]] と呼ぶ人がいる。 - BOM があったら [CODE[UTF-8]] と呼び、 BOM がなければ [CODE[UTF-8N]] と呼ぶ人がいる。 - BOM の問題を知らない人がいる。 - この問題とは関係ないけど、 UTF-8 のことを Unicode と呼ぶ人もいる。 「UTF-8N」といえば BOM なしであることに疑問の余地はありませんが、 「UTF-8」といった時に一般には BOM のあり・なしを断定できないのです。 経験的には、「UTF-8」に対応しているソフトウェアの多くは BOM ありまたは BOM なしのいずれかしか扱えなくて、 BOM なしだけを扱える方がずっと多く、 たまに、 BOM ありで最初に実装したソフトウェアに後から「UTF-8N」 と称して BOM なしを追加することがあるくらいの様に思われます。なんとなく。 ** XML における BOM [46] [[XML MIME実体]]は、 [[BOM]] のない [[UTF-8]] を使う[['''べき''']]です [SRC[>>45]]。 [43] [[XML]] では、 [CODE(charset)@en[[[UTF-16]]]] では [[BOM]] は必須とされています [SRC[>>42]]。 また、[[外部実体]]の[[置換文]]が [CODE(char)[[[U+FEFF]]]] で始まる場合で、 [[実体]]に[[テキスト宣言]]が含まれない場合には、 [[UTF-8]] でも [[BOM]] は必須とされています [SRC[>>42]]。 [44] [[XML処理器]]は [CODE(charset)@en[[[UTF-8]]]] と [CODE(charset)@en[[[UTF-16]]]] の [[BOM]] への対応が義務付けられています [SRC[>>42]]。 [31] [[XML]] 関連の [[MIME型]]の規定は、 [[RFC 2781]] [[UTF-16]] から変換する場合には [[BOM]] を除去し、 [[UTF-16]] に変換する場合には [[BOM]] を追加することを要求しています [SRC[>>45, >>33, >>32]]。 ただし [[UTF-8]] との変換の場合を除きます [SRC[>>45]]。 また [[UTF-8]] から [[UTF-16]] 以外へ変換するときも、 [[BOM]] を除去することを要求しています [SRC[>>45]]。 ;; [34] [[RFC 2376]] 時代はなぜか [['''SHOULD''']] でしたが、 [[RFC 3023]] で [['''MUST''']] に修正されています。 [35] ただし [[RFC 2781]] [[UTF-16BE]], [[UTF-16LE]] ([[BOM]] が禁止されている) では [[BOM]] を付けてはならず、 [[UTF-16]] と変換するときは [[BOM]] をつけたりはずしたりしなければ[['''ならない''']]ともされています [SRC[>>45, >>32]]。 [REFS[ - [42] [CITE@EN[Extensible Markup Language (XML) 1.0 (Fifth Edition)]] ([TIME[2013-05-28 20:49:56 +09:00]] 版) - [45] [CITE@en[RFC 7303 - XML Media Types]] ([TIME[2014-07-07 20:56:43 +09:00]] 版) -- [33] 旧旧版 [CITE@en[RFC 2376 - XML Media Types]] ([TIME[1998-07]] 版) -- [32] 旧版 [CITE@en[RFC 3023 - XML Media Types]] ([TIME[2014-07-11 12:46:44 +09:00]] 版) ]REFS] ;; [47] [[BOM]] と他の[[文字コード]]指定との関係については、 [[XMLにおける文字コード]]を参照してください。 * メモ [FIG(amazon)[ [[Unicode]] ]FIG] - [11] [ABBR[BOM]] なんて消えてなくなれ! - [12] ついでに [[UTF-16]] もなくなれ! - [13] このさい [[Unicode]] もなくなってしまえ!! [16] [CITE[QA/Utf8BomInteropReport - ESW Wiki]] ([[名無しさん]] [WEAK[2006-12-13 12:36:42 +00:00]]) [17] [CITE[I18N Tests: UTF-8 signature 1]] [18] [CITE@ja[BOM は Bomb? | | プログラマ2.0日報 | あすなろBLOG]] ([TIME[2008-11-13 10:21:17 +09:00]] 版) [19] >>18 >まあ「BOM が必要」なコンテキストというのは単に > 今が移行期だから > ということであるに過ぎません。とっととこういうものは要らなくなるようになってほしいですね。 [[UTF-16]] よとっととなくなれということですね、わかります。 [20] [CITE@en[MAMA: Basic document structure - Opera Developer Community]] ([TIME[2008-11-25 20:12:03 +09:00]] 版) >The 3 BOMs were found in a total of 17,649 URLs (0.50% of all URLs analyzed). The BOM found most often is utf-8. > ,BOM ,Frequency ,utf-8 ,"17,006" ,utf-16 (little-endian) ,647 ,utf-16 (big-endian) ,26 [21] [CITE@ja-JP[PHP スクリプトは BOM 付き UTF-8 で書いてはいけない - れぶろぐ (2009-01-29)]] ([[revulo]] 著, [TIME[2009-02-11 18:42:19 +09:00]] 版) [22] [CITE@en[(X)HTML5 Tracking]] ([TIME[2009-09-15 20:15:36 +09:00]] 版) [23] [CITE[Bug 12897 – In some parsers, UTF-8 BOM trumps the HTTP charset attribute (Encoding sniffing algorithm)]] ([TIME[2011-12-29 20:02:59 +09:00]] 版) [24] [CITE@en[Web Applications 1.0 r7360 Make a BOM override HTTP headers.]] ( ([TIME[2012-09-16 12:55:00 +09:00]] 版)) [25] [CITE@en[Charinfo — ""]] ( ([TIME[2013-03-16 12:16:43 +09:00]] 版)) [26] [CITE@en[Web Applications 1.0 r7782 Strip a leading BOM from scripts in workers, if any. Also, use more of the encoding spec.]] ( ([TIME[2013-03-30 03:45:00 +09:00]] 版)) [27] [CITE@en[Re: ''''''[''''''Json'''''']'''''' JSON: remove gap between Ecma-404 and IETF draft]] ( ([[Martin J. Dürst]] 著, [TIME[2013-11-14 20:14:29 +09:00]] 版)) [28] [CITE@en[Re: BOMs]] ( ([[Bjoern Hoehrmann]] 著, [TIME[2013-11-18 21:35:00 +09:00]] 版)) [29] は [[Firefox]] でも [[Chrome]] でも5になります。つまり innerHTML の先頭に U+FEFF があっても無視されません。 [TIME[2014-06-10T01:40:33.100Z]] [30] は [[Firefox]] でも [[Chrome]] でも5になります。つまり [CODE(JS)@en[[[document.open]]]] + [CODE(JS)@en[[[document.write]]]] で新しい[[文書]]を作成しても先頭の [[U+FEFF]] は無視されません。 [TIME[2014-06-10T01:42:35.500Z]] [48] [CITE@en[RFC 5854 - The Metalink Download Description Format]] ( ([TIME[2014-09-14 16:54:14 +09:00]] 版)) [49] [CITE@en[Let the Encoding standard deal with the BOM · whatwg/html@83ebb72]] ([TIME[2016-02-10 22:46:09 +09:00]] 版) [50] [CITE@en[Clarify that using the BOM before Content-Type is a violation of sorts · whatwg/encoding@0a29220]] ([TIME[2016-02-10 22:47:11 +09:00]] 版) [51] ([TIME[2013-11-18 10:05:28 +09:00]]) [52] >>51 [[Exif]] の [CODE[DeviceSettingDescription]] [[タグ]]の値は [[BOM]] 付きの [[UCS-2]] と定義されています。 [56] [CITE@en[Describe the relationship between encodings and Unicode encoding schemes]] ([[hsivonen]]著, [TIME[2018-08-23 22:57:39 +09:00]]) [57] [CITE@en[Add an informative note about the relationship of encodings and Unicode encoding schemes by hsivonen · Pull Request #151 · whatwg/encoding]] ([TIME[2018-09-04 16:41:36 +09:00]]) [58] [CITE@en[Give clearer advice on hooks for standards]] ([[annevk]]著, [TIME[2018-04-25 21:22:45 +09:00]]) [104] [CITE[21038-bom-guidance.pdf]], [TIME[2021-01-12T15:47:34.000Z]], [TIME[2023-06-16T10:51:06.151Z]] [106] [CITE@ja[XユーザーのS (ツイートはスレッド全体をご確認ください)さん: 「先日も、弊研究科の担当業者さんが作成してくださったaliasesファイルの先頭にUTF-8のBOMが混入して1番目のアドレスが転送できていなかった×2を発見したのですが、他のドメインは大丈夫ですか?」 / X]], [TIME[午後5:51 · 2024年3月24日][2024-03-24T08:51:54.000Z]], [TIME[2024-03-26T03:14:27.000Z]] [107] [CITE@ja[Xユーザーの狭山あかねさん: 「今まで出会った最悪「BOMつき SJIS」 (中身は Shift JIS のはずなんだけどあたまに UTF-8 の BOM だけついてる)」 / X]], [TIME[午後5:48 · 2025年1月6日][2025-01-06T08:48:32.000Z]], [TIME[2025-01-06T09:25:23.000Z]] [109] [CITE@en[183354 - Make Universal Charset Autodetector recognise UTF by BOM]], [TIME[2025-12-01T08:23:39.000Z]]