まさおのChangeLogメモ / 2006-03-31

- yapcグループ - YAPC::Asia 2006 Tokyo audio files: 41 users
- Journal@rchiveについて: users
- 開発者のための正しいCSRF対策: 187 users
- もちろん本気・はじめてのイタメール犯告発: users

http://xming.sf.net/
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設定を行うのが正しい対応な気がする。（この順番を
入れ替えるのはちょっと面倒そうなので…）

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