導入 — 文字化けはなぜ起きるか

「縺薙ｓ縺ｫ縺｡縺ｯ」— この画面、何が起きているのか

取引先から届いた CSV を Excel で開いたら日本語が全部「縺薙ｓ縺ｫ縺｡縺ｯ」のような漢字の羅列になっていた。Web ページの一部だけ「ã“ã‚“」のような記号が並ぶ。DB に登録したはずの名前が「????」になっている。— 対処として「符号化を変えて開き直したら直った」経験はあっても、なぜそれで直るのかを説明できる人は意外と少ないものです。

出発点はたった 1 つの事実です。コンピュータが保存したり送ったりできるのは、0x00〜0xFF のバイトの並びだけ。「あ」や「A」という文字そのものが保存されているわけではありません。文字をバイト列に変換する規則を符号化（エンコーディング）と呼び、UTF-8 も Shift_JIS もこの規則の一種です。

そして重要なのが次の点です。ファイルには「このバイト列は UTF-8 です」という札は付いていません。読む側は、設定や宣言や推測を頼りに「たぶんこの符号化だろう」と決めて対応表を引きます。書いた側の規則と読む側の規則が一致していれば元の文字に戻り、ズレていれば — 別の文字に見えます。これが文字化けです。

化けても、データは壊れていない

上の図をもう一度見てください。E3 81 AB という 3 バイトは、どの読み方をしてもまったく同じ 3 バイトのままです。壊れたのはデータではなく「読み方の選択」だけ。だから、正しい符号化を指定して読み直せば、元の「に」がそのまま戻ってきます。

ただし 1 つだけ注意があります。化けた見た目のまま上書き保存してしまうと、「縺ｫ」という化けた文字列が新しいバイト列としてディスクに書き込まれ、元のバイト列は失われます。文字化けに出会ったら「書き込まずに、まず読み方を疑う」— これが実務での第一動作です。

この講座の合言葉: 文字化けを見たら問いかけてください — どの符号化で書かれたバイト列を、どの符号化として読んでしまったのか？

「番号を振る」と「バイトにする」— 2 段階に分けて考える

ここで、この講座全体を貫く見方を導入します。文字がバイト列になるまでには、実は 2 つの独立した段階があります。

「Unicode と UTF-8 って何が違うの？」という定番の疑問は、この 2 段階で即答できます。Unicode は第 1 段階（番号の振り方）、UTF-8 は第 2 段階（番号のバイトへの変え方）。土地の番地の決め方と、番地を封筒にどう書くかの違い、と言ってもよいでしょう。第 2 章で第 1 段階を、第 3 章以降で第 2 段階を、それぞれじっくり扱います。

この章で持ち帰ること

• ファイルの実体はバイト列だけ。「何の符号化か」の札は付いていない
• 文字化けの正体は「書いた符号化」と「読んだ符号化」のズレ。バイト列そのものは壊れていないことが多く、読み方を直せば戻る（ただし化けたまま保存しない）
• 文字は番号（コードポイント）→ バイト列（符号化）の 2 段階で扱われる。Unicode は第 1 段階、UTF-8 は第 2 段階

次章では第 1 段階「番号を振る」の歴史を、ASCII の 128 文字から世界中の文字を収める Unicode まで一気にたどります。