ア | イ | ウ | エ | オ |
カ | キ | ク | ケ | コ |
サ | シ | ス | セ | ソ |
タ | チ | ツ | テ | ト |
ナ | ニ | ヌ | ネ | ノ |
ハ | ヒ | フ | ヘ | ホ |
マ | ミ | ム | メ | モ |
ヤ | ユ | ヨ | ||
ラ | リ | ル | レ | ロ |
ワ | ヰ | ヴ | ヱ | ヲ |
ン |
A | B | C | D | E |
F | G | H | I | J |
K | L | M | N | O |
P | Q | R | S | T |
U | V | W | X | Y |
Z | 数字 | 記号 |
UTF-16と呼ばれる、Unicodeの符号化方法で使われる拡張方法のこと。
可決寸前だった32ビットコード体系ISO/IEC 10646の案DIS 10646 1.0を潰してまで16ビット固定長として1991(平成3)年10月に作られたUnicodeではあったが、そのビット数から潜在的に最大で65,536種類の文字しか扱えないという制限があった。
当初発表されたUnicode 1.0にはまだ約2万字分の空きが存在したが、その後の文字追加要望が後をたたず、Unicode 2.0策定中の1995(平成7)年の時点で既に16ビット(65,536字)に収まらないことが明らかとなった。尤も、最初から16ビットで収まらないことに気付かない方がどうかしていたとも言える。
今後Unicodeを続けて行くためには、この問題を解決しなければならない。
まだこの頃は、異体字セレクターの仕様も存在しなかった。これが初登場したUnicode 3.2.0は、2002(平成14)年3月で遥か後である。
そこでUnicodeは、16ビットに収める事を諦めて、コードレンジを拡張することにしたのである。
また、UTF-8も存在しなかった。最初の仕様RFC 2279が作られたのは1998(平成10)年1月である。従って、16ビット単位の符号系で使える方法の模索が、至上命令だった。
そこで考案されたのが、サロゲートペアによる拡張方法だった。
1996(平成8)年に改訂されたUnicode 2.0規格では、従来未定義で残された文字コード領域を利用して、サロゲートと呼ばれるコードを用意した。
上位サロゲート1,024個(0xD800〜0xDBFF)と下位サロゲート1,024個(0xDC00〜0xDFFF)からなる制御文字であり、これを互いに組み合わせることで1024×1024=1,048,576字の拡張を実現した。二組を組み合わせることから「ペア」という名が付いた。
これは256×256で構成される、従来の基本多言語面の範囲で16面分(約100万文字)に相当する範囲となる。
サロゲートをどの範囲にするかは色々な選択肢があったが、バランスからこの量が選択された。
サロゲート512個×512個だと4面分(約26万文字)にしかならず少ない、2048個×2048個だと64面分(約400万文字)になるが、これは多すぎると考えられた。
実際に、将来的にも100万字を埋め尽くす可能性は低く、仮にあったとしても、その頃には別の方法で符号化されているはずだ、とも考えられた結果であった。
この拡張を併用することで、ISO/IEC 10646のうち00群00面〜00群16面までの合計17面分の文字(U+00000000〜U+0010ffffの文字)が利用可能となった。
00群17面以降はどうするのか、という問題はあり、それゆえにUTF-16を付け焼き刃と酷評する向きもあったが、全ての面を埋めることは当分の間は無いと見込まれている。
また、Unicodeだけでなく、ISO/IEC 10646も、00群00面〜00群16面の範囲内のみに文字を定義することが決定された。
このサロゲートを利用した符号化はUnicode用語としてUTF-16と命名された。
これがRFC化されたのはかなり後で、Unicode 3.0が出た後、2000(平成12)年2月で、UTF-8よりも遅い。
コメントなどを投稿するフォームは、日本語対応時のみ表示されます