UTF-32

UTF-32 (32ビット Unicode 変換形式) は UCS-4 とも呼ばれ、 Unicodeコード ポイントをエンコードするために使用される固定長エンコーディングで、コード ポイントごとに正確に 32 ビット (4バイト) を使用します (ただし、Unicode コード ポイントは 2 ³²よりはるかに少なく、実際に必要なのは 21 ビットだけなので、先頭のビット数は 0 でなければなりません)。^[1]対照的に、他のすべての Unicode 変換形式は可変長エンコーディングです。UTF-32 の各 32 ビット値は 1 つの Unicode コード ポイントを表し、そのコード ポイントの数値と正確に等しくなります。

UTF-32 の主な利点は、Unicode コード ポイントが直接インデックス付けされることです。コード ポイントのシーケンス内のN番目のコード ポイントを見つけるのは、定数時間の操作です。対照的に、可変長コードでは、文字列の先頭からN 個のコード ポイントを数えるのに線形時間が必要です。これにより、UTF-32 は、 ASCIIで一般的に行われていたように、文字列内の各位置を調べるために 1 ずつ増加する整数を使用するコードで簡単に置き換えることができます。ただし、文字シーケンスの結合や絵文字など、Unicode コード ポイントが完全に分離して処理されることはほとんどありません。 ^[2]

UTF-32 の主な欠点は、コード ポイントごとに4バイトを使用するため、スペース効率が悪いことです。このうち 11 ビットは常にゼロです。BMPを超える文字は、ほとんどのテキストでは比較的まれであり (たとえば、人気のある絵文字を含むテキストの場合を除く)、通常はサイズの見積もりでは無視できます。このため、UTF-32 はUTF-16の 2 倍近くの大きさになります。ASCIIサブセットに含まれる文字の数によっては、UTF-8の最大 4 倍の大きさになることもあります。^[2]

オリジナルのISO/IEC 10646規格では、 UCS-4と呼ばれる32 ビットのエンコード形式が定義されています。この形式では、ユニバーサル文字セット(UCS) の各コード ポイントは、0 から 0x7FFFFFFF (符号ビットは未使用でゼロ) までの 31 ビット値で表されます。2003 年 11 月、Unicode は RFC 3629 によってUTF-16エンコードの制約に一致するように制限され、U+10FFFF を超えるコード ポイント (および上位サロゲート U+D800 から U+DFFF) は明示的に禁止されました。この制限されたサブセットが UTF-32 を定義します。^{[3] [1]} ISO 規格では (1998 年の Unicode 2.1 の時点で) 0xE00000 から 0xFFFFFF まで、および 0x60000000 から 0x7FFFFFFF までが「私的使用のために予約済み」とされていましたが^[4]、これらの領域は後のバージョンで削除されました。ISO/IEC JTC 1/SC 2ワーキンググループの原則と手順の文書では、今後のコードポイントの割り当てはすべてUnicodeの範囲に制限されると述べられているため、UTF-32はすべてのUCSコードポイントを表すことができ、UTF-32とUCS-4は同一です。^[5]

コード ポイントあたりのバイト数が固定されていることには理論的には利点がありますが、実際にはそれぞれに問題があります。

• 切り捨ては容易になりますが、 UTF-8やUTF-16と比べるとそれほど簡単ではありません(どちらも、最大 2 ～ 4 個のコード単位を参照して切り捨てポイントを後方に検索できます)。^{[a] [引用が必要]}
• 文字列内のN番目の文字を見つける。固定幅の場合、これは単純にO(1)の問題ですが、可変幅エンコーディングではO(n)の問題になります。初心者のプログラマーは、これがどれほど便利かを過大評価することがよくあります。 ^[6]また、ユーザーが「文字」と呼ぶものも可変幅です。たとえば、結合文字シーケンスáは2つのコードポイント、絵文字👨‍🦲は3つ、^[7]合字ffは1つです。
• 文字列の「幅」を素早く知る。しかし、「固定幅」フォントでも幅は様々で、CJK表意文字は2倍の幅になることが多く、^[6]加えて、コードポイントの数が文字数と一致しないという、すでに述べた問題もあります。

