文字コード変換と文字化け診断

エンコード

読み込み中

ツールを読み込んでいます

ツールを準備しています。残り時間はまだわかりません。

このツールの処理はすべてブラウザー内で行われ、入力内容はサーバーへ送信されません。

このツールについて

従来の UTF-8、UTF-16LE、UTF-16BE とテキスト・16進数・Base64 の変換機能を維持しています。独立した文字化け診断では、貼り付けた Unicode テキストやローカルファイルの元バイトを確認し、入力を保持して根拠のある限定的な候補を表示します。文字コードを確実に判定したり、本来の文章を証明したりするものではありません。

主な用途

既知のテキストを UTF-8 や指定したバイト順の UTF-16 に変換し、従来の変換機能で既知の16進数・Base64 をデコードする。
UTF-8 のバイトが Windows-1252 として読まれた場合など、一度の誤ったデコードを、貼り付け元を変更せずに調べる。
コピー、置換文字、エディターでの保存によってバイトを失う前に、元のローカルファイルを明示的なデコード経路で比較する。
エスケープされた制御文字、BOM の根拠、経路の前提を確認してから、一つの候補を選んで UTF-8 でコピー・保存する。

使い方

1.通常の変換ではエンコード・デコード、UTF-8/UTF-16LE/UTF-16BE、Hex/Base64 を選び、入力して従来の変換を実行します。
2.診断では貼り付けテキストか元のローカルファイルを選び、診断を実行します。テキスト復元は一度の誤デコードを逆向きに検証し、ファイル診断は実際のバイトを明示的な経路でデコードします。保持された入力と根拠を確認してください。
3.候補は固定された経路順で並び、信頼度の百分率や言語による順位は付けません。一つを選んで確認済みにすると、完全な UTF-8 テキストをコピー・保存できます。編集、キャンセル、入力元の変更で古い結果は無効になります。

実行可能な変換・復元例

従来の UTF-8 / Hex 変換

request (ASCII JSON): {"mode":"converter","operation":"encode","encoding":"utf-8","format":"hex","input":"\u4f60\u597d"}

{"output":"E4BDA0E5A5BD"}

従来の変換機能で、この二文字を6バイトの UTF-8 として出力します。

従来の UTF-16BE / Base64 変換

request (ASCII JSON): {"mode":"converter","operation":"encode","encoding":"utf-16be","format":"base64","input":"A\ud83d\ude00"}

{"output":"AEHYPd4A"}

00 41 D8 3D DE 00 は完全なサロゲートペアを含み、バイト順は明示的にビッグエンディアンです。

従来の UTF-16LE / Hex デコード

request (ASCII JSON): {"mode":"converter","operation":"decode","encoding":"utf-16le","format":"hex","input":"41003DD800DE"}

{"output":"A\ud83d\ude00"}

従来のデコード機能で、明示的なリトルエンディアンのバイトから同じテキストを得ます。

二つの経路で同じ候補テキスト

request (ASCII JSON): {"mode":"text","text":"caf\u00c3\u00a9"}

{"candidates":[{"id":"windows-1252-to-utf-8","text":"caf\u00e9","byteRoundTrip":true,"stringRoundTrip":true},{"id":"iso-8859-1-to-utf-8","text":"caf\u00e9","byteRoundTrip":true,"stringRoundTrip":true}],"nativeOptional":true,"otherwise":"unsupported: native decoder unavailable or conformance check failed"}

どちらの単バイト仮説も 63 61 66 C3 A9 を再構成します。同じ結果でも過去のデコード方法は分かりません。ネイティブの Windows-1252 が利用不可・不適合なら明示的に非対応となり、字面どおりの経路は独立しています。

C1 制御文字には字面どおりの経路

request (ASCII JSON): {"mode":"text","text":"\u00e2\u0080\u0099"}

{"candidates":[{"id":"iso-8859-1-to-utf-8","text":"\u2019","byteRoundTrip":true,"stringRoundTrip":true}],"missing":["windows-1252-to-utf-8"]}

字面どおりの E2 80 99 から UTF-8 の引用符を再構成します。Windows-1252 の80は U+20AC なので、U+0080 をそのバイトには戻せません。

中国語の一段階復元の仮説

request (ASCII JSON): {"mode":"text","text":"\u00e4\u00bd\u00a0\u00e5\u00a5\u00bd"}

