二重デコードが原因の文字化け

よく見かけるパターンである。同じテキストで前半はなんともないが、後半から文字化けしている。
「プログラム 変換 文字」以後が文字化けしているのはなぜか。このパターンは「まだエンコードされている文字があるぞ」と錯覚させるようなテキストが混入していることが原因である。
LOG
218.227.113.160 - - [12/Jan/2014:23:48:09 0900] "GET #potato#ipc#ipc_0011$html HTTP/1.1" 200 6222
"http://search.yahoo.co.jp/search?p=
プログラム 変換 文字 ††愀†††††††††攀椀†?掬†††††?装?幣††戀†?這攀††?蔓?肘††愀†††?鱗?幣?蔓∀†∀††稀椀††愀††† †††††?肘愀?蔓椀戀†攀†††?鴨†††† † ††圀椀?這††?鱗††一†††††††圀?威圀†††††?幣椀†攀?這?蔓††† †"
このログは次のようになっている。
LOG
218.227.113.160 - - [12/Jan/2014:23:48:09 +0900] "GET #potato#ipc#ipc_0011$html HTTP/1.1" 200 6222
"http://search.yahoo.co.jp/search?p=
%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%A0+%E5%A4%89%E6%8F%9B+%E6%96%87%E5%AD%97%E3%80%80%25e3
&aq=-1&oq=&ei=UTF-8&fr=sb-necctp_sa&x=wrt"
"Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.1; WOW64; Trident/6.0)"
「%E6%96%87%E5%AD%97%E3%80%80%25e3」の部分に問題があることは一目瞭然である。特に末尾の「%25e3」の異常さはすぐに目につく。「%」の後が4文字(他は2文字)、「e3」とこれだけが「e」と小文字になっている(他は大文字)。これが文字化けの原因である。

さて「%E6%96%87%E5%AD%97」は「文字」である。となると、その後の「%E3%80%80%25e3」の「%E3%80%80」は「 」(全角スペース)である。「%25」は「%」であるから、このオトコは検索キーワードに「プログラム 変換 文字 %e3」と書いていたことがわかる。前半2つのスペースは半角、最後のスペースは全角。

こうなると「%e3」以降がまだ何かエンコードされているということになってくる。プログラムはそれをデコードしようとする。それは無理なことは明白である。結局、その部分が文字化けしてしまうことになる。

ここで使ったのはline_conv_utf8.cgiとhex_conv.cgiである。このツールはこのサンプルのように二重エンコードされている場合もデコードするようになっている(二重デコード)。単純デコード(一重デコード)だけならこういう文字化けは起こらなかったかもしれない。

猫も杓子もログファイルを見ていることは調査上から明白である。ネットバカ(またはドシロウト)の文字コードごっこ屋が多いのは、ログの逆引きをしたいというだけのことであることもわかってくる。「%e3」などはログファイル以外にはドシロウトの目につくような所には出てこないからである。

また、このオトコが自分で「プログラム」などを、その基礎から勉強して作ろうとする気持ちもないはずである。それには数年はかかるだろう(笑)。即効性のあるワンタッチで使える出来合いのものを探しているだけのことである。

さて、これが単純デコード(一重エンコード)するだけなら、次のように文字化けは発生しない。
LOG
218.227.113.160 - - [12/Jan/2014:23:48:09 +0900] "GET #potato#ipc#ipc_0011$html HTTP/1.1" 200 6222
"http://search.yahoo.co.jp/search?p=プログラム 変換 文字 %e3&aq=-1&oq=&ei=UTF-8&fr=sb-necctp_sa&x=wrt"
"Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.1; WOW64; Trident/6.0)"
となると、この問題はプログラムを二重エンコード対応にしたことから生じたものでもあるといえる。このプログラムの仕様は、以前に二重エンコードが多発したことから、その対策として導入したものである。現在では、その当時に多発した二重エンコードのログはほとんどない。

line_conv_utf8.cgiやhex_conv.cgiなどでこの仕様(二重エンコード対応仕様)を続けるべきか、単純デコード(一重エンコード)に戻すべきか、それはヒマなときに考えておこう。


これと同様の例は少なからず出てくる。
LOG
【ナマログ】
125.195.247.235 - - [10/Aug/2014:19:44:41 +0900] "GET #potato#ipc#ipc_0011$html HTTP/1.1" 200 178
"http://search.yahoo.co.jp/search?p=
URL+Encode+%E6%96%B9%E6%B3%95+%25e3%E3%80%80UTF-8&aq=-1&oq=&ei=UTF-8&fr=top_ga1_sa&x=wrt"
"Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Firefox/31.0"

【2重デコード】
125.195.247.235 - - [10/Aug/2014:19:44:41 0900] "GET #potato#ipc#ipc_0011$html HTTP/1.1" 200 178
"http://search.yahoo.co.jp/search?p=
URL Encode 方法 †?掬†††††愀†††††††††攀椀†?掬†††††?装?幣†?蔓†?肘†最愀†††愀†††?鱗?幣?蔓∀†∀††稀椀††愀††† ††圀椀?這††?鱗††一†††††††圀?威圀††††?幣?翼†††† †††攀††††† †  † †††椀?幣攀?装†††††† ∀

【1重デコード】
125.195.247.235 - - [10/Aug/2014:19:44:41 0900] "GET #potato#ipc#ipc_0011$html HTTP/1.1" 200 178
"http://search.yahoo.co.jp/search?p=
URL Encode 方法 %e3 UTF-8&aq=-1&oq=&ei=UTF-8&fr=top_ga1_sa&x=wrt"
"Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Firefox/31.0"


まぎらわしいタイプ

上と似て非なるものに次のようなものがある。
これは最初からデコードに使った文字コードがエンコードされた文字コードと異なっているからこういう文字化けになる。
LOG
220.55.82.102 - - [13/Jan/2014:11:43:54 0900] "GET #potato#dat5#dt5_0003$html HTTP/1.1" 200 6267
"http://search.azby.fmworld.net/websearch/search?select=1041&cflg=
†践&htmltype=2&Text=?忿†i?忿†j?忿抃N?幎沂c ?璢††††††攀††† 戀†††††愀†††愀?幣?蔓?亢?肘攀† ∀†∀††稀椀††愀††† †††††?肘愀?蔓椀戀†攀†††?鴨†††† † ††圀椀?這††?鱗††一††††††††?幣椀†攀?這?蔓††† †∀
元のエンコードはShift_JISであるのに、それをUTF-8としてデコードしたためである。

- 2014/01/12 -