アカウント名:
パスワード:
BOMは「ゴミ」であって不要なデータが入ってくるのが無駄だと主張する人がいますが、無駄なのは文字コードの自動判別の方です。
よくある文字コードを自動判定するという動作は、ファイルの内容の一部（1KBとか）、アプリによってはファイルの全部を読んでから文字コードを判定するので非常に負荷が大きいのです。BOMなら3バイト読むだけで済みます。
そして、Unicodeに対応しているアプリであればBOMは文字コード・エンディアンの判別に使えばいいし、そうでないなら無視すればよろしい。
UTF-8のBOMがあるだけで不具合起こすアプリなんていうのは、今時そっちの方がおかしいので修正すれば
わかってないなー。サイズが勿体ないのではなくて、バイトオーダーをわざわざ示す行為が二度手間で無駄なんだよ
世の中に UTF-8 だけしか存在しないならね。現実は 8bitの文字コードなんて山のようにあるから、ファイルの内容を解析するプログラムなら、文字コードを指定するか、決め打ちするか、コードを推測するかのどれかが必要になる。
良くも悪くも WindowsSearch で文字化けした結果が表示されないのはBOMのおかげっていうことだ。
BOMはあくまでバイトオーダーを示すために規定されたもので、BOMによってエンコードを判定できるのは結果論でしかないけどな
どちらにしろ推測が必要ならビット列の出現率からエンコード推測するよりマシでしょう。
いやいやこのご時世、BOMを信用してエンコードを決定するなんて頭お花畑もいいところでしょ悪意のある入力をいくらでも食わせられそう
「推測する」は「信用する」ではない
それでは#4051321の文意・趣旨をお聞かせ願おうか。詭弁なら結構だ。
推測程度で信用できるプログラムを書かないってことでしょう。BOMはゴミ。
Windowsの改行コードに使われている CR (キャリッジリターン) と LF (ラインフィード) の意味はご存知でしょうか。タイプライターでは印字装置は固定され、紙の方が上下左右に移動することで、文字送りや行送りが行われるんです。CRは、紙を固定して移動する装置（キャリッジ）を元の位置に戻すことで、LFとは行を送る（タイプライターなら紙を進める）ことです。
CRとLFはあくまでタイプライターの動作を示すために規定されたもので、CR+LFによって改行を判定できるのは結果論でしかないのですよ。
これを考えればもともと何を目的としていたかなんて無意味であることが理解できるはず。
話をBOMに戻すと、例えば、RFC3023
文字コード判別はバッドノウハウの集合体だということですね。そんなものをありがたがる気にはなれません
昔のRFCは、当時の考えの浅はかさや甘さを示すバッドノウハウ。
20年前の段階で、BOM で文字エンコーディングを判別すべきとかそういう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にも適用されるってソースは何ら示されてない。
8bitの文字コードなんて山のようにあるなら、WindowsSearchもおとなしくコードを推測しとけって話ですわな。
アスキーの方も最後にこう書いてある。
＞UTF-8のテキストがほとんどになって、シフトJISのファイルの利用率が下がれば、＞Windows SearchもBOMなしのUTF-8を全文検索できるようになるかもしれない。筆者が生きてる間にそうなるといいんだけど……。
ただ実現する前にWindowsがなくなる方が現時的だろうね。それとも出来るようになるのはWindows13の頃かな？
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
UNIXはただ死んだだけでなく、本当にひどい臭いを放ち始めている -- あるソフトウェアエンジニア
BOM有りに統一すべきだった (スコア:0)
BOMは「ゴミ」であって不要なデータが入ってくるのが無駄だと主張する人がいますが、無駄なのは文字コードの自動判別の方です。
よくある文字コードを自動判定するという動作は、ファイルの内容の一部（1KBとか）、アプリによってはファイルの全部を読んでから文字コードを判定するので非常に負荷が大きいのです。
BOMなら3バイト読むだけで済みます。
そして、Unicodeに対応しているアプリであればBOMは文字コード・エンディアンの判別に使えばいいし、そうでないなら無視すればよろしい。
UTF-8のBOMがあるだけで不具合起こすアプリなんていうのは、今時そっちの方がおかしいので修正すれば
Re: (スコア:0)
わかってないなー。サイズが勿体ないのではなくて、
バイトオーダーをわざわざ示す行為が二度手間で無駄なんだよ
Re:BOM有りに統一すべきだった (スコア:1)
世の中に UTF-8 だけしか存在しないならね。
現実は 8bitの文字コードなんて山のようにあるから、
ファイルの内容を解析するプログラムなら、文字コードを指定するか、
決め打ちするか、コードを推測するかのどれかが必要になる。
良くも悪くも WindowsSearch で文字化けした結果が表示されないのはBOMのおかげっていうことだ。
[Q][W][E][R][T][Y]
Re: (スコア:0)
BOMはあくまでバイトオーダーを示すために規定されたもので、BOMによってエンコードを判定できるのは結果論でしかないけどな
Re:BOM有りに統一すべきだった (スコア:1)
どちらにしろ推測が必要ならビット列の出現率からエンコード推測するよりマシでしょう。
[Q][W][E][R][T][Y]
Re: (スコア:0)
いやいやこのご時世、BOMを信用してエンコードを決定するなんて頭お花畑もいいところでしょ
悪意のある入力をいくらでも食わせられそう
Re:BOM有りに統一すべきだった (スコア:1)
「推測する」は「信用する」ではない
[Q][W][E][R][T][Y]
Re: (スコア:0)
それでは#4051321の文意・趣旨をお聞かせ願おうか。詭弁なら結構だ。
Re: (スコア:0)
推測程度で信用できるプログラムを書かないってことでしょう。
BOMはゴミ。
もともとは～とか言い出すと (スコア:0)
Windowsの改行コードに使われている CR (キャリッジリターン) と LF (ラインフィード) の意味はご存知でしょうか。
タイプライターでは印字装置は固定され、紙の方が上下左右に移動することで、文字送りや行送りが行われるんです。
CRは、紙を固定して移動する装置（キャリッジ）を元の位置に戻すことで、LFとは行を送る（タイプライターなら紙を進める）ことです。
CRとLFはあくまでタイプライターの動作を示すために規定されたもので、CR+LFによって改行を判定できるのは結果論でしかないのですよ。
これを考えればもともと何を目的としていたかなんて無意味であることが理解できるはず。
話をBOMに戻すと、例えば、RFC3023
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にも適用されるってソースは何ら示されてない。
Re: (スコア:0)
8bitの文字コードなんて山のようにあるなら、
WindowsSearchもおとなしくコードを推測しとけって話ですわな。
Re: (スコア:0)
アスキーの方も最後にこう書いてある。
＞UTF-8のテキストがほとんどになって、シフトJISのファイルの利用率が下がれば、
＞Windows SearchもBOMなしのUTF-8を全文検索できるようになるかもしれない。筆者が生きてる間にそうなるといいんだけど……。
ただ実現する前にWindowsがなくなる方が現時的だろうね。
それとも出来るようになるのはWindows13の頃かな？