{"candidates":[{"id":"windows-1252-to-utf-8","text":"\u4f60\u597d","byteRoundTrip":true,"stringRoundTrip":true},{"id":"iso-8859-1-to-utf-8","text":"\u4f60\u597d","byteRoundTrip":true,"stringRoundTrip":true}],"nativeOptional":true,"otherwise":"unsupported: native decoder unavailable or conformance check failed"}

言語の頻度を参照せず、厳密なバイト変換でこの文字列を得ます。入力中の U+00A0 はエスケープ表示します。ネイティブの Windows-1252 が利用不可・不適合なら明示的に非対応となり、字面どおりの経路は独立しています。

疑問符から履歴は復元できない

request (ASCII JSON): {"mode":"text","text":"Order?"}

{"candidates":[{"id":"original-text","text":"Order?","unchanged":true}],"warnings":["question-mark-may-be-original"]}

入力は変わりません。疑問符は意図した文字か過去の置換かもしれませんが、このツールでは区別できません。

既存の U+FFFD はエスケープ表示

request (ASCII JSON): {"mode":"text","text":"bad\ufffd"}

{"candidates":[{"id":"original-text","text":"bad\ufffd","unchanged":true}],"missing":["windows-1252-to-utf-8","iso-8859-1-to-utf-8"],"warnings":["replacement-may-be-original"]}

欠けた文字は作りません。U+FFFD はどちらの単バイト逆変換にも表せず、元テキストを保持します。

対にならないサロゲートを拒否

request (ASCII JSON): {"mode":"text","text":"\ud800"}

{"error":"unpaired-surrogate"}

ASCII JSON で不正な UTF-16 値を安全に表記します。UTF-8 出力で黙って置換する前に診断が拒否します。

双方向文字・改行・NUL の安全な表示

request (ASCII JSON): {"mode":"text","text":"A\u202eB\n\u0000"}

{"candidates":[{"id":"original-text","text":"A\u202eB\n\u0000","unchanged":true}],"preview":"A\\u202EB\\n\\u0000"}

プレビューは印字可能な ASCII だけで、周囲のラベルを並べ替えません。選択した UTF-8 出力には元文字が残り、安全化ではありません。

UTF-8 BOM のコードポイントを保持

request (ASCII JSON): {"mode":"bytes","hex":"EF BB BF 41"}

{"candidates":[{"id":"decode-utf-8","text":"\ufeffA","byteRoundTrip":true}],"bom":"utf-8"}

診断は先頭の U+FEFF を保持します。UTF-8 出力は文字を追加・除去せず EF BB BF 41 になります。

サロゲートペアを含む明示的な UTF-16LE

request (ASCII JSON): {"mode":"bytes","hex":"FF FE 41 00 3D D8 00 DE"}

{"candidates":[{"id":"decode-utf-16le","text":"\ufeffA\ud83d\ude00","byteRoundTrip":true}],"bom":"utf-16le"}

LE 経路は Unicode テキストを再構成し U+FEFF を保持します。診断の保存形式は元の UTF-16 バイトではなく UTF-8 です。

同じテキストを明示的な UTF-16BE で読む

request (ASCII JSON): {"mode":"bytes","hex":"FE FF 00 41 D8 3D DE 00"}

{"candidates":[{"id":"decode-utf-16be","text":"\ufeffA\ud83d\ude00","byteRoundTrip":true}],"bom":"utf-16be"}

BE は LE と別の経路です。成功はその経路の根拠であり、ファイルの履歴の証明ではありません。

不正な UTF-8 経路は失敗

request (ASCII JSON): {"mode":"bytes","hex":"C3 28"}

{"missing":["decode-utf-8"],"invalidAttempts":["decode-utf-8"]}

C3 の後の28は継続バイトではありません。置換して UTF-8 候補を作らず、他の文字コードは独立した仮説として扱います。

奇数バイトの UTF-16 を拒否

request (ASCII JSON): {"mode":"bytes","hex":"41"}

{"missing":["decode-utf-16le","decode-utf-16be"],"invalidAttempts":["decode-utf-16le","decode-utf-16be"]}

1バイトでは UTF-16 コード単位を作れず、両バイト順で失敗します。単バイト文字コードや UTF-8 では妥当な場合があります。

バイト80：ウェブの別名と字面の対応

