文字化け修復 (壊れた UTF-8 を修復)
テキスト
文字化け（mojibake）は、UTF-8 バイトを単一バイトエンコーディング — ほぼ常にレガシー Windows の既定である Windows-1252 — として誤って読んだときに生じる壊れたテキストです。é は é に、丸いアポストロフィは ’ に、ノーブレークスペースは  に、絵文字は 😀 のような 4 つの妙な文字になります。本ツールはそれを逆転します：各文字を元の Windows-1252 バイトに再エンコードし、そのバイトを UTF-8 として復号して元のテキストを復元します。二重に壊れたテキストには修復を繰り返し適用し、設計上安全です — 正しくエンコードされたテキスト（非ラテン文字を含む）は逆変換すると有効な UTF-8 にならないため、壊さずそのまま残します。壊れたテキストを貼り付け、修復版をコピーしてください。すべてローカルで動作し、アップロードされません。
—
修復済み · 1 回のパスで修復
Windows-1252 として誤復号された UTF-8 を戻します。正しいテキスト（どの文字でも）は有効と判定されそのまま残ります。
使い方
- 壊れたテキストを貼り付け。
- 修復された出力を読みます — 何回のパスが必要だったか、または修復不要だったかが表示されます。
- 修正されたテキストをコピー。
よくある質問
- 文字化けの原因は？
- UTF-8 で保存されたテキストを後で別の単一バイトエンコーディング — 多くは Windows-1252 や ISO-8859-1 — で読んだときに起きます。各非 ASCII 文字は 2 つ以上の UTF-8 バイトで保存され、それを 1 バイトずつ読むと誤った文字になります：é（2 バイト）は 2 文字 é として現れます。CSV インポート、データベース移行、エンコーディングが異なるシステム間のコピペが典型です。
- すでに正しいテキストを壊しますか？
- いいえ。修復は逆変換したバイトが有効な UTF-8 になるときのみ成功し、本物の文字化けはそうなりますが正しくエンコードされたテキストはなりません。だから既に正しい 'café'、'Köln'、'한국어'、'日本語' は有効と判定されそのまま残り、修復不要と報告されます。
- なぜ時々 2 回以上パスを適用しますか？
- テキストが二重に誤復号された場合 — 例えば UTF-8 を Windows-1252 で読み保存し、再び Windows-1252 で読むと — 化けが重なります。ツールはテキストが変化しなくなるか有効な UTF-8 に戻らなくなるまで修復を繰り返し、何回パスを使ったか伝えます。
- テキストが直りませんでした — なぜ？
- テキストがすでに正しいか、破損が一般的な UTF-8-を-Windows-1252-で読んだ種類でないためです（例：Shift_JIS や EUC-KR で誤復号された、またはバイトが実際に失われた）。本ツールは最も頻繁なケースを対象とします。特定のレガシーエンコーディングでファイルを開くには、テキストエンコーディング変換ツールを使ってください。
関連ツール
Markdown テーブル → CSV 変換
GitHub 形式の Markdown テーブルを CSV、TSV、セミコロン区切りの行に変換します。ブラウザ上で動作します。
テキスト00
Markdown テーブル生成
CSV・TSV・パイプ区切りデータを整列された GitHub 風 Markdown テーブルに変換。
テキスト00
テキスト Diff ビューア
2 つのテキストを行 / 単語単位で比較し、追加・削除をハイライト。
テキスト00
Lorem Ipsum ジェネレーター
段落・文・単語の単位でダミーテキストを生成。
テキスト00
大文字・小文字変換
大文字・小文字・Title・camelCase・snake_case などに変換。
テキスト00
文字数・単語数カウンター
文字・単語・文・行・バイト数をリアルタイムで数えます。
テキスト00