分析と広告のためのCookie
分析と広告のためにCookieを使っており、どちらもGoogleに送られます。拒否しても、目に見える動作は何も変わりません。プライバシーポリシーを読む
コピーしたままの形で 16 進を貼り付けて、その背後にあるテキストを読んでください。区切りは無視するので、ログのダンプもソースコードのカンマ区切りの並びも同じように通ります。妥当な UTF-8 の並びを構成しないものは、「?」に変える代わりにその旨を伝えます。答えが得られるか、誤った答えが得られるかを分けるのがこの違いです。
処理される場所
ファイルがないので、何もアップロードされません。計算はこのページの中で行われます。
順番待ちもアカウントもなし
お使いの機械の速さで答え、あなたが誰かを尋ねることはありません。
何度でも
回数は数えず、上限もありません。もう一度答えることに費用はかからないからです。
空白、コロン、カンマ、改行、そして `0x` の接頭辞は、読む前に取り除かれます。貼り付けるものがパケットキャプチャからでも、OpenSSL の出力からでも、C の配列の定義からでもかまいません。事前に掃除する必要はありません。
問うのは残った桁数です。偶数でなければなりません。1 バイトが 2 桁だからです。奇数の長さは、黙ってゼロで埋めてよい境界の場面ではありません。コピーの途中で何かが失われたという意味であり、だからそれを伝えます。
バイトの並びは、文章と同じくらい容易に PNG や PDF や ZIP でありえます。PNG は `89 50 4e 47` で始まり、PDF は `25 50 44 46`、ZIP は `50 4b` で始まります。それを UTF-8 として読めば、置換文字が出るか、技術的には妥当でも何も意味しない並びが出ます。
結果らしきものを返す代わりに、ここではバイト列がテキストではないことと、何バイトあるかを伝えます。それが役に立つ答えです。存在しない符号化の誤りを探すのをやめさせ、本来の問い——これは実際どんな種類のデータなのか——へ注意を移します。
UTF-8 には、少し慣れれば読める構造があります。`80` 未満のバイトは ASCII で 1 バイト 1 文字。`c2` から `df` のバイトは 2 バイトの並びを開き、`e0` から `ef` は 3 バイト、`f0` から `f4` は 4 バイトを開きます。継続バイトはすべて `80` から `bf` のあいだにあります。
ここから実用的な規則が出ます。ダンプの中の `e3 81` と `e3 82` はほぼ確実にひらがなで、`e3 82` の後半と `e3 83` はカタカナ、`e4` から `e9` で始まる 3 バイトはほぼ漢字です。日本語があるはずの場所でその並びが見えた人は、バイトは正しく、問題は表示の側にあると分かります。
並びが `ef bb bf` で始まっていれば、そこにあるのは UTF-8 の BOM です。目に見えず、内容の一部であり、Excel から書き出した CSV の 1 列目の名前を、読み込むプログラムが認識しないことがある理由です。
同じ印は、別の文字コードでは `fe ff` や `ff fe` になります。その場合は UTF-8 ではなく UTF-16 で、バイト列はここではテキストとして読めません。先頭の `ff fe` に続いて文字のあいだにゼロが並ぶのは、古いバージョンの Windows のメモ帳が書いたファイルの典型的な署名です。
ダンプの中で、読める各バイトのあいだに `00` が現れるなら、文字コードは UTF-8 ではなく UTF-16 です。`48 00 61 00` は下位バイトを先に置く UTF-16 の「Ha」で、同じ文字、別の文字コードです。UTF-8 として読むと、制御文字が挟まったテキストになります。
Windows のレジストリのエクスポート、SQL Server の一部の項目、そして Windows API の Unicode 版を通ったすべてに現れます。バイトが見えれば見分けは容易で、答えだけを吐き出す道具に対するこのページの実際の効用がそこにあります。
妥当な UTF-8 でないものに出会ったとき、黙って Shift_JIS や CP932 で読み直すデコーダーは、たいてい何かを返します。そしてその何かは、バイナリデータならごみであり、実際には UTF-8 のテキストなら見覚えのない漢字の羅列——いわゆる文字化けです。
そうした迂回は、見分けのつく誤りをもっともらしい結果に変えます。2 つの性質のうち悪いほうです。ここに黙った第 2 の文字コードはありません。妥当な UTF-8 であるか、そうでないと知らされて、それが何を意味するかをあなたが決めるかのどちらかです。
よくある理由は、2 つの証明書のフィンガープリントか 2 つのチェックサムを比べていて、片方がコロン付きの大文字で、もう片方が区切りなしの小文字で書かれていることです。バイトは同一で、文字列は同一ではなく、テキストの比較は当然そこに差を指します。
両方をこの欄に通せば、同じバイトかどうかが即座に見えます。同じなら書式の問題でした。違うなら本当に違うのであり、次の問いは美観ではなくセキュリティのものになります。
ファイルとしての出力はありません。バイト列が PNG なら、このページにはそれをダウンロードとして提供するだけの情報があります。それをしないのは、別の仕事であり、しかも何をしているか分かっているべき仕事だからです。出どころの分からないダンプから実行ファイルを組み立てることは、テキストの道具がついでに提供してよい所作ではありません。
文字コードの自動判定もありません。短い入力では信頼できず、しかも肝心なときにちょうど外します。代わりにこのページがするのは、UTF-8 ではないと伝えることです。ではそれが何なのかという判断は、推測の仕組みよりあなたのほうがよく握っています。
ログやパケットキャプチャの 16 進ダンプは、しばしばそのとき送られていたものを含みます。資格情報、セッションキー、氏名の入った実データ。ここではページの中でデコードされるので、当方への提供が起きず、その内容についての第三者提供も委託も生じません。
この種の値では、そこが決め手です。キャプチャは定義上、二度と外へ出したくないものであり、それを他所のサーバーでデコードする道具は、すでにそれを見ています。ネットワークパネルは、ここから何も出ていないことを示します。
いいえ。空白、コロン、カンマ、改行、0x の接頭辞は無視されます。パケットキャプチャのダンプも、ソースコードからコピーしたカンマ区切りの並びも同じように通ります。
バイト列が妥当な UTF-8 の並びを構成しないからです。バイナリデータでは普通のことで、PNG も PDF も ZIP もテキストではありません。結果らしきものを返す代わりに、明示的にそう伝えます。
文字コードが UTF-8 ではなく UTF-16 だということです。Windows のレジストリのエクスポート、SQL Server の一部の項目、Windows API の Unicode 版を通ったものに典型的です。
1 バイトが 16 進 2 桁なので、奇数の長さは何かが欠けているという意味だからです。代わりにゼロを足せば、コピーの失敗をもっともらしい誤った結果に変えてしまいます。
いいえ。このページの中でデコードされます。ダンプでは特に効きます。そのとき送られていたものをそのまま含むことが多いからです。資格情報、セッションキー、実データ。