BOM は必要?
◆ つけてて困ることそうないし つけといたほうがいろいろな面でいいかも
C# と PHP を書いていてふと思いました
BOM は必要??
PHP は 「<?php ~ ?>」 の外は全部そのまま出力するという特殊な言語なので BOM があってはいけない言語です
他の言語は だいたいあってもなくてもどっちでも問題ないと思います
C# というか VisualStudio でファイルを作ると基本 BOM 付きです
なしにしたくても デフォルト設定はないみたい (Express 以外ならエクステンションで対応してるみたい) で手動でひとつひとつファイルの設定を変えないとだめです
最初のうちは BOM なんてなくてもいいものつけるのってなんかいや ということで何十もあるファイルの BOM の設定を全部手動切り替えてました
ですが 最近はさすがに面倒になってきて BOM ありのままです
wav だと 52 49 46 46 (RIFF)
jpg だと FF D8
png だと 89 50 4E 47 0D 0A 1A 0A
zip だと 50 4B 03 04
こういうのをみて 拡張子判定ソフトが拡張子を判断してるわけですが テキストファイルだと基本最初からいきなりテキストが始まります
バイナリフォーマットのどれでもなければテキスト でいいのかもしれませんが テキストの中でも SJIS とか UTF-8 を分けたいときに全部読み込んでチェックしないといけません
100MB のファイルだとまずエンコードチェックに1回 そのエンコードで再度読み込みで 200MB も読み取る必要がでてきます
そのせいでエディタによっては ある程度以上のサイズだと最初の数 KB だけで判断していたりもします
そのせいで後半にある日本語が文字化けしていたり それに気づかず保存してひどいことになったり
また 読み込み時に全部読み取って 「アルファベットしかないから ASCII ね」 って判断するソフトもけっこう多いです
作った人は UTF-8 で保存してるので 大丈夫だと思って次開いたときに気にせず日本語を書いて上書きすると 「ASCII だったものに日本語が追加された! とりあえず SJIS 保存」 ってことが起きます
エディタで UTF-8 固定すればいいともいえますが それはそのエディタでしか開かないと制限受けます
誰かと もしくは自分の他の PC と共有していて全員が保存時に毎回 UTF-8 になってるか確認するのは難しいです
それなら最初から開いてすぐに UTF-8 とわかるように BOM つけたほうがいいと思えます
VisualStudio の例を書きましたが VisualStudio に限らず Windows (マイクロソフト製) は全部こうなってると思います
Office やメモ帳などどれも UTF-8 保存は BOM が付きますし 私の知る範囲だとつけないという設定ができないもののほうが多いです
エクセルにいたっては BOM のない UTF-8 は開けない とかだった気がします
ググってみると BOM を嫌がっている人が多いようでしたが PHP みたいな特殊なものでしか困るとこもないですし 新しくできたソフトは基本的に BOM は考慮されているはずなのでつけるデメリットはほぼないと思います
UTF-8: 0xEF 0xBB 0xBF
UTF-16 (BigEndian): 0xFE 0xFF
UTF-16 (LittleEndian): 0xFF 0xFE
16 は綺麗なのに 8 が覚えにくいよくわからない値
BOM は必要??
PHP は 「<?php ~ ?>」 の外は全部そのまま出力するという特殊な言語なので BOM があってはいけない言語です
他の言語は だいたいあってもなくてもどっちでも問題ないと思います
C# というか VisualStudio でファイルを作ると基本 BOM 付きです
なしにしたくても デフォルト設定はないみたい (Express 以外ならエクステンションで対応してるみたい) で手動でひとつひとつファイルの設定を変えないとだめです
最初のうちは BOM なんてなくてもいいものつけるのってなんかいや ということで何十もあるファイルの BOM の設定を全部手動切り替えてました
ですが 最近はさすがに面倒になってきて BOM ありのままです
BOM あったほうがいいかもしれない
考えてみるとバイナリファイルって基本 最初にどういうファイルか表すヘッダがありますよねwav だと 52 49 46 46 (RIFF)
jpg だと FF D8
png だと 89 50 4E 47 0D 0A 1A 0A
zip だと 50 4B 03 04
こういうのをみて 拡張子判定ソフトが拡張子を判断してるわけですが テキストファイルだと基本最初からいきなりテキストが始まります
バイナリフォーマットのどれでもなければテキスト でいいのかもしれませんが テキストの中でも SJIS とか UTF-8 を分けたいときに全部読み込んでチェックしないといけません
100MB のファイルだとまずエンコードチェックに1回 そのエンコードで再度読み込みで 200MB も読み取る必要がでてきます
そのせいでエディタによっては ある程度以上のサイズだと最初の数 KB だけで判断していたりもします
そのせいで後半にある日本語が文字化けしていたり それに気づかず保存してひどいことになったり
また 読み込み時に全部読み取って 「アルファベットしかないから ASCII ね」 って判断するソフトもけっこう多いです
作った人は UTF-8 で保存してるので 大丈夫だと思って次開いたときに気にせず日本語を書いて上書きすると 「ASCII だったものに日本語が追加された! とりあえず SJIS 保存」 ってことが起きます
エディタで UTF-8 固定すればいいともいえますが それはそのエディタでしか開かないと制限受けます
誰かと もしくは自分の他の PC と共有していて全員が保存時に毎回 UTF-8 になってるか確認するのは難しいです
それなら最初から開いてすぐに UTF-8 とわかるように BOM つけたほうがいいと思えます
VisualStudio の例を書きましたが VisualStudio に限らず Windows (マイクロソフト製) は全部こうなってると思います
Office やメモ帳などどれも UTF-8 保存は BOM が付きますし 私の知る範囲だとつけないという設定ができないもののほうが多いです
エクセルにいたっては BOM のない UTF-8 は開けない とかだった気がします
ググってみると BOM を嫌がっている人が多いようでしたが PHP みたいな特殊なものでしか困るとこもないですし 新しくできたソフトは基本的に BOM は考慮されているはずなのでつけるデメリットはほぼないと思います
BOM のデータ
ところで BOM のデータはこんなのUTF-8: 0xEF 0xBB 0xBF
UTF-16 (BigEndian): 0xFE 0xFF
UTF-16 (LittleEndian): 0xFF 0xFE
16 は綺麗なのに 8 が覚えにくいよくわからない値
COMMENT
コメント一覧 (2)
-
- 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のルールで符号化したらそういうバイト列になったってだけなんでそりゃ半端な値になりますとも。
-
- 2016/11/22 22:32
-
> BOMであるU+FEFF(ZWNBSP:ZERO WIDTH NO-BREAK SPACE)をUTF-8のルールで符号化したらそういうバイト列になったってだけ
そういう理由だったんですね
FEFF は BOM のための専用のコードだと思っていました
なので UTF-8 も FDFEFF とかわかりやすいのでいいじゃない って
ファイルの最初だからと特別視してるんじゃなく ZWNBSP という文字を表していたなら UTF-8 に合わせてへんな値になるのも納得です
勉強になりました