アカウント名:
パスワード:
BOMは「ゴミ」であって不要なデータが入ってくるのが無駄だと主張する人がいますが、無駄なのは文字コードの自動判別の方です。
よくある文字コードを自動判定するという動作は、ファイルの内容の一部(1KBとか)、アプリによってはファイルの全部を読んでから文字コードを判定するので非常に負荷が大きいのです。BOMなら3バイト読むだけで済みます。
そして、Unicodeに対応しているアプリであればBOMは文字コード・エンディアンの判別に使えばいいし、そうでないなら無視すればよろしい。
UTF-8のBOMがあるだけで不具合起こすアプリなんていうのは、今時そっちの方がおかしいので修正すれば
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の思想を理解してない半可通、というのがここまでの感想。
それはカーネルと権利関係の話でしょ。テキストベースのコンソールの文化は、そもそも死んですらいないどころか、サーバーではデファクトスタンダードだ。
横から失礼。その「理由」を具体的に示してもらいたいね文脈から判断するに、「(デファクトスタンダードとなった)テキストベースのコンソールの文化」が腐ってる理由、ってのがちゃんとあるんだよね
どうぞこれからもしんどい思いをお続けください。いつも通りに
vscodeのRemote Developmentを使うと幸せになれる。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
Stay hungry, Stay foolish. -- Steven Paul Jobs
BOM有りに統一すべきだった (スコア:0)
BOMは「ゴミ」であって不要なデータが入ってくるのが無駄だと主張する人がいますが、無駄なのは文字コードの自動判別の方です。
よくある文字コードを自動判定するという動作は、ファイルの内容の一部(1KBとか)、アプリによってはファイルの全部を読んでから文字コードを判定するので非常に負荷が大きいのです。
BOMなら3バイト読むだけで済みます。
そして、Unicodeに対応しているアプリであればBOMは文字コード・エンディアンの判別に使えばいいし、そうでないなら無視すればよろしい。
UTF-8のBOMがあるだけで不具合起こすアプリなんていうのは、今時そっちの方がおかしいので修正すれば
Re:BOM有りに統一すべきだった (スコア: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)
vscodeのRemote Developmentを使うと幸せになれる。