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, すばらしい洞察)
BOM は重要 (スコア:1)
BOMは文字エンコーディングやエンディアンを確実に判別できるという重要な役割を果たしているわけなんだけど
それが無かったら判別のためにテキスト全文を読んで、どの文字コードだと解釈すれば矛盾が無いかを評価しなくてはならず
非常に負荷が高い
その上、本文が短い場合には複数の文字コードで矛盾が生じないケースもあって、自動判別が不可能な場合まである
複数のファイルを結合して問題が生じる?
いや、BOMはファイルの先頭以外では無視しなければならない(幅0の空白文字)仕様なんだから不具合が生じる方がおかしい
そして、BOMのせいで動作しないアプリケーションはUnico
Re: (スコア:1)
何言ってんの、BOM 付き UTF-8 は、UTF-8 の最大の利点である、
ASCIIの範囲の文字しか使っていない場合は、従来のプレーンテキストと一切変わらず、古いプログラムでもそのまま処理できる
を投げ捨てているわけで、正直考えた奴は莫迦の極みでしかないエンコーディングなんだが
# windows 以外ではまず使われることがない、よくある「標準規格からちょっとズレたMS独自仕様」の名残だと思ってる
Re:BOM は重要 (スコア:0)
あくまでもテキストエディタで UTF-8 を扱う話ですよね
ASCII 以外で不具合を起こすプログラムで扱うデータを編集するなら、
文字コードとして ASCII が指定されている設定のテキストエディタを使うべきでしょう
BOM が含まれるだけで不具合を起こすプログラムならば、
どっかからコピペしたデータに不可視の UTF-8 制御コードが含まれていたりとか、
入力ミスでうっかり ASCII外の文字がどっかに混入してしまったりというヒューマンエラーで不具合が起こりかねません
ようするに、
「テキストエディタで UTF-8 としてデータを編集するけど
万が一 Unicode の制御コードや ASCII外の文字がどっかに混入してしまったら(コピペやキータイプミス)
使う先のプログラムで不具合を起こしてしまう」
というデンジャラスな環境で作業しているってことでしょ?
ヒューマンエラーに対するリスク管理が全くできていないとしか言いようがありません
# windows 以外ではまず使われることがない、よくある「標準規格からちょっとズレたMS独自仕様」の名残だと思ってる
BOM は標準規格に存在するんですけど
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)
Re: (スコア:0)
縺ゅ⊇
# UTF-8はかなり冗長な符号なので他のコードをUTF-8に誤認することは少ないだろうが逆はいくらでも起こる
Re: (スコア:0)
話読めてる?
Re: (スコア:0)
えぇぇぇぇ。
(#3407491) は「BOMは余計なもの」って言ってるんだけど、余計だけどつけろってこと?
それとも(#3407639) は(#3407495) の1行目の反例(?)を聞いてるってこと?
Re: (スコア:0)
BOMが有ったところで文字コード誤認識を完全に防ぐのは不可能だよ。
0xEF 0xBB 0xBF って Shift_JIS-2004 では "鬠ソ" だし、 EUC-JP でも
"鏤" + (31区の文字の 1バイト目) だから、先頭 3バイトだけ見ても
Shift_JIS-2004 なのか EUC-JP なのか、それとも BOM 有りの
UTF-8 なのかすら確定できない。
Re: (スコア:0)
まさか完全じゃなきゃ意味がないとでも?
BOMは先頭にあることに意味があるんです。
鬠ソや鏤から始まってUTF-8と解釈されて困るテキストがどれだけありますか?
テキストの途中に文字コードの曖昧さがないことを検証することは非常にコストがかかります。
マッピングが多対多だからです。
一方でどうしてもBOM付きUTF-8と解釈されて困るテキストがあったなら
それについてのみ対策すればいいのです。
Re: (スコア:0)
困る困らないじゃなくて、そんなのリッチテキストでやれって話だろ。
っつか、テキストファイルってUnicode以外は余計なメタデータを含まないraw-dataなんだよ。
rawだからこそOSが直接解釈できる命令文を埋め込むことが出来たりしたのに、
「当たり前に出来たこと」をBOMの存在が全てぶち壊している。
# もう実際のデータではBOM無しばかりになってるから、メモ帳が「データを汚す」こと
# さえしなければいいだけの話なんだけどな。
Re: (スコア:0)
> っつか、テキストファイルってUnicode以外は余計なメタデータを含まないraw-dataなんだよ。
それでみんな酷い目にあってきたのに、web屋は本当に馬鹿だね
Re: (スコア:0)
>まさか完全じゃなきゃ意味がないとでも?
完全じゃなきゃ意味がないと思っているのは BOM 強制肯定派では?
BOM があれば完璧だと思ってるから、 UTF-8 では BOM を付けろ、
あらゆる場面で BOM 付を扱えるようにしろとうるさいんでしょ。
実際には BOM 付けても完璧じゃないのだから、 OS やシェルの
ようなシステムの中枢部では、従来の仕様を崩してまでそんな
あいまいなものに頼った処理を入れるべきではないと思う。
別に BOM を全否定しているわけじゃないんで、付けてメリットが
ある場面では付けたって良いとは思うよ。
Re: (スコア:0)
なんか「web屋」って単語で煽ってるの1人だと思うんだけど、BOMの件でムカついてるのは主にUNIXユーザだと思うぞ。
Re: (スコア:0)
1990年代のunix屋は本当にエンコーディングに苦労していて、高橋さんはニューラルネットワークで判別させるプログラムを書いたりしてたんだけど、
今日のunix屋は先頭の数バイトの処理もできないボンクラばかりになりましたか
Re: (スコア:0)
うーん、完全を求めているところが違う気がします。
「先頭3ByteがBOMと一致したらそれはUTF-8とみなしてください」という
紳士協定のようなものなんじゃないでしょうかね。
文字コードの判定においてではなく
責任範囲を明確化において完全さを求めていると言えばいいんでしょうか。
Re: (スコア:0)
unix屋にとってのBOMは、そんなもの無くても問題なくやってきたのに
Winやってる奴らが持ち込んできた余計なものなんだよ。
処理できるできないで言えばできないわけじゃないけど、
なんでうちらがそんな余計なことをしなきゃいけないんだと怒ってる。
Re: (スコア:0)
>BOM無しのメリットが弱すぎると思うのですが
過去の膨大な ASCII ファイルの資産が、変換なしに扱えるというのが
どれほど大きいメリットか想像できませんか?
Re: (スコア:0)
それはおそらく過去の資産より多い
Re: (スコア:0)
BOM を付けない環境向けの資産をわざわざ BOM 付きで残す人がどれだけいるの?
Re: (スコア:0)
> unix屋にとってのBOMは、そんなもの無くても問題なくやってきたのに
ぎゃはははははは
Re: (スコア:0)
BOM無しにすることで活用できる(BOM有りでは活用できない)資産は
ASCIIにのみ対応した「プログラム」であって
ASCII「テキスト」ではありません。
・BOM有りだろうと無しだろうとUTF-8とみなす
→ASCIIはBOM無しUTF-8として受理される
・BOM有りならUTF-8とみなし無いならロケール設定に従う
→UTF-8, EUC等のASCII互換ロケール設定においてはASCIIは受理される
・BOM有りならUTF-8とみなし無いなら文字コード推定を行う
→ASCIIまたはUTF-8, EUC等のASCII互換文字コードとしてASCIIは受理される
ASCII互換はUTF-8だけのものではありません。
ASCIIとの共存は今更心配するような話じゃないのです。