はらぺこ日誌» ブログアーカイブ » C++11 で Unicode プログラミングのススメ
文字列リテラルではさらに 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 の文字値を
はらぺこ日誌» ブログアーカイブ » Boost.Regex の ICU 拡張と char32_t は相性がいいかも?
なんとなく Virtual Box から利用している Ubuntu のアップグレードなどをして、そこからなんとなく「やっぱり Long Time Release 版の Ubuntu もテスト環境に持っておきたいよなぁ」などと思いつつ Virtual Box ディスクイメージを追加でこさえて、 Boost ライブラリのセットアップなどもしつつ動作チェックも兼ねて昔書いた記事なんぞを掘り起こしておりましたら、そこに書かれた内容に関連して、そういえば Boost.Regex も ICU ライブラリと組み合わせれば Unicode に対応できたはずだよなぁなどということが気になりだしてしまいまして、いろいろ試しているうちに、以下のようなサンプルコードが問題なく動作してしまうことを発見してしまったのでメモしておこうかと思った次第なのであります。ああ、なんだかこちらのブログも口調が個人ブログや普段の
はらぺこ日誌» ブログアーカイブ » UTF-8 もイマイチだが…
UTF-32 が内部文字列に使えないことがわかったので、 UTF-8 を内部文字列に使用するというルールで libiconv によるエンコーディング操作と Boost.Regex による正規表現の両方を同時に試すサンプルを作成してみました。 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 に上書きする形で) インストールしている場合は -li
はらぺこ日誌» ブログアーカイブ » char32_t だと regex が使えない
C++0x では UCS に対応し、専用の型やリテラルの記法が導入されました。その関係で、以下の点について調査を行っていました。 C++0x で UCS を UTF-32 として扱う型 char32_t, u32string およびリテラル U"..." と、 libiconv の UCS-4-INTERNAL との間に互換性はあるか。 C++0x で新たに追加された正規表現ライブラリ <regex> は利用可能か。 <regex> が利用できない場合、 Boost.Regex を用いて UTF-32 文字列を処理することは可能か。 これらの調査は、すべて otoco のコアデータを扱うプログラム内で内部文字列に UTF-32 を採用することを前提としたものでした。 結論から言うと、内部文字列に UTF-32 を採用することは、現時点では諦めざるを得ない、ということになりました。＼(^O^
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Alpha の अनुपयोगी な日記
