文字コード修正ツール — 文字化け（mojibake）をオンラインで無料修復
文字化け（mojibake）を修復します。元のエンコーディングを自動検出して UTF-8 に変換。Shift_JIS、GBK、EUC-JP、Latin-1 の誤認解釈に対応。100% ローカル処理、サーバー送信ゼロ。
Mojibake — 誤った文字エンコーディングによって生じる文字化け — は、ソフトウェア史上最も厄介で根強いバグの一つです。日本の銀行からエクスポートした CSV を Excel で開くと、意味不明なアクセント付き欧州文字の羅列に見えます。中国語 Windows 環境で保存した README を Linux で開くと「?」や豆腐文字が現れます。旧式システムのデータベースダンプは、あらゆるモダンエディタで読めない文字列を吐き出します。根本原因は常に同じです — あるエンコーディング（多くは UTF-8）で書き込まれたバイト列が、別のエンコーディング（多くはシステムの旧式コードページ）で読み取られているのです。文字コード修正ツールは、文字化けテキストに含まれるバイトパターンから元のエンコーディングを最も高い確度で推定し、出力側で正しい UTF-8 を再構築します。
本ツールは 2 つのモードで動作します。自動検出は入力のバイトパターンを走査して、UTF-8、Shift_JIS、EUC-JP、GBK、ISO-8859-1 の 5 種類のエンコーディングとの照合を行い、もっとも信頼度の高い修復を適用します。手動ペアモードは明示的な制御を提供します — あなたの mojibake シナリオに対応するエンコーディングの組み合わせを直接選んでください。最初のオプション「UTF-8 を Latin-1 としてデコード」は、もっともよく発生するケース — 西ヨーロッパ系アプリで開かれてしまった UTF-8 テキストで、マルチバイト UTF-8 シーケンスの各バイトが個別のアクセント付き Latin 文字に化けたもの — を修復します。この 1 つのペアが、世に出回る mojibake 報告の大半を占めています。
プライバシーへの取り組みは明快です：TextEncoder と TextDecoder API はあなたのブラウザ内で動作します。文字化けしたテキストは textarea から読み出され、元エンコーディングでバイト列に再エンコードされ、目的のエンコーディングで UTF-8 にデコードされます。データが外部サーバーへ送られることはありません。これは重要なポイントです。なぜなら、文字化けするテキストは機密性の高い情報源 — 銀行取引明細、診療記録、法律文書 — に由来することが多く、サーバー型の変換サービスに送信すれば第三者へ内容を曝すことになるからです。ブラウザ内ローカルでの処理は、構造そのものによってプライバシーを保証します。
使い方
文字化けしたテキストを貼り付ける
間違った文字として表示されているテキストを貼り付けます — つまり、アクセント付き Latin 文字が現れているけれど本来は日本語・中国語・韓国語であるべき部分です。これは「mojibake（文字化け）」と呼ばれ、ある文字セットでエンコードされたテキストが別の文字セットでデコード・表示された状態です。
修復モードを選ぶ
自動検出は入力のバイトパターンを走査し、代表的なエンコーディング（UTF-8、Shift_JIS、EUC-JP、GBK、ISO-8859-1）の特徴と照合して、最も一般的と思われる修復を適用します。手動ペアでは具体的なエンコーディングの組み合わせを選べます — たとえば「UTF-8 を Latin-1 として解釈された場合」は、UTF-8 のバイト列が Windows-1252 として読み取られたケースを修正します。
修復後のテキストをコピー
自動検出が成功すれば、出力には正しい文字が表示されるはずです。もし正しくない場合は、手動ペアのオプションを順番に試してください。最も多い mojibake ケース — UTF-8 テキストが Latin-1 として開かれた場合 — が最初のペアで、テキスト化けの大多数をこれで修復できます。
よくある質問
mojibake とは何ですか？
Mojibake（æ–¾å–ã、文字通り「character transformation」）は、あるエンコーディングのバイト列を別のエンコーディングとして解釈してしまうことで生じる文字化けです。典型例は次のとおり：UTF-8 で保存された日本語テキストはマルチバイト列を生成します。このバイト列を Latin-1（1 バイト = 1 文字）として解釈すると、マルチバイト列の各バイトが個別のアクセント付き文字になり、「日本èª」（Nihongo）が「æâ¥Ã¦Å¬Ã¨Âª」のように化けてしまいます。
どのエンコーディングを検出できますか？
自動検出は UTF-8、Shift_JIS（日本語）、EUC-JP（日本語 Unix）、GBK（簡体字中国語）、ISO-8859-1（西ヨーロッパ）のバイトパターンをチェックします。手動ペアモードはよくある誤認解釈パターンを網羅しています：UTF-8 を Latin-1 として解釈、Shift_JIS を Latin-1 として解釈、GBK を Latin-1 として解釈、EUC-JP を Latin-1 として解釈、そして Latin-1 と UTF-8 の往復変換です。
なぜこのようなことが起きるのですか？
最も多いシナリオは次のとおりです：日本や中国のアプリケーションが出力した CSV ファイルは UTF-8 で保存されますが、受け手の Excel はシステムのレガシーエンコーディング（英語環境では Windows-1252、日本語環境では Shift_JIS）で開きます。Excel は UTF-8 の各バイトを誤ったエンコーディングの 1 文字として扱うため、文字化けが生じます。修正は、この誤った解釈処理を逆向きに行って元のテキストを再構築します。
あらゆる文字化けを修復できますか？
元となるバイト列が完全に残っている場合に限ります。一部のエンコーディング変換は情報を失います — 変換先エンコーディングの文字集合に含まれない文字は `?` に置換されるか完全に削除されます。本ツールが復元できるのは、元のエンコーディングのバイトが 1 バイト残らず保持されているテキストだけです。失われたデータは恒久的なものであり、いかなるツールでも復元できません。
複数言語が混在するテキストにも対応していますか？
自動検出は統計的なヒューリスティクスに基づいており、単一言語のテキストで最も精度が高くなります。複数言語が混在するテキスト（例：中国語の文字に英語のコメントが添えられているようなケース）は検出器を混乱させる可能性があります。そうしたケースでは手動ペアの選択肢を試してください — 非英語部分に対応する正しいエンコーディングを選べば、通常はテキスト全体を修復できます。
制限事項
- エンコーディング欠落からの復元不可以前のエンコーディング変換で文字が `?` に置換されたり削除されたりしていた場合、その情報は永久に失われています。本ツールはエンコーディングの誤認解釈を逆転できるだけであり、切り詰めや置換による欠落を回復することはできません。
- ヒューリスティック検出自動検出はバイトパターンのヒューリスティクスに依存するため、誤判定の可能性があります。特に短いテキスト（50 文字未満）や言語が複雑に入り混じっている場合に顕著です。手動ペアの選択は決定論的なフォールバックを提供します。
- EBCDIC やエキゾチックなエンコーディングは非対応本ツールは Web とデスクトップで最も一般的なエンコーディングを扱います。メインフレーム系の EBCDIC、ISO-2022-JP のようなマイナーな CJK 変種、アラビア文字やインド系文字のエンコーディングなどは対象外です。
プラットフォーム別の注意点
- macOS
- macOS は多くのアプリでネイティブに UTF-8 を使用しますが、Terminal.app や旧式の Carbon アプリでは依然として MacRoman がデフォルトになることがあります。本ツールは Latin-1 の誤認解釈を扱えるため、macOS と Windows 間で発生する最も多いエンコーディング不一致に対応できます。
- Windows
- Windows は mojibake の多発環境です。多くのアプリケーションが UTF-8 ではなく、システム ANSI コードページ（西側では Windows-1252、日本では Shift_JIS、中国では GBK、韓国では EUC-KR）をデフォルトにしているためです。
- Linux
- Linux システムはほぼ例外なく UTF-8 をデフォルトとしますが、Windows システムや、ロケールに応じてデフォルトが EUC-JP・ISO-8859-1 になっている旧式 Unix サーバーから転送されたファイルでは mojibake が発生することがあります。CLI での代替は `iconv` コマンドです：`iconv -f shift_jis -t utf-8 file.txt`。
- Web
- 完全にブラウザ内で動作します。テキストデータがサーバーに送信されることはありません。検出器と変換器にはブラウザ標準の TextEncoder / TextDecoder API が使われています。