初心者表明を免罪符にするつもりは毛頭無いのですが、 C++0x/11 の学習、およびそれを用いた経験はまだまだ浅いため、内容的に拙い部分が多々あることを、あらかじめご容赦願いたいと思います m(_ _)m 。ていうか突っ込みだいかんげいでつ。

一応 ISO/IEC 14882:2011 の draft “n3242″ を参照しています。 GCC は 4.7 入れるの面倒だったので、動作確認できるものについては Ubuntu 11.10 に入っていた 4.6.1 を用いています。

Unicode に対応したリテラル

文字リテラルについてはドラフトの 2.14.3、文字列リテラルについては 2.14.5 に記述があります。

文字リテラルには従来の

'a'
L'あ'

といったスタイルに加えて、

u'\u00a9'   // コピーライト記号
U'\U0002000b'  // 丈の右上に点がついた字

といったスタイルが追加されました。想定されるべき対応関係を表にすると以下の通りになります。

文字列リテラルではさらに u8 という接頭子も使えます。

u8"Copyright \u00a9 2011 Harapeko, Inc."    // \u00a9 は UTF-8 のオクテット列 [C2 A9] に変換される
u"\U0002000bは「丈」の字にクリソツ"         // \U0002000b は UTF-16 の該当するサロゲートペアに変換される…ハズ

対応関係の表は、…面倒くさいからもういいか。

あとさらっと流しちゃいましたが、 Unicode 用のエスケープ文字も追加されました。\uNNNN は 16bits の、 \UNNNNNNNN は 32bits の UCS を表現できます。上記の例のように、適切な文字列リテラル内で使用すれば、対応する文字セットの数値列に適宜変換されるはずです。この辺の説明はドラフトの 2.3 にありますが、以下の説明の通り、あくまで UCS の文字値を表現するものであって UTF の数値列を表現するものではないので、 \uNNNN の形式でサロゲートペアの上位代用符号位置に相当する値を指定することはできません。

The character designated by the universal-character-name \UNNNNNNNN is that character whose character
short name in ISO/IEC 10646 is NNNNNNNN; the character designated by the universal-character-name \uNNNN
is that character whose character short name in ISO/IEC 10646 is 0000NNNN. If the hexadecimal value for a
universal-character-name corresponds to a surrogate code point (in the range 0xD800.0xDFFF, inclusive),
the program is ill-formed. Additionally, if the hexadecimal value for a universal-character-name outside the
c-char-sequence, s-char-sequence, or r-char-sequence of a character or string literal corresponds to a control
character (in either of the ranges 0×00.0x1F or 0x7F.0x9F, both inclusive) or to a character in the basic
source character set, the program is ill-formed.15

Unicode に対応した物理型

Unicode に対応した型については、ドラフトの 3.9.1 に説明があります。重要なのは多分以下の箇所。

5. Type wchar_t is a distinct type whose values can represent distinct codes for all members of the largest
   extended character set specified among the supported locales (22.3.1). Type wchar_t shall have the same
   size, signedness, and alignment requirements (3.11) as one of the other integral types, called its underlying
   type. Types char16_t and char32_t denote distinct types with the same size, signedness, and alignment as
   uint_least16_t and uint_least32_t, respectively, in <stdint.h>, called the underlying types.

