@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を持って(る|しまった)みたいだし
  なんとかする必要があるかもしれない。