10.1.14.1 Unicode 文字セット

MySQL 5.6 は、次の Unicode 文字セットをサポートします。

• ucs2。文字ごとに 16 ビットを使用する Unicode 文字セットの UCS-2 エンコーディング。

• utf16。Unicode 文字セットの UTF-16 エンコーディング。ucs2 に似ていますが、補助文字用の拡張機能があります。

• utf16le。Unicode 文字セットの UTF-16LE エンコーディング。utf16 と似ていますが、ビッグエンディアンではなくリトルエンディアンです。

• utf32。文字ごとに 32 ビットを使用した Unicode 文字セットの UTF-32 エンコーディング。

• utf8。文字ごとに 1 から 3 バイトを使用する Unicode 文字セットの UTF-8 エンコーディング。

• utf8mb4。文字ごとに 1 から 4 バイトを使用した Unicode 文字セットの UTF-8 エンコーディング。

ucs2 および utf8 は、Basic Multilingual Plane (BMP) 文字をサポートします。utf8mb4、utf16、utf16le、および utf32 は BMP と補助文字をサポートします。utf16le は MySQL 5.6.1 で追加されました。

これらの文字セットを使用すると、約 650 の言語でテキストを格納できます。このセクションでは、Unicode 文字セットごとに利用可能な照合順序を示し、それらを区別するプロパティーについて説明します。文字セットの一般的な情報については、セクション10.1.10「Unicode のサポート」を参照してください。

類似した一連の照合順序を、ほとんどの Unicode 文字セットで使用できます。これらは次のリストに表示されます。ここで xxx は文字セット名を表します。たとえば、xxx_danish_ci はデンマーク語の照合順序を表し、具体的には ucs2_danish_ci、utf16_danish_ci、utf32_danish_ci、utf8_danish_ci、および utf8mb4_danish_ci の名前を構成します。

utf16le に対する照合順序のサポートはさらに限定されます。使用可能な唯一の照合順序は、utf16le_general_ci と utf16le_bin です。これらは、utf16_general_ci と utf16_bin に似ています。

このセクションで後述するように、Unicode 照合順序名には、照合順序が基づいている Unicode 照合順序アルゴリズムのバージョンを示すバージョン番号も含まれる場合があります (たとえば xxx_unicode_520_ci)。このような照合順序の場合、対応する utf8 照合順序の utf8mb3 エイリアスはありません。セクション10.1.10.6「utf8mb3 文字セット (utf8 のエイリアス)」を参照してください。

• xxx_bin

• xxx_croatian_ci

• xxx_czech_ci

• xxx_danish_ci

• xxx_esperanto_ci

• xxx_estonian_ci

• xxx_general_ci (デフォルト)

• xxx_german2_ci

• xxx_general_mysql500_ci

• xxx_hungarian_ci

• xxx_icelandic_ci

• xxx_latvian_ci

• xxx_lithuanian_ci

• xxx_persian_ci

• xxx_polish_ci

• xxx_roman_ci

• xxx_romanian_ci

• xxx_sinhala_ci

• xxx_slovak_ci

• xxx_slovenian_ci

• xxx_spanish_ci

• xxx_spanish2_ci

• xxx_swedish_ci

• xxx_turkish_ci

• xxx_unicode_ci

• xxx_vietnamese_ci

MySQL は、http://www.unicode.org/reports/tr10/ で説明している Unicode 照合順序アルゴリズム (UCA) に従って xxx_unicode_ci 照合順序を実装します。照合順序は、バージョン 4.0.0 UCA 重みキー (http://www.unicode.org/Public/UCA/4.0.0/allkeys-4.0.0.txt) を使用します。現在、xxx_unicode_ci 照合順序は、Unicode 照合順序アルゴリズムを一部だけサポートします。中にはまだサポートされていない文字もあります。また、結合マークは完全にはサポートされていません。これは主に、ベトナム語、ヨルバ語、ナバホ語などの一部のより小さな言語に影響します。組み合わされた文字は、文字列比較では、単一の Unicode 文字で書き込まれた同じ文字とは異なると見なされ、2 つの文字は長さが異なると考えられます (たとえば、CHAR_LENGTH() 関数で返されたものや、結果セットのメタデータにおけるもの)。

