utf16 文字セットは、補助文字のエンコーディングを可能にする拡張機能を備えた ucs2 文字セットです。
BMP 文字の場合、
utf16とucs2には、同じコード値、同じエンコーディング、同じ長さという同一のストレージ特性があります。補助文字の場合、
utf16には、32 ビットを使用する文字を表すための特殊シーケンスがあります。 これは、「サロゲート」メカニズムと呼ばれます。0xffffより大きな数値の場合、10 ビットを確保して、これらを0xd800に追加し、最初の 16 ビット語に配置します。さらに 10 ビットを確保して、これらを0xdc00に追加し、次の 16 ビット語に配置します。 この結果、すべての補助文字に 32 ビットが必要になります。このうち最初の 16 ビットは0xd800と0xdbffの間の数値であり、残りの 16 ビットは0xdc00と0xdfffの間の数値になります。 Unicode 4.0 ドキュメントの「15.5 Surrogates Area」に例が記載されています。
utf16 はサロゲートをサポートし、ucs2 をサポートしていないので、utf16 でのみ適用される妥当性チェックがあります。下位サロゲートがなければ上位サロゲートを挿入できず、逆も同様です。 例:
INSERT INTO t (ucs2_column) VALUES (0xd800); /* legal */
INSERT INTO t (utf16_column)VALUES (0xd800); /* illegal */
技術的に有効であるが真の Unicode ではない文字 (つまり、Unicode が「未割り当てコードポイント」または「個人使用」文字、さらには 0xffff のように「不正」と見なす文字) に対する妥当性チェックはありません。 たとえば、U+F8FF は Apple のロゴなので、これは有効です。
INSERT INTO t (utf16_column)VALUES (0xf8ff); /* legal */このような文字は、すべてのユーザーに対し同じ意味を持たせることは期待できません。
MySQL は、最悪の場合 (文字が 4 バイトを必要とする場合) に対応する必要があるので、utf16 カラムまたはインデックスの最大長は、ucs2 カラムまたはインデックスの最大長の半分しかありません。 たとえば、MEMORY テーブルのインデックスキーの最大長は 3072 バイトであるため、次のステートメントは、ucs2 および utf16 カラムに対して許可されている最長のインデックスを持つテーブルを作成します:
CREATE TABLE tf (s1 VARCHAR(1536) CHARACTER SET ucs2) ENGINE=MEMORY;
CREATE INDEX i ON tf (s1);
CREATE TABLE tg (s1 VARCHAR(768) CHARACTER SET utf16) ENGINE=MEMORY;
CREATE INDEX i ON tg (s1);