アカウント名:
パスワード:
BOMは「ゴミ」であって不要なデータが入ってくるのが無駄だと主張する人がいますが、無駄なのは文字コードの自動判別の方です。
よくある文字コードを自動判定するという動作は、ファイルの内容の一部（1KBとか）、アプリによってはファイルの全部を読んでから文字コードを判定するので非常に負荷が大きいのです。BOMなら3バイト読むだけで済みます。
そして、Unicodeに対応しているアプリであればBOMは文字コード・エンディアンの判別に使えばいいし、そうでないなら無視すればよろしい。
UTF-8のBOMがあるだけで不具合起こすアプリなんていうのは、今時そっちの方がおかしいので修正すれば
わかってないなー。サイズが勿体ないのではなくて、バイトオーダーをわざわざ示す行為が二度手間で無駄なんだよ
世の中に UTF-8 だけしか存在しないならね。現実は 8bitの文字コードなんて山のようにあるから、ファイルの内容を解析するプログラムなら、文字コードを指定するか、決め打ちするか、コードを推測するかのどれかが必要になる。
良くも悪くも WindowsSearch で文字化けした結果が表示されないのはBOMのおかげっていうことだ。
BOMはあくまでバイトオーダーを示すために規定されたもので、BOMによってエンコードを判定できるのは結果論でしかないけどな
Windowsの改行コードに使われている CR (キャリッジリターン) と LF (ラインフィード) の意味はご存知でしょうか。タイプライターでは印字装置は固定され、紙の方が上下左右に移動することで、文字送りや行送りが行われるんです。CRは、紙を固定して移動する装置（キャリッジ）を元の位置に戻すことで、LFとは行を送る（タイプライターなら紙を進める）ことです。
CRとLFはあくまでタイプライターの動作を示すために規定されたもので、CR+LFによって改行を判定できるのは結果論でしかないのですよ。
これを考えればもともと何を目的としていたかなんて無意味であることが理解できるはず。
話をBOMに戻すと、例えば、RFC3023https://datatracker.ietf.org/doc/html/rfc3023 [ietf.org]
今から20年前、2001年のRFCです。ここで、またXMLを解釈するソフトウェアでは、先頭にBOMがあった場合はxml宣言における の指定よりも優先してエンコーディングを判別すべきとしています。
20年前の段階で、BOM で文字エンコーディングを判別すべきとかそういうRFCがあるんです。
ちなみに、結果論でしかない～を言い出すと、文字コードの自動判別なんていうのはもっと駄目で、『「美乳」はEUC-JPにしかないバイト配列だからEUC-JPである』なんて判別のやり方こそ、結果論として成立しているに過ぎず、誤検出の原因になります。
文字コード判別はバッドノウハウの集合体だということですね。そんなものをありがたがる気にはなれません
昔のRFCは、当時の考えの浅はかさや甘さを示すバッドノウハウ。
そのように書いてある箇所が当のRFCに見つからないんですが、具体的に示してもらえますかね。一瞥した限りでは、BOMはもっぱらUTF-16のバイトオーダーを判別する文脈にしか出てきません。
https://tex2e.github.io/rfc-translater/html/rfc3023.html [github.io]
8.9 Application/xml with Omitted Charset and UTF-16 XML MIME Entity
Specifically, the XML processor reads the BOM, and thus knows deterministically that the charset is UTF-16.具体的には、XMLプロセッサはBOMを読み取り、こうして文字セットがUTF-16で確定することを知っています。
のようにBOMが～の場合、CHARSET宣言が～の場合など、条件に応じて消去法等で文字
文字コードの判別じゃなくてUTF-16か否かの判別に使うことしか言及してないじゃん。この話がUTF-8にも適用されるってソースは何ら示されてない。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
あと、僕は馬鹿なことをするのは嫌いですよ (わざとやるとき以外は)。-- Larry Wall
BOM有りに統一すべきだった (スコア:0)
BOMは「ゴミ」であって不要なデータが入ってくるのが無駄だと主張する人がいますが、無駄なのは文字コードの自動判別の方です。
よくある文字コードを自動判定するという動作は、ファイルの内容の一部（1KBとか）、アプリによってはファイルの全部を読んでから文字コードを判定するので非常に負荷が大きいのです。
BOMなら3バイト読むだけで済みます。
そして、Unicodeに対応しているアプリであればBOMは文字コード・エンディアンの判別に使えばいいし、そうでないなら無視すればよろしい。
UTF-8のBOMがあるだけで不具合起こすアプリなんていうのは、今時そっちの方がおかしいので修正すれば
Re: (スコア:0)
わかってないなー。サイズが勿体ないのではなくて、
バイトオーダーをわざわざ示す行為が二度手間で無駄なんだよ
Re: (スコア:1)
世の中に UTF-8 だけしか存在しないならね。
現実は 8bitの文字コードなんて山のようにあるから、
ファイルの内容を解析するプログラムなら、文字コードを指定するか、
決め打ちするか、コードを推測するかのどれかが必要になる。
良くも悪くも WindowsSearch で文字化けした結果が表示されないのはBOMのおかげっていうことだ。
[Q][W][E][R][T][Y]
Re: (スコア:0)
BOMはあくまでバイトオーダーを示すために規定されたもので、BOMによってエンコードを判定できるのは結果論でしかないけどな
もともとは～とか言い出すと (スコア:0)
Windowsの改行コードに使われている CR (キャリッジリターン) と LF (ラインフィード) の意味はご存知でしょうか。
タイプライターでは印字装置は固定され、紙の方が上下左右に移動することで、文字送りや行送りが行われるんです。
CRは、紙を固定して移動する装置（キャリッジ）を元の位置に戻すことで、LFとは行を送る（タイプライターなら紙を進める）ことです。
CRとLFはあくまでタイプライターの動作を示すために規定されたもので、CR+LFによって改行を判定できるのは結果論でしかないのですよ。
これを考えればもともと何を目的としていたかなんて無意味であることが理解できるはず。
話をBOMに戻すと、例えば、RFC3023
https://datatracker.ietf.org/doc/html/rfc3023 [ietf.org]
今から20年前、2001年のRFCです。
ここで、またXMLを解釈するソフトウェアでは、先頭にBOMがあった場合はxml宣言における の指定よりも優先してエンコーディングを判別すべきとしています。
20年前の段階で、BOM で文字エンコーディングを判別すべきとかそういうRFCがあるんです。
ちなみに、結果論でしかない～を言い出すと、文字コードの自動判別なんていうのはもっと駄目で、『「美乳」はEUC-JPにしかないバイト配列だからEUC-JPである』なんて判別のやり方こそ、結果論として成立しているに過ぎず、誤検出の原因になります。
Re: (スコア:0)
文字コード判別はバッドノウハウの集合体だということですね。
そんなものをありがたがる気にはなれません
Re: (スコア:0)
昔のRFCは、当時の考えの浅はかさや甘さを示すバッドノウハウ。
Re: (スコア:0)
20年前の段階で、BOM で文字エンコーディングを判別すべきとかそういうRFCがあるんです。
そのように書いてある箇所が当のRFCに見つからないんですが、具体的に示してもらえますかね。
一瞥した限りでは、BOMはもっぱらUTF-16のバイトオーダーを判別する文脈にしか出てきません。
Re: (スコア:0)
https://tex2e.github.io/rfc-translater/html/rfc3023.html [github.io]
8.9 Application/xml with Omitted Charset and UTF-16 XML MIME Entity
Specifically, the XML processor reads the BOM, and thus knows deterministically that the charset is UTF-16.
具体的には、XMLプロセッサはBOMを読み取り、こうして文字セットがUTF-16で確定することを知っています。
のようにBOMが～の場合、CHARSET宣言が～の場合など、条件に応じて消去法等で文字
Re: (スコア:0)
文字コードの判別じゃなくてUTF-16か否かの判別に使うことしか言及してないじゃん。
この話がUTF-8にも適用されるってソースは何ら示されてない。