10.1.14.1. Наборы символов Unicode

MySQL 5.6 поддерживает эти наборы символов Unicode:

ucs2, UCS 2 кодирования набора символов Unicode, используя 16 битов за символ.
utf16, UTF-16, кодирующий для набора символов Unicode; как ucs2 но с расширением для дополнительных символов.
utf16le, UTF-16LE, кодирующий для набора символов Unicode; как utf16 но а не обратный порядок байтов с прямым порядком байтов.
utf32, UTF-32, кодирующий для набора символов Unicode, используя 32 бита за символ.
utf8, кодирование UTF-8 набора символов Unicode, используя один - три байта за символ.
utf8mb4, кодирование UTF-8 набора символов Unicode, используя один - четыре байта за символ.

ucs2 и utf8 поддерживайте Основную Многоязычную Плоскость (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 могут также включать номер версии (например, xxx_unicode_520_ci) указать на версию Алгоритма сопоставления Unicode, на которой сопоставление базируется, как описано позже в этом разделе. Для таких сопоставлений, есть нет utf8mb3 исказите к соответствию utf8 сопоставление. См. Раздел 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 реализует xxx_unicode_ci сопоставления согласно Алгоритму сопоставления Unicode (UCA), описанный в http://www.unicode.org/reports/tr10/. Сопоставление использует версию 4.0.0 ключи веса UCA: http://www.unicode.org/Public/UCA/4.0.0/allkeys-4.0.0.txt. В настоящий момент, xxx_unicode_ci у сопоставлений есть только частичная поддержка Алгоритма сопоставления Unicode. Некоторые символы еще не поддерживаются. Кроме того, объединяющиеся метки не полностью поддерживаются. Это влияет на прежде всего вьетнамский, языка йоруба, и некоторые меньшие языки, такие как язык навахо.

MySQL реализует специфичные для языка сопоставления Unicode только если упорядочивание с xxx_unicode_ci не работает хорошо на язык. Специфичные для языка сопоставления UCA-на-основе. Они получаются из xxx_unicode_ci с дополнительными правилами адаптации языка.

Сопоставления, основанные на версиях UCA позже чем 4.0.0, включают версию в имя сопоставления. Таким образом, xxx_unicode_520_ci сопоставления основаны на UCA 5.2.0 ключа веса: http://www.unicode.org/Public/UCA/5.2.0/allkeys.txt.

LOWER() и UPPER() выполните случай, сворачивающийся согласно сопоставлению их параметра. Символ, у которого есть верхний регистр и строчные версии только в версии Unicode, более свежей чем 4.0.0, будет преобразован этими функциями, только если у параметра есть сопоставление, которое использует достаточно недавнюю версию UCA.

Для любого набора символов Unicode операции выполняли использование xxx_general_ci сопоставление быстрее чем те для xxx_unicode_ci сопоставление. Например, сравнения для utf8_general_ci сопоставление быстрее, но немного менее корректно чем сравнения для utf8_unicode_ci. Причина этого - это utf8_unicode_ci поддерживает отображения, такие как расширения; то есть, когда один символ сравнивается как равный комбинациям других символов. Например, на немецком языке и некоторых других языках"ß"равно"ss". utf8_unicode_ci также поддерживает сокращения и игнорируемые символы. utf8_general_ci сопоставление наследства, которое не поддерживает расширения, сокращения, или игнорируемые символы. Это может сделать только непосредственные сравнения между символами.

Чтобы далее иллюстрировать, следующие равенства содержат в обоих utf8_general_ci и utf8_unicode_ci (для эффекта это имеет в сравнениях или делая поискы, см. Раздел 10.1.7.8, "Примеры Эффекта Сопоставления"):

Ä = AÖ = OÜ = U

Различие между сопоставлениями - то, что это - истина для utf8_general_ci:

ß = s

Принимая во внимание, что это - истина для utf8_unicode_ci, который поддерживает немецкий DIN 1 упорядочивание (также известный как лексикографический порядок):

ß = 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_german_ci соответствие latin1_german_ci для немецкого лексикографического порядка, потому что utf8_general_ci достаточен.

xxx_swedish_ci включает шведские правила. Например, на шведском языке, следующее отношение содержит, который не является чем-то ожидаемым немецким или французским динамиком:

Ü = Y < Ö

xxx_spanish_ci и xxx_spanish2_ci сопоставления соответствуют современному испанскому и традиционному испанскому языку, соответственно. В обоих сопоставлениях,"ñ"(n-тильда) является отдельной буквой между"n"и"o". Кроме того, для традиционного испанского языка,"ch"отдельная буква между"c"и"d", и"ll"отдельная буква между"l"и"m"

В xxx_roman_ci сопоставления, I и J сравнитесь как равный, и U и V сравнитесь как равный.

xxx_croatian_ci сопоставления адаптируются для этих хорватских букв: Č, Ć, Dž, Đ, Lj, Nj, Š, Ž.

Для всех сопоставлений Unicode кроме "двоичного файла" (xxx_bin) сопоставления, MySQL выполняет поиск по таблице, чтобы найти вес сопоставления символа. Этот вес может быть выведен на экран, используя WEIGHT_STRING() функция. (См. Раздел 12.5, "Строковые функции".), Если символ не находится в таблице (например, потому что это - "новый" символ), сопоставляя определение веса становится более сложным:

Для символов BMP в общих сопоставлениях (xxx_general_ci), вес = кодовая точка.
Для символов BMP в сопоставлениях UCA (например, xxx_unicode_ci и специфичные для языка сопоставления), следующий алгоритм применяется:
```
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. Например:
```
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 сопоставления, весь palochkas вид вместе.
Для дополнительных символов в общих сопоставлениях вес является весом для 0xfffd REPLACEMENT CHARACTER. Для дополнительных символов в UCA 4.0.0 сопоставления их вес сопоставления 0xfffd. Таким образом, к MySQL все дополнительные символы равны друг другу, и больше чем почти все символы BMP.

Пример с символами Deseret и 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, тогда как у Мишени Пчелы и Deseret Deseret оба есть вес 0xfffd. (Были utf32_general_ci используемое сопоставление вместо этого, результат был бы 1, потому что у всех трех символов есть вес 0xfffd в том сопоставлении.)

Пример с клинообразными символами и WEIGHT_STRING():
```
/*The four characters in the INSERT string are00000041  # LATIN CAPITAL LETTER A0001218F  # CUNEIFORM SIGN KAB000121A7  # CUNEIFORM SIGN KISH00000042  # 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
```
Для дополнительных символов, основанных на версиях UCA позже чем 4.0.0 (например, 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. Например, следующая диаграмма показывает два редких символа. Первый символ находится в диапазоне E000-FFFF, таким образом, это больше чем заместитель, но меньше чем дополнительное. Второй символ является дополнительным.

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

Эти два символа в диаграмме в порядке значением кодовой точки потому что 0xff9d < 0x10384. И они в порядке utf8 значение, потому что 0xef < 0xf0. Но они не в порядке utf16 значение, если мы используем сравнение байта байтом, потому что 0xff > 0xd8.

Так MySQL utf16_bin сопоставление не является "байтом байтом." Это "кодовой точкой." Когда MySQL видит, что дополнительно-символьное кодирует в utf16, это преобразовывает в значение кодовой точки символа, и затем сравнивается. Поэтому, utf8_bin и utf16_bin то же самое упорядочивание. Это является непротиворечивым со стандартным требованием SQL:2008 для сопоставления UCS_BASIC: "UCS_BASIC является сопоставлением, в котором упорядочивание определяется полностью скалярными значениями Unicode символов в сортируемых строках. Это применимо к репертуару символа UCS. Так как каждый символьный репертуар является подмножеством репертуара UCS, сопоставление UCS_BASIC потенциально применимо к каждому набору символов. ОТМЕТЬТЕ 11: скалярное значение Unicode символа является своей кодовой точкой, обработанной как целое без знака."

Если набор символов ucs2, сравнение является байтом байтом, но ucs2 строки не должны содержать заместителей, так или иначе.

xxx_general_mysql500_ci сопоставления были добавлены в MySQL 5.6.5. Они сохраняют пред5.1.24 упорядочивания оригинала xxx_general_ci сопоставления и разрешение обновляют для таблиц, составленных перед MySQL 5.1.24. Для получения дополнительной информации см. Раздел 2.11.3, "Проверяя Или Таблицы, или Индексирует, Должен быть Восстановлен", и Раздел 2.11.4, "Восстанавливая или Восстанавливая Таблицы или Индексирует".

Для дополнительной информации о сопоставлениях Unicode в MySQL см. Collation-Charts.Org (utf8).