アカウント名:
パスワード:
BOMは「ゴミ」であって不要なデータが入ってくるのが無駄だと主張する人がいますが、無駄なのは文字コードの自動判別の方です。
よくある文字コードを自動判定するという動作は、ファイルの内容の一部(1KBとか)、アプリによってはファイルの全部を読んでから文字コードを判定するので非常に負荷が大きいのです。BOMなら3バイト読むだけで済みます。
そして、Unicodeに対応しているアプリであればBOMは文字コード・エンディアンの判別に使えばいいし、そうでないなら無視すればよろしい。
UTF-8のBOMがあるだけで不具合起こすアプリなんていうのは、今時そっちの方がおかしいので修正すればいいのです。0xEF 0xBB 0xBF の3バイトがあれば、無視するだけですよ。文字コードの自動判別と違って、たったプログラムのコード数行ですむ改修です。そっちにもってくべきでした。
複数のファイルを結合したときの問題?インタプリタ言語でのエラー?どこにあろうが 0xEF 0xBB 0xBF などのBOMを無視すればいいだけでしょう。
ゴミがどうのという主張に対しては、改行コードをLFじゃなくてCR+LFを使えば改行ごとに1バイト無駄になるし、タブインデントの代わりにスペース4でインデントすればインデントのたびに3バイト無駄になりますが、そんなの気にする時代じゃないでしょう。
検索に関しては識別などしないでデフォルトコードページとUTF-8の両方ともインデックス作っておけばいいんじゃないですかね。どっちかでマッチすればよいのだし。
個人的にはゴミデータ以前にBOM無しで手間がかかることは有るけど困ることは滅多になく、BOMありで困る事はあっても良かったと思う事はなかったのでBOM無しに統一して欲しかったです
一部の人にはとことん迷惑という意味で、往年のMacバイナリを思い出した。
しかし、この問題はBOMでなくそれこそリソースフォークみたいなので対応するのが筋がいいと思うけどな。UTF8でBOMなんて無意味極まりないし、ASCIIが存在する以上BOMはどうにもらん。
わかってないなー。サイズが勿体ないのではなくて、バイトオーダーをわざわざ示す行為が二度手間で無駄なんだよ
世の中に UTF-8 だけしか存在しないならね。現実は 8bitの文字コードなんて山のようにあるから、ファイルの内容を解析するプログラムなら、文字コードを指定するか、決め打ちするか、コードを推測するかのどれかが必要になる。
良くも悪くも WindowsSearch で文字化けした結果が表示されないのはBOMのおかげっていうことだ。
BOMはあくまでバイトオーダーを示すために規定されたもので、BOMによってエンコードを判定できるのは結果論でしかないけどな
どちらにしろ推測が必要ならビット列の出現率からエンコード推測するよりマシでしょう。
いやいやこのご時世、BOMを信用してエンコードを決定するなんて頭お花畑もいいところでしょ悪意のある入力をいくらでも食わせられそう
「推測する」は「信用する」ではない
それでは#4051321の文意・趣旨をお聞かせ願おうか。詭弁なら結構だ。
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の頃かな?
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を付けさせるのか
CSVを使っているということはお手軽に書いたバッチファイルや簡易的なスクリプトだと思いますが、BOMを無視or削除するなんてコード、原始的なWindowsバッチファイルやシェルスクリプトでも数分あれば書けます。古いプログラムなら修正すればいいですし、今時他のユーザ(社内の他の従業員を含む)がBOM付きファイルを処理することすら想定できていないならプログラマーとしての資質に問題があるでしょう。
ゴチャゴチャとご高説を垂れてるけど、コストが掛かる(コード作成、テスト、デプロイ)ことに触れていない時点で、言葉に反して君が3流である証明になってるよw
BOM入ってるとcatで簡単に結合できないし、パイプでテキスト処理したあとにBOM付け直したりが鬱陶しいじゃん。どう考えてもゴミじゃん。
そりゃあ cat は Unicode 非対応だから。むしろ勝手に BOM 操作したらバイナリが壊れるから cat として使えない。
cat じゃないプログラムで連結するか input 側でBOM対応すればいいだけ。そもそもファイルの途中で ZWNBS 出てくるのはUnicode テキストとしてはエラーじゃないから。いつまでもテキスト連結に cat を使うというのが Unicode 推進側の怠慢である。
catじゃないプログラムって例えば何?たかだかBOMの為にUnixのソフトウェア資産とノウハウを捨てるなんてバカバカしい。専用ソフトウェアで処理する前提なら、プレーンテキストである必要すらない。
知らないよそんなの。そもそも怠慢してるんだから well known なソフトは無いんじゃないの。
Unicode以外だってそれなりに文字コード処理必要なんだからcat だけ怠慢してるのが悪い。
結局対応ソフトが無いのでは使い物にならない。
別にcatに限った話じゃない。リダイレクトやパイプで繋いだときに上流のコマンドがUTF-8か否かを識別して、出力の時にBOM付けるようにしないといけない。ファイルを最初に読むプログラムだけなら話は簡単だが、findstrやgrepみたいな加工するコマンドのアウトプットのこと考えると。
テキストファイルをテキストエディタ以外で操作するなんてことは、エンジニアじゃない人にはわからない。
統一されていれば必然的にそういう面倒もなくなる(つまりある意味不具合なので簡単に結合できるよう cat 側が対応する)とは考えないんですかね
catコマンドの実装に関する部分が正確性にかけていた(コンソールの仕様を含めてcatコマンドであるかのような書き方をしていた)ので突っ込まれる前に訂正
正しくは「一般的なLinuxコンソールではBOMは不可視なので、catコマンドの標準出力にBOMが含まれていても気になることはない。 だから無視すれば良い。」です。
その出力からパイプで繋いでファイル作成とかしてると、BOM付きファイル名の厄介なファイルが生成されてしまうのでは…地獄でしかない。
BOM推進派 == UNIXの思想を理解してない半可通、というのがここまでの感想。
それはカーネルと権利関係の話でしょ。テキストベースのコンソールの文化は、そもそも死んですらいないどころか、サーバーではデファクトスタンダードだ。
横から失礼。その「理由」を具体的に示してもらいたいね文脈から判断するに、「(デファクトスタンダードとなった)テキストベースのコンソールの文化」が腐ってる理由、ってのがちゃんとあるんだよね
どうぞこれからもしんどい思いをお続けください。いつも通りに
今に至って「BOM有りに統一すべきだった」だとか、擁護する相手が逆だろ
バイトオーダーマークの意味を未だに勘違いして自明なコードすらトチって不具合起こすアプリなんていうのは、今時そっちの方がおかしいので修正すればいいのです。
べき論でいえばWindowsSearchを直すべきなのは明らかなのに無理矢理その肩を持つからこんな苦しい長文になる。
不具合起こすアプリに「今時」も「どっちの方が」もない。ましてや「そもそも規格が~」とか、OS純正アプリの言い訳には酷すぎるわ。
ASCIIの範囲しか含まれてないデータなのに、「自動識別ツールがこのデータはSJISだと判定している、仕様通りUTF-8で納品してください」って主張する客に困らされた、みたいな話を思い出した
#逆だったかな?話の細部は忘れた
何を気にしない時代なのかは知らんけど、いまさらメモ帳がBOMなしUTF-8をデフォルトしたから気にせず使ってるだけだ。
テキストファイル=RAWデータである価値が全く理解できとらんな。
余計なデータを1ビットでも付加した瞬間にそれはリッチテキストとして扱うべき存在に変貌する。
これに一票(3バイト連続って、検査するの意外と面倒だし)
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
Stay hungry, Stay foolish. -- Steven Paul Jobs
BOM有りに統一すべきだった (スコア:0)
BOMは「ゴミ」であって不要なデータが入ってくるのが無駄だと主張する人がいますが、無駄なのは文字コードの自動判別の方です。
よくある文字コードを自動判定するという動作は、ファイルの内容の一部(1KBとか)、アプリによってはファイルの全部を読んでから文字コードを判定するので非常に負荷が大きいのです。
BOMなら3バイト読むだけで済みます。
そして、Unicodeに対応しているアプリであればBOMは文字コード・エンディアンの判別に使えばいいし、そうでないなら無視すればよろしい。
UTF-8のBOMがあるだけで不具合起こすアプリなんていうのは、今時そっちの方がおかしいので修正すればいいのです。
0xEF 0xBB 0xBF の3バイトがあれば、無視するだけですよ。
文字コードの自動判別と違って、たったプログラムのコード数行ですむ改修です。そっちにもってくべきでした。
複数のファイルを結合したときの問題?
インタプリタ言語でのエラー?
どこにあろうが 0xEF 0xBB 0xBF などのBOMを無視すればいいだけでしょう。
ゴミがどうのという主張に対しては、改行コードをLFじゃなくてCR+LFを使えば改行ごとに1バイト無駄になるし、
タブインデントの代わりにスペース4でインデントすればインデントのたびに3バイト無駄になりますが、そんなの気にする時代じゃないでしょう。
Re:BOM有りに統一すべきだった (スコア:2)
検索に関しては識別などしないでデフォルトコードページとUTF-8の両方ともインデックス作っておけばいいんじゃないですかね。
どっちかでマッチすればよいのだし。
Re:BOM有りに統一すべきだった (スコア:2)
時代後れすぎる。
okome
Re: (スコア:0)
個人的にはゴミデータ以前に
BOM無しで手間がかかることは有るけど困ることは滅多になく、BOMありで困る事はあっても良かったと思う事はなかったのでBOM無しに統一して欲しかったです
Re: (スコア:0)
一部の人にはとことん迷惑という意味で、往年のMacバイナリを思い出した。
Re: (スコア:0)
しかし、この問題はBOMでなくそれこそリソースフォークみたいなので対応するのが筋がいいと思うけどな。
UTF8でBOMなんて無意味極まりないし、ASCIIが存在する以上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の文意・趣旨をお聞かせ願おうか。詭弁なら結構だ。
もともとは~とか言い出すと (スコア: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の頃かな?
Re: (スコア:0)
BOM無しUTF-8の一番の利点は既存のASCIIコードしか想定してないプログラムが修正なしで動く可能性がそこそこ有るという部分なのでBOM付きにしたらUTF-8の意味がない。
例えば売れた時刻,品名,個数がカンマ区切りで書かれているファイルを処理するプログラムがあるとする。
ここでファイルがBOM無UTF-8で品名にUTF-8文字が含まれていても、多くの場合プログラムの修正はいらない。でもBOM付だと修正しないと誤動作する。
Re: (スコア:0)
そのASCII互換というのはUTF-8を普及させる段階では最大のメリットと言えたでしょう。
しかしUTF-8が一般化した現時点においては、BOMによってUTF-8であると判定できるメリットが、UTF-8非互換のプログラムを誤動作させるデメリットを上回っていると言えるでしょう。
Re: (スコア:0)
3バイトも使うなら、タグでいいんじゃないかって気になるからな。
Re: (スコア:0)
なんだかなー
プログラマー(not プログラム)の都合でASCIIテキストのリソースを全否定して冒頭にBOMを付けさせるのか
Re: (スコア:0)
CSVを使っているということはお手軽に書いたバッチファイルや簡易的なスクリプトだと思いますが、BOMを無視or削除するなんてコード、原始的なWindowsバッチファイルやシェルスクリプトでも数分あれば書けます。
古いプログラムなら修正すればいいですし、今時他のユーザ(社内の他の従業員を含む)がBOM付きファイルを処理することすら想定できていないならプログラマーとしての資質に問題があるでしょう。
Re: (スコア:0)
ゴチャゴチャとご高説を垂れてるけど、コストが掛かる(コード作成、テスト、デプロイ)ことに触れていない時点で、言葉に反して君が3流である証明になってるよw
Re: (スコア:0)
BOM入ってるとcatで簡単に結合できないし、パイプでテキスト処理したあとにBOM付け直したりが鬱陶しいじゃん。
どう考えてもゴミじゃん。
Re:BOM有りに統一すべきだった (スコア:1)
そりゃあ cat は Unicode 非対応だから。
むしろ勝手に BOM 操作したらバイナリが壊れるから cat として使えない。
cat じゃないプログラムで連結するか input 側でBOM対応すればいいだけ。
そもそもファイルの途中で ZWNBS 出てくるのはUnicode テキストとしてはエラーじゃないから。
いつまでもテキスト連結に cat を使うというのが Unicode 推進側の怠慢である。
[Q][W][E][R][T][Y]
Re: (スコア:0)
catじゃないプログラムって例えば何?
たかだかBOMの為にUnixのソフトウェア資産とノウハウを捨てるなんてバカバカしい。
専用ソフトウェアで処理する前提なら、プレーンテキストである必要すらない。
Re:BOM有りに統一すべきだった (スコア:1)
知らないよそんなの。
そもそも怠慢してるんだから well known なソフトは無いんじゃないの。
Unicode以外だってそれなりに文字コード処理必要なんだから
cat だけ怠慢してるのが悪い。
[Q][W][E][R][T][Y]
Re: (スコア:0)
結局対応ソフトが無いのでは使い物にならない。
Re: (スコア:0)
別にcatに限った話じゃない。
リダイレクトやパイプで繋いだときに上流のコマンドがUTF-8か否かを識別して、出力の時にBOM付けるようにしないといけない。
ファイルを最初に読むプログラムだけなら話は簡単だが、findstrやgrepみたいな加工するコマンドのアウトプットのこと考えると。
Re: (スコア:0)
テキストファイルをテキストエディタ以外で操作するなんてことは、エンジニアじゃない人にはわからない。
Re: (スコア:0)
統一されていれば必然的にそういう面倒もなくなる(つまりある意味不具合なので簡単に結合できるよう cat 側が対応する)とは考えないんですかね
cat に関する訂正 (スコア:0)
catコマンドの実装に関する部分が正確性にかけていた(コンソールの仕様を含めてcatコマンドであるかのような書き方をしていた)ので突っ込まれる前に訂正
正しくは
「一般的なLinuxコンソールではBOMは不可視なので、catコマンドの標準出力にBOMが含まれていても気になることはない。
だから無視すれば良い。」
です。
Re: (スコア:0)
その出力からパイプで繋いでファイル作成とかしてると、BOM付きファイル名の厄介なファイルが生成されてしまうのでは…
地獄でしかない。
Re: (スコア:0)
BOM推進派 == UNIXの思想を理解してない半可通、というのがここまでの感想。
Re:cat に関する訂正 (スコア:1)
Re: (スコア:0)
それはカーネルと権利関係の話でしょ。
テキストベースのコンソールの文化は、そもそも死んですらいないどころか、サーバーではデファクトスタンダードだ。
Re:cat に関する訂正 (スコア:1)
// Plan9 はそこからスタートしたんじゃなかったっけ
Re: (スコア:0)
横から失礼。その「理由」を具体的に示してもらいたいね
文脈から判断するに、「(デファクトスタンダードとなった)テキストベースのコンソールの文化」が
腐ってる理由、ってのがちゃんとあるんだよね
Re:cat に関する訂正 (スコア:1)
が、これだけデータがメタだらけになっている昨今コンソールだけではしんどいです…
Re: (スコア:0)
どうぞこれからもしんどい思いをお続けください。いつも通りに
Re: (スコア:0)
今に至って「BOM有りに統一すべきだった」だとか、擁護する相手が逆だろ
バイトオーダーマークの意味を未だに勘違いして
自明なコードすらトチって不具合起こすアプリなんていうのは、
今時そっちの方がおかしいので修正すればいいのです。
Re: (スコア:0)
べき論でいえばWindowsSearchを直すべきなのは明らかなのに
無理矢理その肩を持つからこんな苦しい長文になる。
不具合起こすアプリに「今時」も「どっちの方が」もない。
ましてや「そもそも規格が~」とか、OS純正アプリの言い訳には酷すぎるわ。
Re: (スコア:0)
ASCIIの範囲しか含まれてないデータなのに、
「自動識別ツールがこのデータはSJISだと判定している、仕様通りUTF-8で納品してください」って
主張する客に困らされた、みたいな話を思い出した
#逆だったかな?話の細部は忘れた
Re: (スコア:0)
何を気にしない時代なのかは知らんけど、
いまさらメモ帳がBOMなしUTF-8をデフォルトしたから気にせず使ってるだけだ。
Re: (スコア:0)
テキストファイル=RAWデータである価値が全く理解できとらんな。
余計なデータを1ビットでも付加した瞬間にそれはリッチテキストとして扱うべき存在に変貌する。
Re: (スコア:0)
これに一票
(3バイト連続って、検査するの意外と面倒だし)