16進数デコードのガイド：ログのバイトを文字に戻す

デコードが失敗するのは、元のバイトが UTF-8 のテキストではなかったか、コピー時にオフセットや行番号まで含めてしまったかのどちらかです。

16進数はどこから来るのか

サーバがリクエスト本文を16進数でログに残す、キャプチャツールがフィールドを書き出す、データベースにエスケープされた文字列が入っている、同僚からバイト列が送られてくる。用途はさまざまですが、やることは同じです。

文字化けの切り分けにも使えます。壊れた文字を16進数にしてから戻し、保存時・転送時・描画時のどこで壊れたかを確認できます。バイトは変えずに表現だけを変えるので、比較実験に向いています。

各バイトは2桁必要です。空白区切りの3バイトは通りますが、区切りを省いて連続させると1つの大きな数として読まれ、別のバイトになります。区切りは空白でもカンマでもよく、大文字小文字や 0x 接頭辞も問題ありません。

結果に置換文字が多い場合、そのバイト列は正しい UTF-8 ではありません。元データが GBK や Big5、バイナリであるか、多バイト文字を途中で切った可能性があります。再試行を繰り返さず、元の文字コードを確認してください。

デコードはバイトを文字に対応させるだけです。内容の妥当性や長さ、チェックサムは検証しません。途中で切れたログは前半だけ正しく見え、後半が崩れます。これを文字コードの問題と誤解しやすいので注意してください。

テキストでないデータを無理に通さないでください。画像、圧縮ファイル、暗号文は Base64 やバイナリビューアの領域です。また16進数は暗号ではないので、機密項目の「難読化」にはなりません。

出力が疑問符や四角だらけになります

元の文字コードを確認してください。このツールは UTF-8 で解くため、GBK や Big5 の中国語は必ず崩れます。バイナリはそもそもテキストとして解く対象ではありません。

空白や 0x は自分で付ける必要がありますか

不要です。空白とカンマで分割し、0x は無視され、大文字小文字も問いません。大切なのは各バイトを2桁に保ち、ログのオフセットをデータとして貼らないことです。

16進数を暗号として使えますか

使えません。鍵がなく1手で戻せます。パスワードやトークンを16進数にするのは、攻撃者の手間を数秒増やすだけです。暗号化と鍵管理を行ってください。