long double
strtold(const char *s, char **p) {
return (long double)strtod(s, p);
}
FreeBSDのsrc/contribに入ったみたい
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
libGBK2K.soでVARIABLEのパラメタで動作を切替えてGBKも扱ってもいいけど、
IBM-DBCS用のmoduleもでっちあげて、GBKはCP936のaliasにする方がいい鴨。
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との変換とか考えると。
誰かが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みたいだし。
実装しはじめたけど
~{~}~{~}~{~}...
みたいな冗長なエスケープシーケンスがあった場合、
なんで、特に悩まないでも良さそうだ。
少なくとも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に
をどう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略)
mklocaleを書く上でwchar_tは
unicode compatな部分はunicodeに変換するべきだったかもなぁ。
もうちょい放置しとけばよかったなぁ...
こっちもmklocaleを
#include "charset/GB2312"
#include "charset/BIG5"
とするんだとBIG5に戻してやらんとダメか。
祭キター (AA略) のか？
今更ですが、mklocaleの出力を眺めて、あの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も同等の処理が必要だなぁ。
どうやら
CHARSET charsetbit charsetmask
という書式を受けつけるので、既存のmklocaleファイルの記述ルールを
変更する必要は無いけども、unsignedが通るようにmklocaleを修正する必要あるっぽい。
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は苦手なんだが。
書いちょります。