総合演習 — 文字化けを推理する

ひらがなの UTF-8 バイト列は E3 81 / E3 82 / E3 83 で始まり、この 2 バイトを Shift_JIS の表で引くとそれぞれ「縺」「繧」「繝」になります。だから UTF-8 の日本語を Shift_JIS として誤読すると、この 3 文字が異常な頻度で現れ、余ったバイトが半角カナ（ｫ や ｯ など）に見えます。逆方向（Shift_JIS を UTF-8 で読む）なら次問のとおり置換文字だらけになるので、化け方の見た目だけで方向まで特定できます。

「テスト」の Shift_JIS は 83 65 83 58 83 67。UTF-8 として読むと、0x83 は「続きのバイト」の形をした孤立バイトで不正となり �（U+FFFD）に置換されます。一方 2 バイト目の 65（e）、58（X）、67（g）は ASCII 範囲なのでそのまま生き残る — 第 4 章で学んだ「Shift_JIS の 2 バイト目は ASCII 域に食い込む」がここで指紋になります。「� が多発 + 英字の破片」は Shift_JIS 系を UTF-8 で読んだサインです。

日本語の UTF-8 は 1 文字 3 バイトで、先頭バイトはほぼ E3〜E9。Latin-1 系の表では E3 が ã、E5 が å、E6 が æ に当たるため、「ã などが 3 文字おきに現れ、文字数が約 3 倍にふくらむ」という指紋が出ます（間のバイトの一部は目に見えない制御コードになります）。1 バイト = 1 文字の表で読んでいるので置換文字は出にくく、q2 のパターンとの見分けどころです。charset 宣言を無視・欠落させた海外製ツールやメールソフトの定番の化け方です。

「縺」の指紋から UTF-8 を Shift_JIS（CP932）系で読んだと推理でき、ダブルクリックで開かれた Excel の既定動作と符合します。宣言の仕組みがない CSV では、BOM（EF BB BF）が数少ない「実体に埋め込めるラベル」で、これを付けるのが定石です（第 6 章）。なお、この場合もファイルの実体は無傷なので、利用者側でもインポート機能で UTF-8 を明示すれば正しく読めます。

誤読（縺薙ｓ型）はバイト列が無傷なので可逆ですが、? への置換は変換処理が「表せない文字」を ? という別の文字に書き換えて保存した結果で、不可逆です。①や 髙 のような CP932 の機種依存文字を厳密な変換にかけたときなどに起きます（第 4 章）。対処も異なり、誤読なら読み直し、置換なら移行元データからの再投入が必要です。「化け」と「置換」を言い分けられることが、復旧可否の判断に直結します。

メールのヘッダは歴史的に ASCII しか許されなかったため、日本語の件名は「=?符号化名?B?Base64 データ?=」という MIME エンコードで包んで送られます。件名と本文では符号化の宣言場所が別なので、片方だけ化けるのはむしろ自然な症状です。受信側が MIME を解釈できない・宣言と実体がズレている・途中のシステムがヘッダを壊した、などが典型原因で、「宣言と実体」の考え方（第 6 章）がヘッダ単位で適用される例です。

「特定の文字を含む行だけ壊れる」は、第 4 章のダメ文字の指紋です。「ソ」（83 5C）の 2 バイト目がバックスラッシュと同じ値のため、バイト単位でエスケープ処理をするプログラムが文字の途中を記号と誤解します。対処は、Shift_JIS を正しく認識するライブラリで処理する・受け渡しを UTF-8 に変える、など「文字の切れ目を正しく扱う」方向です。カタカナ自体が悪いわけでも、桁あふれでもありません。

講座の総まとめです。宣言はラベルにすぎず（第 6 章）、実体のバイト列は変換処理をして初めて変わります。変換とは「EUC-JP の表で読んでコードポイント（番号）に戻し、UTF-8 の規則でバイト列にし直す」という、2 段階（第 1 章）を経由する引っ越しです。化けてから直すのではなく、境界を越える前に正しく変換する — 「書いた符号化」と「読んだ符号化」を一致させ続けることが、文字コード実務のすべてです。