いくつかの基本的なルールがUTF-8に違反するという懸念に基づいて、UTF-32を選択することは理にかなっていますか？
私はクロスプラットフォームのC++プロジェクトに取り組んでいます。これはユニコードを考慮しておらず、ユニコードをサポートするための変更が必要です。
次の2つの選択肢があります。どちらを選択するかを決める必要があります。
- Posixシステムのサポートを容易にするUTF-8（std :: string）の使用。
- Windows APIの呼び出しを容易にするUTF-32（std :: wstring）の使用。
したがって、項目＃1 UTF8の場合、コードの変更が多すぎないという利点があります。しかし、懸念事項は、UTF8ではいくつかの基本的なルールが破られることです。たとえば、
- string.size（）は文字の長さと等しくありません。
- パス内の「/」を検索すると、実装が難しくなります（100％確実ではありません）。
これ以上の経験はありますか？そして、どれを選ぶべきですか？
UTF-8を使用します。string.size()は、コードポイントの量に等しくありません、しかしそれはとにかくほとんど役に立たない指標です。ほとんどすべての場合、ユーザーが認識する文字/グリフの数（およびそのために、UTF-32は同じくらいひどく失敗します）、またはbytes使用ストレージ（このため、UTF-32は利点がなく、起動に多くのバイトを使用します）。
ASCII文字（_/_など）の検索は、実際には他のエンコーディングよりも簡単です。バイト/ ASCIIベースの検索ルーチン（ターミネータが0の場合は古いC strstr）。UTF-8は、すべてのASCII文字が同じバイト表現をUTF-で使用するように設計されています8、ASCII以外の文字は、ASCII文字とバイトを共有しません。
Windows APIはUTF-16を使用しており、UTF-16はstring.size() == code_point_countも提供していません。また、多かれ少なかれ、UTF-32のすべての欠点を共有しています。さらに、アプリケーションにUnicodeを処理させることは、すべての文字列をUTF- {8,16,32}にすることほど単純ではないでしょう。 goodUnicodeサポートには、テキストの正規化、愚かなコードポイントの処理などのトリッキーロジックが必要になる場合があります（これは セキュリティの問題 になる場合があります）、文字列の作成スライスや反復などの操作は、バイトなどの代わりにグリフまたはコードポイントで機能します。
ここで合理的に説明できるよりも、UTF-8を使用する理由（およびUTF- {16,32}を使用しない理由）は他にもあります。さらに説得力が必要な場合は TF-8マニフェスト を参照してください。