[Mlterm-dev-ja] Big5 CTEXT

[Araki K. <j00...@ip...>]

	荒木です:-)

        随分古い話ですが。

	Subject: [mlterm: 4] どうもです。
	From: Tomohiro KUBOTA <tk...@ri...>
	Message-ID: <200...@si...>
	Date: Thu, 25 Oct 2001 21:43:16 +0900

> Big5 は、このうち、
>      01/11 02/05 02/15 03/02 M L   2 octets per character
> を使っています。つまり、
>    ESC "%" "/" "2" M L "B" "I" "G" "5" "-" "0" 0x02 <Big5文字列>
> となります。
> ここで、M と L は、それ以降の文字列すべて
> (BIG5-0 0x02 内容) の合計バイト数 (14 ビット) を表します。
> ( (M - 128) * 128 ) + (L - 128) が、それになります。

        KOI8-R では、

        ESC "%" "/" "2" M L "k" "o" "i" "8" "-" "r" 0x02 [KOI8-R char] ESC "%" \
        "/" "2" M L "k" "o" "i" "8" "-" "r" 0x02 [KOI8-R char]

        のように、KOI8-R 一文字につき、毎回 ESC % / シーケンスを出すことで、CTEXT
        の規格通りの動作をしてくれるので、特に問題はないのですが、Big5については
        少々疑問があります。

        手元で確認した限り、<Big5文字列>が複数文字からなるときに、M/Lによる長さ
        指定には、先頭の一文字分2bytes以外は含まれないようです。

        af 64 a8 a5 aa 4f 20

        なBig5シーケンスだと、CTEXTでは、
        
        1b 25 2f 32 80 89 42 49 47 35 2d 30 02 80 89 42 49 47 35 2d 30 02 \
        af 64 a8 a5 aa 4f 1b 28 42 20

        こんな感じです。

        そこで、XLC_LOCALE/zh_TW.big5 を眺めていると、

        byte1           \xa1,\xf9
        byte2           \x40,\x7e;\xa1,\xfe
 
        ct_encoding     BIG5-0:GLGR:\x1b\x25\x2f\x32\x80\x89\x42\x49\x47\x35\x2d\x30\x02

        と書いてありました。

        XLC_LOCALE の定義方法については全くわかりませんので、推測ですが、これは以
        下のように考えてよいのでしょうか?

        まず、ct_encoding が、GLGR である場合、GLGR 領域を全部 Big5 に割り当てる。
        その際の指示シーケンスとして、

        \x1b\x25\x2f\x32\x80\x89\x42\x49\x47\x35\x2d\x30\x02

        を使う。
        (事実上、指示シーケンスは、

        \x1b\x25\x2f\x32\x80\x89\x42\x49\x47\x35\x2d\x30\x02\x80\x89\x42\x49\x47\x35\x2d\x30\x02

        と考えてよい)

        一度指示されれば、それ以降は、byte1,byte2 で定義された範囲の文字列が続く
        限りは、それをBig5として解釈する。

        ちゃんと読んでいませんが、lcCT.c あたりを眺めてみて、そういうことかな、
        と思っています。

        一方、XLC_LOCALE/koi8-r では、
        
XLC_CHARSET_DEFINE
csd0    {
        charset_name    KOI8-R
        side            GR
        length          1
        string_encoding False
        sequence        \x1b%/1
}
END XLC_CHARSET_DEFINE

        と、XLC_CHARSET_DEFINEで、\x1b % / 1を使った文字集合として定義されており
        ますので、CTEXT の規格通りのシーケンスが生成されているのだと思っています。

        # なぜ、Big5やGBKでは、XLC_CHARSET_DEFINE しないのか、よくわかりませんが...

        一応、手元では、この解釈にそって実装し、Big5 の copy&paste ができるように
        なっていますが、実際こういう解釈で正しいのか、ご指摘いただけると幸いです。

	では
--
kiken
j00...@ip...