削除された内容 追加された内容
→‎文字符号化スキーム: 「いつ範囲」解除(Word 2016 + UTF-32 の組み合わせで挙動を確認)。UTF-32の項目を適宜段落に分割。
40行目:
; UTF-32
{{main|UTF-32}}
: Unicodeのすべての符号位置を単一長の符号単位として32ビットで表現する文字符号化形式及び文字符号化スキーム。実際に使われるのは21ビット(Unicodeの符号空間がU+10FFFFまでであるため)であり、この21ビットの範囲内では[[UCS-4]]と互換性がある。
: UTF-32符号化スキームでもUTF-16符号化スキームと同じく、[[ビッグエンディアン]]と[[リトルエンディアン]]が存在し、それぞれ'''UTF-32BE'''、'''UTF-32LE'''と呼ばれる。プロトコル若しくはアプリケーションの設定などの手段で符号化スキームに'''UTF-32BE'''や'''UTF-32LE'''を指定している場合にはBOMを付与することは許容されない(BOMの符号位置はZERO WIDTH NON-BREAKING SPACEとみなす)。
: 単純な符号化スキームであるが、テキストファイルなどではファイルのサイズが大きくなる(すべてBMPの文字からなる文章の場合はUTF-16符号スキームの2倍、すべてASCII文字の場合はASCII/UTF-8の4倍のサイズとなる)ため、ストレージ用として使われることは稀である。そのためか、{{いつ範囲|date=2016年6月14日|[[Microsoft Office]]での「エンコードされたテキストファイル」の読み書きこの、Office 2016 でもいまだに符号化スキームにはいまだに対応していない}}。[[フリーウェア]]・[[シェアウェア]]の[[テキストエディタ]]のうち多数の符号化スキームに対応しているものでも、この符号化スキームには対応していないものが存在する。
: ただし、すべてのUnicode文字を処理する場合には、すべての文字を単一の符号単位で表現したほうが処理に適するため、内部の処理ではUTF-32符号化形式(あるいはUCS-4)で扱うこともある。実例として、[[Linux]] 上の[[C言語]]環境では <code>wchar_t</code> は32ビット整数型である。
:UTF-16符号化スキームなどと同様にUTF-32符号化スキームにもBOMがあり、データストリームの先頭に付される。先頭の4バイトがFF FE 00 00ならリトルエンディアン、00 00 FE FFならビッグエンディアンになる。UTF-16のリトルエンディアンとUTF-32のリトルエンディアンは最初の2バイトが等しいため、4バイトまで読んで判断する必要がある。
<br />
 
以下は[[エイプリルフール]]に公開された[[Request for Comments#ジョークRFC|ジョークRFC]]である (RFC 4042)。UTF-9に関しては同名の規格が実際に検討されていた(ただし内容は大きく異なる)が、ドラフト段階で破棄されているため重複にはならない。
; UTF-9