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_ciucs2_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_ciutf8
照合順序の utf8mb3
エイリアスはありません。セクション10.1.10.6「utf8mb3 文字セット (utf8 のエイリアス)」を参照してください。
xxx
_binxxx
_croatian_cixxx
_czech_cixxx
_danish_cixxx
_esperanto_cixxx
_estonian_ci
(デフォルト)xxx
_general_cixxx
_german2_cixxx
_general_mysql500_cixxx
_hungarian_cixxx
_icelandic_cixxx
_latvian_cixxx
_lithuanian_cixxx
_persian_cixxx
_polish_cixxx
_roman_cixxx
_romanian_cixxx
_sinhala_cixxx
_slovak_cixxx
_slovenian_cixxx
_spanish_cixxx
_spanish2_cixxx
_swedish_cixxx
_turkish_cixxx
_unicode_cixxx
_vietnamese_ci
MySQL は、http://www.unicode.org/reports/tr10/ で説明している Unicode 照合順序アルゴリズム (UCA) に従って
照合順序を実装します。照合順序は、バージョン 4.0.0 UCA 重みキー (http://www.unicode.org/Public/UCA/4.0.0/allkeys-4.0.0.txt) を使用します。現在、xxx
_unicode_ci
照合順序は、Unicode 照合順序アルゴリズムを一部だけサポートします。中にはまだサポートされていない文字もあります。また、結合マークは完全にはサポートされていません。これは主に、ベトナム語、ヨルバ語、ナバホ語などの一部のより小さな言語に影響します。組み合わされた文字は、文字列比較では、単一の Unicode 文字で書き込まれた同じ文字とは異なると見なされ、2 つの文字は長さが異なると考えられます (たとえば、xxx
_unicode_ciCHAR_LENGTH()
関数で返されたものや、結果セットのメタデータにおけるもの)。
での順序付けが各言語で適切に機能しない場合にのみ、MySQL は言語固有の Unicode 照合順序を実装します。言語固有の照合順序は UCA ベースです。これらは、追加の言語の調整ルールを使用して、xxx
_unicode_ci
から派生されます。
xxx
_unicode_ci
4.0.0 以降の UCA バージョンに基づく照合順序では、照合順序名の中にバージョンが含まれます。したがって、
照合順序は、UCA 5.2.0 重みキー (http://www.unicode.org/Public/UCA/5.2.0/allkeys.txt) に基づきます。
xxx
_unicode_520_ci
LOWER()
および UPPER()
は、その引数の照合順序に従って、大文字と小文字の変換を実行します。4.0.0 より新しい Unicode バージョンでのみ大文字バージョンと小文字バージョンがある文字は、新しい UCA バージョンを使用する照合順序が引数にある場合にのみ、これらの機能によって変換されます。
Unicode 文字セットの場合、
照合順序を使用して実行する演算は、xxx
_general_ci
照合順序のものよりも高速です。たとえば、xxx
_unicode_ciutf8_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_ciI
と J
は等しいと見なされ、U
と V
は等しいと見なされます。
照合順序は、xxx
_croatian_ciČ
、Ć
、Dž
、Đ
、Lj
、Nj
、Š
、Ž
のクロアチア語の文字を調整します。
「バイナリ」 (
) 照合順序を除くすべての Unicode 照合順序に対し、MySQL は文字の照合重みを探すようにテーブルルックアップを実行します。この重みは、xxx
_binWEIGHT_STRING()
関数を使用して表示できます。(セクション12.5「文字列関数」を参照してください。)文字がテーブル内にない場合 (たとえば、「新しい」文字であるため)、照合重み判定がより複雑になります。
一般的な照合順序 (
) での BMP 文字の場合、重み = コードポイント。xxx
_general_ci-
UCA 照合順序 (たとえば、
と言語固有の照合順序) での BMP 文字の場合、次のアルゴリズムが適用されます。xxx
_unicode_ciif (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_ci0x0dc6
の重みを持ちますが、デザレット 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 バージョンに基づいた補助文字の場合 (たとえば、
)、必ずしもすべての補助文字が同じ照合順序重みを持つとはかぎりません。一部には、UCAxxx
_unicode_520_ciallkeys.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
照合順序の 5.1.24 以前の順序付けを維持し、MySQL 5.1.24 より前に作成されたテーブルのアップグレードを許可します。詳細は、セクション2.11.3「テーブルまたはインデックスの再構築が必要かどうかのチェック」およびセクション2.11.4「テーブルまたはインデックスの再作成または修復」を参照してください。
xxx
_general_ci