Spec-Zone .ru
спецификации, руководства, описания, API
|
MySQL 5.7 поддерживает эти наборы символов 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 и дополнительные
символы.
Можно сохранить текст приблизительно на 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_ciutf8mb3
исказите к соответствию 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 реализует
сопоставления согласно Алгоритму сопоставления Unicode (UCA), описанный в xxx
_unicode_ci
у
сопоставлений есть только частичная поддержка Алгоритма сопоставления Unicode. Некоторые символы еще не
поддерживаются. Кроме того, объединяющиеся метки не полностью поддерживаются. Это влияет на прежде всего
вьетнамский, языка йоруба, и некоторые меньшие языки, такие как язык навахо. xxx
_unicode_ci
MySQL реализует специфичные для языка сопоставления Unicode только если упорядочивание с
не работает хорошо на язык.
Специфичные для языка сопоставления UCA-на-основе. Они получаются из xxx
_unicode_ci
с дополнительными правилами адаптации языка.
xxx
_unicode_ci
Сопоставления, основанные на версиях UCA позже чем 4.0.0, включают версию в имя сопоставления. Таким образом,
сопоставления основаны
на UCA 5.2.0 ключа веса: xxx
_unicode_520_ci
LOWER()
и UPPER()
выполните случай, сворачивающийся согласно сопоставлению их параметра.
Символ, у которого есть верхний регистр и строчные версии только в версии Unicode, более свежей чем 4.0.0, будет
преобразован этими функциями, только если у параметра есть сопоставление, которое использует достаточно недавнюю
версию UCA.
Для любого набора символов Unicode операции выполняли использование
сопоставление быстрее чем те для xxx
_general_ci
сопоставление. Например,
сравнения для xxx
_unicode_ciutf8_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_ciI
и J
сравнитесь как равный, и U
и V
сравнитесь как равный.
сопоставления адаптируются
для этих хорватских букв: xxx
_croatian_ciČ
, Ć
, Dž
,
Đ
, Lj
, Nj
, Š
, Ž
.
Для всех сопоставлений Unicode кроме "двоичного файла"
(
) сопоставления, MySQL выполняет
поиск по таблице, чтобы найти вес сопоставления символа. Этот вес может быть выведен на экран, используя xxx
_binWEIGHT_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_ci0x0dc6
, тогда как у
Мишени Пчелы и 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
основные веса как в FFFD
вес для KAB и также для KISH.
Правило, что все дополнительные символы равны друг другу, неоптимально, но, как ожидают, не доставит неприятности. Эти символы очень редки, таким образом, будет очень редко, чтобы мультисимвольная строка состояла полностью из дополнительных символов. В Японии, так как дополнительные символы являются неясными идеограммами Кандзи, типичный пользователь не заботится, что упорядочивает, они находятся в, так или иначе. Если Вы действительно хотите строки, сортированные правилом MySQL и во вторую очередь значением кодовой точки, это легко:
ORDER BY s1 COLLATE utf32_unicode_ci, s1 COLLATE utf32_bin
Для дополнительных символов, основанных на версиях UCA позже чем 4.0.0 (например,
), у
дополнительных символов не обязательно все есть тот же самый вес сопоставления. У некоторых есть явные
веса от UCA xxx
_unicode_520_ciallkeys.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
строки не должны содержать заместителей, так или иначе.
сопоставления
сохраняют пред5.1.24 упорядочивания оригинала xxx
_general_mysql500_ci
сопоставления и разрешение обновляют для
таблиц, составленных перед MySQL 5.1.24. Для получения дополнительной информации см. Раздел
2.11.3, "Проверяя Или Таблицы, или Индексирует, Должен быть Восстановлен", и Раздел
2.11.4, "Восстанавливая или Восстанавливая Таблицы или Индексирует". xxx
_general_ci
Для дополнительной информации о сопоставлениях Unicode в MySQL см. Collation-Charts.Org