UTF-32

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

UTF-32の主な利点は、Unicodeのコードポイントが直接インデックス化されていることです。コードポイントのシーケンスからN番目のコードポイントを見つけるのは、定数時間の処理です。一方、可変長コードでは、文字列の先頭からN個のコードポイントを数えるのに線形時間が必要です。そのため、ASCIIで一般的に行われていたように、文字列内の各位置を調べるために1ずつ増加する整数を使用するコードでは、UTF-32は単純な代替手段となります。初心者プログラマーは、この有用性を過大評価しがちです。[ 2 ]

UTF-32の主な欠点は、コードポイントごとに4バイト（常に0となる11ビットを含む）を使用するため、スペース効率が悪いことです。BMPを超える文字は、ほとんどのテキストでは比較的まれであり（例えば、一部の一般的な絵文字を含むテキストを除く）、通常はサイズの見積もりでは無視できます。そのため、UTF-32のサイズはUTF-16の約2倍になります。ASCIIサブセットに含まれる文字の数によっては、UTF-8の最大4倍のサイズになることもあります。[ 3 ]

歴史

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

固定幅の有用性

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

  • 切り捨ては容易になりますが、UTF-8やUTF-16と比べるとそれほど容易ではありません(どちらも、切り捨てるポイントを最大 2 ～ 4 のコード単位を参照して後方に検索できます)。[ a ]
  • 文字列中のN番目の「文字」を見つける。N番目のコードポイントを見つけるのはO(1)の問題であるが、可変幅エンコーディングではO(n)の問題となる。しかし、ユーザーが「文字」と呼ぶものは依然として可変幅であり、[ 3 ]例えば、結合文字シーケンスáは2つのコードポイント、絵文字👨‍🦲は3つ、[ 7 ]合字ffは1つのコードポイントである。
  • 文字列の「幅」を素早く知る。しかし、「固定幅」フォントであっても幅は一定ではなく、CJK表意文字は2倍の幅になることが多い[ 2 ]。さらに、コードポイントの数が文字数と一致しないという、既に述べた問題もある。

使用

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ではなくUTF-32文字列を使用するようにコンパイルできます。バージョン3.3以降では、文字列に少なくとも1つの非BMP文字がある場合、Unicode文字列はUTF-32で保存されますが、先頭のゼロバイトは「最大のUnicode序数（1、2、または4バイト）の[コードポイント]に応じて」最適化され、すべてのコードポイントがそのサイズになります。[ 10 ]

Juliaプログラミング言語は、1.0リリースで組み込みのUTF-32サポートを廃止し、UTF-8文字列のみをサポートするように言語を簡素化しました（他のすべてのエンコードはレガシーとみなされ、標準ライブラリからパッケージに移動されました[ 11 ] ）。これは「UTF-8 Everywhere Manifesto」 [ 12 ]に従っています。

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

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

C#UTF32Encodingには、Unicode文字を文字列ではなくバイトとして表現するクラスがあります。 [ 15 ]

変種

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

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

参照

注記

  1. ^ UTF-8の場合：切り捨てる位置を選択します。その前のバイトが0～0x7Fの場合、またはその次のバイトが継続バイト0x80～0xBF以外の場合、文字列はその位置で切り捨てられます。それ以外の場合は、最大3バイト後方にそのような位置を検索し、そこで切り捨てます。見つからない場合は、元の位置で切り捨てます。これは、UTF-8にエンコードエラーがあっても機能します。UTF-16は単純で、最大1単語をバックアップするだけで済みます。

参考文献

  1. ^ a b Constable, Peter (2001-06-13). 「コードポイントからUnicodeエンコーディング形式へのマッピング」 . Computers and Writing Systems - SIL International . 2022年10月3日閲覧。
  2. ^ a b Goregaokar, Manish (2017年1月14日). 「コードポイントに意味を付与するのはやめよう」 . In Pursuit of Laziness . 2020年6月14日閲覧.人々はコードポイントに何か意味があり、コードポイント境界でのO(1)のインデックス付けやスライスは便利な操作だと言い始めています。
  3. ^ a b「FAQ - UTF-8、UTF-16、UTF-32、BOM」 . Unicode . 2022年9月4日閲覧。
  4. ^ 「公開標準 - ISO/IEC 10646:2020」。ISO規格。 2021年10月12日閲覧。第9.4条：「サロゲートコードポイントはUCSスカラー値ではないため、UTF-32コード単位の範囲0000 D800～0000 DFFFは不正な形式です。」第4.57条：「[UCSコード空間]は0～10 FFFF（16進数）の整数で構成されます。」第4.58条：「[UCSスカラー値]は上位サロゲートコードポイントと下位サロゲートコードポイントを除く任意のUCSコードポイントです。」
  5. ^ 「付録B - ユニバーサル文字セット（UCS）」DKUUG標準化。2022年1月22日時点のオリジナルよりアーカイブ。2022年10月3日閲覧。
  6. ^ 「C.2 ISO/IEC 10646の符号化形式」（PDF） . Unicode規格バージョン6.0 . カリフォルニア州マウンテンビュー：Unicodeコンソーシアム. 2011年2月. 573ページ. ISBN 978-1-936213-01-6UCS-4は現在ではUTF-32の同義語として扱われており、10646の文字を表現するための標準的な形式と考えられています。
  7. ^ “👨‍🦲 男性：ハゲの絵文字” . Emojipedia . 2021年10月12日閲覧。
  8. ^ 「HTML標準」 . html.spec.whatwg.org . 2024年11月11日閲覧。
  9. ^ "Choisir et appliquer un encodage de caractères" . www.w3.org (フランス語) 。2024 年 11 月 11 日に取得。
  10. ^ Löwis, Martin. 「PEP 393 -- Flexible String Representation」 . python.org . Python . 2014年10月26日閲覧。
  11. ^ JuliaStrings/LegacyStrings.jl: レガシー Unicode 文字列型、JuliaStrings、2019-05-17、2019-10-15取得
  12. ^ 「UTF-8 Everywhere」 . utf8everywhere.org .
  13. ^ "u32string" . cplusplus.com . 2024年11月12日閲覧。
  14. ^ 「文字列リテラル - cppreference.com」 . en.cppreference.com . 2024年11月14日閲覧。
  15. ^ dotnet-bot. 「UTF32Encoding クラス (System.Text)」 . learn.microsoft.com . 2024年11月27日閲覧。
「 https://en.wikipedia.org/w/index.php?title=UTF-32&oldid=1314678147」より取得