具体的な調査内容は以下の通り。 iconv について調べる。 ライブラリとしての iconv は何をしてくれるのか? iostream について調べる。 通常のテキストファイルを wifstream で読み込んだ場合の動作について。 otoco ではテキストの内部表現はすべて wchar_t 型の Unicode で扱う。 iconv が Unicode 値を扱うものではなかった場合、 Unicode 値を扱える別のライブラリとの併用を考える必要もある。
#4 (テキストファイルから読み込んだ文字列を wchar_t 配列と Unicode で扱う方法を調査する。) – otoco
具体的な調査内容は以下の通り。 iconv について調べる。 ライブラリとしての iconv は何をしてくれるのか? iostream について調べる。 通常のテキストファイルを wifstream で読み込んだ場合の動作について。 otoco ではテキストの内部表現はすべて wchar_t 型の Unicode で扱う。 iconv が Unicode 値を扱うものではなかった場合、 Unicode 値を扱える別のライブラリとの併用を考える必要もある。
はらぺこ日誌» ブログアーカイブ » 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^
はらぺこ日誌» ブログアーカイブ » libiconv で文字セット自動認識
ご無沙汰ぶりです…。 以前、wchar_t はどうにも使い物にならないからどうしよう、といった記事を書いたのですが、その続きのお話です。 表題の通りで、 libiconv を用いて文字セットを自動認識する処理のサンプルを書いてみました。詳しい経緯はTicket 内で逐次コメントしています。 これがそのサンプルプログラムです。このプログラムは、 標準入力からファイルを読み込み、 ファイルの文字セットを自動認識し、 句点「。」をピリオド「.」に、読点「、」をカンマ「,」に置換し、 UTF-8 に変換して標準出力に書き出す。 ということをやるものです。 で、以前のブログ記事では、 というわけで、内部コードは wchar_t のような型名で定義するのではなく、より具体的に文字セットで定義した方が良さそうだなぁという結論に至りました。候補は以下の 2通りです。 UCS4 を内部コードとし、物理型は符
icu-project.org is now icu.unicode.org
icu-project.org is now icu.unicode.org clicky > https://icu.unicode.org < clicky
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
