前回の「FLOAT型の罠」と同じプロジェクトでの出来事です。
後日、またしても私のプログラムに疑い（？）の目が向けられた、ちょっと笑えるトラブルがありました。
💡 【連載：開発の記憶】
本記事は、受託開発の現場で直面したトラブルや葛藤を振り返る全3回の連載です。
- 第1回：DBをFLOAT型にしても誤差は出るというお話
- 第2回：システムが出力したExcelが開けない！？犯人は「メモ帳」だった話（現在の記事）
- 第3回：「セキュリティは不要」と指示されたエンジニアの葛藤
「出力されたExcelが壊れています」
ある日、件の担当者さんから次のような調査依頼が届きました。
１点、調査をお願いします。
集計機能で作成されたExcelを開こうとしたら「ファイルが破損している」という旨のメッセージが表示され、開くことができませんでした。
とりあえず、作成されたファイルを送付しますので確認をお願いします。
動的に生成・ダウンロードさせているファイルが破損しているとのこと。「プログラムのバグでバイナリが壊れたか？」と焦りつつ、送られてきたファイルをバイナリエディタで覗いてみました。
すると、あるべきデータの先頭に「謎の3バイト」がくっついていたのです。
バイナリに混入した「3バイトの異物」
ファイルの先頭に存在していたのは、 EF BB BF という3バイトのデータでした。
これは、UTF-8形式のファイルにおいて文字コードを識別するための「BOM（Byte Order Mark）」です。
今回のシステムはPHPで構築されていました。
PHPの仕様上、読み込まれる設定ファイル（config.phpなど）の <?php タグよりも前に何らかのデータが存在すると、それはそのままレスポンスとして出力されてしまいます。
Excelファイルのバイナリデータを出力する直前にこのBOMが出力されてしまったため、ファイルとしては「先頭にゴミがついている不正なデータ」となり、Excel側で拒否されていたわけです。
私は、担当者さんが「あのツール」でファイルを編集したのではないかと推測し、メールを返しました。
送っていただいたファイルを確認したところ、先頭にBOM（EF BB BF）が混入していました。
インクルードファイル（config.phpなど）の編集時に、BOM付きのUTF-8で保存してしまっていませんでしょうか？
（Windows標準の「メモ帳」は、UTF-8で保存する際にこのBOMを勝手に付加してしまいます。Web開発においては、これが原因で「画面上部に謎の空白が出る」「ヘッダー送信エラーが出る」といった不可解なバグを誘発する天敵となります。）
※ちなみに、現在のWindows 10/11のメモ帳は「BOMなしUTF-8」がデフォルトに改善されていますが、2014年当時はBOM付きで保存されるのが標準という、Web開発者泣かせの仕様でした。
担当者さんの素直な解決
前回のFLOAT型の時は数日間の沈黙がありましたが、今回は返信が早かったです。
※config.phpの編集をメモ帳で行っていましたが、秀丸で変更してサーバーにコピーしたら問題なく動作しました。ありがとうございます。
「秀丸（エディタ）で変更して」という一文に、普段はちゃんとエンジニア向けのエディタを使っているんだよ、という小さなプライドが感じられて、少し和んでしまいました。
まとめ：ソース編集に「メモ帳」は厳禁
Web開発における大切な教訓その2です。
「PHPなどのソースコードや設定ファイルを、Windows標準のメモ帳で編集してはいけない」
BOMによる不具合は一見して原因が分かりにくいため、一度ハマると多大な時間を溶かしてしまいます。
ちょっとした修正だからと横着せず、常にBOMなし保存ができるエディタを使う習慣を徹底したいものですね。