2007年6月8日の日記の4番目の記事へのコメント
■PidginでIRC文字化け問題
何か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内部で半角カナ→全角カナの変換をやっちゃった方がいいのかも?
2007年6月8日の日記の4番目の記事へのコメント
[コメントを書く]