文字化け (mojibake) は、テキストを書き込んだときの文字コードと、読み出すときの文字コードが食い違うことで発生します。たとえば UTF-8 で保存された日本語テキストを Shift_JIS として開くと、「こんにちは」が「縺薙s縺ォ縺。縺ッ」のような意味不明な文字列に変わります。逆に Shift_JIS のファイルを UTF-8 で開くと「\ufffd」(置換文字) が大量に表示されるか、まったく別の漢字が並びます。

文字化けが起きる典型的なシナリオは 3 つあります。第一に、ファイルの保存時と読み込み時でエンコーディングが異なるケース。第二に、データベースの接続設定とテーブルの文字セットが不一致のケース。第三に、HTTP レスポンスヘッダの Content-Type で指定した charset と実際の HTML ファイルのエンコーディングが異なるケースです。いずれも「書き手と読み手の約束が合っていない」という同じ構造の問題です。

歴史的に見ると、文字化けは日本のコンピュータ文化と深く結びついています。1980 年代から 1990 年代にかけて、JIS、Shift_JIS、EUC-JP という 3 つの主要な日本語エンコーディングが並立し、メールやウェブページで頻繁に文字化けが発生しました。特に電子メールでは ISO-2022-JP が標準とされていたにもかかわらず、メールクライアントごとに異なるエンコーディングを使うことがあり、受信側で文字化けする問題が日常的でした。

現在は UTF-8 がウェブの事実上の標準となり、文字化けの発生頻度は大幅に減少しました。W3Techs の調査によれば、ウェブサイトの 98% 以上が UTF-8 を採用しています。しかし、レガシーシステムとの連携、CSV ファイルのやり取り (Excel は BOM 付き UTF-8 を期待する)、古いデータベースの移行など、文字化けが完全になくなったわけではありません。

文字化けを防ぐ実務上のポイントは明確です。ファイルは UTF-8 (BOM なし) で統一する。データベースの文字セットは utf8mb4 を使う。HTTP レスポンスには Content-Type: text/html; charset=UTF-8 を明示する。CSV を Excel で開く場合は BOM 付き UTF-8 で出力する。これらを徹底するだけで、現代の開発環境ではほとんどの文字化けを回避できます。

文字数カウントの観点では、文字化けしたテキストは見た目の文字数と実際のバイト数が大きく乖離します。たとえば UTF-8 の日本語テキストを Latin-1 として解釈すると、1 文字が 3 文字に膨張して見えるため、文字数カウントの結果が本来の 3 倍近くになることがあります。正確な文字数カウントの前提として、テキストのエンコーディングが正しく認識されていることが不可欠です。