/
899.txt
695 lines (552 loc) · 26.9 KB
/
899.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
[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] 文字情報
<https://chars.suikawiki.org/char/FEFF>
]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]] <https://www.unicode.org/versions/latest/ch02.pdf#G9354>
- [62] [CITE[The Unicode Standard, Version 13.0 - ch23.pdf]], [TIME[2020-03-09T17:53:52.000Z]], [TIME[2020-12-09T10:59:29.820Z]] <https://www.unicode.org/versions/latest/ch23.pdf#G15334>
- [72] [CITE[The Unicode Standard, Version 13.0 - ch23.pdf]], [TIME[2020-03-09T17:53:52.000Z]], [TIME[2020-12-14T11:10:22.507Z]] <https://www.unicode.org/versions/latest/ch23.pdf#G19635>
]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]]
を書きます。
[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[(<http://www.airemix.com/bbs/> 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]] 版) <http://www.w3.org/TR/xml/#charencoding>
- [45] [CITE@en[RFC 7303 - XML Media Types]] ([TIME[2014-07-07 20:56:43 +09:00]] 版) <http://tools.ietf.org/html/rfc7303#section-3.3>
-- [33] 旧旧版 [CITE@en[RFC 2376 - XML Media Types]] ([TIME[1998-07]] 版) <http://tools.ietf.org/html/rfc2376>
-- [32] 旧版 [CITE@en[RFC 3023 - XML Media Types]] ([TIME[2014-07-11 12:46:44 +09:00]] 版) <http://tools.ietf.org/html/rfc3023#section-4>
]REFS]
;; [47] [[BOM]] と他の[[文字コード]]指定との関係については、
[[XMLにおける文字コード]]を参照してください。
* メモ
[FIG(amazon)[
[[Unicode]]
]FIG]
- [11] [ABBR[BOM]] なんて消えてなくなれ!
- [12] ついでに [[UTF-16]] もなくなれ!
- [13] このさい [[Unicode]] もなくなってしまえ!!
[16]
[CITE[QA/Utf8BomInteropReport - ESW Wiki]] <http://esw.w3.org/topic/QA/Utf8BomInteropReport>
([[名無しさん]] [WEAK[2006-12-13 12:36:42 +00:00]])
[17]
[CITE[I18N Tests: UTF-8 signature 1]] <http://www.w3.org/International/tests/sec-utf8-signature-1.html>
[18]
[CITE@ja[BOM は Bomb? | | プログラマ2.0日報 | あすなろBLOG]] ([TIME[2008-11-13 10:21:17 +09:00]] 版) <http://blog.pasonatech.co.jp/sugiura/8981.html>
[19]
>>18
>まあ「BOM が必要」なコンテキストというのは単に
>
今が移行期だから
>
ということであるに過ぎません。とっととこういうものは要らなくなるようになってほしいですね。
[[UTF-16]] よとっととなくなれということですね、わかります。
[20] [CITE@en[MAMA: Basic document structure - Opera Developer Community]] ([TIME[2008-11-25 20:12:03 +09:00]] 版) <http://dev.opera.com/articles/view/mama-basic-document-structure/#boms>
>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]] 版) <http://www.revulo.com/blog/20090129.html#p01>
[22] [CITE@en[(X)HTML5 Tracking]]
([TIME[2009-09-15 20:15:36 +09:00]] 版)
<http://html5.org/tools/web-apps-tracker?from=3852&to=3853>
[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]] 版)
<https://www.w3.org/Bugs/Public/show_bug.cgi?id=12897>
[24] [CITE@en[Web Applications 1.0 r7360 Make a BOM override HTTP headers.]]
( ([TIME[2012-09-16 12:55:00 +09:00]] 版))
<http://html5.org/tools/web-apps-tracker?from=7359&to=7360>
[25] [CITE@en[Charinfo — ""]]
( ([TIME[2013-03-16 12:16:43 +09:00]] 版))
<http://chars.suikawiki.org/char/FEFF>
[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]] 版))
<http://html5.org/tools/web-apps-tracker?from=7781&to=7782>
[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]] 版))
<http://lists.w3.org/Archives/Public/www-tag/2013Nov/0102.html>
[28] [CITE@en[Re: BOMs]]
( ([[Bjoern Hoehrmann]] 著, [TIME[2013-11-18 21:35:00 +09:00]] 版))
<http://lists.w3.org/Archives/Public/www-tag/2013Nov/0119.html>
[29] <http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cscript%3E%0A%20%20var%20p%20%3D%20document.createElement%20(%27p%27)%3B%0A%20%20p.innerHTML%20%3D%20%27%5CuFEFFabcd%27%3B%0A%20%20w%20(p.textContent.length)%3B%0A%3C%2Fscript%3E>
は [[Firefox]] でも [[Chrome]] でも5になります。つまり innerHTML の先頭に
U+FEFF があっても無視されません。 [TIME[2014-06-10T01:40:33.100Z]]
[30] <http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Ciframe%3E%3C%2Fiframe%3E%0A%3Cscript%3E%0A%20%20var%20doc%20%3D%20document.getElementsByTagName%20(%27iframe%27)%5B0%5D.contentDocument%3B%0A%20%20doc.open%20()%3B%0A%20%20doc.write%20(%27%5CuFEFFabcd%27)%3B%0A%20%20doc.close%20()%3B%0A%20%20w%20(doc.body.textContent.length)%3B%0A%3C%2Fscript%3E>
は [[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]] 版))
<http://tools.ietf.org/html/rfc5854#section-4.2.13>
[49] [CITE@en[Let the Encoding standard deal with the BOM · whatwg/html@83ebb72]]
([TIME[2016-02-10 22:46:09 +09:00]] 版)
<https://github.com/whatwg/html/commit/83ebb728198801e2f1a32b80ec7d7a2e7dccc593>
[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]] 版)
<https://github.com/whatwg/encoding/commit/0a29220bd70173964f2e29bf8288c57f7255180a>
[51] ([TIME[2013-11-18 10:05:28 +09:00]])
<http://www.cipa.jp/std/documents/j/DC-008-2012_J.pdf#page=70>
[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]])
<https://github.com/whatwg/encoding/commit/6f9a41f3d9dbc7ba6d88f65f7ef1c139fb08d4be>
[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]])
<https://github.com/whatwg/encoding/pull/151>
[58] [CITE@en[Give clearer advice on hooks for standards]]
([[annevk]]著, [TIME[2018-04-25 21:22:45 +09:00]])
<https://github.com/whatwg/encoding/commit/b579018b406d7752f8b7a3aa9c2bc800519c6f1a>