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

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に失敗するのが困りもの。