蝉は、やがて死ぬる午後に気づいた。ああ、私たち、もっと仕合せになってよかったのだ。:2003年03月分

2003/03/12(Wed)

wcstof/wcstold

2003/03/13(Thu)

gdtoa

FreeBSDのsrc/contribに入ったみたい

2003/03/18(Tue)

GB18030

libGBK2K.soをでっちあげてみる。
multibyte<->wide character変換の動作はおっけーそうなんだけど、
mklocale書きはじめてゲンナリ。unicodeよりでかい規格だしなぁ...

メモ
http://www.jaet.gr.jp/gb18030/

@

↓とりあえず置いてみた。テスト用のGB18030なテキスト探してくるか。
/distfiles/citrus/NetBSD/
zh_CN.GB18030.srcはGBKすら満たしてないので注意。
zh_CN.eucCN.src(GB2312)をピーコしてSWIDTH2とIDEOGRAMだけ追加した間に合わせだし。

@

iconv -f SHIFT-JIS -t GB18030 でいくらでもテストデータが作れることに気づいた(w

GBK

libGBK2K.soでVARIABLEのパラメタで動作を切替えてGBKも扱ってもいいけど、
IBM-DBCS用のmoduleもでっちあげて、GBKはCP936のaliasにする方がいい鴨。

2003/03/19(Wed)

IBM DBCS/Microsoft MBCS

libDBCSも作ってみた。IBM DBCS or MS MBCS向け汎用 moduleです。
mklocaleはMS-CP950(Big5)とMS-CP932(MSKanji) MS-936(GBK)が入ってるけど
それぞれzh_TW.Big5.srcとja_JP.SJIS.src、zh_CN.eucCNの単なるピーコなので
中身はあまり信用しないで頂戴。
libMSKanjiとlibBIG5が要らなくなるんだけど、大きなメリットではないなぁ。
逆にデメリットかもなぁ、MSKanjiとJISの変換とか、Big5だとCNS11643との変換とか考えると。

2003/03/21(Fri)

丸投げ

@

誰かがzh_CN.GB18030.srcをちゃんと書き直してくれる事を願ってsend-pr。
libDBCSは放置しておこう...

@

次はHZ-GB-2312/HZ+(GB2312/BIG5)でも書くかなぁ...
RFC探してないんだけど

~{~}~{~}~{~}...

とか

~(\n)
~(\n)
~(\n)
~(\n)
...

みたいなエスケープってHZでは有効なんかな。
であればMB_CUR_MAX = 無限大のパターンだよなぁ...GNU iconvはOKみたいだし。

2003/03/22(Sat)

HZ+

@

実装しはじめたけど

~{~}~{~}~{~}...

みたいな冗長なエスケープシーケンスがあった場合、

  • MB_LEN_MAX溢れたら0を返せば良い
  • wchar_tへの変換の過程で冗長部は失われてしまっても構わない

なんで、特に悩まないでも良さそうだ。
少なくともCitrus XPG4DLのISO2022実装はそうなってる模様↓

#include <limits.h>
#include <locale.h>
#include <wchar.h>
int main(void) {
	char s0[] = {0x1b, 0x24, 0x42, 0x1b, 0x24, 0x42, 0x1b, 0x24, 0x42, 0x24, 0x22, 0x0 },
	s1[MB_LEN_MAX];
	wchar_t wc;
	setlocale(LC_CTYPE, "ja_JP.ISO2022-JP");
	printf("%d\n", mbtowc(&wc, s0, sizeof(s0))); /* -> 変換結果11byte */
	printf("%d\n", wctomb(s1, wc)); -> /* 変換結果5byte */
}

glibc2はどうしてるのかは確認できず。

@

あとはwchar_tに

  • US-ASCII
  • GB2312
  • BIG5 1部(0xA140-)
  • BIG5 2部(0xC940-)
  • BIG5 (0x8140-0xA0FE)

をどうmappingするかだな。GB2312は単純に(c | 0x80)なんだけど、
BIG5を7bitにするルールが割と変則で汎用性がなかったり。
今後の拡張(~[!-z|]がescape sequenceにreserveされてる、まあ無いだろうが)を考慮し、
BIG5に戻さずそのままマスクしちまうか。

@

ググっってたらHZの8bit版EHZとかHZ+8とかいろいろ出てきた...↓
ttp://www.ibiblio.org/pub/packages/ccic/software/unix/convert/
ワケ・ワカ・ラン(AA略)

2003/03/23(Sun)

libcいぢり

@GB18030

mklocaleを書く上でwchar_tは unicode compatな部分はunicodeに変換するべきだったかもなぁ。
もうちょい放置しとけばよかったなぁ...

@HZ+

こっちもmklocaleを

#include "charset/GB2312"
#include "charset/BIG5"

とするんだとBIG5に戻してやらんとダメか。

XFree86

祭キター (AA略) のか?

2003/03/24(Mon)

今更ですが、mklocaleの出力を眺めて、あのgbk2k moduleじゃ
駄目じゃんということに気づきますた、逝ってきます。
さーて、どうしたもんか。

2003/03/26(Wed)

gbk2k module

@何がだめぽかってーと

wchar_tもrunetype.hの__nbrune_tもsignedだという(滝汗)初歩的なアレ。
unsignedな32bitと勘違いしてた漏れはそのまま何も考えずに
0x81308130からのGB18030をwchar_tに突っ込んでますたと。
これじゃぁwctype周りはマトモに動作しないよなぁ、あー恥ずかしい。
サボらずmklocaleファイルを書いてりゃ気づいたものを...

@じゃあどうするかってーと

0x81308130 - 0xfe39fe39の範囲を無理矢理signedの範囲に納める、なんだけど
mklocaleにその為のルールをどうやって教えるかが問題だ罠。
mklocaleはISO2022の場合だと`CHARSET'トークンをみて
wchar_tの内部表現ルールに変換してるので、GB18030も同等の処理が必要だなぁ。

@mklocale

どうやら

CHARSET charsetbit charsetmask

という書式を受けつけるので、既存のmklocaleファイルの記述ルールを
変更する必要は無いけども、unsignedが通るようにmklocaleを修正する必要あるっぽい。

2003/03/29(Sat)

libcいぢり

@gbk2k module

gbk2k module commitされちょります。
sys/ansi.h では

typedef _BSD_WCHAR_T_ int

runetype.h では

typedef __nbrune_t int32_t

なわけですが、shiozak%netbsd.orgな方より

uint32_t v = (wchar_t)(__nbrune_t)v;

を仮定してヨシとのお言葉を戴きますた、なんで今のコードでOK。
しかしmklocaleがunsigned 32bit cleanでないみたいなので
ただいま調査中...yacc/lexは苦手なんだが。

@zh_CN.GB18030.src

書いちょります。