アカウント名:
パスワード:
BOMは「ゴミ」であって不要なデータが入ってくるのが無駄だと主張する人がいますが、無駄なのは文字コードの自動判別の方です。
よくある文字コードを自動判定するという動作は、ファイルの内容の一部(1KBとか)、アプリによってはファイルの全部を読んでから文字コードを判定するので非常に負荷が大きいのです。BOMなら3バイト読むだけで済みます。
そして、Unicodeに対応しているアプリであればBOMは文字コード・エンディアンの判別に使えばいいし、そうでないなら無視すればよろしい。
UTF-8のBOMがあるだけで不具合起こすアプリなんていうのは、今時そっちの方がおかしいので修正すれば
BOM入ってるとcatで簡単に結合できないし、パイプでテキスト処理したあとにBOM付け直したりが鬱陶しいじゃん。どう考えてもゴミじゃん。
それ試してから言ってる?catやWindowsのメモ帳は、ファイルの途中に含まれるBOMを表示しない(幅0の空白)というBOMが邪魔にならない理想の実装になっているんだけど。
catではBOMは表示されないので、ゴミが見えて気になることも無い。catはファイルの途中のBOMも完全無視(半角スペースにもならない完全非表示)してくれる。
fileA (BOM付き) と fileB (BOM付き) を結合するなら↓で良い。
cat fileA fileB > fileC
fileC の fileA と fileB の間にBOMが紛れ込んでないないかって?うん、紛れているよ。でも3バイト多くなっても気にしなくて良いのでは。みんなが cat のようにBOMを無視してくれれば不具合も起こらない。ファイルの途中のBOMも完全なゴミではなく、間違って違うエンココードのファイルを結合してしまったときに内容を解読するヒントに出来る。これだけでも3バイトの価値はあると思うよ。
もし、どうしても気になる神経質な人は、nkf --overwrite --oc=UTF-8 fileBcat fileA fileB > fileCnkf --overwrite --oc=UTF-8-BOM fileCこれで良いのでわ。fileB のBOMを取り除いてから fileA と fileB を結合して、最後にBOM を付ける。
このぐらいが面倒だのなんだのいう人って、理解しているコマンドも少ないし、頭を使う事もできないセンスの無い人じゃないかな。毎回○○を打ち込むのがどうとかというんだったら、まともなエンジニアであれば、BOMを好きなように処理するコマンドを作ることも、シェルスクリプトを書くことも、数分あればできるはず。
catコマンドの実装に関する部分が正確性にかけていた(コンソールの仕様を含めてcatコマンドであるかのような書き方をしていた)ので突っ込まれる前に訂正
正しくは「一般的なLinuxコンソールではBOMは不可視なので、catコマンドの標準出力にBOMが含まれていても気になることはない。 だから無視すれば良い。」です。
その出力からパイプで繋いでファイル作成とかしてると、BOM付きファイル名の厄介なファイルが生成されてしまうのでは…地獄でしかない。
BOM推進派 == UNIXの思想を理解してない半可通、というのがここまでの感想。
それはカーネルと権利関係の話でしょ。テキストベースのコンソールの文化は、そもそも死んですらいないどころか、サーバーではデファクトスタンダードだ。
横から失礼。その「理由」を具体的に示してもらいたいね文脈から判断するに、「(デファクトスタンダードとなった)テキストベースのコンソールの文化」が腐ってる理由、ってのがちゃんとあるんだよね
どうぞこれからもしんどい思いをお続けください。いつも通りに
vscodeのRemote Developmentを使うと幸せになれる。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
開いた括弧は必ず閉じる -- あるプログラマー
BOM有りに統一すべきだった (スコア:0)
BOMは「ゴミ」であって不要なデータが入ってくるのが無駄だと主張する人がいますが、無駄なのは文字コードの自動判別の方です。
よくある文字コードを自動判定するという動作は、ファイルの内容の一部(1KBとか)、アプリによってはファイルの全部を読んでから文字コードを判定するので非常に負荷が大きいのです。
BOMなら3バイト読むだけで済みます。
そして、Unicodeに対応しているアプリであればBOMは文字コード・エンディアンの判別に使えばいいし、そうでないなら無視すればよろしい。
UTF-8のBOMがあるだけで不具合起こすアプリなんていうのは、今時そっちの方がおかしいので修正すれば
Re: (スコア:0)
BOM入ってるとcatで簡単に結合できないし、パイプでテキスト処理したあとにBOM付け直したりが鬱陶しいじゃん。
どう考えてもゴミじゃん。
cat はBOMを無視してくれる (スコア:-1)
それ試してから言ってる?
catやWindowsのメモ帳は、ファイルの途中に含まれるBOMを表示しない(幅0の空白)というBOMが邪魔にならない理想の実装になっているんだけど。
catではBOMは表示されないので、ゴミが見えて気になることも無い。catはファイルの途中のBOMも完全無視(半角スペースにもならない完全非表示)してくれる。
fileA (BOM付き) と fileB (BOM付き) を結合するなら↓で良い。
cat fileA fileB > fileC
fileC の fileA と fileB の間にBOMが紛れ込んでないないかって?
うん、紛れているよ。でも3バイト多くなっても気にしなくて良いのでは。
みんなが cat のようにBOMを無視してくれれば不具合も起こらない。
ファイルの途中のBOMも完全なゴミではなく、間違って違うエンココードのファイルを結合してしまったときに内容を解読するヒントに出来る。
これだけでも3バイトの価値はあると思うよ。
もし、どうしても気になる神経質な人は、
nkf --overwrite --oc=UTF-8 fileB
cat fileA fileB > fileC
nkf --overwrite --oc=UTF-8-BOM fileC
これで良いのでわ。
fileB のBOMを取り除いてから fileA と fileB を結合して、最後にBOM を付ける。
このぐらいが面倒だのなんだのいう人って、理解しているコマンドも少ないし、頭を使う事もできないセンスの無い人じゃないかな。
毎回○○を打ち込むのがどうとかというんだったら、まともなエンジニアであれば、BOMを好きなように処理するコマンドを作ることも、シェルスクリプトを書くことも、数分あればできるはず。
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を使うと幸せになれる。