Use of a BOM is neither required nor recommended for UTF-8, but may be encountered in contexts where UTF-8 data is converted from other encoding forms that use a BOM or where the BOM is used as a UTF-8 signature. See the “Byte Order Mark” subsection in Section 23.8, Specials, for more information.
いいぞ (スコア:0)
次はデフォルトの文字コードに手を付けてくれたまへ
Re: (スコア:0)
Windowsの文字コードって複数あるの?
Re:いいぞ (スコア:0)
メモ帳のだぞ
デフォルトだとANSIになってる
他にUnicode、Unicode big endian、UTF-8が使える
最近はHTMLやソースコード関連がUTF-8推奨なので
デフォルトをUTF-8に変えても良さそう
Re:いいぞ (スコア:5, すばらしい洞察)
Re:いいぞ (スコア:1)
いや、むしろ他がBOMを必須にしてほしい
Re: (スコア:0)
必須じゃなくていいけどちゃんと受け付けるようにしてほしい
Re: (スコア:0)
最悪受け付けないなら受け付けないでいいけど、BOM対応してないプログラムにBOM付きテキスト食わせて
自分以外の何かの所為にするバカを黙らせて欲しい。
Re: (スコア:0)
UnicodeコンソーシアムがBOM対応してないプログラムにBOM付きテキスト食わせて
自分以外の何かの所為にするバカを粛正する警察機関になるのか。胸が熱くなるな。
BOM は重要 (スコア:1)
BOMは文字エンコーディングやエンディアンを確実に判別できるという重要な役割を果たしているわけなんだけど
それが無かったら判別のためにテキスト全文を読んで、どの文字コードだと解釈すれば矛盾が無いかを評価しなくてはならず
非常に負荷が高い
その上、本文が短い場合には複数の文字コードで矛盾が生じないケースもあって、自動判別が不可能な場合まである
複数のファイルを結合して問題が生じる?
いや、BOMはファイルの先頭以外では無視しなければならない(幅0の空白文字)仕様なんだから不具合が生じる方がおかしい
そして、BOMのせいで動作しないアプリケーションはUnicode自体に非対応なのだから、Ascii だけ使ってればいいのでは
BOMで不具合を起こすようなアプリケーションは、UTF-8 が読めているように思えてもたまたま動いているだけで、
その他のUnicode制御文字も扱えないでしょう
シェルスクリプトから Ascii しか扱えないような古いスクリプトを呼び出して使いたいとかだったら
その前にBOM消してから渡す処理書けばいいだけでは、そんなの1分ありゃ書けるでしょ
UTF-8 において、BOMは必須でも推奨でもないけど、付けたからといって仕様違反ではない
扱えないアプリがタコ
Re:BOM は重要 (スコア:1)
何言ってんの、BOM 付き UTF-8 は、UTF-8 の最大の利点である、
ASCIIの範囲の文字しか使っていない場合は、従来のプレーンテキストと一切変わらず、古いプログラムでもそのまま処理できる
を投げ捨てているわけで、正直考えた奴は莫迦の極みでしかないエンコーディングなんだが
# windows 以外ではまず使われることがない、よくある「標準規格からちょっとズレたMS独自仕様」の名残だと思ってる
Re: (スコア:0)
なんというか、考えの浅いやつほど規格をバカ呼ばわりするよね
Re: (スコア:0)
あくまでもテキストエディタで UTF-8 を扱う話ですよね
ASCII 以外で不具合を起こすプログラムで扱うデータを編集するなら、
文字コードとして ASCII が指定されている設定のテキストエディタを使うべきでしょう
BOM が含まれるだけで不具合を起こすプログラムならば、
どっかからコピペしたデータに不可視の UTF-8 制御コードが含まれていたりとか、
入力ミスでうっかり ASCII外の文字がどっかに混入してしまったりというヒューマンエラーで不具合が起こりかねません
ようするに、
「テキストエディタで UTF-8 としてデータを編集するけど
万が一 Unicode の制御コードや A
Re: (スコア:0)
そんなもの利点でもなんでもなくてバグと同レベル。そんなものを利用しようという発想からして技術者に向いていないよ。
Re: (スコア:0)
あなたは、テキストを入力した環境と、テキストを使用する環境が異なる状況があることを判っていないようですね。
# いっちゃ悪いが、入出力の環境を指定できるのならば、UTF-8 w/ BOM だろうと、 mule-internal だろうと、オレオレエンコーディングだろうと、好きなエンコーディングを使えば良いんです。
入出力を揃えられない可能性があるときに、共通規格としてテキストの交換用符号があるわけで..
元の UTF-8 ができるだけ従来のプログラムでもそのまま使える様に配慮しているのに、BOMがそれをぶち壊しにするわけです。
規格に入っているけど、歓迎されていない感じしませんか? Unicode 10.0規格(sec 2.6)には
Use of a BOM is neither required nor recommended for UTF-8, but may be encountered in contexts where UTF-8 data is converted from other encoding forms that use a BOM or where the BOM is used as a UTF-8 signature. See the “Byte Order Mark” subsection in Section 23.8, Specials, for more information.
とありますし、W3C も、 HTMLにおけるBOMの扱い [w3.org]
Re: (スコア:0)
なんか必死ですね
Re: (スコア:0)
これが何の反論になっているか、よく意味が分からないのですが。
Windowsのメモ帳は、BOMの有るファイルも、無いファイルも両方正常に読めますよ。書き込み時にはBOM有りになりますけどね。
メモ帳で、BOMが入ったら不具合が起こる可能性のあるプログラムで扱うファイルを編集しない限り、何の問題もありません。そして、BOMが入ったら不具合が起こる ASCII 全体のプログラムで扱う可能性のあるデータを出力するなら、エディタのBOM出力の有無に関わらず、そもそも UFT-8 として編集すべきではあり
Re: (スコア:0)
そりゃBOMなんて無い方が良い世界でしょう。
でも歓迎するか否かに関わらずBOMは必要だから
存在して許容されているんじゃないでしょうか?
何か前半の話と後半の話が
全く逆のことを言っているような気がするんですけど。
HTMLの件に関しては#3407238が何を言いたいのかさっぱり分かりません。
メリット>デメリット (スコア:1)
BOM有りのメリット:
文字コードやエンディアンの誤認識を防げる
BOM無しのメリット:
ASCIIしか扱えないプログラムとの互換性を保てる
ただし、ASCII文字以外を含めない場合に限る
BOM無しのメリットが弱すぎると思うのですが
BOM有りのBOMを消すのは簡単だけど、BOM無しUFT-8で文字コード誤認識を完全に防ぐのは技術的に不可能ですからね
色々な環境で扱う可能性を考慮するなら、BOMが無いせいで文字コードが誤認識される場合も考慮すべきでは
Re: (スコア:0)
BOMなしUTF-8のファイルにEUCのファイルをくっつけて判別不可能なゴミにするのだ
これを防ぐには入力すべてがUTF-8だということを設計者が保証しなければならないが、素直にBOMなしをはじく方が楽かつ確実ですね
Re: (スコア:0)
なんというか、何か問題があるとすぐMSガーとかIEガーとか言って、自分の能力のなさを
人のせいにする、Web屋によくいるタイプの人のように見えますね。
Re: (スコア:0)
> 書き込み時にはBOM有りになりますけどね。
ここじゃね?
Re: (スコア:0)
文字コードが誤認識されて困るケースってあります?
Re: (スコア:0)
文字化けでテキストが読めなくなります
そのままうっかり保存したらもう
Re: (スコア:0)
BOM有はBOM有。BOM無しはBOM無しで保存してくれたら何も問題はない。
強制的にBOMつけるのが問題で、新規でBOM有だけならしょうがない。
Re: (スコア:0)
テキストファイルをドキュメントとして考えてるか、言語仕様の一部として考えてるかで全く立場が変わってるよね。
シェルスクリプトの存在を考慮すればBOMなんて発案されることもないレベルなので、MSの関与が大きいんだろう。
むしろ知っててライバル勢力に嫌がらせした可能性すらあるんだけど。
Windows以外の世界では「UTF-8N」が標準なので、仕様改訂があるとすればBOMは廃止もしくは非推奨に変更でしょう。
そもそもUTF-8は他のコードと誤認されることはないのでBOMは余計なもの。
Re: (スコア:0)
個人的にMSに悪意を見出すのは勝手ですが規格は規格です。
斬新な意見ですね。
Re: (スコア:0)
UNIX系のシェルスクリプトとPHPがタコなんだな。
他で問題になったことはほぼないので。
Re: (スコア:0)
まぁ、その「タコな環境」が多く存在するから問題になるんだが。
BOMってWindowsと規格文書以外には実装しないものってのが話をややこしくしてる。
マイナーな仕様は「規格」も含めてデファクトスタンダードで上書きされるってのは、
繰り返してきた歴史でもある。
# っていうか、先頭の「#!」はUNIX系のシステムコールなのでタコって話じゃないだろ。
# 歴史的に重要な部分に仕様変更をねじ込むのは規格の方に問題がある。
Re: (スコア:0)
> 扱えないアプリがタコ
シェル……いやカーネルかも。#!を処理してるの誰だろう。昔のUNIXのカーネルで見たことあるけど。
色んな環境でファイルをやりとりしてるとたまにシェルスクリプトにBOM入れられることがあるもんで。
Re: (スコア:0)
は?
お前、符号化の仕組みを全く理解してないだろ。
BOMに文字エンコーディングを判別する役割なんかねぇぞ。
それにUTF-8はエンディアン関係ない。
UTF-16等はエンディアンによってバイトオーダー変わるから必要ってだけだ。
BOMは先頭以外で無視?バカか、バイトをCPUでなくBOMで指定されたエンディアンで処理しないといけないんだからんなわけないだろ。
Re: (スコア:0)
みんなUTF-8の話をしていて理解してると思いますよ
UTF-8のBOMが「バイトオーダーマーク」でないのは事実ですが
CRもLFも元々の意味と違いますよね?
そもそも論がしたいならコメント付ける場所間違ってますよ
Re: (スコア:0)
シバンが使えなくて困るので却下
Re: (スコア:0)
> BOMは文字エンコーディングやエンディアンを確実に判別できるという重要な役割を果たしているわけなんだけど
UTF-8 にエンディアン関係ないじゃん。
文字エンコーディングの判別に BOM を使うとか意味が分からない。
SJISやEUC,JISにもBOMが付いてるとでも思ってるの?
BOMが付いてる->Unicodeかな?くらいしか判別できないじゃん。
Re: (スコア:0)
#3407358と同じACですか?
UTF-8自体にエンディアンは関係ありませんが
UTF-8を処理するアプリケーションがどちらのCPUで動くかは関係あります。
1byteずつ処理すると効率が悪いですから。
勿論それはBOMの本来機能ではありません(むしろ目的の逆の使い方です)が
本来機能を支障しない限りどう使おうとアプリケーション側の自由です。
そうですね。
でも100%正しく判定できる手段が存在しないことは自明なので
普通は「実用上十分」くらいの意味に捉えるんじゃないでしょうか。
あとこの議論は散々なされて新しい建設的で実際的なアイデアなど生まれる余地はないので
メモ帳の記事でおしゃべりするのはもう止めませんか?
Re: (スコア:0)
エディタの仕様としてBOMがついてなければ勝手につけるべきではない
よって強制でつけるエディタ(Notepad,Sakura)はタコ
Re: (スコア:0)
いや、強制で付けてほしい
一般的なBOM有無論は問題ではなくね (スコア:0)
Re: (スコア:0)
そういう理想論は今はいいです。
Re: (スコア:0)
BOM困るよね。
スクリプトとか設定ファイルとかメモ帳で弄っちゃって、BOMのせいで動作しないってケースが希にある。
Re: (スコア:0)
改行コードが CRLF になっているくらいで command not found とか言う
シェルのうんこっぷりを直す方が良い気がする。頑なにCRを無視するように
しないのは、したらいけない理由がなんかあるんだろうか
Re: (スコア:0)
シェルスクリプトってものが分かってない奴が好き勝手に書いてるな。
あれは人間から見たらテキストファイルだけど、カーネルから見たらプログラム(実行ファイル)だぞ。
Windowsで言えばexeファイルの先頭が「0x5A4D」以外でも動作しろって言ってるレベルで酷い。
OSは#!で始まるファイルが起動されたら、それが参照するバイナリをロードするって厳然とした規格なので
1行目だけは「柔軟な対応」は出来ないし、やってはいけない。
2行目以降なら起動されたプログラム側(/bin/shや/usr/bin/perlなど)が好きに処理できるが。
https://ja.wikipedia.org/wiki/%E3%82%B7%E3%83%90%E3%83%B3_(Unix) [wikipedia.org]
Re: (スコア:0)
シェルスクリプトってものが分かってない奴が好き勝手に書いてるな。
あれは人間から見たらテキストファイルだけど、カーネルから見たらプログラム(実行ファイル)だぞ。
だから何なの?
"#!" の前に Unicode の BOM を認めらばよいだけ。
#! (BOM無し)
0xEF 0xBB 0xBF #! (UTF-8)
0xFE 0xFF #! (UTF-16 BE)
0xFF 0xFE #! (UTF-16 LE)
0x00 0x00 0xFE 0xFF #! (UTF-32 BE)
0xFF 0xFE 0x00 0x00 #! (UTF-32 LE)
上記の6通りを実行できるようにカーネルを書き換えれば良いだけ。
何故やってはいけないの?
セキュリテ
Re: (スコア:0)
プロセス起動に分岐なんて入れたら全プロセスが単純に6倍遅くなるぞ。
バカじゃねーの?
Re: (スコア:0)
ぜひパッチを作ってLinux Kernelへ貢献してください。
Re: (スコア:0)
カーネル書き換えの是非は置いておくとして。
全プロセスと言いますが
もしファイルから起動しないプロセスでも遅くなるというのなら
致命的なので設計を見直すべきですね。
また6倍遅くなるという表現からif文の羅列みたいなものを想定されていると思うのですが
もしそういう実装であるというのなら
if文の羅列の末尾に追加する分には現行より6倍遅くなることはありえません。
繰り返しますがBOMに対応すべきとは言いません。
Re: (スコア:0)
そこのリンク先のWikipediaの記事に書いてあるように、#!の解釈は結構OSによってブレがあります。なので、LFの手前のCRを切り捨てたり、EF BB BF # !の5バイトもshebangとして認識するシステムが将来登場しても別におかしなことではないと思います。
OSは#!で始まるファイルが起動されたら、それが参照するバイナリをロードするって厳然とした規格なので1行目だけは「柔軟な対応」は出来ないし、やってはいけない。
そのWikipediaの記事内からリンクが貼られている The #! m [in-ulm.de]
Re: (スコア:0)
本気でそう思うならLKMLでLinusあたりに提案してみてくれ。
本人も見てるから最大級の感謝の言葉を貰えるぞ。
systemdやSELinuxを超える歴史のページになりそうだ。
Re: (スコア:0)
こんなアホなこと言ってるレベルのやつに感謝の言葉なんて来るはずないだろ
Re: (スコア:0)
将来登場する可能性は否定しないが、現在逸脱したシステムが存在しないってことは、それは「変えてはいけない部分」でしょう。
っていうか2バイトを5バイトに変更って簡単な話じゃないぞ・・・・・もう新種のOS作った方が早いかもしれない。
そのwikipediaに書いてあるように、シバンには仕様上の制限が問題になってるにも関わらず実装側のトリックで
回避せざるを得ないほど「手を付けてはいけない部分」なんだよ。
POSIXも全ての実装を網羅してるわけではないがUNIXの長年の歴史が作った不文律が相当存在する。
Re: (スコア:0)
linusからの謝辞なら来るだろw
https://linux.srad.jp/story/18/01/23/078252/ [linux.srad.jp]
Re: (スコア:0)
Re: (スコア:0)
UTF-8システムロケールを有効にしてメモ帳で文字コード「ANSI」を選んで保存するとBOMなしUTF-8になる。そのかわりシフトJISで保存できなくなるというのは前も書いたが。