日記みたいな何か

何かWikiの方にIRCで半角カタカナが文字化けするという情報が・・・．うーん，IRCねぇ・・・．普段使ってないだけに，モチベーションが全然上がらないわけですが．自分がPidginの中の人だったら放ってはおけないけど，超外の人だしなぁ・・・といつもなら「そのうち」とかいって放置するところなんですが，うっかり戯れに追ってしまいました．

以前テストでIRCサーバをインストールしていたことを思い出し，ポートを開けて起動．で，早速LinuxとWindowsでPidgin上げて，Pidgin間で通信してみたんですが，全然化ける気配なし．あー，デフォルトだとエンコードがUTF-8なんだっけ．というわけで，ISO-2022-JPにしてみましたが，やっぱり化けないぞ．何だこれは？

再現条件が全然書かれて無かったんですが，まあきっとISO-2022-JPで発言したときに，Winodwsの他のクライアントだと文字化けしてしまうんだろうとにらんで，一番使われてそうなLimeを入れて実験．・・・おお，化けた．半角カタカナがことごとく化けますな・・・．

wiresharkでパケットをキャプチャしてみたら，半角カタカナが混じるとISO-2022-JPっぽくないバイト列が送られている模様．デバッグウィンドウを開いたら，「文字コードの変換に失敗した」みたいなメッセージが出ますわ(;´д`)．で，ソースを見てみると，g_convertでUTF-8から指定したコード(この場合ISO-2022-JP)への変換に失敗したら，そのままUTF-8で送るみたいな感じになってました．スゴス．だからPidgin同士だと化けなかったのかぁ．

では何でg_converが半角カタカナを処理してくれないのかという話ですが，Wikipediaに色々書いてありますな．なるほど，そもそも ISO-2022-JPについて書いてあるRFC 1468に，JIS X 0201のカナを含まないぜと記されてるのね．その辺をlibiconvとかglibcがきちんと守っているからダメなわけか・・・．というわけで，結論としては「ISO-2022-JPを指定した以上，半角カタカナを使うんじゃない」となるわけですが，そんなコチコチ頭的考えは嫌なのでもうちっと追ってみました．

とりあえず手元のLinuxではglibはlibiconvを見ていて，libiconvにはCP932絡みのパッチが当ててあります．「iconv -l」とやったら「ISO-2022-JP-MS」なんてのがありました．これをPidginで指定してみたところ，変換失敗のデバッグメッセージが出なくなり，何とLimeでも化けずに表示されるようになりました．ということは，LimeはISO-2022-JPと見せかけて「ESC ( I」に対応しているのか？ まあいいや，これにて一件落着・・・．

というわけにはいかなくて，肝心のWindows版の方では，libiconvにパッチ何か当たってないので「ISO-2022-JP-MS」を指定しても変換できんわけです (´・ω・｀)．じゃあ，何を指定すれば・・・？ 試しにISO-2022-JP-2を設定してみたらいきなり成功．Windows版Pidgin → Lime で半角カタカナが通りました．でも，これをやると，今度は「〜」が化けます．もしかしてと「¬」を試してみたら，こっちも化けました．さらに外から「〜」を打った場合，WindowsのPidginだけフォントが汚くなります．あれか，WindowsのUnicodeのアレ．

というわけで，Pidginのlibpurpleのircのところにでyazさんの関数呼ぶようにして，送信時と受信時にUTF-8をいじるようにして解決させてみました．多分こんな感じ．ちなみに，現在のyazさんパッチでは，ircのソースに関して一切変更を加えてないようです．

しかし，ISO-2022-JP-2で半角カタカナがエンコードできるようになるのがよくわからんなぁ．ISO-2022-JP-2にはJIS X 0201のカナの方は含まれてないように見えるが・・・．そもそも無理やり変換することを考えるより，Limeと同じように，ISO-2022-JPのときはPidgin内部で半角カナ→全角カナの変換をやっちゃった方がいいのかも？