アカウント名:
パスワード:
BOMは「ゴミ」であって不要なデータが入ってくるのが無駄だと主張する人がいますが、無駄なのは文字コードの自動判別の方です。
よくある文字コードを自動判定するという動作は、ファイルの内容の一部(1KBとか)、アプリによってはファイルの全部を読んでから文字コードを判定するので非常に負荷が大きいのです。BOMなら3バイト読むだけで済みます。
そして、Unicodeに対応しているアプリであればBOMは文字コード・エンディアンの判別に使えばいいし、そうでないなら無視すればよろしい。
UTF-8のBOMがあるだけで不具合起こすアプリなんていうのは、今時そっちの方がおかしいので修正すれば
BOM無しUTF-8の一番の利点は既存のASCIIコードしか想定してないプログラムが修正なしで動く可能性がそこそこ有るという部分なのでBOM付きにしたらUTF-8の意味がない。
例えば売れた時刻,品名,個数がカンマ区切りで書かれているファイルを処理するプログラムがあるとする。
ここでファイルがBOM無UTF-8で品名にUTF-8文字が含まれていても、多くの場合プログラムの修正はいらない。でもBOM付だと修正しないと誤動作する。
そのASCII互換というのはUTF-8を普及させる段階では最大のメリットと言えたでしょう。
しかしUTF-8が一般化した現時点においては、BOMによってUTF-8であると判定できるメリットが、UTF-8非互換のプログラムを誤動作させるデメリットを上回っていると言えるでしょう。
3バイトも使うなら、タグでいいんじゃないかって気になるからな。
なんだかなープログラマー(not プログラム)の都合でASCIIテキストのリソースを全否定して冒頭にBOMを付けさせるのか
UTF-8が一般化した前提なら、そもそも判定する必要性自体がレアケースになっちゃいませんかね。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
吾輩はリファレンスである。名前はまだ無い -- perlの中の人
BOM有りに統一すべきだった (スコア:0)
BOMは「ゴミ」であって不要なデータが入ってくるのが無駄だと主張する人がいますが、無駄なのは文字コードの自動判別の方です。
よくある文字コードを自動判定するという動作は、ファイルの内容の一部(1KBとか)、アプリによってはファイルの全部を読んでから文字コードを判定するので非常に負荷が大きいのです。
BOMなら3バイト読むだけで済みます。
そして、Unicodeに対応しているアプリであればBOMは文字コード・エンディアンの判別に使えばいいし、そうでないなら無視すればよろしい。
UTF-8のBOMがあるだけで不具合起こすアプリなんていうのは、今時そっちの方がおかしいので修正すれば
Re: (スコア:0)
BOM無しUTF-8の一番の利点は既存のASCIIコードしか想定してないプログラムが修正なしで動く可能性がそこそこ有るという部分なのでBOM付きにしたらUTF-8の意味がない。
例えば売れた時刻,品名,個数がカンマ区切りで書かれているファイルを処理するプログラムがあるとする。
ここでファイルがBOM無UTF-8で品名にUTF-8文字が含まれていても、多くの場合プログラムの修正はいらない。でもBOM付だと修正しないと誤動作する。
Re:BOM有りに統一すべきだった (スコア:0)
そのASCII互換というのはUTF-8を普及させる段階では最大のメリットと言えたでしょう。
しかしUTF-8が一般化した現時点においては、BOMによってUTF-8であると判定できるメリットが、UTF-8非互換のプログラムを誤動作させるデメリットを上回っていると言えるでしょう。
Re: (スコア:0)
3バイトも使うなら、タグでいいんじゃないかって気になるからな。
Re: (スコア:0)
なんだかなー
プログラマー(not プログラム)の都合でASCIIテキストのリソースを全否定して冒頭にBOMを付けさせるのか
Re: (スコア:0)
UTF-8が一般化した前提なら、そもそも判定する必要性自体がレアケースになっちゃいませんかね。