UTF-32 の主な用途は、データが文字列ではなく単一のコード ポイントまたはグリフである内部^{APIです。たとえば、現代のテキスト レンダリングでは、最後のステップとして、座標(} x, y) 、属性、^および描画するグリフを識別する単一の UTF-32 コード ポイントを含む構造のリストを作成するのが一般的です[ 引用が必要 ] 。多くの場合、非 Unicode 情報は各単語の「未使用」の 11 ビットに格納されます。^{[引用が必要]}

Windows（wchar_tが 16 ビット）では UTF-32 文字列はほとんど使用されていません。Unix システムでは、wchar_t型が 32 ビットとして定義されているため、UTF-32 文字列がアプリケーションによって内部的に使用されることはまれですが、時々あります。UTF-32 は HTML 文字エンコーディングとしても禁止されています。^{[8] [9]}

Pythonバージョン 3.2 までは、UTF-16の代わりにそれら^{[明確化が必要]を使用するようにコンパイルできます。バージョン 3.3 以降では、文字列に少なくとも 1 つの非}BMP文字がある場合、Unicode 文字列は UTF-32 で保存されますが、先頭のゼロバイトは「最大の Unicode 序数 (1、2、または 4 バイト) の [コードポイント] に応じて」最適化され、すべてのコードポイントがそのサイズになります。^[10]

Seed7 ^[11]とLasso ^[要出典]プログラミング言語は、直接インデックス付けが重要であるという信念のもと、すべての文字列を UTF-32 でエンコードします。一方、Juliaプログラミング言語は、1.0 リリースで組み込みの UTF-32 サポートをやめ、「UTF-8 Everywhere Manifesto」に従って、UTF-8 文字列のみを持つように言語を簡素化しました (他のすべてのエンコードはレガシーとみなされ、標準ライブラリからパッケージ^[12]に移動されました)。^[13]

C++11では、UTF-32を使用する2つのデータ型があります。char32_tデータ型はUTF-32で1文字を格納します。データ型u32stringはUTF-32でエンコードされた文字の文字列を格納します。UTF-32でエンコードされた文字または文字列リテラルは、文字または文字列リテラルの前に が付きますU。^{[14] [15]}

#include <string> char32_t UTF32_character = U '🔟' ; // U'\U0001F51F' とも表記されるstd :: u32string UTF32_string = U "UTF–32 エンコードされた文字列" ; // `const char32_t*´ として定義される  
    
    

技術的には無効ですが、サロゲートの半分はエンコードされて許可されることがよくあります。これにより、無効な UTF-16 (Windows ファイル名など) を UTF-32 に変換できます。これは、UTF-8 のバリアントであるWTF-8の動作に似ています。CESU -8と同様に、ペアになったサロゲートが非 BMP 文字の代わりにエンコードされることもあります。未使用の 32 ビット値が多数あるため、非 Unicode 値を使用して UTF-8 エラーをエンコードすることで無効な UTF-8 を保持することもできますが、これに関する標準はありません。

UTF-32 には、ビッグ エンディアンとリトルエンディアンの 2 つのバージョン ( UTF-32-BEとUTF-32-LE)があります。

• Unicode エンコーディングの比較
• UTF-16

• Unicode 標準 5.0.0、第 3 章 – § 3.9、D90 (PDF ページ 40) および § 3.10、D99-D101 (PDF ページ 45) で UTF-32 を正式に定義しています。
• Unicode 標準付録 #19 – Unicode 3.x 用の UTF-32 が正式に定義されました (2001 年 3 月、最終更新 2002 年 3 月)
• 新しい文字セットの登録: UTF-32、UTF-32BE、UTF-32LE – IANA 文字セット レジストリに UTF-32 が追加されることの発表 (2002 年 4 月)