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

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 のエイリアス)」を参照してください。

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「文字列関数」を参照してください。)文字がテーブル内にない場合 (たとえば、「新しい」文字であるため)、照合重み判定がより複雑になります。

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「テーブルまたはインデックスの再作成または修復」を参照してください。

MySQL での Unicode 照合順序の追加情報については、Collation-Charts.Org (utf8) を参照してください。