文字コード総合スレ part13
レス数が1000を超えています。これ以上書き込みはできません。
>>947
> 規格に BOM は不要で非推奨と書かれていることが判明した。
ちゃんと基礎知識を身につけろ
BOMはバイトオーダーマークの略で、UTF-16などのために作られた仕様
互換性のためじゃねーよ。Unicodeで必要だからBOMが作られたんだろ
でUTF-8は1バイト単位の可変長だから、BOMはいらないはずだって主張するやつが出てきた
ところがどっこいBOMにははUnicode Signatureの意味があることが判明した
（知っている人にとっては常識）
そしてUTF-8でBOMは仕様違反だとか禁止とか言ってるやつのトーン下がって
「非推奨だから付けたらだめ」みたいな屁理屈を言い始めたが
PDFにBOM Allowed?: yesという文言が見つかって、ゲームオーバーっていうのが
これまでの流れだ >>951
ちゃんと「規格で許可されている」って書こうね
これは事実なんだから
それができないから、嘲笑されてる お前ら何もわかってないな
各サービスに複雑な文字コード自動判定処理が追加されたことで、
UTF-8/16/32であることをオレオレ自己申告して複雑な文字コード自動判定をスキップするBOMの存在価値はかえって高まったのだ >>952
脳内で歪んだか？
過去レス見直しても「規格に禁止と書いてある」と主張してるやつは一人もいないぞ
「規格に不要かつ非推奨って書いてある」と主張してるやつは多数いる >>953
だから勝手につける分にはつけていいだろ。
「許可、不要、非推奨」なのは認めるんだな？ 復唱してみろ。 >>955
だからなんで「規格で許可されている」を消すんだよ？
「規格で許可されているが、必須ではなく推奨もしていないと書いてある」だろうが
Its usage at the beginning of a UTF-8 data stream is neither required nor recommended by the Unicode Standard,
but its presence does not affect conformance to the UTF-8 encoding scheme.
UTF-8データストリームの冒頭で使用することは UTF-8データストリームの先頭での使用は、
Unicode Standardでは必須でも推奨でもありませんが、その存在はUTF-8エンコーディングスキームへ
の適合性に影響を与えず、UTF-8エンコーディングスキームへの適合性に影響を与えません。
neither required nor recommended
→ neither 必須 nor 推奨
→ 必須ではなく、推奨でもない
不要は unnecessary だ
訳ぐらい間違えんな >>956
「許可されている。必須ではない。推奨されていない。」と認めるわけだぞ。
BOM Allowed?: yes
neither required nor recommended
書いてあるとおりだ。 >>946
付けろとは描いてないだろ
それがすべてだ >>958
それでいいよ。技術的には不要でも必須でもないでも同じ意味だ。
必須でなくて非推奨なものの他人につけろっていったり、対応を要求したりしなければOK。 >>948
つけてもいいということはつけなくてもいいということだ
要らないものをつけるためには理由が必要
その理由があまりにもくらだんから全部却下されてるのが今の流れ > 要らないものをつけるためには理由が必要
だから何度もUnicode Signatureって
書いてあるって話をしてるんだがな 文字コードが統一されているシステムなら(意味が無いから)BOMは付けない
他の文字コードも扱うシステムなら(識別子として)BOMを付けるか検討する
で良いじゃん 書き忘れた
他の文字コードも扱うシステムでも、文字列以外から文字コードが分かるならそちらを使い、BOMは付けない
BOMが欲しくなるのはSJISとUTF-8等が混在するWindowsのファイル
ファイルのメタデータとして文字コードが設定出来れば良いのに windowsなら
hoge.utf8.txt
hoge.sjis.txt
で解決
しらんけど ファイルの拡張属性にでも，TextEncoding を加えておけば良いんでは？ いや、そこまでしてBOMを避ける理由がわからん
BOMでなければなんでもいいのかよw >>968
好きな理由1つ選んで
・UTF-8の最大の特徴はASCIIと上位互換、BOMをつけたら台無しになる
・今はUTF-8 はBOM無しが主流
・将来の外部コードはUTF-8のBOM無しになることがほぼ確定している
・移行期だけのために余計なものをつけたくない
・BOMつきだと動かないシステムがある
・文字コードの自動判定はバグやセキュリホールの温床になるので削除したい
・SJISとか時代遅れのものはもう使用してない
・BOMの曖昧さはセキュリティホールになる可能性がある
・ZWNBS との曖昧さがいやらしい
・規格で非推奨のものは避けたい
・ファイルの接続とか分割やファイル名操作などに曖昧さがあるのはいや
・不要なものを付ける理由が思いつかない
・とにかく嫌い
他にも理由はあるだろうけど、人それぞれ BOMを付けておくと都合がいいケースがたまたまあっただけ ・移行期だからこそBOMで他のエンコーディングと区別できるようにしておきたい場合がある
・BOMなしだと動かないシステムがある
・文字コードの自動判定はバグやセキュリホールの温床になるのでBOMを付けておきたい
・SJISはJIS X 0208で標準化されている現役の規格
・今のUnicodeの規格ではZWNBSP(U+FEFF)ではなくWORD JOINER(U+2060)の使用が強く推奨されているのでBOMとの曖昧性は起きない
・規格で許可されてるものを無理に避ける必要はない
・許可されているものを避ける理由が思いつかない すべてはカネ次第。カネを出す人が決めればいいだけ。つまり経営マターってこと。 > ・文字コードの自動判定はバグやセキュリホールの温床になるのでBOMを付けておきたい
BOM付けてリスク変わる？ そりゃ変わるだろ、BOMが付いてれば判定ミスがなくなる BOM見てUTF-8だってのは自動判定の一要素でしかないしBOMなし対応いらなくなるわけじゃないから変わらないと思うんだけどな
ユーザー視点の話なら一つ前のと同じこと言ってるわけだし >>975
ゴールポストを動かすように自動判定の定義を動かすのはみっともないからやめとけ >>975
BOMは99.999%正しく判定できる自動判定だよ
実質完全に判定できるといっても過言じゃない。 >>977
自動判定のセキュリティ・リスクはそういうところじゃないよ。認識率100％でも起こる、むしろそっちが攻撃に使い易い。セキュリティまわりは勉強したことない素人が思いつくほど単純じゃない。 >>978
BOMによる自動判定だけなら先頭の数バイトの固定パターンを見るだけの単純なものだから
バグの入り込む余地はかなり小さくなるだろ >>978
つまり世の中のテキストエディタからEUC-JP対応を削除しろって話をしてるの？ 仕様で文字コードが固定されていようがBOMで判断しようが
不正データを読んで変なことにならないようにすることと全く関係ないだろ
もしかして「文字コードの自動判定」という機能単体の話でBOMチェックだけならば堅牢だって趣旨だったのか 「文字コードの自動判定にはセキュリティリスクがある」
↓
BOMによる判定も自動判定だ
↓
だからBOMにセキュリティリスクがある
なにこの三段論法w BOMがあればデータチェックをスキップしていいと考えるやつがいることを想定するなら確かに心理的セキュリティリスクが存在することにはなる
でもそんな話はしていないんだよなあ
俺の起点は>>971に対するものでこれは>>969を受けてのものだから最初からBOMによる自動判定の話だし >>984
すげー単純な例だとバイナリファイルの先頭に UTF-8 BOM つけてテキストに偽装、ファイアウォールやウィルスチェックをすり抜ける。うかつなソフトが自動判別してBOMを外して次段に渡してマルウェア発動。
アホみたいだがこんなんで実際に被害が出てるんだぜ。実際はこんな単純じゃなくてもっと複雑で発見され難い攻撃ができる。 >>971
ZWNBS についてだが uniccode standard には
「BOMが不要な場合には先頭の U+FEFF は後方互換性のために ZWNBS と解釈される」という規定がある。
これと「UTF-8 に BOM は不要」という規定を合わせると...入力処理系の実装はどうなる？ 曖昧さがあるだろ。 >>986
BOMをなくすとバイナリとして扱うのか？
それともテキストして扱うのか？ >>987
まずお前の言う「入力処理系」が何なのか説明しろ
「あれが困る」みたいな曖昧な言い方をするな バイナリとして扱ったとしてもデータとして使うのか?
それとも実行可能ファイルとして使うのか?
後者はもう BOMの使い方を大きく離脱しているな >>980
ついでにSJIS対応もISO2022JP対応も削除で お前だろ
ってかBOMは許可されてるのに
そういう例外を持ってきてわーわー騒ごうとするのは頭が悪い シェルスクリプトが万が一BOM付きshebangを解釈するようになったとしても
catはどう処理されるんだろ
面倒だから止めてるんだろうな 昔のmsysのcat.exeは0x0Aを勝手に0x0D0x0Aに変換して出力する仕様だったので、人知れず泣いた人多かったんじゃないかと思う
>>997
BOMをスキップするオプションとか追加すれば対処できるんじゃまいか binaryオプション付けなければwin上で0d0aにされても文句言えない罠
しかしデフォでbom無であるべきで
デフォがbom付になるのは許すまじ このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 972日 15時間 57分 1秒 5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/
▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php レス数が1000を超えています。これ以上書き込みはできません。
