Shift-JIS / UTF-8 文字化け解読：実はもうちょっと読めるかも

文字化け、それは一昔前のパソコンにおいて情報交換でよく起こる不具合である。近年になってからは Unicode（だいたい UTF-8）がネット上の文字コードの事実上の標準になっており、意図しないで発生する文字化けはほとんどみられなくなった。今では、よくみられる文字化けはほぼ創作でホラー要素、謎解き、あるいは隠しメッセージとして登場している。その中に、最もよく使われている文字化けの種類は「Shift-JiS / UTF-8」による文字化けで、いわゆる「繝繧」とか糸へんの漢字がいっぱい入ってるのやつ。この記事は、「Shift-JiS / UTF-8」による文字化けを既存ツールよりはもうちょっと解読できる方法を解説します。

どれくらい解読できる？

まず実際の解読例を見てみましょう。

この例の通り、既存のツールで解読した「?」の部分に入りそうな文字の候補を提示してくれるのが今回のツールです。では、いったいどうやって候補を検出できるのかを解説していこう。

文字コードの前提知識

細かい仕組みに踏み入る前に、まずは今回扱う2種類の文字コード、Shift-JIS と UTF-8 の構造を少し見てみよう。

Shift-JIS は相対的に単純で、一文字は１バイトもしくは２バイトで構成して、それぞれで使える値の範囲が限られている。次の表の通り、１ビットは必ず 0x00–0x1F 0x20–0x27 0xA1–0xDF のどれかで、２バイトの場合は、１バイト目は 0x81–0x9F 0xE0–0xFC で、２バイト目は 0x40–0x9E 0x9F–0xFC に入ることになる。

対して、UTF-8 が対応する範囲がかなり広いので、符号化の体系もより複雑になっている。U+0000 から U+10FFFF までの約 111 万の符号位置を表す必要があるため、UTF-8 が使用するバイト幅が１バイトから４バイトまでになる。

パターン的に、１バイトから４バイトの構成ではそれそれ先頭のビットは確定されている。

実際に解読する

Shift-JIS でエンコードされた文字列を UTF-8 でデコードすると、対応する文字が見つからない場合があり、それが文字化けの原因となる。先の例文を使って実際エンコードするとこうなります。

上の表の�の部分は、データを Shift-JIS として解読する時にデータに対応する文字が見つからないため、仮に置かれるプレースホルダーである。元データと照らし合わせると、「テ」「の」「例」に対応するデータの一部が復元できないことがわかる。このため、一般の文字化け解読ツールは「�キスト��」までしか解読できない。

ただし、この場合で失ったデータは１文字ごとに１バイトだけ、残った部分はまだ解読のヒントになれるはず。いくつかの仮定を立てて、この表をより細かく分けてみよう。

仮定その１：元データは有効な UTF-8 データ

タイトルに書いた通り、当然元データは UTF-8 でなかったり、改変したりすると、そもそも大前提が成り立たない。この仮定のもとに、復元できない部分を UTF-8 の先頭ビット規則に当てはまると、実際に失われたデータはこの場合 8 ビットずつではなく 6 ビットずつになる。

1 ビット、つまり二進数の一桁は 0 か 1 の二通りで構成するから、6 ビットの組み合わせは 2⁶ = 64 通りになる。これで無限にある可能性から一文字分 64 個の候補に絞られます。

この仮定で絞られた候補はこちら：

つまり、今のところの解読予想はこうである

仮定その２：元の文字列は日本語である

さっきの仮定で 64 個の候補に絞られたが、並べるとまだ多すぎる気がする。ここで2つ目の仮定の登場です。原理的に UTF-8 でエンコードされたデータが Shift-JIS でデコードするだけだから、どんな言語でもできるが、「そもそも日本語じゃないと Shift-JIS で化ける必要なくない」と思っちゃうから、ここで原文が日本語であることを仮定する。

上のリストに「ㅮ」や「侦」など日本語じゃほぼ絶対使わない文字が散見するが、文字単位で十分な言語判定はできないから、ここで大まかに Shift-JIS に符号化できる文字のみを「日本語」とします。

この条件で絞られた候補は以下のとおりである。かなり少なくなったね。

仮定その３：化け戻すとデータはロストしなければならない

タイトルはちょっと回りくどいが、まず以下の例を見てみよう。一文字目の候補の「ム」と「メ」の2文字に注目して、それぞれが当てはまる場合再び文字化けをする時の結果を求めよう。

一文字目に「ム」を代入して予想の原文を化け直すと最初から解読したい文字列に一致する結果が得られるが、「メ」の場合は化け直す文字列に�が含まれていない。つまり、背理法 （?）によって「メ」は一文字目ではないことが証明できる。この方法で全ての候補を化け直してチェックすると、候補をさらに絞られます。

これで５文字目が「の」であることを確定できました。

仮定その４：難しい漢字は使わない（任意）

さっきの候補はすでにかなり絞られたが、中にはまだ「侈」や「侊」など普通じゃ読めない漢字がかなり残っている。解読したい文字列の出自にもよるが、難読漢字は出ない場合は多いだろうと仮定する。ここは上の候補の中にある漢字を JIS 第一水準漢字に絞ると、こうしてさらに候補を減らせる。

当然、自信があれば常用漢字や教育漢字などの文字集合に絞るのもありです。

補足：１バイトと２バイト⸺デコーダ仕様の違い

最後に補足したいのは、文字化けはツール（デコーダ）の仕様によって結果はかならず同じではないこと。私はいろんな文字化けツールを試している中、一つ面白いことが気付いた。それは、ツールによっては同じ文章でも、文字化けにすると違う結果が出て、それぞれデコードできないデータの処理方法が違うことである。ここでデコーダをその仕様で「１バイト類」と「２バイト類」に分ける。

「１バイト類」のデコーダは解読できないデータを見つけたら、１バイト飛ばして次から解読するものである。例えば、「E3 83 86 E3 82 AD」をデコードするときはこういう風になる：

対して、「２バイト類」のデコーダは解読できないデータを見つけたら、解読できない部分をまとめて飛ばすものである。例えば、同じく「E3 83 86 E3 82 AD」をデコードするときはこういう風になる：

このため、デコーダによっては、�が１バイトを意味する時があるし、２バイトを意味する時もある。冒頭にあるツールで「?」は１バイトを意味するため、�を１バイトや２バイトに変換するボタンを用意した。片方が解読できなかったら、もう一方も試してみよう。

これからさらに絞りたいなら、たぶん文脈で頑張るしかないかなと思う。この方法で、最初の無限にある選択肢からかなり限られたオプションに絞られて、文脈で当てる難易度も結構下げたと思う。

もしこの先にまたどこかで文字化けを解読したい時があったら、この記事・ツールが役に立つことができたらとても嬉しいです。ではまた。