mutt-j Wiki

teraterm で確認したところ、以下のようになった。転送されてくる文字はUTF-8な文字である。理由は、teratermが、文字をwctomb()で変換している為なのだそうだ。どうなるかについては、 http://www.massangeana.com/mas/charsets/jis2ucs.htm や http://gihyo.jp/admin/serial/01/charcode/0007 に記述がある。

FreeBSDでの対応方法

2011-03-21T11:52:42+09:00

FreeBSDでの対応方法

/usr/share/locale/ja_JP.UTF-8 を作り直す。

元データは/usr/src/share/mklocale/UTF8-src 。これを修正する。このファイルは少なくても6.xから8.2まで変更がないようだ。修正した結果はsvnにUTF-9.srcとして登録済み。

ncursesのデバッグ

2011-03-02T06:59:02+09:00

ncursesのデバッグ

基本的に、別画面を出して、gdb から等外プロセスにattachすればよい。

ncursesにはトレース機能がついている。通常では利用できない。トレース付きのライブラリを別途インストールするようになっているが、それは static link用だったため、なぜかリンクエラーが出てしまった。同じ名前のものがlibcにあるため、どちらを使うかでエラーが出ている様子。

コンパイル時にデバッグとトレースを有効にしてコンパイルすればOK。その後、プログラム内でtrace()関数を呼び出す。これは man curses_trace に書いてある。フルトレースするとけっこうな量になる。

PutAttrCharの中でマルチバイト文字列を出力している。 PUTCというマクロを使っている。このマクロを処理した後、_nc_outputchars が2 になっているので2バイト(UCS2)処理は正しく行われている様子。

もうちょっと追ってみる。

doupdateの996行目あたり

 994         UpdateAttrs(SP_PARM, normal);
 995
 996     NCURSES_SP_NAME(_nc_flush) (NCURSES_SP_ARG);
 997     WINDOW_ATTRS(CurScreen(SP_PARM)) = WINDOW_ATTRS(NewScreen(SP_PARM));

で、画面に表示される。そこまでは、