エーゴは苦手なんですが、ここを読む限り、wchar_t はサポートするロケールに含まれるもっとも大きな値の文字値を表現できるのに十分なサイズの整数型であることが補償されてなきゃいけなさそうに見えます。 wchar_t については大分昔に見捨てているんですが (^_^; 、VC++2010 だと 32bits 整数に変更されていたりするんでしょうか…?

# この辺とか見る限り、やっぱり unsigned short int 相当、のままみたいですね… orz

char16_t と char32_t は、それぞれ UTF-16、 UTF-32 を扱うための型と考えて差し支えなさそうです。

「内部文字」のポリシー

型についての想定を考えるならば、プログラムが内部で扱う文字データは、 C++11 では wchar_t を使用するべきであるように思われます。将来的にはそうなってゆくべきなのでしょう。しかし過去との互換性などの観点から、各ベンダーの wchar_t に対する取り扱いは当面現状維持か、もしくは段階的な仕様変更 (コンパイラオプションでの切り替え等) となっていくことが予想されます。

それに対し、 UTF-32 に関して言えば、恐らく向こう十何年かぐらいは「1要素 = UCS 1文字」であり続けるのではないかと思われます。従って、内部文字への要件として「1文字を 1つの数値のみで扱いたい」というのがあるのであれば、当面は char32_t と U"…" 形式のリテラルを用いるのが良さそうです。

char32_t で文字列置換を試してみる

そんなわけで、実際に UTF-32 を内部文字の文字セットとして採用したプログラム例を作ってみることにしました。内容的には、静的に用意した文字列内のすべての「くま」を「ぱんだ」に置き換える、という簡単なものです。

#include <iostream>
#include <algorithm>
#include <string>

using namespace std;

int main()
{
    u32string before = U"てくまくまやこんてくまくまやこん むらやましゃちょうよ おおきなくまにな～ぁれ";
    u32string after;
    u32string kuma = U"くま";
    u32string panda = U"ぱんだ";

    auto start_it = before.begin();
    auto find_it = start_it + (kuma.size() - 1);
    while (find_it < before.end()) {
        int cnt = 0;
        auto stop_it = find_if(kuma.rbegin(), kuma.rend(), [&cnt, find_it](char32_t letter) {
            return *(find_it - cnt++) != letter;
        });
        if (stop_it != kuma.rend()) {
            find_it += cnt;
            continue;
        }
        // くまを発見、ぱんだに変身!!
        after.append(start_it, find_it - (kuma.size() - 1));
        after += panda;
        start_it = find_it + 1;
        find_it = start_it + (kuma.size() - 1);
    }
    after.append(start_it, find_it);

    cout << "before: " << before.size() << endl;
    cout << "after: " << after.size() << endl;

    return 0;
}

えっと… アルゴリズムの説明とかはいいですよね? 文字列の先頭からと検索語の後からで評価して、完全一致しなかった場合は一致した数値の数だけ読み飛ばして、を繰り返すというオーソドックスなやり方です。これだったらかっこつけて find_if とか使わんで for で回しても大して変わらんやんとかそういう突っ込みはさておき (^_^; 。

GCC4.6/Ubuntu での実行結果は以下の通り。

murachi@ubuntu-vbox:~/otoco/trunk/sample$ g++ -std=c++0x -o kumapan-n kumapan-n.cpp 
murachi@ubuntu-vbox:~/otoco/trunk/sample$ ./kumapan-n
before: 39
after: 44
murachi@ubuntu-vbox:~/otoco/trunk/sample$ 

実行結果として置換前後の u32string::size() を表示しています。 5つある「くま」が「ぱんだ」に置き換えられたので、その数が 5 増えています。増える筈の文字数と一致するので、正しく動作しているように見えます。

iconv を使って実際に出力してみる

さて、実際の文字列を出力してみたいのですが、このままだとロケールが UTF-8 で動作している端末上では表示できません。ファイルに出力してテキストエディタで、という手もありますが、せっかくなので libiconv を使って指定した文字セットに変換して出力、ということをやってみることにしましょう。

libiconv の利用に際しては、お手製のラッパークラスを作成することで対応しました。作成したソースコードを以下にリンクします。

• EncodeString.hpp
• EncodeString.cpp

このクラスは過去の記事においても使用しておりますが、 C++11 の勉強も兼ねて (?)、内部文字に使用する物理型と文字セットをテンプレートパラメータに指定できるテンプレートクラスに書き換えています (あ、過去の記事でのソースへのリンク先が最新版になっちゃってる…直さなきゃ…)。

そして先ほどのサンプルプログラムは、最初の方で EncodeString.hpp を #include し、

#include <iostream>
#include <algorithm>
#include <string>

#include "EncodeString.hpp" // ←

using namespace std;

最後の方で出力内容を以下のように修正します。

    cout << "before: " << EncodeString<char32_t, chset_Utf32>(before, chset_Utf8).getCharArray() << endl;
    cout << "after: " << EncodeString<char32_t, chset_Utf32>(after, chset_Utf8).getCharArray() << endl;

Windows 環境とかで Shift JIS (CP-932) で出力したい人は、 chset_Utf8 を chset_Cp932 に置き換えてあげれば ok です。GCC4.6/Ubuntu での実行結果は以下の通り。

murachi@ubuntu-vbox:~/otoco/trunk/sample$ g++ -std=c++0x -o kumapan EncodeString.cpp kumapan.cpp 
murachi@ubuntu-vbox:~/otoco/trunk/sample$ ./kumapan
before: てくまくまやこんてくまくまやこん むらやましゃちょうよ おおきなくまにな～ぁれ
after: てぱんだぱんだやこんてぱんだぱんだやこん むらやましゃちょうよ おおきなぱんだにな～ぁれ
murachi@ubuntu-vbox:~/otoco/trunk/sample$ 

環境によっては libiconv を別途導入してコンパイルオプションに -liconv を付け加える必要があるかもしれません (MinGW とか←動作未確認)。

正規表現を使いたい

さて、上記のサンプルでさらっと u32string とか使っちゃってますが、このシノニムはドラフトの 21.3 にてちゃんと明記された標準のものです。もちろん、 u16string というのも存在します (u8string は無いので、考慮されているのはアラインメントのみと考えるべきですが…)。

しかし、「28 Regular expressions library」の章においては、 char32_t という文字はカケラも hit しません。標準の <regex> においては、 char16_t、 char32_t への対応は見送られてしまっているようです。

もちろん、basic_regex はテンプレートクラスなのですから、自分でテンプレートパラメータを指定してあげればうまくいきそうに見えます。しかし、同様の試みを Boost.Regex について行った際には、 std::bad_cast 例外が送出されてプログラムがエラー終了してしまいました。将来的には、あるいは処理系によってはうまく動かせる (ようになる) のかもしれませんが、あまり期待は持たない方が良いかもしれません…。

# そもそも GCC (libstdc++) では <regex> 自体がまだちゃんと実装されてなかったり… orz

もっとも、Boost.Regex の ICU 拡張における UChar32 と char32_t (およびそれらの配列へのポインタ) を無理矢理キャストして使うと割と上手く行くっぽかったりするので、どうにかこうにかラッパーを書いて当座はそれで凌ぐというのも手かもしれません…。

ちなみに、char と UTF-8 を使用するのであれば <regex> はそのまま使えるはずですが、その場合、 (Boost.Regex と同様に) <regex> は UTF-8 を知らないので、マルチバイト特有の問題に悩まされることになるでしょう。少なくとも日本語の文字に対する量指定子 (あ+ とか あ? とか) は期待通りには動きません。

仮に、<regex> が char32_t で利用できる場合、先のサンプルは以下のようなコーディングになるでしょう。こういう風に組める日がいつか来るといいですね… (;_;)/。

#include <iostream>
#include <algorithm>
#include <string>
#include <regex>

#include "EncodeString.hpp"

using namespace std;

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


int main()
{
    u32string before = U"てくまくまやこんてくまくまやこん むらやましゃちょうよ おおきなくまにな～ぁれ";
    u32string after;
    u32regex reg(U"くま");
    u32smatch match;

    u32string textbuf = before;
    while (regex_search(textbuf, match, reg)) {
        after += match.prefix().str() + U"ぱんだ";
        textbuf = match.suffix().str();
    }
    after += textbuf;

    cout << "before: " << EncodeString<char32_t, chset_Utf32>(before, chset_Utf8).getCharArray() << endl;
    cout << "after: " << EncodeString<char32_t, chset_Utf32>(after, chset_Utf8).getCharArray() << endl;

    return 0;
}

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

using namespace std;

using boost::u32regex;
using boost::u32match;

int main()
{
        u32string text(U"C++0x のせかいへようこそ!!");
        cout << "pre-modified text length = " << text.length() << endl;
        u32string modified;
        u32regex reg(reinterpret_cast<UChar32 const*>(U"せかい"));
        u32match match;
        while (boost::regex_search(reinterpret_cast<UChar32 const*>(text.c_str()), match, reg)) {
                modified += u32string(reinterpret_cast<char32_t const*>(match.prefix().str().c_str())) + U"世界";
                text = reinterpret_cast<char32_t const*>(match.suffix().str().c_str());
        }
        modified += text;
        cout << "modified text length = " << modified.length() << endl;
        return 0;
}

とりあえず動作確認環境は以下の通りです。

• Ubuntu 11.04 + gcc 4.5.2 + Boost 1.42.0
• Ubuntu 10.04 LTS + gcc 4.4.3 + Boost 1.40.0

どちらでもコンパイルコマンドは以下で通ります (ソースファイルを u32test.cpp として保存した場合)。

$ g++ -std=c++0x -o u32test u32test.cpp -lboost_regex

実行してみると、置換前と置換後の文字数が正しくカウントされており、マッチングが期待通りに動作していることが確認できます。

$ ./u32test
pre-modified text length = 17
modified text length = 16
$ 

ただ、コードを見ていただければわかる通り、 reinterpret_cast の嵐であり、こうした書き方が C++0x 的にも Boost.Regex 的にも ICU 的にも Valid なのかはわかりません。また、現時点では Windows 環境 (MinGW + gcc 4.5 など) での動作確認は行っておりません。 ICU 拡張部分のヘッダを見る限り、内部で wchar_t を使っているので、 wchar_t が 16bits 境界になっている Windows では、バイトオーダーがひっくり返るなどの問題があって、もしかしたら正常に動かないかもしれません。

あくまで参考までと言いますか、将来的にはこういう感じの書き方ができるようになると良いなぁと言う程度の妄想、と捉えていただければと思います… m(_ _)m

ちなみに、ここ最近ちっとも進んでいない otoco ですが、恐らく C++0x 自体の採用を見送る形になると思われます…。ただ、 Boost.Regex の ICU 拡張は有効利用できそうな気がしてきたので、こちらは利用することになるかもしれません。

Google の re2 に流れてしまいそうな悪寒もしてますが…。

• sample/EncodeString.hpp
• sample/EncodeString.cpp
• sample/regex-test.cpp

Makefile は作ってません＼(^O^)／。試してみたい人は頑張ってコンパイルしてねｗ

$ g++ -std=c++0x -o regex-test regex-test.cpp EncodeString.cpp -lboost_regex

まともな環境 (Linux + GCC4.5 とか) なら上記コマンドで通るはず。libiconv を (glibc に上書きする形で) インストールしている場合は -liconv を末尾に入れる必要があるかも。そして MinGW を使う場合は更にもう一工夫必要かも (((;/^^)/

さてこのプログラム、注目して頂きたいのは、regex-test.cpp の以下の行です。

        regex reg(u8"くま|川|(お)?魚");

正規表現を定義しているのですが、一文字でしかないはずの "お" がわざわざ丸括弧でくくってありますね。これが Perl で use utf8; していたり、 UTF-8 で JavaScript を書いていたりしているのであれば、不要な括弧です。

しかし、 Boost.Regex を UTF-8 で使用する場合には必要です。この括弧がなければ、 "?" は "お" の最終オクテットにしか適用されません。なぜなら、 Boost.Regex は UTF-8 なんて知らないので、 "お" が論理的には 1文字でしかない、なんてことは認識できないからです。

すなわち、

        regex reg(u8"くま|川|お?魚");

と書いてしまうと、"お魚" には hit しますが、 "魚" には hit しなくなってしまうのです。

otoco では、 MML コンパイラ機能において、プログラマブルマクロを定義できる機能を提供する予定です。具体的には Lua でマクロを定義し、そのマクロを用いて生成した MML をインライン展開できるようにする、といったものです (実際の所、言語に Lua を採用すべきか JavaScript を採用すべきか、はたまた Python を採用すべきかで迷っているところではあるのですが…)。

で、 (Lua を採用する場合には) 正規表現を用いた文字列加工を行う関数を提供するつもりでいるのですが (JavaScript とかだったら不要なんですけどね、言語機能にあるし)、仮に非 ASCII な文字 (列) を hit させようとする正規表現に "?" やら "[…]" やらが使われた場合、どう扱うべきなんだろう、といった辺りが悩みどころではあったりします…。

まぁなんにせよ、他に選択の余地もないので、とりあえず内部文字列は UTF-8 で実装するという方針でやっていくことにしようかと思います。前途多難じゃ… orz

以前、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 を用いた簡単なプロトタイプを書いて、上記の件も含めて検討してみる予定です…。