日記みたいな何か

Fedora7 上でビルドした w3m だと Twitter が表示できるのはなぜか・・・．手元のユーザ環境だとだめぽ．まあ現状特に困ることとかないんでいいんですが・・・．

2時間かけて行って3時間くらい飲んで2時間かけて帰ってきました．遠いよー．キング先生が既に軽く出来上がっていて，何でか知らんけど色々苛められたような気がします (;´Д`)

今日もグラIIやってます．1面でコースを決められなくてうろうろしているうちによく死にますｗ．2面はとても安定しているのに・・・．で，3面もだいぶ慣れてきたんですが，やっぱ破壊できないクリスタルがふよふよしてるところ辺りから終盤まで超緊張．そしてクリスタルコアが全然ダメっす・・・．

2回ほど勝てたんですが，どっちも1回ミスして，その後ほぼ何も装備していない状態で目の前の安置に潜り込んで撃破というパターン(笑)．フル装備だと安置にうまく入れないのは3速だから？

4面は初回は瞬殺だったんですが，2回目はほぼすっぴんからそこそこ復活し，そのまま後半突破→デスMk-II撃破という奇跡のビギナーズラックで突破．ほとんど全部初見だったんですが，よく抜けられたなーと・・・．もう当分抜けられんだろうなぁ・・・．そしてそのまま5面でモアイが赤くなるあたりまで頑張ったんですが，ハッチから出てきた雑魚の弾に当たってしまい，復活もできずに終了となりました・・・orz

bugzillaキター．今後の展開に注目．

T42にMTVX2006USBをつないでみたんですが，音は出るものの画面がまったく出ず．あれこれ試してみたところ，2005モードにすると出ることが判明．FAQから察するに，どうやら2005モードだとDirectDrawのオーバーレイで表示するようになるらしく，2006モードのDirect3Dでの表示だとT42のビデオチップ (確かRadeon Mobility 7500) ではうまくいかないということか？・・・ってこれじゃあVHScrCapで拾えんぞ (;´Д`)