TransformLine(955行目)あたりから、PutRange->EmitRange->PutChar->PutAttrChar。メモリ上は正しくUCS2な文字が入っている様子。ただ、996行目の_nc_flush(実体は flushを呼び出すだけを実行すると、文字が表示され、桁がずれる。

wnoutrefresh()のあたりにブレークポイントを仕掛け、winという構造体の中身をダンプ。これが画面に対応しているデータを保持しているらしい。それを見ると、 win->_lineが各行データを保持しているらしい。ここには、各1文字毎に文字の値と属性値を保持している。中身は確かに、1つの文字毎にきちんと格納されている。ということで、内部データ(UCS2)での保持については問題なくできているはず。ワイド文字->マルチバイト文字に変換し、エスケープシーケンスで出力する時におかしい? _nc_getchという関数があるが、これは、チャイルドプロセスを起こす時などに、 ESCシーケンスで画面を消したりするのに使われるようだが、画面表示の時には使われない。

さらに、_nc_flush()の所にブレークポイントを仕掛け、その時の状態を見る。 1バイト文字では、1バイトずつバッファに文字が入り、そのまま出力される。 UCS文字の場合は、_nc_flush()が呼び出されてもバッファに文字が入っていない。 3回呼び出された後、バッファにUTF-8文字が入り、そのあとに1バイトの空白文字が入っている。よって、_nc_flushに来る前に空白が付けられている。

FreeBSDのwcwidth

2011-03-01T23:46:28+09:00

FreeBSDのwcwidth

wcwidth()は /usr/include/wchar.h に定義されている。定義部分は

#if __XSI_VISIBLE
int     wcswidth(const wchar_t *, size_t);
int     wcwidth(wchar_t);
#define wcwidth(_c)     __wcwidth(_c)
#endif

gcc -E で展開した結果を見る限り、__XSI_VISIBLEは有効になっている。

さらにそこから、/usr/include/_ctype.hを呼び出している。実体は__wcwidth()。_ctype.hの中に定義されている__wcwidth()は以下の通り。

static __inline int
__wcwidth(__ct_rune_t _c)
{
        unsigned int _x;

        if (_c == 0)
                return (0);
        _x = (unsigned int)__maskrune(_c, _CTYPE_SWM|_CTYPE_R);
        if ((_x & _CTYPE_SWM) != 0)
                return ((_x & _CTYPE_SWM) >> _CTYPE_SWS);
        return ((_x & _CTYPE_R) != 0 ? 1 : -1);
}

さらに、__maskrune()は、やはり!_ctype.h中に定義がある。

static __inline int
__maskrune(__ct_rune_t _c, unsigned long _f)
{
        return ((_c < 0 || _c >= _CACHED_RUNES) ? ___runetype(_c) :
                _CurrentRuneLocale->__runetype[_c]) & _f;
}

___runetype()が実際に判別する関数。これは、/usr/src/sys/lib/libc/locale/runetype.c に実体がある。

unsigned long
___runetype(__ct_rune_t c)
{
        size_t lim;
        _RuneRange *rr = &_CurrentRuneLocale->__runetype_ext;
        _RuneEntry *base, *re;

        if (c < 0 || c == EOF)
                return(0L);

        /* Binary search -- see bsearch.c for explanation. */
        base = rr->__ranges;
        for (lim = rr->__nranges; lim != 0; lim >>= 1) {
                re = base + (lim >> 1);
                if (re->__min <= c && c <= re->__max) {
                        if (re->__types)
                            return(re->__types[c - re->__min]);
                        else
                            return(re->__map);
                } else if (c > re->__max) {
                        base = re + 1;
                        lim--;
                }
        }

        return(0L);
}

ここで、!_CurrentRuneLocaleやRuneEntry,RuneRangeは、/usr/include/runetype.hに定義がある。_CurrentRuneLocaleは、/usr/src/lib/libcの下を検索してみると、たとえばlibc/locale/utf_8.c の!_utf8_init()で、LC_CTYPEファイルから読み込まれている。LC_CTYPEは、mklocaleコマンドで作成される。そのソースは/usr/src/share/mklocale/UTF-8.srcである。これが、wcwidth()関数で、文字幅を定義してある実体。その構造は、先のrunetype.hに定義がある。またman mklocaleにも記述がある。

ソースコード解析

2011-03-01T22:14:52+09:00

漢字がきちんと表示されない件の解析メモ

現象

mutttをUTF-8環境(LANGが ja_JP.UTF-8)の所で使うと、キー入力した時、Unicodeで、幅が不定な文字、例えば「★」の表示が乱れる。幅が定まっている文字、例えば「〒」は乱れない。現象としては下記の通り。

FreeBSD8.1の場合
- クライアントがOpenSUSEのmltermの場合は、★が*になって表示される。
- クライアントがOpenSUSEのgnome-terminalの場合は、1文字入力すると「★」は正しく表示されるが、2文字続けて入力すると、前の★に被さって次の★が表示される。
- クライアントがOpenSUSEのgnome-terminal で、VTE_CJK_WIDTH=1を設定した場合、連続して★を入力しても、正しく表示されるが、バックスペースを入力すると、1バイト分しか戻らない。
- クライアントがWindowsのteraterm(4.68)の場合、★を入力した後、カーソルが3バイト分進む。

ソースはどうなっている?

入力された文字列をハンドリングしているのは、 enter.c内の _mutt_enter_string()である。ここの、

 287       clrtoeol ();
 288       move (y, x + my_wcswidth (state->wbuf + state->begin, state->curpos - state->begin));
 289     }
 290     mutt_refresh ();
 291 
 292     if ((ch = km_dokey (MENU_EDITOR)) == -1)
 293     {
 294       rv = -1; 
 295       goto bye;
 296     }

の、mutt_refresh()を何回か通過した時に、入力された文字列が表示される。

実際にキーが入力されるのを待ち合わせるのは、keymap.cの中にある km_dokey()の中。更にその中から、

  94 #ifdef KEY_RESIZE
  95   /* ncurses 4.2 sends this when the screen is resized */
  96   ch = KEY_RESIZE;
  97   while (ch == KEY_RESIZE)
  98 #endif /* KEY_RESIZE */
  99     ch = getch ();
 100   mutt_allow_interrupt (0);
 101

で、mutt_getch()が呼ばれる。ここで★(UTF8では、E2 98 85)を入力すると、まず「E2」が帰る。ちなみに、Ctrl-Gを押すと、エラーが帰るように、mutt_getch()内でハードコードされている。入力した文字は、大域変数LastKeyに格納される。その後、mapテーブルを検索した後、retry_generic()を呼び出し、結果を返す。

 663         k = mbrtowc (&wc, &c, 1, &mbstate);
 664         if (k == (size_t)(-2))
 665           continue;
 666         else if (k && k != 1)
 667         {
 668           memset (&mbstate, 0, sizeof (mbstate));
 669           continue;
 670         }
 671       }