xxx_unicode_ci での順序付けが各言語で適切に機能しない場合にのみ、MySQL は言語固有の Unicode 照合順序を実装します。言語固有の照合順序は UCA ベースです。これらは、追加の言語の調整ルールを使用して、xxx_unicode_ci から派生されます。

4.0.0 以降の UCA バージョンに基づく照合順序では、照合順序名の中にバージョンが含まれます。したがって、xxx_unicode_520_ci 照合順序は、UCA 5.2.0 重みキー (http://www.unicode.org/Public/UCA/5.2.0/allkeys.txt) に基づきます。

LOWER() および UPPER() は、その引数の照合順序に従って、大文字と小文字の変換を実行します。4.0.0 より新しい Unicode バージョンでのみ大文字バージョンと小文字バージョンがある文字は、新しい UCA バージョンを使用する照合順序が引数にある場合にのみ、これらの機能によって変換されます。

Unicode 文字セットの場合、xxx_general_ci 照合順序を使用して実行する演算は、xxx_unicode_ci 照合順序のものよりも高速です。たとえば、utf8_general_ci 照合順序の比較は、utf8_unicode_ci の比較よりも高速ですが、精度は少し低くなります。この理由は、utf8_unicode_ci では、ある文字がほかの文字の組み合わせに等しいものと見なされる拡張形式などのマッピングをサポートしているためです。たとえば、ドイツ語とほかのいくつかの言語では、「ß」は「ss」と同じです。utf8_unicode_ci は、短縮形式と無視可能な文字もサポートします。utf8_general_ci は、拡張形式、短縮形式、無視可能な文字をサポートしない従来の照合順序です。文字間で 1 対 1 の比較しかできません。

さらに説明するために、次の等式は utf8_general_ci と utf8_unicode_ci の両方で構成されています (比較または検索を行うときのこの効果については、セクション10.1.7.8「照合順序の効果の例」を参照してください)。

Ä = A
Ö = O
Ü = U

照合順序間の違いは、次の式が utf8_general_ci に当てはまるという点です。

ß = s

一方、次の式は、ドイツ語 DIN-1 順序 (辞書順序とも呼ばれます) をサポートする utf8_unicode_ci に当てはまります。

ß = ss

MySQL が utf8 文字セットに対する言語固有の照合順序を実行するのは、utf8_unicode_ci による順序付けが言語に対してうまく機能しないときだけです。たとえば、utf8_unicode_ci は、ドイツ語辞書順序とフランス語には適切に機能するので、特殊な utf8 照合順序を作成する必要はありません。

utf8_general_ci も、ドイツ語とフランス語の両方にとって十分ですが、「ß」が「s」に等しく、「ss」に等しくない点が異なります。これがアプリケーションで許容可能な場合は、utf8_general_ci のほうが高速なので、こちらを使用する必要があります。これが許容できない場合 (たとえば、ドイツ語辞書順序が必要な場合) は、utf8_unicode_ci のほうがより正確なので、こちらを使用してください。

ドイツ語 DIN-2 (電話帳) 順序が必要な場合は、utf8_german2_ci 照合順序を使用してください。これは次の文字セットを等しいものと見なします。

Ä = Æ = AE
Ö = Œ = OE
Ü = UE
ß = ss

utf8_german2_ci は、latin1_german2_ci に似ていますが、後者は、「Æ」を「AE」に、または「Œ」を「OE」に等しいものとは見なしません。utf8_general_ci で十分であるので、ドイツ語辞書順序のための latin1_german_ci に対応する utf8_german_ci はありません。

xxx_swedish_ci には、スウェーデン語のルールが含まれます。たとえば、スウェーデン語には、ドイツ語やフランス語を使用するユーザーでは予期しないような次の関係があります。

Ü = Y < Ö

xxx_spanish_ci および xxx_spanish2_ci 照合順序は、それぞれ現代のスペイン語と伝統的なスペイン語に対応しています。どちらの照合順序でも、「ñ」 (n チルダ) は、「n」と「o」の間の独立した文字です。さらに、伝統的なスペイン語の場合、「ch」は、「c」と「d」の間の独立した文字であり、「ll」は、「l」と「m」の間の独立した文字です。

xxx_spanish2_ci 照合順序は、アストゥリアス語およびガリーシア語にも使用できます。

xxx_danich_ci 照合順序は、ノルウェー語にも使用できます。

xxx_roman_ci 照合順序では、I と J は等しいと見なされ、U と V は等しいと見なされます。

xxx_croatian_ci 照合順序は、Č、Ć、Dž、Đ、Lj、Nj、Š、Ž のクロアチア語の文字を調整します。

「バイナリ」 (xxx_bin) 照合順序を除くすべての Unicode 照合順序に対し、MySQL は文字の照合重みを探すようにテーブルルックアップを実行します。この重みは、WEIGHT_STRING() 関数を使用して表示できます。(セクション12.5「文字列関数」を参照してください。)文字がテーブル内にない場合 (たとえば、「新しい」文字であるため)、照合重み判定がより複雑になります。

• 一般的な照合順序 (xxx_general_ci) での BMP 文字の場合、重み = コードポイント。

• UCA 照合順序 (たとえば、xxx_unicode_ci と言語固有の照合順序) での BMP 文字の場合、次のアルゴリズムが適用されます。

  if (code >= 0x3400 && code <= 0x4DB5)
    base= 0xFB80; /* CJK Ideograph Extension */
  else if (code >= 0x4E00 && code <= 0x9FA5)
    base= 0xFB40; /* CJK Ideograph */
  else
    base= 0xFBC0; /* All other characters */
  aaaa= base +  (code >> 15);
  bbbb= (code & 0x7FFF) | 0x8000;

  結果は、aaaa に bbbb が続いた 2 つの照合要素のシーケンスになります。例:

  mysql> SELECT HEX(WEIGHT_STRING(_ucs2 0x04CF COLLATE ucs2_unicode_ci));
  +----------------------------------------------------------+
  | HEX(WEIGHT_STRING(_ucs2 0x04CF COLLATE ucs2_unicode_ci)) |
  +----------------------------------------------------------+
  | FBC084CF                                                 |
  +----------------------------------------------------------+

  したがって、U+04cf CYRILLIC SMALL LETTER PALOCHKA は、すべての UCA 4.0.0 照合順序で、U+04c0 CYRILLIC LETTER PALOCHKA より大きくなります。UCA 5.2.0 照合順序では、すべての palochka は一緒にソートされます。

• 一般的な照合順序の補助文字の場合、重みは 0xfffd REPLACEMENT CHARACTER の重みです。UCA 4.0.0 照合順序の補助文字の場合、照合重みは 0xfffd です。つまり、MySQL では、すべての補助文字は互いに等しく、ほとんどすべての BMP 文字より大きくなります。

  デザレット文字と COUNT(DISTINCT) を使用した例:

  CREATE TABLE t (s1 VARCHAR(5) CHARACTER SET utf32 COLLATE utf32_unicode_ci);
  INSERT INTO t VALUES (0xfffd);   /* REPLACEMENT CHARACTER */
  INSERT INTO t VALUES (0x010412); /* DESERET CAPITAL LETTER BEE */
  INSERT INTO t VALUES (0x010413); /* DESERET CAPITAL LETTER TEE */
  SELECT COUNT(DISTINCT s1) FROM t;

  結果は 2 です。これは、MySQL xxx_unicode_ci 照合順序で、置換文字は 0x0dc6 の重みを持ちますが、デザレット B とデザレット T はどちらも、0xfffd の重みを持つからです。(utf32_general_ci 照合順序が代わりに使用された場合、この照合順序ではすべての 3 文字が 0xfffd の重みを持つので、結果は 1 になります。)

  くさび形文字と WEIGHT_STRING() を使用した例:

  /*
  The four characters in the INSERT string are
  00000041  # LATIN CAPITAL LETTER A
  0001218F  # CUNEIFORM SIGN KAB
  000121A7  # CUNEIFORM SIGN KISH
  00000042  # LATIN CAPITAL LETTER B
  */
  CREATE TABLE t (s1 CHAR(4) CHARACTER SET utf32 COLLATE utf32_unicode_ci);
  INSERT INTO t VALUES (0x000000410001218f000121a700000042);
  SELECT HEX(WEIGHT_STRING(s1)) FROM t;

  結果は次のようになります。

  0E33 FFFD FFFD 0E4A

  0E33 と 0E4A は、UCA 4.0.0 の主要な重みです。FFFD は KAB の重みであり、KISH の重みでもあります。

  すべての補助文字が互いに同じであるというルールは、最適ではありませんが、問題を引き起こすとは考えられません。これらの文字は非常に珍しく、マルチ文字文字列全体が補助文字から構成されることは非常にまれです。日本では、補助文字はあいまいな漢字表意文字であるので、一般的なユーザーは、いずれにしてもそれらの順序を気にしません。実際には、MySQL のルールに従って行をソートし、二次的にコードポイント値でソートする場合、次のようにすることが簡単です。

  ORDER BY s1 COLLATE utf32_unicode_ci, s1 COLLATE utf32_bin

• 4.0.0 以降の UCA バージョンに基づいた補助文字の場合 (たとえば、xxx_unicode_520_ci)、必ずしもすべての補助文字が同じ照合順序重みを持つとはかぎりません。一部には、UCA allkeys.txt ファイルからの明示的な重みがあります。それ以外には、このアルゴリズムから計算された重みがあります。

  aaaa= base +  (code >> 15);
  bbbb= (code & 0x7FFF) | 0x8000;

utf16_bin 照合順序

「文字のコード値による順序付け」と「文字のバイナリ表現による順序付け」と間には違いがあります。これは、サロゲートのために、utf16_bin でのみ表示される違いです。

utf16_bin (utf16 のバイナリ照合順序) が、「文字ごと」ではなく「バイトごと」のバイナリ比較であったとします。その場合は、utf16_bin での文字の順序は utf8_bin での順序とは異なります。たとえば、次の表には 2 つの珍しい文字が示されています。最初の文字は E000-FFFF の範囲にあるので、サロゲートより大きくなりますが、補助文字より小さくなります。2 番目の文字は補助文字です。

Code point  Character                    utf8         utf16
----------  ---------                    ----         -----
0FF9D       HALFWIDTH KATAKANA LETTER N  EF BE 9D     FF 9D
10384       UGARITIC LETTER DELTA        F0 90 8E 84  D8 00 DF 84

表の 2 つの文字は、0xff9d < 0x10384 であるので、コードポイント値による順序になります。また、0xef < 0xf0 なので、utf8 値による順序になります。ただし、0xff > 0xd8 なので、バイトごとの比較を使用する場合は、utf16 値による順序にはなりません。

したがって、MySQL の utf16_bin 照合順序は「バイトごと」にはなりません。「コードポイントによる」順序になります。MySQL は、utf16 での補助文字エンコーディングを認識すると、文字のコードポイント値に変換してから比較します。したがって、utf8_bin と utf16_bin の順序付けは同じになります。これは、UCS_BASIC 照合順序の SQL:2008 標準の要件に一致します。「UCS_BASIC は、ソートされている文字列の文字の Unicode スカラー値によって、順序付け全体が決定される照合順序です。これは UCS 文字レパートリーに適用できます。すべての文字レパートリーは、UCS レパートリーのサブセットなので、UCS_BASIC 照合順序は、すべての文字セットに適用できる可能性があります。ノート 11: 文字の Unicode スカラー値は、符号なしの整数として扱われるそのコードポイントです。」

文字セットが ucs2 である場合、比較はバイトごとになりますが、いずれにしても、ucs2 文字列にはサロゲートを含めないでください。

MySQL 5.6.5 で xxx_general_mysql500_ci 照合順序が追加されました。これらは、元の xxx_general_ci 照合順序の 5.1.24 以前の順序付けを維持し、MySQL 5.1.24 より前に作成されたテーブルのアップグレードを許可します。詳細は、セクション2.11.3「テーブルまたはインデックスの再構築が必要かどうかのチェック」およびセクション2.11.4「テーブルまたはインデックスの再作成または修復」を参照してください。