request (ASCII JSON): {"mode":"bytes","hex":"80"}

{"candidates":[{"id":"decode-windows-1252","text":"\u20ac","byteRoundTrip":true},{"id":"decode-iso-8859-1-literal","text":"\u0080","byteRoundTrip":true}],"nativeOptional":true,"otherwise":"unsupported: native decoder unavailable or conformance check failed"}

Windows-1252 は U+20AC、字面どおりの ISO-8859-1 は C1 制御文字 U+0080 です。WHATWG の ISO-8859-1 別名は Windows-1252 の解釈です。ネイティブの Windows-1252 が利用不可・不適合なら明示的に非対応となり、字面どおりの経路は独立しています。

明示的な WHATWG Shift_JIS の読み取り

request (ASCII JSON): {"mode":"bytes","hex":"82 A0"}

{"candidates":[{"id":"decode-shift_jis","text":"\u3042","byteRoundTrip":null}],"nativeOptional":true,"otherwise":"unsupported: native decoder unavailable or conformance check failed"}

ネイティブの Shift_JIS 経路で読みます。旧来のエンコーダーはないため、バイト往復の根拠は true ではなく null です。ネイティブのデコーダーが使えない、または適合性チェックに通らない場合、この経路は明示的に非対応になります。

明示的な GB18030 の読み取り

request (ASCII JSON): {"mode":"bytes","hex":"D6 D0 CE C4"}

{"candidates":[{"id":"decode-gb18030","text":"\u4e2d\u6587","byteRoundTrip":null}],"nativeOptional":true,"otherwise":"unsupported: native decoder unavailable or conformance check failed"}

この一般的な対応は実行環境のデコーダーを使います。GB18030 の版は固定せず、バイト往復の証明や言語の順位付けは行いません。ネイティブのデコーダーが使えない、または適合性チェックに通らない場合、この経路は明示的に非対応になります。

明示的な WHATWG Big5 の読み取り

request (ASCII JSON): {"mode":"bytes","hex":"A4 A4 A4 E5"}

{"candidates":[{"id":"decode-big5","text":"\u4e2d\u6587","byteRoundTrip":null}],"nativeOptional":true,"otherwise":"unsupported: native decoder unavailable or conformance check failed"}

対応環境ではブラウザーの Big5 対応表を使います。あらゆる歴史的な Big5 実装との一致は保証せず、往復も未検証です。ネイティブのデコーダーが使えない、または適合性チェックに通らない場合、この経路は明示的に非対応になります。

UTF-32 の署名は根拠であり対応ではない

request (ASCII JSON): {"mode":"bytes","hex":"FF FE 00 00 41 00 00 00"}

{"bom":"utf-32le","warnings":["utf32-not-supported"]}

先頭は UTF-32LE の根拠として表示しますが、UTF-32 デコーダーはありません。他の妥当な読みを自動的な UTF-32 復元と考えないでください。

診断結果を安全に読むために

先頭の候補を正解と考えないでください。固定された経路順は信頼度の順位ではありません。
16進数をテキスト復元欄に貼り付けてもバイトとしては扱いません。従来の Hex/Base64 変換か、診断の元ファイル入力を使ってください。
ブラウザーの ISO-8859-1 別名と、明示した字面どおりの ISO-8859-1 経路を混同しないでください。C1 範囲のバイトの解釈が異なります。
UTF-8 や UTF-16 の失敗はその仮説が成立しないことを示します。他の旧来の文字コードで成功しても真の文字コードは証明されません。
先頭の EF BB BF、FF FE、FE FF は BOM の根拠になりますが、バイト順の経路は明確に区別し、診断テキストは U+FEFF を保持します。
対にならないサロゲートは UTF-8 に無損失で出力できません。黙って置換するのではなく、整形式の元データを入手してください。
以下の例は ASCII JSON のエスケープ表記です。画面上の \uXXXX や \n は文字の説明で、実際の制御文字をページに埋め込んでいません。

制限と注意事項

