C ++標準ライブラリはどの程度Unicodeをサポートしていますか？
ひどく。
Unicodeサポートを提供する可能性のあるライブラリー機能をざっとスキャンすると、次のリストが得られます。
- 文字列ライブラリ
- ローカリゼーションライブラリ
- 入出力ライブラリ
- 正規表現ライブラリ
最初のものを除いてすべてがひどいサポートを提供すると思います。他の質問を少し迂回した後で、さらに詳しく説明します。
ないstd::string何それが必要ですか？
はい。C ++標準によると、これはstd::stringその兄弟とその兄弟が行うべきことです。
クラステンプレートbasic_stringは、シーケンスの最初の要素が位置0にある、さまざまな数の任意のcharのようなオブジェクトで構成されるシーケンスを格納できるオブジェクトを記述します。
まあ、それstd::stringはうまくいきますか。Unicode固有の機能はありますか？番号。
よろしいですか？おそらく違います。オブジェクトのstd::stringシーケンスとしては問題ありcharません。それは便利です。唯一の不満は、それがテキストの非常に低レベルのビューであり、標準のC ++が高レベルのビューを提供しないことです。
どうやって使うの？
charオブジェクトのシーケンスとして使用します。それが別のふりをするふりをすることは苦痛で終わるにちがいない。
潜在的な問題はどこにありますか？
あらゆる所に？どれどれ...
文字列ライブラリ
文字列ライブラリはbasic_string、標準が「charのようなオブジェクト」と呼ぶものの単なるシーケンスであるusを提供します。私はそれらをコード単位と呼びます。テキストの高レベルのビューが必要な場合、これはあなたが探しているものではありません。これは、シリアライズ/デシリアライズ/ストレージに適したテキストのビューです。
また、狭い世界とUnicodeの世界の間のギャップを埋めるために使用できるCライブラリのツールもいくつか提供しています：c16rtomb/ mbrtoc16とc32rtomb/ mbrtoc32。
ローカリゼーションライブラリ
ローカリゼーションライブラリは、これらの「charのようなオブジェクト」の1つが1つの「文字」に等しいとまだ信じています。もちろんこれはばかげているので、ASCIIのようなUnicodeの小さなサブセットを超えて多くのことを適切に機能させることは不可能です。
たとえば、標準で<locale>ヘッダーの「便利なインターフェース」と呼んでいるものを考えてみます。
template <class charT> bool isspace (charT c, const locale& loc);
template <class charT> bool isprint (charT c, const locale& loc);
template <class charT> bool iscntrl (charT c, const locale& loc);
// ...
template <class charT> charT toupper(charT c, const locale& loc);
template <class charT> charT tolower(charT c, const locale& loc);
// ...
これらの関数のいずれかが、たとえば、U + 1F34C inを適切に分類することを期待しますu8"🍌"かu8"\U0001F34C"？これらの関数は入力として1つのコード単位しか使用しないため、機能する方法はありません。
これは、UTF-32の単一のコードユニットchar32_tのみを使用している場合、適切なロケールで動作する可能性がありますU'\U0001F34C'。
しかし、それはまだあなただけの単純なケースで変換得ることを意味toupperし、tolower「SS」を「ß」大文字の☦しかし：例えば、いくつかのドイツ語のロケールのために良い十分ではない、toupper一つだけ返すことができ、文字コードユニットを。
次は、wstring_convert/ wbuffer_convertと標準のコード変換ファセットです。
wstring_convertある特定のエンコーディングの文字列を別の特定のエンコーディングの文字列に変換するために使用されます。この変換には2つの文字列タイプが含まれ、標準ではバイト文字列とワイド文字列を呼び出します。これらの用語は本当に誤解を招くので、代わりに「シリアル化」と「非シリアル化」をそれぞれ使用することを好みます†。
変換するエンコーディングは、テンプレートタイプの引数としてに渡されるcodecvt（コード変換ファセット）によって決定されwstring_convertます。
wbuffer_convert同様の機能を実行しますが、バイトのシリアル化されたストリームバッファーをラップするワイドな非シリアル化ストリームバッファーとして機能します。すべてのI / Oは、codecvt引数で指定されたエンコーディングとの間の変換を伴う、基礎となるバイトシリアル化ストリームバッファーを介して実行されます。書き込みは、そのバッファーにシリアル化してから書き込み、読み取りはバッファーに読み取り、逆シリアル化します。
：標準では、これらの施設で使用するためのいくつかのcodecvtクラステンプレートを提供しcodecvt_utf8、codecvt_utf16、codecvt_utf8_utf16、およびいくつかのcodecvt専門分野。これらの標準ファセットを組み合わせることで、以下のすべての変換が提供されます。（注：次のリストでは、左側のエンコードは常にシリアル化された文字列/ streambufで、右側のエンコードは常に非シリアル化された文字列/ streambufです。標準では両方向の変換が許可されています）。
- UTF-8↔UCS-2と
codecvt_utf8<char16_t>、及び、codecvt_utf8<wchar_t>sizeof(wchar_t) == 2
- UTF-8と↔UTF-32
codecvt_utf8<char32_t>、codecvt<char32_t, char, mbstate_t>および、codecvt_utf8<wchar_t>sizeof(wchar_t) == 4
- UTF-16↔UCS-2と
codecvt_utf16<char16_t>、及び、codecvt_utf16<wchar_t>sizeof(wchar_t) == 2
- UTF-16↔とUTF-32
codecvt_utf16<char32_t>、および、codecvt_utf16<wchar_t>sizeof(wchar_t) == 4
- UTF-8と↔UTF-16
codecvt_utf8_utf16<char16_t>、codecvt<char16_t, char, mbstate_t>および、codecvt_utf8_utf16<wchar_t>sizeof(wchar_t) == 2
- 狭い↔広い
codecvt<wchar_t, char_t, mbstate_t>
- で何もしません
codecvt<char, char, mbstate_t>。
これらのいくつかは便利ですが、ここには多くの扱いにくいものがあります。
まず、聖なる代理人です。その命名方式は面倒です。
次に、UCS-2のサポートがたくさんあります。UCS-2は、基本的な多言語プレーンのみをサポートするため、1996年に置き換えられたUnicode 1.0からのエンコーディングです。委員会が20年以上前に置き換えられたエンコーディングに焦点を合わせることが望ましいと考えた理由は、私にはわかりません‡。それはより多くのエンコーディングのサポートが悪いか何かであるようではありませんが、UCS-2はここに頻繁に現れます。
それchar16_tは明らかにUTF-16コード単位を格納するためのものです。ただし、これは別の方法で考える標準の一部です。codecvt_utf8<char16_t>UTF-16とは何の関係もありません。たとえば、wstring_convert<codecvt_utf8<char16_t>>().to_bytes(u"\U0001F34C")は正常にコンパイルされますが、無条件に失敗します。入力はUCS-2文字列として扱われ、u"\xD83C\xDF4C"UTF-8は0xD800-0xDFFFの範囲の値をエンコードできないため、UTF-8に変換できません。
まだUCS-2の前にありますが、これらのファセットを使用して、UTF-16バイトストリームからUTF-16文字列に読み取る方法はありません。UTF-16バイトのシーケンスがある場合、それをの文字列に逆シリアル化することはできませんchar16_t。これは多かれ少なかれアイデンティティ変換であるため、これは驚くべきことです。ただし、さらに驚かされるのは、UTF-16ストリームからを使用したUCS-2文字列への逆シリアル化がサポートされていることですcodecvt_utf16<char16_t>。これは、実際には非可逆変換です。
ただし、UTF-16-as-bytesのサポートは非常に優れています。BOMからエンディアンを検出したり、コードで明示的に選択したりできます。また、BOMがある場合とない場合の出力の生成もサポートします。
さらに興味深い変換の可能性はありません。UTF-8はデシリアライズされた形式としてサポートされないため、UTF-16バイトストリームまたは文字列をUTF-8文字列にデシリアライズする方法はありません。
そして、ここで、ナロー/ワイドの世界は、UTF / UCSの世界から完全に分離しています。古いスタイルのナロー/ワイドエンコーディングとUnicodeエンコーディングの間の変換はありません。
入出力ライブラリ
I / Oライブラリは、上記のwstring_convertおよびwbuffer_convert機能を使用して、Unicodeエンコーディングでテキストを読み書きするために使用できます。標準ライブラリのこの部分でサポートする必要のある他の多くのものはないと思います。
正規表現ライブラリ
以前に、スタックオーバーフローでのC ++正規表現とUnicodeの問題について説明しました。ここではそれらすべてのポイントを繰り返すことはしませんが、C ++正規表現がレベル1のUnicodeサポートを持たないことだけを述べます。
それでおしまい？
はい、それだけです。それが既存の機能です。正規化やテキストセグメンテーションアルゴリズムのようにどこにも見られない多くのUnicode機能があります。
U + 1F4A9。C ++でより良いUnicodeサポートを取得する方法はありますか？
通常の容疑者：ICUおよびBoost.Locale。
†バイト文字列は、当然のことながら、バイトの文字列、つまりcharオブジェクトです。ただし、常にオブジェクトの配列であるワイド文字列リテラルとは異なり、wchar_tこのコンテキストの「ワイド文字列」は必ずしもwchar_tオブジェクトの文字列であるとは限りません。実際、標準では「ワイド文字列」の意味を明示的に定義していないため、使用方法から意味を推測する必要があります。標準的な用語はずさんでわかりにくいので、わかりやすくするために、自分の用語を使用します。
UTF-16のようなエンコーディングはのシーケンスとして格納できchar16_t、エンディアンはありません。または、エンディアンを持つ一連のバイトとして格納することもできます（連続するバイトの各ペアはchar16_t、エンディアンに応じて異なる値を表すことができます）。標準はこれらの形式の両方をサポートします。シーケンスはchar16_t、プログラムの内部操作に役立ちます。バイトシーケンスは、そのような文字列を外部の世界と交換する方法です。したがって、「バイト」や「ワイド」の代わりに使用する用語は、「シリアライズ」および「デシリアライズ」されます。
"「Windowsですが！」あなたの🐎🐎を保持します。Windows 2000以降のすべてのバージョンのWindowsはUTF-16を使用しています。
☦はい、私はEszett（ẞ）のグロスについて知っていますが、すべてのドイツ語のロケールを夜に変更してßの大文字をẞにしても、これが失敗するケースは他にもたくさんあります。大文字のU + FB00ʟᴀᴛɪɴsʟɪɢᴀᴛᴜʀᴇupperғғを試してください。ʟᴀᴛɪɴᴄᴀᴘɪᴛᴀʟʟɪɢᴀᴛᴜʀᴇғғはありません。2つのFを大文字にします。またはU + 01F0ʟᴀᴛɪɴsᴍᴀʟʟʟᴇᴛᴛᴇʀᴊᴡɪᴛʜᴄᴀʀᴏɴ; 事前構成された資本はありません。大文字のJと結合するキャロンだけを大文字にします。