2010年 12月 17日

semba

ここ最近文字コードはUTF-8で統一することが多くなったので、いわゆる「文字化け」を目にすることは随分少なくなったが、それでもまだ「化けて出る」のが日本語という奴ではある。

で、まあ文字コード関連のノウハウは色々あるようだけども、今回はそういう話題ではない。

この幽霊たち、いくつかは特徴のある姿をしているので、分かりやすい幽霊についてちょっと紹介してみようと思う。

これは最近良く見るようになった幽霊だ。なにやら糸偏のついた漢字が多く混じっている。

サンプルの文字列には正体を埋め込んであるのでバレバレではあるが、こいつはUTF-8であるにも関わらず、CP932(あるいはShift_JIS、色々細かい話はあるがとりあえず今回は気にしないことにする)で解釈されてしまったがための幽霊である。

というわけで、元のバイナリ列がそのまま保持されているのなら、UTF-8として再解釈してあげればちゃんと読めるようになる。

元々の文字列はこうだ：

が、なんらかの伝送路を通じてこれが送られてきた場合、例えば「こんなん表示されたんだけど…」とかってコピー＆ペーストされてきた場合は、一部のデータが欠落しているので、残念ながら完全に元に戻すことはできない。でも、やってみると思いのほか復元できたりするので、結構面白い。

ちょっとやってみよう。端末設定はUTF-8を想定する。コマンドラインは適当に改行しているので了解してほしい。本来は一行だ。

なんとなく元の文字列が見えた。内容によってはかなり綺麗に復元できたりする。

混乱しがちなのだが、iconvが出力しているのは指示の通りcp932である。しかし、端末がUTF-8の設定になっているので、cp932バイナリ列をUTF-8で解釈して表示している。ということは、間違いなく「化けた」文字列なのだが(まあ確かに半分化けている)、元々UTF-8だった文字列をCP932に「間違って解釈していた」ので、そいつが剥がれて意味を成している部分が見える、というわけだ。

こいつも結構特徴のある幽霊だ。見たことがある人も多いだろう。

なにやら半角カナがたくさん見える。

ま、こちらも正体はバレバレなのだが、euc-jpがcp932として解釈されて出た幽霊だ。というわけでもちろん、元のバイナリがあればeuc-jpで再解釈してやればちゃんと読める：

これはeuc-jpのテキストです。それなりに便利だったのでまだ見かけます。

伝送路を通した後の場合を想定して、これもちょっと救出に挑戦してみよう。

こEeuc-jpのテキストです。そE覆蠅吠慷だったのでまだ見かけます。

うむ。なんとか読めなくはない。

まあ半角カナは伝送路で全角文字に変換されてしまう危険があるのが悩ましいところではあるが。

iconvを二回使っているが、これは端末設定がUTF-8であることを想定しているためだ。よくパイプの繋ぎを見てみると、一回目のiconvはcp932を出力しているにも関わらず、二回目のiconvはeuc-jpを入力としている。この繋ぎ目で「元々あった勘違い」を正しているというわけだ。

いやはや、こいつは実に分かりやすい幽霊だ。