ウィキペディアから：
C++ コンパイラでの Unicode のサポートを強化する目的で、char 型の定義が変更され、少なくとも UTF-8 の 8 ビット コーディングを格納するのに必要なサイズになりました。
移植可能なアプリケーションを作成するために、これが正確に何を意味するのか疑問に思っています。これを書くことと何か違いはありますか
const char[] str = "Test String";
それともこれ？
const char[] str = u8"Test String";
コード内のすべての文字列リテラルに後者を使用しない理由はありますか?
TestString 内に非 ASCII 文字があるとどうなりますか?
のエンコーディング"Test String"は、実装定義のシステム エンコーディング (狭い、場合によってはマルチバイト エンコーディング) です。
のエンコーディングu8"Test String"は常に UTF-8 です。
例はひどく伝えていません。いくつかの Unicode リテラル ( など\U0010FFFF) を文字列に含めた場合、それら (UTF-8 としてエンコードされたもの) は常に取得されますが、それらをシステムでエンコードされた文字列で表現できるかどうか、また可能であればその値はどうなるでしょうか。実装定義です。
参考になる場合は、EBCDIC マシンでソース コードを作成していると想像してください。次に、リテラル「テスト文字列」はソース ファイル自体で常に EBCDIC エンコードされますが、u8-initialized 配列には UTF-8 エンコードされた値が含まれますが、最初の配列には EBCDIC エンコードされた値が含まれます。
あなたはウィキペディアを引用します：
C++ コンパイラでの Unicode のサポートを強化する目的で、char 型の定義が変更され、少なくとも UTF-8 の 8 ビット コーディングを格納するのに必要なサイズになりました。
まあ、「目的のために」は真実ではありません。charは常に少なくとも 8 ビットであることが保証されています。つまり、C 標準でCHAR_BIT必要とされる範囲により、常に ≥8 である必要があります。charこれは (C++11 §17.5.1.5/1 を引用) C++ 標準に「組み込まれています」。
この文言の変更の目的を推測するなら、C 標準への依存を認識していない読者向けに説明するだけです。
u8リテラル接頭辞の効果に関しては、
実行可能ファイルの文字列のエンコーディングに影響しますが、
残念ながら、タイプには影響しません。
したがって、どちらの場合でも"tørrfisk"、. ただし、前者のリテラルでは、エンコーディングはコンパイラで選択されたものです。たとえば、Latin 1 (または Windows ANSI Western) では、文字の 8 バイトと配列サイズ 9 のヌルバイトになります。後者のリテラルでは、エンコーディングは次のようになります。 UTF-8 であることが保証されており、"ø" は 2 または 3 バイト (正確には覚えていません) でエンコードされ、配列サイズがわずかに大きくなります。u8"tørrfisk"char const[n]
コンパイラは、プラットフォームに自然なネイティブ エンコーディングを選択します。典型的な POSIX システムでは、おそらく ASCII を選択し、ASCII 範囲外の文字値に対する環境設定に応じて何かを選択します。メインフレームでは、おそらく EBCDIC が選択されます。ファイルやコマンド ラインなどから受け取った文字列の比較は、おそらくネイティブの文字セットで行うのが最適です。ただし、UTF-8 を使用して明示的にエンコードされたファイルを処理する場合は、おそらくu8"..."文字列を使用することをお勧めします。
とはいえ、文字エンコーディングに関連する最近の変更により、C および C++ での文字列処理の基本的な前提が崩れました。各内部文字オブジェクト ( char、wchar_tなど) は 1 つの文字を表すために使用されていました。これは、各文字オブジェクトが特定の文字のバイトを表すだけの UTF-8 文字列には明らかに当てはまりません。その結果、すべての文字列操作、文字分類などの機能がこれらの文字列に対して機能するとは限りません。標準に含めるために、このような文字列を処理するための適切なライブラリが用意されていません。