文字化け変換・自動修復ツール|UTF-8/Shift_JIS/EUC-JP対応

文字化けした文字列を貼り付けるだけで、原因のエンコーディングを自動判定し正しい文字に変換・修復します。UTF-8・Shift_JIS・EUC-JP・JIS(ISO-2022-JP)間の相互変換にも対応、登録不要・無料ですぐ使えます。

文字化け変換ツールとは

文字化けは、テキストを保存したときの文字コードと、それを読み込む側が想定している文字コードが食い違ったときに起こります。このツールは、化けた文字列を貼り付けるだけで、想定される組み合わせを総当たりで試し、日本語として自然に読める候補を上位から並べます。どの文字コードで化けたのか分からない状態からでも復元を試せるのが特徴です。

注意したいのは、すべての文字化けが直せるわけではないという点です。文字として読み込まれた時点で元のバイト列が失われている場合、文字列だけを手がかりにした復元は原理的にできません。「?」や「�」が並んでいる箇所はこれに該当します。組み合わせが分かっている場合は「明示的な変換」タブを使うと、総当たりを経ずに一度で変換できます。

文字化けを直す手順

  1. 化けた文字列を貼り付ける 「文字化け自動修復」タブの入力欄へ、化けたテキストをそのまま貼り付けます。入力内容は外部へ送信されません。
  2. 修復候補を確認する 考えられる組み合わせを総当たりで試した結果が並びます。「最有力候補」バッジが付いたものから確認してください。
  3. 候補が出ないときは明示的に指定する 「明示的な変換」タブで、化けて見えている文字コードと本来の文字コードを選ぶと、その組み合わせだけで変換できます。
  4. 直らない場合は元データに戻る 文字列から復元できないときは、元のファイルをテキストエディタで文字コードを指定して開き直すほうが確実です。

使いこなすためのヒント

  • 修復候補が複数表示された場合、通常は最も自然な日本語になっている「最有力候補」バッジ付きのものが正解です。
  • メールソフトやCSVファイルの文字化けでよく見られる「縺薙繧薙?...」のような文字列は、UTF-8→Shift_JISの組み合わせで解決することがほとんどです。
  • 「?」や「�」の連続に化けている場合は、元のバイト列の一部が失われている可能性が高く、文字列だけからの完全な復元は難しくなります。
  • 明示的な変換タブでは、修復したいエンコーディングの組み合わせがわかっている場合にワンステップで変換結果を確認できます。

文字化け変換の活用シーン

受け取ったCSVが読めないとき

取引先から届いたCSVを表計算ソフトで開いて化けた場合、セルの中身をここへ貼れば本来の文字を確認できます。作り直しを依頼する前の切り分けに使えます。

メールの件名や本文が化けたとき

古いメールソフトから届いた文面が読めない場合に復元できます。差出人へ問い合わせずに内容を把握できることがあります。

ログやデータベースの中身を読む

文字コードの設定がずれたまま蓄積されたログやレコードを確認するときに、該当箇所だけを取り出して復元できます。

文字コードの違いを確かめる

「明示的な変換」タブで同じ文字列を複数の組み合わせに通すと、どの想定違いがどんな化け方になるのかを実際に確認できます。

文字コードに関する用語

UTF-8
世界中の文字を扱える現在の標準的な文字コードです。日本語1文字を3バイトで表すことが多く、Webページの大半がこの方式を使っています。
Shift_JIS
日本語向けに作られた文字コードで、日本語1文字を2バイトで表します。国内の古いシステムやWindows向けアプリで今も使われています。
EUC-JP
主にUNIX系の環境で使われてきた日本語の文字コードです。Shift_JISとはバイトの割り当てが異なるため、取り違えると文字化けします。
JIS (ISO-2022-JP)
電子メールで長く使われてきた日本語の文字コードです。特定の記号列で文字集合を切り替えながら文字を表現します。
エンコーディング
文字をバイト列へ変換する規則のことです。保存側と読み込み側でこの規則が一致していないと文字化けが起こります。
不可逆な文字化け
読み込みの時点で元のバイト列が失われ、文字列からは戻せなくなった状態を指します。「?」や「�」に置き換わっている箇所が該当します。

よくある質問

テキストを保存した際のエンコーディング(文字コード)と、それを読み込む側が想定しているエンコーディングが異なる場合に発生します。日本語では特にUTF-8・Shift_JIS・EUC-JPの3種類が混在しやすく、これらの想定違いが文字化けの主な原因です。

いいえ。文字化けの種類によっては、元のバイト列の情報がデコード時点で失われてしまい、文字列だけからは完全に復元できないケースがあります。特に日本語の2バイト文字が別の日本語エンコーディングとして誤読された場合は復元が難しく、「?」や「�」に置き換わっている箇所は基本的に復元不可能です。

現在最も普及している文字コードはUTF-8ですが、日本国内の古いシステム・一部のWindowsアプリケーションは今でもShift_JISを前提にしていることがあります。UTF-8のバイト列は多くの場合Shift_JISとしても有効なバイト列として解釈できてしまうため、情報が失われずに文字化けし、結果として復元も可能になるケースが多いのです。

送信されません。変換処理はすべてブラウザ内のJavaScriptで実行されるため、パスワードや個人情報を含む文字列でも安全にお使いいただけます。
ツールくん

余談ですが ― 「縺薙繧薙?縺ォ縺。縺ッ」はなぜ日本語文字化けの代名詞なのか

日本語の文字化けを検索すると必ず出てくる「縺薙繧薙?縺ォ縺。縺ッ」(本来は「こんにちは」)という文字列は、日本のインターネット利用者の間で一種の文化的アイコンのような存在になっています。これはUTF-8で書かれたテキストを、Shift_JISを前提とするアプリケーション(古いWindowsのメモ帳や一部のレガシーシステムなど)で開いてしまったときに現れる、非常に典型的な文字化けパターンです。

なぜこの組み合わせがこれほど頻発するかというと、UTF-8における日本語1文字分のバイト列(3バイト)を、Shift_JISのデコーダーが2バイト文字として無理やり解釈してしまうためです。偶然にもその大半が有効なShift_JIS文字として解釈可能な範囲に収まってしまうため、エラーにならずに「一見文字化けだが実は元に戻せる」という特殊な状態が生まれます。この性質のおかげで、本ツールのような自動修復が高い確率で成功するのです。

一方で、Shift_JISで書かれた文章をEUC-JP前提で開いてしまうような組み合わせでは、無効なバイト列が生じて情報そのものが失われてしまうことが多く、この場合は文字列レベルでの復元が原理的に不可能になります。日本語の文字コード問題が長年ITエンジニアを悩ませてきた背景には、こうした「復元できる化け方」と「復元できない化け方」が混在しているという事情があります。