文字化けはなぜ起きるのか—□や謎の記号の正体と直し方

文字化けは、文字そのものが壊れたのではなく、文字を数字に置き換える約束事（文字コード）が、保存したときと読んだときで食い違うために起きています。日本語にはShift_JISやUTF-8など複数の対応表があり、書いた表と読む表がずれると別の文字として表示されます。多くの場合データ自体は無事なので、化けた状態で上書き保存せず、正しい文字コードで読み直せば元に戻せます。 ■ 文字化けは、何が起きている状態なのか 文字化けは、文字そのものが壊れたのではなく、文字を数字に置き換える約束事（文字コード）が、保存したときと読んだときで食い違うために起きています。データは無事なまま、解釈だけがずれている状態だと考えると分かりやすいと思っています。 コンピュータは文字をそのまま保存できません。文字の一つひとつに番号を振り、数値の並び（バイト列）として記録しています。この「どの文字に何番を割り当てるか」の対応表が文字コードです。 日本語では、古くから使われてきたShift_JIS、EUC-JP、メール用のISO-2022-JP、そして世界中の文字をまとめて扱えるUnicodeにもとづくUTF-8など、複数の対応表が併存してきました。書いた側の表と読む側の表が違えば、同じ数値の並びが別の文字として解釈されます。 よく見かける「譁?ｭ怜喧」のような並びは、UTF-8で書かれた日本語をShift_JISの表で読んだときに起きる典型例です。逆に、読み込んだ表に該当する文字がないと、置換文字と呼ばれる「」が並びます。 つまり文字化けは、ファイルの中身が破損したのではなく、解釈の段階でずれているだけのことが多いのです。ここが分かると、「壊れたから諦める」ではなく「読み方を合わせれば戻せるかもしれない」と考えられるようになります。作る側が気をつけているのも、まさに「どの表で書いたかを正しく宣言すること」です。 ■ なぜ文字コードの食い違いが起きるのか 食い違いが起きやすいのは、異なる時代や異なる環境のあいだでデータが受け渡されるときです。古いホームページ、メール、CSVファイル、圧縮ファイルの中のファイル名、古い業務ソフトからの出力などが代表的な場面です。 ・古いホームページ：HTMLに書かれた文字コードの宣言（meta charset）と、サーバーが通信で返す宣言が食い違うと起きます。ブラウザは通信側の宣言を優先するため、HTMLだけ直しても直らないことがあります。2026年9月時点では、新しく作るサイトはUTF-8に統一するのが一般的です。 ・メール：日本語メールは長らくISO-2022-JPが使われてきました。送信側と受信側のソフトの設定や世代が違うと、本文や件名がずれて表示されることがあります。 ・CSVファイル：表計算ソフトは、ファイルの中身から文字コードを推測して開こうとします。UTF-8で書き出したファイルを別の表で読まれると化けます。 ・ZIPファイルの中のファイル名：圧縮したパソコンと解凍したパソコンで、ファイル名に使う文字コードの扱いが異なる場合があります。 ・古い機器やシステムからの出力：長年使ってきた業務ソフトやレジ、印刷機などは、当時主流だった文字コードのまま出力していることがあります。 私の見てきた範囲では、作り変え前の古いサイトからテキストを移すときに、この食い違いが表に出やすいと感じています。 ■ 「□」や「〓」だけ出るのは別の原因？ 全体が別の文字列に置き換わっている場合は文字コードの食い違いですが、一部の文字だけが□や〓になる場合は原因が別です。フォントに字形がない、あるいは環境依存文字が変換できていない可能性が高く、対処の仕方も変わります。 文字コードの食い違いの場合: 文章全体、または段落単位でまとめて意味不明な文字列になる。日本語が丸ごと別の記号列に置き換わって見える。元のデータは無事なことが多く、正しい文字コードで読み直せば戻ることがある。 フォントに字形がない場合: 文章はきちんと読めるのに、一部の文字だけが□（豆腐と呼ばれます）や空白になる。これは表示する端末に、その文字の形のデータが入っていないだけで、コピーして別の環境に貼れば正しく表示されることが多い。 環境依存文字の場合: 丸囲み数字、単位記号、髙や﨑といった異体字、絵文字などだけが別の文字や□になる。特定の環境でしか使えない文字を、対応していない環境に送ったときに起きやすい。 変換先に文字がない場合: 「〓」（ゲタ記号）が現れる。変換の途中で該当する文字が見つからず、印の文字で埋められた状態で、元の文字は失われている可能性がある。 見分けの目安は「全体が崩れているか、一部だけか」です。全体なら読み方の問題、一部だけなら文字そのものや表示側の問題、と当たりをつけると原因にたどり着きやすくなります。 ■ 文字化けに出会ったとき、何から試せばいいか 文字化けに気づいたら、まず「化けた状態で上書き保存しない」ことが最優先です。そのうえで、別のソフトで開き直す、文字コードを指定して読み込む、送り手に再送を頼む、という順で試すと、多くの場合は元の文章を取り戻せます。 1. 化けた状態で上書き保存しない。まず元のファイルのコピーを取ります。化けた表示のまま保存すると、置き換わった文字が確定してしまい、戻せなくなることがあります。 2. 別の方法で開き直す。同じファイルを、別のソフトやテキストエディタで開くだけで正しく読めることがあります。ここで読めれば、ファイルは無事だと分かります。 3. CSVは直接開かず、取り込み機能を使う。表計算ソフトの「テキストまたはCSVから」といったデータ取り込み機能で、文字コードをUTF-8などに指定して読み込みます。メニューの名称はソフトやバージョンで異なります。 4. メールは送り手に依頼する。本文をテキスト形式で再送してもらう、または内容を別の方法（共有ファイルなど）で受け取るほうが早いことがあります。 5. 自社サイトのページが化けたら、制作した方にHTML側とサーバー側の文字コード設定の両方を確認してもらう。片方だけの修正では直らない場合があります。なお、ブラウザの表示は端末やバージョンで異なり、手動で文字コードを切り替える機能は現在のブラウザでは用意されていないことが多いです。 当社では、サイトを一からソースコードを書いて作るときに、文字コードの宣言をサーバー側の設定まで含めて揃えるようにしています。古いサイトを作り変える際に気になる点があれば、お気軽にご相談ください。 ■ よくある質問 Q. メールの本文は読めるのに、件名だけ文字化けするのはなぜですか？ A. 件名は本文とは別の方式で符号化されているためです。メールの件名は英数字しか通せない仕組みを前提に、日本語をMIMEエンコードという方式で英数字の並びに変換して送ります。受け取ったソフトがその宣言を解釈できないと、件名だけが「=?ISO-2022-JP?B?...」のような文字列や別の文字で表示されます。本文が読めて件名だけ崩れる場合は、この段階の食い違いを疑うと見当がつきやすいと思っています。 Q. 表計算ソフトでCSVを開くと化けるのに、メモ帳では読めるのはなぜ？ A. 表計算ソフトがCSVを開くとき、どの文字コードで書かれたファイルかを自動で判断しようとするためです。日本語環境ではShift_JIS系を前提に読む動作が残っている場合があり、UTF-8で書き出されたファイルと食い違うと化けます。ファイル先頭にBOMという「これはUTF-8です」という短い印が入っていると正しく開けることが多く、入っていない場合は、ファイルを直接開かずにデータの取り込み機能から文字コードを指定して読み込む方法が確実です。画面の名称はソフトのバージョンで異なります。 Q. 一度文字化けしたファイルは、元の文字に戻せますか？ A. 元のデータ（保存されているバイト列）が残っていれば、正しい文字コードで読み直すことで戻せる場合が多いです。一方、化けた状態で上書き保存したり、読めない文字が「」や「〓」に置き換わった状態で保存されたりすると、元の情報が失われて戻せなくなることがあります。文字化けに気づいたら、まず上書き保存をせず、元のファイルのコピーを取ってから作業するのが安全だと考えています。 Q. 自社サイトの一部のページだけ文字化けする場合、どこを疑えばいい？ A. 多くの場合、HTMLに書かれた文字コードの宣言と、サーバーが返す通信上の宣言が食い違っていることが原因です。ブラウザは通信上の宣言を優先するため、HTML側だけを直しても直らないことがあります。制作を担当した方に、HTMLのmeta charsetとサーバー側の設定の両方を確認してもらうのが早道です。古いページを部分的に作り変えるときは、新旧のページで文字コードが混在していないかも合わせて見ておくと安心です。