どうにかならんかとあれこれググってみたら，Omega Driversなんていうドライバを発見．とりあえず Mobility Radeonにも対応していそうだったので，ダウンロードして入れてみたところ・・・2006モードだとウィンドウすら出なくなってしまいましたorz．そしてディスプレイまわりの各種設定を弄っている内に，気づけば2005モードでも何も出ない状態に．dxdiag で確認してみたら，DirectDrawもDirect3Dも無効になっとるし (;´Д`)

どうにもわからん状態になってしまったので，仕切り直しということで，一旦ディスプレイアダプタのドライバをロールバックしてみることに．今まで一回も使ったことなかったんですが，普通に前のドライバに戻ってくれたみたいです．へー．そして，再起動したら2005モードで画面が出るようになりました．ふぅ．

で，この状態で2006モードにするとなんにも出ないわけで・・・って2006モードでも映っているぅ！ い，一体どういうことだ・・・．そのまま VHScrCap で普通に取り込めてUstreamに流し込めました．というわけで，結論としては，なんだかよくわからないけどやぱり T42 で MTVX2006USB は使えるらしい．いやー，何がどう直ったのかさっぱりですが，まああっさり諦めなくて良かったってことで．

昨日ぐらにどっとこむさんの動画を見てたらやりたくなって，サターンをつけてやってみました．・・・クリスタルコアで終了 orz．もうどうしようもなく下手だ ＿|‾|○

いやしかし3ボスで終わってる人が何を言ってやがるって感じですが，今やっても普通に面白いというか，古さをさほど感じないのがすごい．20年前からこの水準のゲームが存在していたんだなぁ．とりあえず1周ぐらいはしたいものです．頑張ろう・・・．

歯医者行って，前に削ったりしてもらったところの型とったりしたんですが，最後に「何か」を対象の歯とその周辺にぎゅうぎゅう練り込まれました．何かキャラメルがひっついてるみたいで超非常に気になる・・・というか，来週半ばまで耐えられるのかこいつは・・・．

Windows版のPidginの oscar (AIMとかICQのプロトコル) では，ユーザの入力したUTF-8な文字列を UTF-16BEに変換する前に，まず ISO-8859-1 に変換できるか試します．これで変換できたら1byte文字で送ったりするわけで，多分常にUTF-8で送るよりは多少は効率的とか，そんな感じなんでしょう (oscarでは非Latin1な文字はUTF-16BEで送るらしいので)．

で，Windowsだと，上記の箇所で，全角記号や全角英数字までもが UTF-8 から ISO-8859-1 へ変換できてしまい，しかもその際勝手に半角に置き換えられてしまう・・・というのが今回の問題．上の方でworkaroundを仕込むのもいいんですが，気持ちが悪いのでどうにかできんかと，yazさんを無理矢理巻き込みつつ原因を追ってみました．以下，わかったことと推測されることの要点．

• g_convertを呼んで UTF-8 の全角アルファベットをISO-8859-1に変換するだけのコードを書いてテストしたところ，Linuxでは g_convert に失敗するが，Windows上でPidginについてきた Glib とリンクさせると成功して半角アルファベットになった．Pidginが変なことをしているわけではない模様．
• GNU libiconvには，変換先の文字コードに「ISO-8859-1//TRANSLIT」のように「//TRANSLIT」をつけると，前述のような挙動になる機能があった (libiconvのソースのlib/translit.defを見てみよう)．
• Windows版のPidginと一緒に入るGTKのGlibは，なんと GNU libiconvを使っておらず，代わりに win_iconvというのを利用している模様 (libglib-2.0-0.dll を objdump -d して確認)．glib-2.16.1 のソースを落として中を見てみたら，普通に win_iconv 入ってるのね．
• win_iconv は，Windows のAPIを呼び出してlibiconv互換のAPIを実現しているっぽい．多分 UTF-8 から ISO-8859-1 に変換する際には，WideCharToMultiByte が呼ばれることになる．
• WideCharToMultiByte は，デフォルトで「TRANSLIT」的な動作をするようで，2個目の引数に「WC_NO_BEST_FIT_CHARS」というフラグをつけるとこれを防げるらしい (ここに書いてある「WC_NO_BEST_FIT_CHARS」の説明だと逆なように見えるのでいまいち確証が持てませんが)．
• Glib内蔵の win_iconv のソースを見ると，2個目の引数に0が突っ込まれていた．外からいじれないっぽい (´・ω・｀)

というわけで，アプリの側からどうこうできるような問題じゃないっぽいというのが結論でございます．これだけ書くとすごくあっさりここにたどり着いたように見えますが，どこで問題が起きているのかなかなか見抜けず，半日ずっとこればっかやってました ＿|‾|○

で，既存のコードを尊重するなら，以下のようなパッチが良さそうです．ISO-8859-1に変換できたとしてもすぐに結果を信じずに，再変換してサイズが同じだったら初めて信じる，みたいな．

--- /home/compile/pidgin-2.4.0/libpurple/protocols/oscar/oscar.c.old
+++ /home/compile/pidgin-2.4.0/libpurple/protocols/oscar/oscar.c
@@ -551,7 +551,19 @@
 	 * XXX - We need a way to only attempt to convert if we KNOW "from"
 	 * can be converted to "charsetstr"
 	 */
-	*msg = g_convert(from, -1, charsetstr, "UTF-8", NULL, &msglen, NULL);
+	*msg = g_convert(from, strlen(from), charsetstr, "UTF-8", NULL, &msglen, NULL);
+#ifdef _WIN32
+	if (*msg != NULL) {
+		gchar *msgr;
+		msgr = g_convert(*msg, strlen(*msg), "UTF-8", charsetstr, NULL, NULL, NULL);
+		if (msgr == NULL || strcmp(msgr, from) != 0) {
+			g_free(*msg);
+			*msg = NULL;
+		}
+		if (msgr != NULL)
+			g_free(msgr);
+	}
+#endif
 	if (*msg != NULL) {
 		*charset = AIM_CHARSET_CUSTOM;
 		*charsubset = 0x0000;

古いクライアントなんてクソ喰らえなら，こんな数byteをケチるためのコードとはとっととお別れしてUTF-16BEで統一すべきですね(笑)．って，ICQはそれで平気なんだっけ？

最新のyazさんパッチを当ててWindows版をビルドしてみました．大体よさそうかと思いきや，Windows版のPidginから「～」のみを送ると，送り出す時点で「~」に置換されちゃうという問題が．「あ～」のように，非Latin1文字と混ぜて送ると平気だったりします．何だこりゃ．

調べてみたら，どうも「～」単体だと，oscar.c の purple_plugin_oscar_convert_to_best_encoding の中で，

*msg = g_convert(from, strlen(from), charsetstr, "UTF-8", NULL, &msglen, NULL);

で UTF-8 から ISO-8859-1 に変換できてしまう模様・・・．なんでー？Linuxだと発生しないので，Windows固有の現象なんですかね．もしやと思って全角アルファベットや全角数字を突っ込んでみたら，こちらも半角に変換されて送り届けられました．うわー・・・ナニコレ・・・．

とりあえずこんなことして回避してみましたが，なんだかなぁ．

@@ -551,8 +552,10 @@
         * XXX - We need a way to only attempt to convert if we KNOW "from"
         * can be converted to "charsetstr"
         */
-       *msg = g_convert(from, -1, charsetstr, "UTF-8", NULL, &msglen, NULL);
-       if (*msg != NULL) {
+       *msg = g_convert(from, strlen(from), charsetstr, "UTF-8", NULL, &msglen, NULL);
+       if (*msg != NULL && !(strcmp(charsetstr, "ISO-8859-1") == 0
+                              && strlen(*msg) != strlen(from))) {
                *charset = AIM_CHARSET_CUSTOM;
                *charsubset = 0x0000;
                *msglen_int = msglen;

今日も飲んできました．結構遅くまで飲んでても帰れるのはいいんですが，やっぱ遠いね・・・．帰りの電車は割と空いてて助かりました．