２日ほど泥沼にハマって抜け出せなくなっていた問題が解決できたので、その謎を共有します。

元々はこんなシステムを PHP で作ろうとしていました：
　- 画像をアップロードできる
　- アップロード画像は ID を付与した上で MySQL の BLOB （バイナリ・ラージ・オブジェクト）として格納する
　- ID を指定して、アップロード済みの画像を表示させることができる

自分自身でも Java では何度も作ったことのある仕組みで、その PHP 版を作ろうとしただけでした。

いざ作って動かしてみると、アップロードは成功します。でも表示時に画像が壊れてしまい、うまく表示できないのです。この原因究明と解決に時間を使ってしまいました。


もう少し詳しく状況を説明します。調べていくうちに同じ現象が MySQL を使わなくても再現できることがわかったので、話をシンプルにするために MySQL なしで説明します（実際にはこの切り分けも簡単ではなかった）。

ソースコードはこんな感じ。同一ディレクトリにある bmxug148.png というファイルのバイナリコンテンツ（元々のコードでは MySQL の BLOB に格納されていたもの）を取り出して、PNG 画像用の HTTP ヘッダを指定して echo でバイナリをそのまま出力しています：

<?php
$img = file_get_contents("./bmxug148.png");
header('Content-Type: image/png');
echo $img;
?>

この PHP ファイルをブラウザから呼び出すと、画像が表示・・・されることを期待していたのに、画像が壊れてしまっている旨のメッセージが表示されてしまいます（FireFox で確認した場合）：



こういう状況だと、表示側の PHP スクリプトに問題があるのか、それともアップロードしたファイルバイナリデータの格納時に既に壊れてしまっているのかすらわかりません。まあ、上記のシンプルなスクリプトでも再現するということは前者ということになるのですが、それが分かったのは相当後になってのことです。


で、とりあえずこの「壊れた画像バイナリ」を無理やり取り出してファイルとして保存し、バイナリエディタで開いてみました。そこで分かったのは画像の最初３バイトに PNG 画像としてふさわしくない情報が追加されていた、ということです：



0xEF, 0xBB, 0xBF という３バイトが余分です（４バイト目から本来の PNG 画像のヘッダが始まっています）。４バイト目から表示されていれば正しく表示できそうなのですが、ではこの最初の３バイトはどこで付与されてしまったのでしょう？　DB への格納時の処理を疑うこともできたのですが、この EF BB BF という３バイトの組みあわせ、どこかで見たことありました。。

ちょっと調べると分かるのですが、これは BOM(Byte Order Mark) と呼ばれる符号で、テキストが Unicode で記述されていることと、その符号化の種類を示すものです。で、UTF-8 の場合の BOM がまさにこの 0xEF 0xBB 0xBF の３バイトなのです。


つまり、実はもとの PHP ファイルそのものが UTF-8 で記述されていて、しかも BOM 付きでファイルが保存されていたことが直接の原因だったのでした。このため、ブラウザでこのファイル実行した場合も、最初に 0xEF 0xBB 0xBF の３バイトは（PHP ファイルの一部として）返ってきて、次に PHP で処理した結果の画像バイナリが続いていた、ということになります：



画像の情報は正しく返っていたのに、その前に画像とは関係のない３バイトが送られてきていたため、「画像としては壊れている」と判断された、ということです：



したがって、解決策は PHP ファイルを BOM なしで保存することです：



この PHP をブラウザから実行すれば、本来の正しい画像が表示されるようになります：



あー、よかった。