UTF-32
| Unicode |
|---|
| 文字符号化スキーム |
| UTF-7 |
| UTF-8 |
| CESU-8 |
| UTF-16 |
| UTF-32 |
| UTF-EBCDIC |
| SCSU |
| Punycode (IDN/IDNA) |
| GB 18030 |
| その他 |
| UCS |
| マッピング |
| 書字方向 |
| BOM |
| 漢字統合 |
| UnicodeとHTML |
| Unicodeと電子メール |
| Unicodeフォント |
|
UTF-32（およびUCS-4。#歴史を参照）は、Unicodeの各符号位置に32ビット符号単位 1つだけを使う、固定長のUnicodeの符号化形式および符号化スキームである。他の UTF（英: Unicode transformation format）はすべて符号位置によって符号単位列の長さが変化する可変長であるため、UTF-32はもっとも単純なUTFであるとみなせる。
UTF-32は、テキストファイルで使用されることは少なく、主にシステムのメモリ上での管理や、符号位置の数で管理するデータベースなどで使用される。
概要
一般にシステムが文字を扱う場合には、必要な1つの符号位置にアクセスすることで文字情報（グリフの形状や文字の持つ意味など）を取得する。UTF-32の場合は対象の1領域のみアクセスすることで対象となる文字情報を得ることができるが、可変長のUnicode形式では1つの符号位置を特定するために複数回のアクセスが必要となる。そのため、アクセス対象のメモリ上に配置する場合には固定長であるUTF-32が使用されることがある。
昨今のデータベースでは、バイト数ではなく、符号位置の数で領域を確保できる型を利用できる。符号位置数の型では他のUnicode形式では固定のバイト数を確保できないが、UTF-32の場合にはバイト数が固定であるため物理サイズをディスク上に確保することが可能である。
データのサイズで見た場合、他の文字符号化スキームと比較するとサイズは大きくなる。また文字列の表示幅の計算も、非常に限られた場合を除いて全く簡単にはならない。なぜならば、“固定幅”フォントを使った場合でさえ、 1つの文字位置に対して複数の符号位置が存在するかもしれない（結合文字など）し、 1つの符号位置に対して複数の文字位置を使うかもしれない（CJKV漢字など）。結合文字があるので、エディタは 1つの符号位置を編集時の 1単位とみなすこともできない。
これらの理由から、データの交換などの場合には、UTF-32はほとんど使われず、UTF-8やUTF-16がUnicode文書の通常の符号化スキームとして使われている。
なお、特定の文字がUnicodeでどの符号位置になるかをテキストで表現する場合には、U+10001などのように、UTF-32で扱った場合の16進数表記が使用されることがほとんどである[要出典]。
テキスト形式で扱う場合、UTF-32は先頭にバイト順マーク (BOM) をつける。先頭の4バイトの並びが FF FE 00 00 ならリトルエンディアンとなり、00 00 FE FF ならビッグエンディアンとなる。
プログラミング言語においては、UTF-32の指定には大文字のUを利用することが多く、C言語 (C11) や C++ (C++11) などではそれを文字列リテラルの前に置くことでUTF-32として処理されるようになる。
歴史
最初のISO/IEC 10646規格は、UCS-4[注 1]と呼ばれる31ビットの符号化文字集合を定義していた。この形式では、UCSに含まれるおのおのの符号化された文字は、32ビットで扱いやすい0–7FFFFFFFの符号位置で表現される。
最上位ビットが1になる値を避け、32ビットではなく31ビットとしたのは、これをコンピュータの内部表現として使用した場合に、最上位ビットが1のコードをエスケープなどの目的に使い、ISO/IEC 2022などの Unicode や ISO 10646 と異なるコード体系のための内部表現と共用するといった便宜のためである。参考として、4バイトコードで最上位ビットが1のコードを使うものにGB 18030がある。
UCS-4 は、 1114112個 (= 220+216) の符号位置を持ち、そのため十六進で10FFFFまでしか必要としないUnicode符号空間のすべてを表現するのに、UCS-4は十分である。比較的小さな符号位置の集合へのマッピングのためにそのように大きな符号空間を予約するのは浪費だと考える者がいるので、新しい符号化形式 UTF-32 が提案された。UTF-32 は UCS-4 の部分集合で、32ビットの符号値を0から10FFFFの符号空間の範囲でのみ使用する。
UTF-32は、最初はUCS-4規格の部分集合だったが、ISO/IEC JTC 1/SC 2/WG 2の方針と手続きの文書は、すべての将来の文字割り当ては、BMPか最初の14の追加面に制限され、さらに私用面のうち第0群の第224–255面 (E00000–FFFFFF) と第96–127群の面 (60000000–7FFFFFFF) は削除されたと述べている。
脚注
出典
注釈
- ^ UTF（符号化形式/符号化スキーム）ではなくUCSであることに注意
参考資料
用語の日本語表記は原則として次にならった：“Unicode Terminology English - Japanese”. Unicode, Inc. 2010年1月1日閲覧。
関連項目
外部リンク
- The Unicode Standard 4.1, chapter 3 : §3.10, D43-D45にUTF-32の公式な定義
- Unicode Standard Annex #19 : Unicode 3.xにおけるUTF-32の公式な定義（2001年3月; 最終更新2002年3月）
- Registration of new charsets: UTF-32, UTF-32BE, UTF-32LE[リンク切れ] : UTF-32がIANA charset登録簿に追加されたことの告知（2002年4月）
| |||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 日本語用の 文字コード |
| ||||||||||||||||||||||||||
| 日本語を含む 多言語文字集合 |
| ||||||||||||||||||||||||||
| 日本語以外用の 文字集合 |
| ||||||||||||||||||||||||||
| ソフトウェア |
| ||||||||||||||||||||||||||
| 区分け | |||||||||||||||||||||||||||
| 概念 | |||||||||||||||||||||||||||
| 関連トピック | |||||||||||||||||||||||||||
 カテゴリ | |||||||||||||||||||||||||||
