私のプラットフォームはMacとC++ 11(またはそれ以上)です。私はC++初心者で、中国語と英語を処理する個人プロジェクトに取り組んでいます。 UTF-8は、このプロジェクトの推奨エンコーディングです。
Stack Overflowに関するいくつかの投稿を読みましたが、それらの多くはUTF-8を扱うときにstd::string
を使用することを提案し、現在UTF-8にはwchar_t
がないのでchar8_t
を避けます。
ただし、str[i]
、std::string::size()
、std::string::find_first_of()
、またはstd::regex
などの関数を適切に処理する方法については、UTF-8に直面したときにこれらの関数が通常予期しない結果を返すため、これらについては話しません。
std::string
を続行するか、std::wstring
に切り替える必要がありますか? std::string
のままにする必要がある場合、上記の問題を処理するためのベストプラクティスは何ですか?
std::string
とstd::wstring
は両方とも、UTFエンコードを使用してUnicodeを表す必要があります。特にmacOSでは、std::string
はUTF-8(8ビットコード単位)であり、std::wstring
はUTF-32(32ビットコード単位)です。 wchar_t
のサイズはプラットフォームに依存することに注意してください。
両方について、size
は、コードポイントまたは書記素クラスターの数ではなく、コード単位の数を追跡します。 (コードポイントはUnicodeエンティティという名前の1つで、そのうちの1つ以上が書記素クラスタを形成します。書記素クラスタは、文字や絵文字など、ユーザーが対話する目に見える文字です。)
私は中国語のUnicode表現に精通していませんが、UTF-32を使用すると、コード単位の数が書記素クラスターの数に非常に近いことがよくあります。ただし、明らかに、これには最大4倍のメモリを使用するという犠牲が伴います。
最も正確な解決策は、ICUなどのUnicodeライブラリを使用して、求めているUnicodeプロパティを計算することです。
最後に、結合文字を使用しない人間の言語のUTF文字列は、通常find
/regex
で非常にうまく機能します。中国語についてはわかりませんが、英語もその1つです。
std::string
とその友達はエンコード非依存です。 std::wstring
とstd::string
の唯一の違いは、std::wstring
がchar
ではなくwchar_t
を個々の要素として使用することです。ほとんどのコンパイラでは、後者は8ビットです。前者は、Unicode文字を保持するのに十分な大きさであると想定されていますが、一部のシステムでは実際にはそうではありません(たとえば、Microsoftのコンパイラは16ビットタイプを使用します)。 UTF-8をstd::wstring
に保存することはできません。それは設計されたものではありません。 UTF-32(各要素が単一のUnicodeコードポイントである文字列)と同等になるように設計されています。
UTF-8文字列をUnicodeコードポイントまたは構成されたUnicodeグリフ(またはその他)でインデックス化する場合、Unicodeコードポイントまたは他のUnicodeオブジェクトでUTF-8文字列の長さをカウントするか、Unicodeコードポイントで検索します標準ライブラリ以外のものを使用する必要があります。 ICU は、フィールド内のライブラリの1つです。他にもあるかもしれません。
おそらく注目に値することは、ASCII文字を検索する場合、UTF-8バイトストリームをバイト単位で扱うことができるということです。各ASCII文字は、ASCIIの場合と同じUTF-8でエンコードし、UTF-8のすべてのマルチバイトユニットは、ASCII範囲のバイトを含まないことが保証されます。
C++ 20とstd::u8string
にアップグレードすることを検討してください。これは、UTF-8を保持するための2019年時点での最良のものです。個々のコードポイントまたは書記素クラスタにアクセスするための標準ライブラリ機能はありませんが、少なくともあなたのタイプは、少なくともそれが本当のUTF-8であると言うほど十分に強力です。