次に、マルチバイト文字(UTF-8)からワイド文字(UCS-2)への変換を行う。これは、mbrtowc()関数を呼び出すことで行う。1バイトのみの解析なので、戻り値は-2(解析できなかった)が返り、ループの先頭に戻る。もう一度mutt_getch()を呼び出し、UTF-8の2バイト目を得る。これもmbrtowc()で解析失敗するので、-2が返る。3回目のループで、UTF-8の3バイト目を得る。ここで、結果が1となり、mbrtowcの引数wcにはUCS-2の文字が返る。kが1なので、mbstateの初期化は行わない。

 699       else if (wc && (wc < ' ' || IsWPrint (wc))) /* why? */
 700       {
 701         if (state->lastchar >= state->wbuflen)
 702         {
 703           state->wbuflen = state->lastchar + 20;
 704           safe_realloc (&state->wbuf, state->wbuflen * sizeof (wchar_t));
 705         }
 706         memmove (state->wbuf + state->curpos + 1, state->wbuf + state->curpos, (state->lastchar - state->curpos) * sizeof (wchar_t));
 707         state->wbuf[state->curpos++] = wc;
 708         state->lastchar++;
 709       }

701行目のif文が真なので、703行目に移動する。すると、lastcharに20を加算したものをwbuflenとし、そのサイズをwchar_t単位(実際はint)で割り当て、wbufのcurposからwbufのcurpos+1に、lastcharからcurposの、wchar_t単位でのバイト数を移動する。言い換えれば、wbufの先頭1要素を空ける。その後、先頭にwcをコピーし、ポインタを1つずらす。またループの先頭に戻る。

ループに戻るとmy_wcwidth()が呼ばれるところがある。ここで、bufの先頭文字の大きさが返る。UCS-2文字なので2が返る。この文字(buf内にある文字)をmy_addwch()で描画する。その後mutt_addwch()で今度はマルチバイトに変換する。bufにUTF-8文字が設定され、3が返る。

その後、my_wcswidth()が呼ばれ、2が返る。

wcwidth()は呼ばれる?

文字の大きさを決めるのはwcwidth()だが、それは呼ばれていない様子。ncurses内にも呼び出している所はあるが、ブレークポイントを仕掛けても引っかからない。--without-wc-funcsを指定しているからか。

→嘘。ちゃんと呼んでいるところがあった。ただし、wcwidthではなくて__wcwidth。で、★だと戻りが1,〒だと2になることを確認。そこで一旦止めて、★の場合、強引に戻り値を2にしたら表示が正しくなった。これが原因か。

wcwidthの仕組みはFreeBSDのwcwidthにまとめる。

どうやって描画される?

シングルバイトの場合は、1バイトずつ、マルチバイトの場合は、_mutt_enter_string()でUTF-8文字の組み立てを終え、3バイトになってから、mutt_addwch()を呼び出す。この中で、addstr()を呼び出している。addstr()を呼び出す前に引数bufの中身がどうなっているかを見ると、

★の場合

[2011-02-13 20:54:35] before_addwch w=0002 wbuf=2605
[2011-02-13 20:54:35] addstr buf=ffffffe2 ffffff98 ffffff85        0
[2011-02-13 20:54:35] before move2 y,x=35,11
[2011-02-13 20:54:36]    a
[2011-02-13 20:54:36] ★

〒の場合

[2011-02-13 20:59:43] before move1 y,x=35,9
[2011-02-13 20:59:43] before_addwch w=0002 wbuf=3012
[2011-02-13 20:59:43] addstr buf=ffffffe3 ffffff80 ffffff92        0
[2011-02-13 20:59:43] before move2 y,x=35,11
[2011-02-13 20:59:43]    a
[2011-02-13 20:59:43] 〒

で、正しく3バイトがcursesの方に渡されている。

その他

ncursesのデバッグ

ファイル置き場

2009-02-18T16:46:53+09:00

コンパイル済みパッケージ置き場

CentOS4.7用

* mutt-1.5.19-1Ja.i386.rpm

* libiconv-1.12-1.i386.rpm