ものがたり(旧)

atsushieno.hatenablog.com に続く

連載が始まった時から最後はid:higeponさんだと思ってたけど(後出しじゃんけん)、ひげが無かったなんて…!!

GB18030エンコーディング無いというので実装しているのだけど、何つうか、これもUCSデコーダには無駄を強いる設計だ。U+10000以下の文字については、GB2312にマッピングが存在する文字については詰めて4バイトを計算することになる。そうするとこういうテーブルを作ることにならざるをえない。GB2312で対応する文字があっても詰めない、という設計にしておけば、マッピングをダイレクトに計算できただろうに。こういう設計になっていると、1文字ごとに200項目以上*1にわたるbinary searchをやるか、あるいはメモリ上に数十KBにわたる膨大なマッピングデータを保持することになってしまう。Windowsのsortkey tableの失敗を彷彿とさせる設計だ。こんなので良いのか中国政府。

まあそれでも分からない文字は無視って言ってすませるWindowsのsortkeyの設計よりはかなりマシだけど。

そんなわけで補助領域の部分だけ先に実装が出来てしまうという妙ちきりんな事態になっている。BMPどうしようかなぁ。managed heapに配列として確保するのは耐え難いので、マップデータを作ってmanaged resourceにするか…マップデータも単純に作成したらでかくなるので、ICUにならってcalculation rangesと組み合わせて実装する方が良いだろうな。200項目のlookupに比べたらだいぶ速くなるだろうし。

ちなみに最近ご無沙汰だった「文字符号の歴史」では、WTOに加盟した中華人民共和国は、国際標準(Unicode)を差し置いてGB18030を国内規格として強制することは、WTO条約2条4項に反するのではないかという指摘もなされている*2。まあ、一方ではWTO逝って良しという気もするけど。

…というわけで1.5日で実装完了。こんなにサクッと終わっちゃっていいのかな。まあいいや。

*1:このページのUni2GbxRangeにある項目が270、うち10000以下にマッピングされているのはGB2312で本来は対応済みのはずだから、上にあるGbx2UniRangeを眺めて上の方の10000以下にマッピングされている50ばかりを引くと220項目となる。

*2:GB2312の拡張であると主張するのであれば、これに反しないという解釈もあり得る