1. C++0x で UCS を UTF-32 として扱う型 char32_t, u32string およびリテラル U"..." と、 libiconv の UCS-4-INTERNAL との間に互換性はあるか。
2. C++0x で新たに追加された正規表現ライブラリ <regex> は利用可能か。
3. <regex> が利用できない場合、 Boost.Regex を用いて UTF-32 文字列を処理することは可能か。

これらの調査は、すべて otoco のコアデータを扱うプログラム内で内部文字列に UTF-32 を採用することを前提としたものでした。

結論から言うと、内部文字列に UTF-32 を採用することは、現時点では諦めざるを得ない、ということになりました。＼(^O^)／ 以下、その解説です。

1 については、互換性に問題がないことを確認しました。

2 についてですが、 GCC 4.5 の標準 C++ ライブラリでは、 <regex> のヘッダファイルは存在するものの、ライブラリの実体がまだ用意されていない、という状態のようでした。

で、 3 についてなのですが… 簡単のため、以下のサンプルを見てみることにします。

#include <string>
#include <boost/regex.hpp>

using namespace std;

typedef boost::basic_regex<char32_t, boost::regex_traits<char32_t> > u32regex;
typedef boost::match_results<u32string::const_iterator> u32smatch;

int main()
{
	u32string text(U"C++0x のせかいへようこそ!!");
	u32string modified;
	u32regex reg(U"せかい");
	u32smatch match;
	while (boost::regex_search(text, match, reg)) {
		modified += match.prefix().str() + U"世界";
		text = match.suffix().str();
	}
	modified += text;
	return 0;
}

このサンプルは、期待通りに動作しても、何もしません。UTF-32 の文字列 U"C++0x のせかいへようこそ!!" の U"せかい" を U"世界" に置換する、という処理を内部で行うだけです。 u32string に対応した iostream があったとして、 UTF-32 をそのままコンソールやファイルに出しても不親切なだけなので、出力までやるなら libiconv と組み合わせるべきですが、プログラムが複雑になるので、ここではそこまで示していません (実際にはそこまで試そうとしていたのですが…)。

で、このプログラム、実際はどうなるのかというと、 GCC 4.5 でコンパイルは通るものの、実行すると、 u32regex オブジェクト (これは boost::basic_regex<char32_t, boost::regex_traits<char32_t> > のシノニムですね) のコンストラクタが std::bad_cast 例外を送出します。どうやら、 Boost.Regex は char32_t、すなわち 32bits 以上の整数型を文字コードに使用するということ、を想定した作りにはなっていなかったようなのです。よーするに char と wchar_t しか想定していなかったんですね (ん? でも GCC の wchar_t は uint32_t だったような…)。

GCC の標準 C++ ライブラリが <regex> のライブラリを実装するのを悠長に待っても居られないので、方針を転換し、内部文字列は UTF-8 で実装せざるを得なさそうです。一応、UTF-8 は文字の先頭オクテットか否かを判断するのが容易なので (0×80≦n≦0xBF 以外なら先頭オクテット)、文字境界の特定も文字数カウントも一度関数を書いてしまえば ok なのですが…。

以前、wchar_t はどうにも使い物にならないからどうしよう、といった記事を書いたのですが、その続きのお話です。

表題の通りで、 libiconv を用いて文字セットを自動認識する処理のサンプルを書いてみました。詳しい経緯はTicket 内で逐次コメントしています。

これがそのサンプルプログラムです。このプログラムは、

1. 標準入力からファイルを読み込み、
2. ファイルの文字セットを自動認識し、
3. 句点「。」をピリオド「.」に、読点「、」をカンマ「,」に置換し、
4. UTF-8 に変換して標準出力に書き出す。

ということをやるものです。

で、以前のブログ記事では、

というわけで、内部コードは wchar_t のような型名で定義するのではなく、より具体的に文字セットで定義した方が良さそうだなぁという結論に至りました。候補は以下の 2通りです。

• UCS4 を内部コードとし、物理型は符号無し 32bits 整数を適当な型名に typedef して用いる。
• UTF-8 を内部コードとし、物理型は char を用いる。

と書いておりましたが、今回はこのうち、前者の UCS4 を内部コードとして用いる方法で実装しています。

