ログに 0xE3 0x80 0x80 と出てきたが、これは何の文字なのか。 00a0 や 0xe2 0x80 0x8b と書かれていても、見た目では空白にしか見えない。 バイト列が壊れていると言われても、どこで壊れたのかが分からない。 16進のUTF-8バイト列を貼ると、文字とコードポイント（U+XXXX）に直し、不正な箇所は何バイト目で壊れたかまで示します。逆に文字を入れると、UTF-8 と UTF-16BE のバイト列にもなります。
使い方
- 上の欄に、16進のバイト列を貼ります。
0xE3 0x80 0x80、\xE3\x80\x80、%E3%80%80、<0xE3><0x80><0x80>、E3 80 80、E38080のどれでも読み取れます。 - 区切りはスペース、カンマ、改行のいずれでも構いません。全角の数字や英字で貼っても半角に直します。
- 変換結果の欄に文字が並び、その下の表にバイトごとの内訳が出ます。全角スペースや NBSP のように見えない文字は、名前が出ます。
ここまでがバイト列から文字への変換です。
- 逆向きは下の欄に文字を入れます。UTF-8 と UTF-16BE のバイト列が出るので、出力形式（スペース区切り、0x 付き、
\x付き、%エンコード、<0x..>、連続）を選んでコピーしてください。
不正なバイト列は、表の該当行が赤字になります。変換結果にはその箇所が � で入ります。
仕組み・計算式
UTF-8 の仕様は RFC 3629 です。文字（コードポイント）によって 1〜4 バイトに分かれます。
- U+0000〜U+007F: 1バイト（0xxxxxxx）
- U+0080〜U+07FF: 2バイト（110xxxxx 10xxxxxx）
- U+0800〜U+FFFF: 3バイト（1110xxxx 10xxxxxx 10xxxxxx）
- U+10000〜U+10FFFF: 4バイト（11110xxx 10xxxxxx 10xxxxxx 10xxxxxx）
先頭バイトの上位ビットで長さが決まり、2バイト目以降は必ず 10 で始まる継続バイト（0x80〜0xBF）です。x の部分をつなげた数値がコードポイントになります。
不正かどうかの判定は、The Unicode Standard の UTF-8 の整形式バイト列の表（Table 3-7）に合わせています。具体的には次のとおりです。
- 0xC0 と 0xC1 は使えない（1バイトで書ける文字を2バイトで書く「過長表現」になるため）
- 0xE0 の次は 0xA0〜0xBF、0xF0 の次は 0x90〜0xBF に限る（同じく過長表現を防ぐ）
- 0xED の次は 0x80〜0x9F に限る（U+D800〜U+DFFF のサロゲート範囲を除く）
- 0xF4 の次は 0x80〜0x8F に限る。0xF5 以上は使えない（U+10FFFF を超える）
不正なバイトの後ろは、WHATWG の Encoding Standard が定める「最大部分列ごとに1つの � に置き換える」方式で読み進めます。ブラウザの TextDecoder と同じ区切り方です。
UTF-16 は、U+FFFF までは16ビット1つ、それを超える文字は上位サロゲート（D800〜DBFF）と下位サロゲート（DC00〜DFFF）の2つで表します。このツールの UTF-16 欄は、上位バイトを先に書くビッグエンディアン（BE）です。
計算例
画面の値は、script.js の関数をそのまま node で動かして出した結果です。0xE3 0x80 0x80 だけは手でも確かめました。
例1: 0xE3 0x80 0x80
入力は 0xE3 0x80 0x80。結果は U+3000、全角スペースでした。手計算では、0xE3 の下位4ビットが 0011、0x80 と 0x80 の下位6ビットがどちらも 000000 なので、0011 000000 000000 で 0x3000 になります。<0xE3><0x80><0x80> の形で貼っても、E38080 と詰めて貼っても、同じ結果です。
例2: 見えない文字
C2 A0 は U+00A0 の NBSP、E2 80 8B は U+200B のZWSP（幅ゼロの空白）、EF BB BF は U+FEFF の BOM と表示されました。コードに紛れ込んだ見えない文字を探すとき、ここが出番です。
例3: 文字からバイト列へ
「あ」は UTF-8 で E3 81 82、UTF-16BE で 30 42。「😀」は UTF-8 で F0 9F 98 80、UTF-16BE では D8 3D DE 00 の4バイトになりました。同じ文字でもバイト数が違いますよね。
例4（境界値）: 壊れたバイト列
E3 81 と入れると、「3 バイト目で破損」と出ます。0xE3 は3バイトの文字の先頭なのに、データが2バイトで終わっているためです（途中切れ）。
ED A0 80 は、2バイト目で破損でした。U+D800 に当たるサロゲートで、UTF-8 では表せません。さらに A0 と 80 が単独の継続バイトとして続き、合計3件のエラーになります。C0 AF は先頭の C0 が過長表現で、AF が単独の継続バイトです。
正直なところ、1つ壊れると後ろまで連鎖して見えるのは意外でした。ランダムな1〜4バイトの列を20万通り、ブラウザ組み込みの TextDecoder と比べたところ、正しいかどうかの判定も � の位置も一致しました。
よくある間違い
1. 0xE3 だけで文字だと思ってしまう
0xE3 は文字ではなく、3バイト文字の「先頭バイト」です。0xE3 0x80 0x80 の3つで1文字（全角スペース）になります。ログの一部だけを切り出すと、先頭バイトだけが残って壊れた表示になります。
2. UTF-8 の E3 81 82 と UTF-16 の 30 42 を取り違える
どちらも「あ」ですが、バイト列は別物です。検索で出てきた16進が、UTF-8 なのか UTF-16 なのか、まず確かめてください。ASCII の範囲だけなら、UTF-16 は 00 41 のように0が混じるので見分けがつきます。
3. 継続バイトを先頭から読み始める
0x80〜0xBF で始まるデータは、UTF-8 の文字の途中から切り出したものです。ファイルの途中から読んだ、固定長で切った、といった原因が多いです。前後のバイトを足してから貼り直してみてください。
よくある質問
Q. 00a0 や U+00A0 は、入力欄にそのまま入れてよいですか？
A. バイト列として読むので、00 a0 は 0x00 と 0xA0 の2バイトになります。0xA0 は単独の継続バイトなのでエラーです。U+00A0 の UTF-8 は C2 A0 で、下の「文字 → バイト列」に NBSP を入れると確かめられます。
Q. 桁が奇数だとエラーになるのはなぜですか？
A. 1バイトは16進2桁です。E38 のように奇数桁だと、区切りの位置が決まらないため、エラーにしています。0x8 と書かれている場合は 0x08 に直してから貼ってください。
Q. BOM が付いた文字列はどう見えますか？
A. EF BB BF は U+FEFF として表に出て、名前は「BOM」になります。変換結果の欄には、見えない文字として先頭に入ります。
Q. 長いバイト列も貼れますか？
A. 貼れます。変換結果の欄にはすべて出ますが、内訳の表は先頭300件までです。壊れた箇所を探したいときは、疑わしい部分だけを切り出して貼ると見やすくなります。
関連ツール
最終更新・根拠の確認日: 2026-10-12 · カテゴリ: テキスト