テキスト ↔ 16進 / 2進変換
テキストを 16 進・2 進・10 進のバイト列に変換し、バイトダンプを復元
ローカル実行
loading…
このツールについて
テキストがどのバイトでできているかを正確に確認できます。このツールはテキストを UTF-8 にエンコードし、16 進・2 進・10 進のバイト値として表示します — 区切り文字、大文字小文字、0x プレフィックスは選択可能です。デコーダーは逆方向を担い、意図的に寛容です。連続した並び(48656c6c6f)、スペース区切りのペア、コロン区切りの MAC アドレス風表記、\x エスケープシーケンスを受け付けます。
エンコードはバイトレベルの UTF-8 なので、マルチバイト文字はメモリ上・通信路上に実在する姿のまま表示されます。é は c3 a9、世 は e4 b8 96、絵文字は 4 バイトです。エンコーディングの不一致、BOM の謎、「なぜこの文字列は見た目より長いのか」問題をデバッグする最速の方法です。
デコードしたバイト列が有効な UTF-8 でない場合は、文字化けを印字する代わりにその旨を伝えます — テキストではなくバイナリデータを見ているという強いヒントです。
よくある質問
- なぜ 1 文字が複数のバイトになるのですか?
- UTF-8 は可変長です。ASCII は 1 バイトのまま、ヨーロッパの文字の多くは 2 バイト、CJK は 3 バイト、絵文字は 4 バイトです。ここで見えるのは、ファイル、HTTP、データベースなど、あらゆる UTF-8 システムがあなたのテキストのために保存する正確なバイト列です。
- デコーダーはどんな入力形式を受け付けますか?
- 16 進は連続した並び、スペース区切りのペア、0x や \x プレフィックス付き、コロン / カンマ区切り。2 進はスペースの有無を問わない 8 ビットのグループ。10 進は区切られたバイト値です。混在した区切り文字やはぐれた空白は自動的に片付けられます。
- なぜデコードで「バイト列が有効な UTF-8 ではない」と言われるのですか?
- そのバイト列が UTF-8 の規則に違反しているためです — たとえば孤立した ff や、リードバイトのない継続バイトです。データはバイナリか、Latin-1 のようなレガシーエンコーディングか、文字の途中で切り詰められたものかもしれません。
- これは xxd の 16 進ダンプと同じですか?
- バイト値は同一です。xxd はそこにオフセットと ASCII の列を追加します。xxd ダンプの 16 進の列を(オフセットの列を除いて)ここに貼り付ければ、問題なくデコードできます。