HTML5で、set_include_pathを用いると、先頭に謎の空白行ができる

何かを勘違いしているだけだと思うが、
解決できないので、メモ。HTML5で、set_include_pathを用いると、先頭に謎の空白行ができる。
しょうがないので、includeファイルを相対パスで直読み込みした。
この方法だと、階層が深くなると、しんどくなるよ。

なんで、できないかな？


2012/3/15
今日、また同じ現象に遭遇。
色々調べた結果、
不具合の原因は、
「includeするファイルの文字コードに、BOM (Byte Order Mark) を付けて保存していたことが原因だったみたい。
「UTF-8 (BOMなし)」で保存したら、あっさり空白行が消えた。


以前の不具合が、どのサイトだったか思い出せない(から今実際に試せない)けど、恐らくこれが原因だと思われ。

つまり、こういうこと。

＜前提＞
includeするファイルを「UTF-8」で保存する場合
○ … BOMを含まない「UTF-8 (BOMなし)」 (またはUTF-8N) でファイル保存
× … BOMを付ける「UTF-8 (BOMあり)」 でファイル保存


ということで、
HTML5とか、全く関係なかった……


ちなみに、BOMの取り扱いについては、
基本的には、UTF-8にはBOMは不要で、不具合がある場合にBOMを付けて試すと実行できたりする、ぐらいの認識で良いみたい

下記呼称も、俗称に過ぎない
「BOM 付き」… UTF-8
「BOM なし」… UTF-8N

そもそも、BOMがあると、何が便利かと言えば、
フォーマットの識別が容易になる
（先頭の3バイトを読むだけで、UTF-8 でエンコーディングされているとみなすことができる）
というだけ。

本来、BOMを付けなければいけない理由はないし、付けることで弊害が起きる可能性がある

　　　↓

基本的には、UTF-8にはBOMは不要で、不具合がある場合にBOMを付けて試すと実行できたりする、ぐらいの認識で良い

＜BOMが付与される例＞
・Windowsメモ帳で保存
・設定にもよるかと思うが、秀丸とかでも、メモ帳で保存したテキストを開き、何も考えずに保存(自動判定-UTF-8)すると、BOM付きで保存される

＜秀丸例＞
・BOM付きファイルを開き、「自動判定-UTF-8」で保存 → BOM付き
・BOMなしファイルを開き、「自動判定-UTF-8」で保存 → BOMなし
※自動判定だから、動作的にはこれで正しいと思うが、この辺あまり意識していなかったので、ちょっと勘違いしてた部分もある
※最も、すぐ横に「BOM」確認チェック欄があるので、大抵の人は間違わないとは思うが…

＜想定されるBOM弊害例＞
・レイアウトが崩れる(空白行が入る)
・header関数の前にBOM付きUTF-8ファイルをincludeしてはいけない
→header()を呼ぶ前にincludeしたファイルに空白や空行がなかったとしても，そのファイルがBOM付きのUTF-8だった場合には，既に出力が行われたと見做されエラーとなってしまう