2006-03-31 Fri
* Xming
http://xming.sf.net/
Cygwin/Xをcygwin.dllぬきでインストールできるようにしたもの。
これは使いやすい!!
が、以前から気になっていたクリップボードでのカット&ペーストが、中
国語の文字列になってしまう問題は解消していない。これはどうやらXWin
自体の問題くさい。
http://www.bookshelf.jp/2ch/unix/1055250582.html#410 の解説が大変
参考になる。
→この後の解決策に載っている、LC_CTYPE環境変数に ja_JP.UTF-8 を指定
するやりかたでうまくいくようになった。。。
万歳!!
ちなみに、XorgのCVSリポジトリ内での、winclipboard関連のコードは以
下にある:
xc/programs/Xserver/hw/xwin
念のため、コードを追った際の情報を残しておくと、、、
_lcLoader にて、各言語設定に適したコード変換ルーチンなどを適切に変
換するらしい。。。
xc/lib/X11/lcUTF8.c
にUTF-8ロケールの場合の実際のコード変換ルーチンは、all_charsetsと
して定義されている。$LANGなどのロケール個別設定で優先するコードを
指定しない限り、これを順番に呼び出し、違反しなければその文字コード
に変換するみたい。その順番は:
となっていて、jisx0208系よりも先にGB2312が来るために、デフォルト設
定ではGB2312系への変換が行われる模様。
ま、素直に$LC_ALL設定を行うのが正しい対応な気がする。（この順番を
入れ替えるのはちょっと面倒そうなので…）
Cygwin/Xをcygwin.dllぬきでインストールできるようにしたもの。
これは使いやすい!!
が、以前から気になっていたクリップボードでのカット&ペーストが、中
国語の文字列になってしまう問題は解消していない。これはどうやらXWin
自体の問題くさい。
http://www.bookshelf.jp/2ch/unix/1055250582.html#410 の解説が大変
参考になる。
410 403sage 03/07/15 23:07 何が問題なのは判明したので報告 -------------------- 問題点: Win -> X の方向にコピーする際、Xutf8TextListToTextProperty(..., XCompoundTextStyle, ...) でUTF-8文字列から CompoundText を作成するが、 GB 2312-80 と JIS X 0208-1983 に共通する文字 (ひらがな、カタカナ) や Unificate された漢字が中文の文字集合 (GB 2312-80) として変換されてしま う。 また、X 側でクリップボードへコピーを行なうと、自動的に Win 側へもコピー し、これを X 側でペーストしようとすると Win -> X へ変換作業が入るため、 見た目上 X -> X であっても同様の問題が発生する。 X -> Win の方向では Win の MultiByteToWideChar(CP_UTF8, ...) が適切に 処理するので問題は発生しない。 例: コピーした文字: "あいう" UTF-8 : 0xe3 0x81 0x82 0xe3 0x81 0x84 0xe3 0x81 0x86 CompoundText : 0x1b 0x24 0x28 0x41 0x24 0x22 0x24 0x24 0x24 0x26 CompoundText の最初の 4byte は、"ESC $ ( A" であり、これは G0 に GB 2312-80 を指示するという意味。411 403sage 03/07/15 23:08 解決方法: 1. GetClipboardData(CF_UNICODE) ではなく、CF_TEXT で sjis のままデータ を取得し、これを XmbTextListToTextProperty() で CompoundText にする。 2. Xutf8TextListToTextProperty(..., XCompoundTextStyle, ...) で UTF-8 から CompoundText を作成する際、LC_CTYPE を参照し、Unificate されている文字は適切な文字集合を優先する。 例えば、GB 2312-80 と JIS X 0208-1983 の両方に適合する場合、 LC_CTYPE が ja_JP.eucJP の場合は JIS X 0208-1983 を、zh_CN.GB2312 の場合は GB 2312-80 を文字集合として指示、というように変換する。 3. X アプリがクリップボードを参照する際、XUTF8StringStyle のスタイルを request する。 →この後の解決策に載っている、LC_CTYPE環境変数に ja_JP.UTF-8 を指定
するやりかたでうまくいくようになった。。。
万歳!!
ちなみに、XorgのCVSリポジトリ内での、winclipboard関連のコードは以
下にある:
xc/programs/Xserver/hw/xwin
念のため、コードを追った際の情報を残しておくと、、、
_lcLoader にて、各言語設定に適したコード変換ルーチンなどを適切に変
換するらしい。。。
xc/lib/X11/lcUTF8.c
にUTF-8ロケールの場合の実際のコード変換ルーチンは、all_charsetsと
して定義されている。$LANGなどのロケール個別設定で優先するコードを
指定しない限り、これを順番に呼び出し、違反しなければその文字コード
に変換するみたい。その順番は:
... { "JISX0201.1976-0", NULLQUARK, jisx0201_mbtowc, jisx0201_wctomb }, { "TIS620-0", NULLQUARK, tis620_mbtowc, tis620_wctomb }, { "GB2312.1980-0", NULLQUARK, gb2312_mbtowc, gb2312_wctomb }, { "JISX0208.1983-0", NULLQUARK, jisx0208_mbtowc, jisx0208_wctomb }, { "JISX0208.1990-0", NULLQUARK, jisx0208_mbtowc, jisx0208_wctomb }, ...となっていて、jisx0208系よりも先にGB2312が来るために、デフォルト設
定ではGB2312系への変換が行われる模様。
ま、素直に$LC_ALL設定を行うのが正しい対応な気がする。（この順番を
入れ替えるのはちょっと面倒そうなので…）
* TREC 2005 Spam Track Overview
Overview論文。
・書誌事項:
Gordon Cormack; Thomas Lynam: TREC 2005 Spam Track Overview.
Proceedings of TREC 2005, 2005.
・概要:
TREC 2005 Spam Trackの説明。
評価指標は以下:
→誤分類率（hm%, sm%）
→誤分類率の対数オッズ平均(logit): lam%
→ROC(Receiver Operating Characteristics) カーブの上側の面積: ROCA
・書誌事項:
Gordon Cormack; Thomas Lynam: TREC 2005 Spam Track Overview.
Proceedings of TREC 2005, 2005.
・概要:
TREC 2005 Spam Trackの説明。
評価指標は以下:
→誤分類率（hm%, sm%）
→誤分類率の対数オッズ平均(logit): lam%
→ROC(Receiver Operating Characteristics) カーブの上側の面積: ROCA
