2010-10-20-01-文字コードの話 - 2

>> Site top >> weblog >> 月別アーカイブ >> 2010年10月のlog >> 2010-10-20-01-文字コードの話 - 2

最終更新日付：2010/10/20 01:00:00

文字コードの話 - 2

2010 年 10 月 20 日

エンコーディングを意識しなければならない文字列処理というのは多い。文字を検索する strchr で検索文字を１バイトのASCII文字にした場合、検索対象文字列が Shift-JISだと誤ったマッチ結果を返す可能性がある。文字列を検索する strstr でも同様だ。これは、Shift-JISにおけるマルチバイト文字の後続バイトでASCIIの文字コードが使用されうるためだ。ポインタを１文字進めるにしても、ASCII なら常に１バイトずつだしutf-16なら常に２バイトだが、EUC-JPは１〜３バイト、utf-8に至っては最大で６バイトだ。こうした諸々をうまく取り扱いたいと思ったわけだ。

というわけで前回からの続き。実際に作り始めたわけだ。これはいわゆる『文字列クラス』ではない。データメンバとして文字列バッファを保有したり、operator+ をオーバーロードしたりはしないのだ。もちろんそれはそれで必要だが、今回の話とは（直接的には）関係しない。あくまで文字エンコーディングに関する処理を集約したクラスユーティリティだ。

で、作り始めてすぐに欲が出た。単一のビルドで動的に複数のエンコーディングに対応したくなったのだ。それは仮想関数を用いた動的解決を意味する。つまり、前回書いたインライン関数による効率確保と typedef やテンプレートパラメータによる伝播がという前提が崩れることになるわけだ。

しかし、だからといって全てを動的解決に倒すというのはあまりにも無邪気過ぎる。動的解決のコストは、それを必要とする場合にのみ負担すべきだ。動的解決をサポートしつつ、単一のエンコーディングだけを使う場合には当初想定していたようなコンパイル時解決ができるのが望ましい。これは一見虫のいい話だが、実際にやってみてわかったことがある。それは、やればできるということだ。多少イビツにはなったが、許容範囲内だし十分使える。次回はその実際について書くとしよう。

コメント

NAS芹沢 - 10/21/2010 01:25:38 AM

kagelow - 10/21/2010 08:31:06 PM

このページにコメントする

このページのタグ

Page tag : 開発

Copyright(C) 2005-2019 project-enigma.
Generated by CL-PREFAB.