以下の内容はhttps://var.blog.jp/archives/67130739.htmlより取得しました。
COMMENT
コメント一覧 (2)
1. ななしさん
2016/11/22 05:49
BOMが不味いのはASCII専用の処理系で食えない事と、エディタによってバイト列構造が隠蔽されてしまう事の2点ですが、
ソースファイルとしてなら差分生成などの外部ツールがASCII専用だったりしない限りは確かに特に支障はないですね。
というかファイルの用途別で見れば、(既に)ファイルにBOMが付いている分には何の問題もなくて、
汎用のテキストエディタ等がファイルを作る時に意図せずBOMが付与されるのが問題なのではないかと思います。
ファイルの問題じゃなくて、汎用であるべきエディタのデフォルトの挙動として問題が起きる的な感じで。
バイト列構造が隠蔽されて見た目とバイト列が一致しない点に関しては、
そもそもUnicodeを正しく処理するとバイト列構造レベルで直接扱うべきでは無いってレベルですね・・・
RLEとかNBSPとか結合だの分解だの正規化だのもう無茶苦茶・・・・・・セキュリティホールにもなるよ！
こうして見るとファイルにBOMを付けるべきかとかではなく、
エディタのデフォルトの挙動はどうあるべきかとか、
Unicode使うべきかとかそっちの話になりそうです。
> 16 は綺麗なのに 8 が覚えにくいよくわからない値
BOMはバイトオーダーマークの意味ですから、本来は16ビットを8ビット単位で保存する時にしか意味が無いんですよね・・・
(おっしゃる通りのヘッダとしての意義などから)BOMであるU+FEFF(ZWNBSP：ZERO WIDTH NO-BREAK SPACE)をUTF-8のルールで符号化したらそういうバイト列になったってだけなんでそりゃ半端な値になりますとも。
2. [管理人]
2016/11/22 22:32
> BOMであるU+FEFF(ZWNBSP：ZERO WIDTH NO-BREAK SPACE)をUTF-8のルールで符号化したらそういうバイト列になったってだけ
そういう理由だったんですね
FEFF は BOM のための専用のコードだと思っていました
なので UTF-8 も FDFEFF とかわかりやすいのでいいじゃない って
ファイルの最初だからと特別視してるんじゃなく ZWNBSP という文字を表していたなら UTF-8 に合わせてへんな値になるのも納得です
勉強になりました
