メモ帳で開いたら漢字が 譁?ｭ怜喧縺 のように崩れた。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として開くと、「��������」のような置換文字や、中途半端な記号の連続が現れます。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コマンドなどで変換できます。
- 送信元に確認する：それでも直らなければ、送信元に元データを送り直してもらいます。
関連ツールで日々の作業をらくにする
TegaruToolsには、テキストや文字コードまわりの作業を助けるツールがあります。
- 文字数カウントツール：UTF-8でのバイト数も表示されるので、「◯◯バイト以内」の制限チェックに使えます。
- URLエンコード/デコードツール：URLに日本語を含めるときの必須処理。文字コードはUTF-8がベースです。
- Base64変換ツール：バイナリとテキストの変換。メール添付やAPIでよく登場します。
まとめ：「迷ったらUTF-8」で大半は防げる
文字化けの根本原因は、「複数のルールが存在すること」です。いまのWeb・モバイル・APIは、ほぼすべてUTF-8を採用しています。だから、自分が扱う側でつねにUTF-8で保存・送信することを習慣にすれば、文字化けに出会う回数はぐっと減ります。
古いシステムと連携するときだけ、Shift_JISの存在を思い出せば十分。そういう時代になっています。