とりあえず動いたから commit してみた、という段階なので、コメントが不十分だったり魔法の値が散らばっていたりと未熟なコードです。追々直していこうかと思っています。また、後者の UTF-8 を内部コードとして用いる方法についても併せて書いてみる予定です。

また、現状では boost::regex を用いたコードにはなっていないので (1文字ずつの置換なので UCS4 だと使う必要がないのよ、今のところ)、これを用いた形に修正した場合、どうなるか、といった辺りも試していきたいと思っています。実際にコードに起こしてみると、頭で分かっている以上の利点や問題点が分かってくるんじゃないかなと。

当初の方針として、 otoco では内部コードに Unicode を使用し、その物理型は wchar_t で扱うつもりでいました。この辺、C/C++ でのクロスプラットフォーム開発に慣れていないと陥りやすい罠であるように思うのですが… 現状の wchar_t ははっきり言ってクロスプラットフォーム開発には向いていないものといわざるを得ないようです。

とりあえず確認しているのは Windows の VC++ 2008 と Linux の gcc だけなのですが、それだけでも調べた限りで以下のような相違点がありました。

まず文字セットですが、 UTF-16LE とはリトルエンディアンの UTF-16 エンコードのことで、 Unicode を表現するためのファイル形式です。ファイル形式であるということは、すなわちファイルに保存する方法を定めた形式であるということです。それに対して、 UCS4 はあくまで Unicode そのものであり、内部データ形式として扱えるものです。

具体的に何が違うのかというと、 UTF-16 の場合は配列内の数値 1つが必ず 1文字を表現するものであることを保証しません。実際、UTF-16 ではサロゲートペアを気にする必要があり、この処理を誤ると文字境界に破綻を来して文字化けの原因を作ってしまうことになります。これに対し、 UCS4 の場合は単に 31bits 以下の文字セットであり、それより拡張されないことが保証されています (万一拡張された場合は新たに UCS8 が規定されて包括されるのでしょうが、現実的にはあり得ないでしょう)。

私は元より Windows 畑の人なので、 wchar_t を使う場合でもサロゲートペアをどうにかすることを前提に考えていましたから、 GNU/Linux でのあり方はむしろ理想的とも思うのですが、反面内部的な処理に過ぎない部分でプラットフォーム依存を気にしながら実装しなければならないというのはあまり好ましいことではなく、そう考えると wchar_t という型は意味論的には破綻しているといわざるを得ないように思います。さらに BSD 系の UNIX 環境では wchar_t が扱う文字セットは環境のロケールに依存するなどという情報もあり… とてもじゃないですがそんなの考慮しきれるわけがありません ((((/;^^)/ 。

というわけで、内部コードは wchar_t のような型名で定義するのではなく、より具体的に文字セットで定義した方が良さそうだなぁという結論に至りました。候補は以下の 2通りです。

• UCS4 を内部コードとし、物理型は符号無し 32bits 整数を適当な型名に typedef して用いる。
• UTF-8 を内部コードとし、物理型は char を用いる。

前者のメリットは何と言っても多言語処理の確実性が高く、文字境界も気にする必要がないことです。例えば、配列の中の n個目の値は、確実に文字列の中の n個目の文字であることが保証されます。反面、 STL や Boost を用いた文字列処理においては、あらかじめ typedef された便利な型名を用いることができず、プログラム側で内部コード用に typedef したものをたくさん用意しておく必要が生じるでしょう。また、何より文字列リテラルが使えなくなるので、正規表現のハードコーディングには工夫を強いられることになります。

後者のメリットは STL の string や Boost.Regex に定義されている typedef がそのまま利用できること、そして何よりハードコーディングした文字列リテラルがそのまま利用できることです。正規表現の記述もこちらの方がよっぽどすっきりするでしょう。また、 XML の入出力を UTF-8 に限定して良いのであれば、その辺の実装も楽になるかも知れません。文字境界については注意する必要がありますが、例えば n文字目の検出は他のエンコーディングに比べれば容易であるのも UTF-8 の特徴でもあります (もちろん、UCS4 を用いる場合に比べれば、実装は複雑になりますが…)。

ちなみに、文字セットの変換にはやっぱり iconv を使うことになりそうです。 Windows 側はまだ試していないのですが… とりあえず近日中に iconv を用いた簡単なプロトタイプを書いて、上記の件も含めて検討してみる予定です…。