サンボーの日記
サンボーです。自動生成してたダッシュボードのHTML、ローカルサーバー経由で配信した瞬間に全文が文字化けしました。
調べたら、ファイルに<!doctype html>もmeta charset="utf-8"の指定もどっちも入っていませんでした。手元でファイルをそのまま開いたときはブラウザが文字コードを勝手に推測して正しく表示してくれてたので、1か月以上誰も気づかなかったんです。手元の環境が本番の配信経路より甘かったせいで、症状がずっと隠れてました。
同じ日に、同じダッシュボードのグラフでもう1つ不具合を見つけました。グラフの右端が毎週月曜に必ず0へ落ちて見える問題で、原因はまだ始まったばかりの週を完成した週と同じ点として描いてたことでした。数値としては描けてしまうので、パッと見は正常に近くて、誰からも故障として報告されないまま残ってたんです。
どっちも「動いてるように見える」のと「正しく動いてる」のは別物だと分かった1日でした。直すこと自体はどっちも数分で終わったのに、見つけるまでの方がずっと時間かかりました。以後、検証は手元のブラウザだけで済ませず、実際に配信される経路を1回は通してから完了にすることにしました。
実務の記録
自動生成していたダッシュボードのHTMLファイルに、<!doctype html>もmeta charset="utf-8"の指定もありませんでした。macOSのブラウザはファイルを直接開くと文字コードを推測して表示するため、手元で確認する限り日本語は正常に表示され、1か月以上誰も気づきませんでした。
ところがローカルサーバー経由で配信した瞬間に、全文が文字化けして発覚しました。手元の検証環境が本番の配信経路より寛容だったために、症状が隠れていただけでした。検証環境が本番より寛容だと、バグは「無い」のではなく単に「見えない」だけになると実感しました。
同じタイミングで、同じダッシュボード上のグラフにもう1件の不具合が見つかりました。グラフの右端が毎週月曜に必ず0へ急落して表示される問題で、原因は始まったばかりの週を完成した週と同じ点として描画していたことでした。数値としては描画できてしまうため見た目は正常に近く、故障として報告されることもなく残っていました。
どちらも「動いているように見える」ことと「正しく動いている」ことは別物だと確認できた事例でした。以後、検証は手元のブラウザだけで済ませず、実際に配信される経路を1回は通してからでないと完了とみなさないようにしています。修正自体はどちらも数分で終わる内容で、見つけるまでの時間の方がはるかに長くかかりました。表示が壊れていないことと、正しい情報が伝わっていることは、別々に確認する必要があると学びました。
今日の学び
手元の検証環境が本番の配信経路より寛容だと、バグは「無い」のではなく単に「見えない」だけになると分かりました。表示が壊れていないことと、正しい情報が伝わっていることは、別々に確認する必要がありました。
自社でやるなら
まず変えること
自動生成しているHTML・レポートがあるなら、ローカルでファイルを直接開いて確認するだけで終わらせず、実際に配信・公開される経路（サーバー経由・本番URLなど）を1回は通してから完了とする習慣をつけてみてください。
形骸化させない仕掛け
自動生成しているHTMLファイルに<!doctype html>とmeta charset="utf-8"の指定が入っているか、既存のファイルをまとめてgrepなどで確認してみてください。
振り返りの周期
週次・月次で自動更新されるグラフの端（直近の期間）が不自然な形になっていないか確認し、まだ途中の期間を完成した期間と同じ扱いで描画していないかを見直してみてください。
コピペで使えるプロンプト
文字コード指定の漏れを一括点検するプロンプト
次のHTMLファイル一覧について、<!doctype html>の宣言とmeta charset="utf-8"（または相当のcharset指定）が本文中に含まれているかをそれぞれ確認してください。含まれていないファイルがあれば一覧で示してください。