Not only is the Internet dead, it's starting to smell really bad.:2006年08月下旬

2006/08/23(Wed)

NetBSD

@PR/34238

wcsdupとかwcscasecmp,wcsncasecmp入ったのね。
copyright、あとからプロプラで送られてきたらどうするんだろねw

@wcsndup

wcsndupはglibc拡張にないのか、なんか中途半端。

近況

@マシン新調

安かったのでAthlon64X2 3800+買って来た。
んでちょうど夏休みなので組み直してたら、接触不良でディスクの基板が燃えた。
つい先日ディスクがトンで痛い目にあい、RAID1組んだばかりだったんで
早速データが助かりましたよ、あぁ神様、RAID様。

財布には貧乏神がぁっ orz。

2006/08/24(Thu)

Citrus iconv

@TODO

  • OOB_MODEの改善
    OOB_MODEってのは、変換する文字がテーブルに存在しない場合
    • ILSEQ(不正なバイト列、変換ストップ)
    • INVAL(変換できない文字、代替文字を出力して続行)
    のどっちの動作をするか指定するもので、*.mpsに含まれているデータ。
    TYPE		ROWCOL
    NAME		"JISX0208/UCS"
    SRC_ZONE	0x21-0x7E / 0x21-0x7E / 8
    OOB_MODE	ILSEQ
    DST_ILSEQ	0xFFFE
    DST_UNIT_BITS	16
    
    こんな感じ。
    こいつの不具合ってのは、share/i18n/csmapper/mapper.dirに
    FOO/BUZ			mapper_std	MISC/FOO%BUZ.mps
    BAR/BUZ			mapper_std	MISC/BAR%BUZ.mps
    FOOBAR/BUZ		mapper_prallel	FOO/BUZ,BAR/BUZ
    
    とあった場合、文字集合にFOOBAR/BUZを選択するとFOO/BUZを最初に調べ
    該当するデータがなければ次にBAR/BUZ(以下繰返)という動作をするんだけども
    FOO/BUZのOOB_MODEがEILSEQだとBAR/BUZを見に行かずにそこで変換がストップしてしまう。

    BAR/BUZのOOB_MODEがEINVALならば
    FOOBAR/BUZ		mapper_prallel	BAR/BUZ,FOO/BUZ
    
    と順序をいれかえて逃げられるんだけど、性能的にも不利になる場合があるし
    BAR/BUZもEILSEQだとだめぽ。根本的な対策はOOB_MODEはmpsで指定するのではなく
    FOO/BUZ		mapper_std	MISC/FOO%BUZ.mps	ILSEQ
    BAR/BUZ		mapper_std	MISC/BAR%BUZ.mps	ILSEQ
    FOOBAR/BUZ	mapper_prallel	FOO/BUZ,BAR/BUZ		ILSEQ
    BARFOO/BUZ	mapper_serial	FOO/BUZ,BAR/BUZ		ILSEQ,INVAL
    
    みたいな感じでmapper.dirで指定すように変更した方がいいのかも。

    でも後方互換性がなぁ...さもなくば
    • _citrus_mapper_parallel_mapper_convert()をいじってadhocな解決を図る
    • OOB_MODE以外は全く同じであっても別の*.mpsにする
    とかやって逃げるか、それも嫌だなぁ。

  • M:N 変換対応
    Windows VistaではJISX0213-2004対応フォントも入るらすいので
    /diary/?20060608#08
    をそろそろなんとかしないとね、これもmapper_parallelで頭の痛いことになりそうな悪寒。

  • 特別なCESの考慮
    /diary/?20050905#05-1あたりの話。正直UTF-6なんぞどうでもいいんだけど
    http://www.hitachi-to.co.jp/prod/prod_2/inter/emk/help/TextEncoder/CodePage.htm
    を見ると文字コード自動判定系もWindows Codepageを持って(る|しまった)みたいだし
    なんとかする必要があるかもしれない。

libEUC

EUC-CN(GB2312)の場合、G2とG3は未定義なんだけれども、libEUC中のparse_variableの実装がちとアレで
必ず指定しないとmoduleのloadに失敗するのが困りもの。

2006/08/26(Sat)

Citrus iconv

@TODO 追加

  • fallback mappingの考慮
    fallback mappingってーのは、例えば:
    • GBKの0xA2E3は、今は通貨記号U+20ACが割り当てられてるが、昔はユーザ私用領域U+E76Cだった
    • 後方互換性を考えると、変換テーブルにはU+20AC → 0xA2E3だけでなくU+E76C → 0xA2E3も必要
    というようなものの事をいいます。
    しかしGBK → GB18030と建て増しを行う際に、U+E76Cはあらためて
    0x8336C739に割り当てられたので、esdbで
    NAME		"GB18030"
    ENCODING	"GBK2K"
    VARIABLE	"4byte"
    DEFCSID		"ISO646-US"	0
    DEFCSID		"GB2312"	1
    DEFCSID		"GBK"		2
    DEFCSID		"GB18030"	3
    
    のように書いちゃうとGBKのfallback mappingの方が先にに評価され
    0x8336C739ではなく0xA2E3に変換されてしまう、まあこれも
    NAME		"GB18030"
    ENCODING	"GBK2K"
    VARIABLE	"4byte"
    DEFCSID		"ISO646-US"	0
    DEFCSID		"GB18030"	3
    DEFCSID		"GBK"		2
    DEFCSID		"GB2312"	1
    
    と逆に書けば回避できるんだろうけど、あんまり美しくない気がする(性能劣化しかねないし)。
    fallback mappingな文字にはそれとわかる属性をつけておいて 遅延評価したほうがいいと思うんだな。

2006/08/29(Tue)

Citrus iconv

@GB18030

4バイトコードの部分の変換表を作ったんだけど、SRC_ZONEを

SRC_ZONE 0x81308130 - 0x8431A437

としてしまうとBMPだけですらmpsのサイズが96MB超える罠、しかも中身スカスカ。
こりゃcommitできねぇ。

SRC_ZONE 0x81-0x84 / 0x30-0x39 / 0x81-0xFE / 0x30-0x39 / 8

みたいに書けるようにmkcsmapper(1)を修正しないとな。
CCCII(台湾の3バイトコード)ならPlain(面)-Row(区)-Col(点)なので
CNS-11643のように別のCSIDを割り当てればいいんだけど
GB18030の上位2バイトをPlainと考えるのはさすがに無理がある。