文字コードと文字化けの基礎｜UTF-8・Shift_JISの違いを30分で理解

「メモ帳で開いたら文字化けした」「フォームに貼り付けたら表示が崩れた」といったトラブルの背景にある文字コードの仕組みを、できるだけシンプルに解説します。

「メモ帳で開いたら漢字が 譁?ｭ怜喧縺 みたいに崩れた」「CSVを Excel で開いたら表が文字化けで読めない」「フォームに貼り付けたら別の文字に変わった」。こうしたトラブルの原因は、ほとんどの場合 文字コード です。

文字コードはエンジニア以外には縁遠い言葉に聞こえますが、仕組みを少しだけ知っておくと、トラブルを未然に避けられたり、復旧の見当がついたりします。この記事では、UTF-8 と Shift_JIS の違いを中心に、最低限知っておきたい知識を整理します。

文字コードとは — 文字を「数字」で表すルール

コンピューターの中では、すべての情報が 0 と 1 の数値で扱われます。文字も例外ではなく、「あ」「a」「漢」のような1文字ずつに、ユニークな番号（コードポイント）が割り当てられています。

ところが、この「文字 ↔ 番号」の対応ルールには複数の流派があります。たとえば「あ」を表す番号は、ルールによって違います。

Shift_JIS：「あ」 = 0x82A0 （2バイト）
EUC-JP：「あ」 = 0xA4A2 （2バイト）
UTF-8：「あ」 = 0xE38182 （3バイト）

書き手と読み手が違うルールを使うと、同じ番号を別の文字として解釈してしまい、文字化けが起きます。

主要な文字コードと特徴

ASCII — 全ての原点（英数字専用）

1963年に制定された最古の文字コード規格。半角英数字と記号、計128文字だけを 1バイト = 7bit で表現します。日本語は1文字も含まれません。後発の文字コードはほぼ全てASCIIと互換性を保つように設計されています。

Shift_JIS — 昔のWindowsとガラケーの標準

日本語Windowsで長らく標準だった文字コード。ASCIIに含まれる半角文字 (1バイト) と、ひらがな・カタカナ・漢字 (2バイト) を混在できるのが特徴です。Windowsのメモ帳が「ANSI」と呼んでいたのは、実質的にShift_JISのことを指していました。

現代でも、古い基幹システム、CSV出力、メール、ガラケー時代のWebサイトなどで使われ続けています。

EUC-JP — Unix系の標準だった日本語コード

Linux や Unix で標準的に使われていた日本語文字コード。Shift_JIS と並んで日本のWebサイトでも一時期広く使われましたが、現在は UTF-8 に置き換わっています。

UTF-8 — 現在の事実上の標準

Unicode を 可変長（1〜4バイト）で表現する方式。半角英数字は1バイト、日本語は3バイト、絵文字は4バイトです。ASCIIと完全互換で、世界中のあらゆる文字を1つの規格で扱えるため、現在のWeb・モバイル・API通信のほぼ全てがUTF-8です。

TegaruTools の各ツールも内部処理はすべて UTF-8 を前提にしています。

なぜ文字化けが起きるのか

文字化けの原因は、結局のところ「書き手と読み手が違うルールを使っている」だけです。よくあるパターンを4つ紹介します。

パターン1：UTF-8 を Shift_JIS として開いた

例：UTF-8 で書かれた「あいう」を、Shift_JIS だと思って開くと「縺ゅ＞縺・」のような連続した謎の文字列になります。日本語が 縺 や 繧 で始まる謎の文字に化けたら、ほぼこのパターンです。

パターン2：Shift_JIS を UTF-8 として開いた

例：Shift_JIS の日本語ファイルを UTF-8 として開くと、「��」のような置換文字 (replacement character) や、半端な記号の連続が現れます。Webブラウザでよく見る「文字化けマーク（◇に？）」もこの種類です。

パターン3：CSV を Excel で開いたら化ける（BOM問題）

UTF-8 で書かれたCSVファイルを Excel で開くと、Shift_JIS として誤認識され、日本語が化けてしまう有名な問題です。これは Excel が「UTF-8 で保存された目印（BOM）」を期待するためです。

対策：CSV作成時に UTF-8 with BOM で保存する。Google スプレッドシートやプログラムで作る場合、明示的にBOM付きで書き出します。

パターン4：フォームに貼り付けたら別文字に変わる

コピー元（PDFやWebページ）と貼り付け先（フォームやエディタ）の文字コード処理が違うと、特定の記号が別文字に置き換わることがあります。たとえば「全角ハイフン」「波ダッシュ」「マイナス記号」など、似た見た目で別の文字コードを持つ記号が原因のことが多いです。

文字化けを未然に防ぐためのコツ

テキストファイルは UTF-8 で保存する：Windowsのメモ帳でも、保存時に「UTF-8」を選べる。これを習慣にする。
HTML の文字コード宣言を明示：<meta charset="UTF-8"> を入れる。
CSVは UTF-8 with BOM で書き出す：Excelで開くことを想定するなら必須。
外部システム連携時は仕様を確認：基幹システムや古い銀行APIは Shift_JIS のまま運用されていることがある。事前に確認する。
絵文字や旧字体に頼りすぎない：環境によって表示できない・別文字に化けることがある。重要なドキュメントは標準的な文字に絞る。

もし文字化けしてしまったら — 復旧の手順

既に化けてしまったファイルでも、元の文字コードが特定できれば復旧できる場合があります。

元の文字コードを推測：「縺」で始まれば UTF-8 を Shift_JIS と誤認識したパターン、「�」が並ぶなら逆。
テキストエディタで開き直す：VS Code やサクラエディタなど多くのエディタは、開く時に文字コードを指定できます。
変換ツールで再エンコード：オンラインの文字コード判定・変換サービス、または iconv コマンド等で変換可能。
元データの送信元に確認：それでも復旧できない場合、送信元に元データを再送してもらう。

まとめ — 「迷ったらUTF-8」で大半の問題は防げる

文字化けは「複数のルールが存在すること」が根本原因です。現代のWeb・モバイル・API のほぼ全てが UTF-8 を採用しているため、自分が扱う側で 常に UTF-8 で保存・送信する ことを習慣にすれば、文字化けに遭遇する頻度は劇的に減ります。

どうしても古いシステムと連携するときだけ、Shift_JIS の存在を思い出してください。それで十分な時代になっています。