診断結果は仮説であり、確実な文字コード判定ではありません。厳密なデコードや完全な往復の成功は、その経路との整合性だけを示します。複数の経路で妥当な文字列を得ても、元の文字コードや意味は証明できません。逆向きのテキスト復元には、全ての入力文字を仮定した旧来の文字コードのバイトへ戻し、厳密な UTF-8 としてデコードできることが必要です。対応する一段階の経路だけを試し、再帰的な修復、綴りの訂正、翻訳、自動上書きは行いません。
WHATWG TextDecoder の ISO-8859-1、latin1、ascii ラベルは Windows-1252 を指します。別名で明示した字面どおりの ISO-8859-1 経路は、C1 制御文字を含む 00–FF を U+0000–U+00FF に直接対応させ、ブラウザーの別名とは区別します。ファイルの経路は UTF-8、UTF-16LE、UTF-16BE、Windows-1252、字面どおりの ISO-8859-1、Shift_JIS、GB18030、Big5 です。最後の三つは利用可能なネイティブの WHATWG デコーダーのみを使い、旧来のエンコーダーがないためバイト往復は未検証です。Shift_JIS はウェブ互換の対応表、GB18030 の版は実行環境に依存し、Big5 は歴史的な実装と異なる場合があります。UTF-32 はデコードせず、署名の検出は警告に留めます。ネイティブ経路は代表的な適合性チェックも必要で、失敗時は誤解を招く候補を出さず非対応と表示します。
診断の Unicode 経路は不正な UTF-8、奇数バイトの UTF-16、対にならないサロゲートを拒否します。UTF-16LE と UTF-16BE は明示的な仮説で、自動バイト順判定ではありません。先頭の U+FEFF は保持し、EF BB BF、FF FE、FE FF を根拠として扱っても勝手に除去しません。 U+FFFD や疑問符が既に情報の欠落を表している場合、元のバイトはその文字から分かりません。どちらも意図した文字である可能性があり、存在だけでは破損を証明できません。失われた履歴は推測せず、可能なら元ファイルやバックアップを使ってください。
診断は元ファイルで 64 KiB（65,536）バイトまでです。貼り付けは 65,536 UTF-16 コード単位と UTF-8 の64 KiBの両方に収まる必要があります。候補は最大12件、各候補は 65,536 コード単位・262,144 UTF-8 バイトまで。中止可能なワーカーは5秒、ローカルファイル読み込みは15秒でタイムアウトします。上限超過は切り捨てず拒否します。
診断プレビューは非 ASCII、制御、双方向文字をエスケープします。表示は短縮されることがありますが、明示的に選んだ出力には制御文字や U+FEFF を含む候補全体が入ります。安全化処理ではなく、候補を自動適用せず、元ファイルも上書きしません。処理はローカルで行い、入力のアップロードや永続保存はありません。診断のコピー・保存は UTF-8 のみで、旧来の文字コードの書き出しではありません。独立した従来の変換機能は、エンコード後4 MiB、デコード8 MiB、符号化入力16 MiBの上限とバイナリ保存を維持します。

よくある質問

貼り付けテキストの復元とファイルのデコードは何が違いますか？

貼り付けテキストは既にどこかでデコードされています。逆向きの経路は過去の特定の誤りを仮定して文字からバイトを再構成し、厳密な UTF-8 として読みます。元ファイルには実際のバイトがあるため、その過去の段階を仮定せず直接デコードできます。できるだけ元バイトのコピーを残してください。

候補や往復の成功は元の文字コードの証明になりますか？

なりません。ASCII は多くの文字コードで共通し、他のバイト列も複数の経路で読めます。往復は宣言した変換だけを検証します。候補は固定順で、確率の点数、言語の推定、自動的な最適候補はありません。

Windows-1252 と字面どおりの ISO-8859-1 はなぜ違うのですか？

ウェブ互換の ISO-8859-1 は Windows-1252 の別名で、バイト80は U+20AC になります。別途明示した字面どおりの経路では80は U+0080 です。逆変換で誤った対応を仮定すると失敗や別候補につながるため、エスケープ表記と由来を確認してください。

欠けた文字は復元できますか？保存時には何を保持しますか？

その文字だけからは復元できません。異なる入力が同じ置換文字になるため、ここでは欠落した履歴を知る方法がありません。既存の U+FFFD や疑問符は元ファイルの確認を促す警告であり、欠けた内容を復元できる根拠ではありません。診断のデコードは先頭の U+FEFF を黙って除去せず保持します。エスケープ表示は双方向文字や制御文字による周囲の表示への影響を防ぎます。手動で選択・確認した後のコピーやダウンロードは、保持された文字を含む UTF-8 の候補自体です。他のアプリで使う前に確認してください。