utf8 general ci что это
В чём разница между кодировками utf8_general_ci, utf8_unicode_ci, utf8mb4_general_ci, utf8mb4_unicode_ci. Какую кодировку выбрать для базы данных MySQL
Начиная с MySQL 5.5.3 вы должны использовать utf8mb4, а не utf8. Обе эти группы относятся к кодировке UTF-8, но более старая utf8 имеет специфичные для MySQL ограничения, не дающие использовать символы, пронумерованные выше 0xFFFD.
Таким образом, больше не нужно использовать ни utf8_general_ci, ни utf8_unicode_ci.
Что касается новых версий кодировки utf8mb4_general_ci и utf8mb4_unicode_ci. То предпочтительной является unicode, а не general. Вариант utf8mb4_general_ci будет чуть более быстрым при сортировке (в настоящее время это уже неактуально), но имеет проблемы с сортировкой в определённых языках. Кодировка utf8mb4_unicode_ci лишена этих недостатков.
Итак, в настоящее время для баз данных и таблиц MySQL рекомендуется использовать кодировку utf8mb4_unicode_ci.
Совет: для сохранения места с utf8mb4, используйте VARCHAR вместо CHAR. В противном случае MySQL будет резервировать четыре байта для каждого символа в стобце CHAR CHARACTER SET utf8mb4, поскольку это максимально возможная длина. Например, MySQL должна зарезервировать 40 байт для столбца CHAR(10) CHARACTER SET utf8mb4.
При настройке подключения к базе данных (БД) может возникнуть затруднение при выборе кодировки БД. Обычно предлагается целый список кодировок, а точнее сопоставлений (сравнений или наборов символов) и в каждой версии СУБД предлагаемая кодировка может отличаться.
Например, ранее по умолчанию предлагался набор utf8_general_ci. Пользователь может не знать, какая кодировка используется, так как выбор может происходить автоматически при установки готовых веб-приложений. Кодировка может применяться по умолчанию при создании базы данных вручную при помощи, например, phpMyAdmin. Выбранная кодировка распространяется на все таблицы БД и это влияет на то, как будут обрабатываться данные при запросах. Например, может обнаружиться, что при выборке данных не учитывается регистр или, не сохраняются некоторые символы из других языков и прочие объекты (смайлы и т.д.).
Какую кодировку выбрать для БД и таблиц? Для большинства проектов рекомендуется выбирать из подмножества кодировок, относящихся к utf8. Но здесь есть отличия в названиях сопоставлений. Сопоставления utf8 являются 3-ех байтными, для простоты у них не указывается mb3. Обычная utf8 имеет специфичные ограничения MySQL, которые не позволяют использовать символы выше 0xFFFD.
Для старых приложений возможно стоит использовать utf8_general_ci, для новых – utf8mb4_general_ci, utf8mb4_unicode_ci или utf8mb4_0900_ai_ci. Предпочтительным вариантом является не general, а unicode. Отличаются они тем, что utf8mb4_general_ci немного быстрее при выполнении сортировки, но могут возникать проблемы с сортировкой для некоторых языков, в то время как utf8mb4_unicode_ci не имеет подобного недостатка.
Как расшифровываются названия кодировок? Рассмотрим на примере utf8mb4_0900_ai_ci. Здесь:
– utf8 обозначает кодировку;
– mb4 обозначает версию или сколько байт используется в обработке данных для одного символа. Если не указано, то обычно подразумевается mb3;
– 0900 обозначает версию алгоритма сопоставления Unicode (UCA), на которой базируется сопоставление. Если не указано, то обычно подразумевается версия 4.0.0;
– ai обозначает нечувствительность к диакритическим знакам (например, древнегреческие ᾱ, ᾰ). Если не указано, подразумевается ai или as в зависимости от следующей части в имени сравнения, то есть ai для ci и as для cs;
– ci обозначает нечувствительность к регистру, означает, что не будет разницы между строчными и заглавными символами в запросах к БД. Существуют также версии cs, которые являются чувствительными к регистру.
Различные ошибки и предупреждения можно увидеть в отчете используемой системы. Там обычно предлагается перейти на использования современных кодировок из комплекта utf8mb4. Например, в Drupal в отчете состояния можно увидеть строку:
Database 4 byte UTF-8 support – Отключено. 4 byte UTF-8 for mysql is disabled. See the documentation on adding 4 byte UTF-8 support for more information.
Это означает, что система рекомендует использовать новые 4-ех байтные кодировки взамен старых из коллекции utf8.
При написании программного кода может возникать ошибка вида: Unknown collation: ‘utf8mb4_0900_ai_ci’ (Неизвестное сопоставление: ‘utf8mb4_0900_ai_ci’). Это в большинстве случае означает отсутствие требуемой кодировки на сервере баз данных. Например, utf8mb4_0900_ai_ci – это новое сопоставление, доступное только начиная с MySQL 8.0. Также ошибка может появиться в случае применения кодировки, предназначенной для MySQL в другой СУБД, например, в MariaDB. Наборы кодировок различаются от версии к версии, а также для разных СУБД.
Drupal Русскоязычное сообщество
Подскажите, в какой кодировке в utf8_general_ci или в utf8_unicode_ci будет меньше проблем и в чем различия между этими двумя кодировками?
Комментарии
Это НЕ КОДИРОВКА, это способ СРАВНЕНИЯ слов и букв.
http://dev.mysql.com/doc/refman/5.0/en/charset-unicode-sets.html
MySQL implements the utf8_unicode_ci collation according to the Unicode Collation Algorithm (UCA) described at http://www.unicode.org/reports/tr10/. The collation uses the version-4.0.0 UCA weight keys: http://www.unicode.org/Public/UCA/4.0.0/allkeys-4.0.0.txt. The following discussion uses utf8_unicode_ci, but it is also true for ucs2_unicode_ci.
Currently, the utf8_unicode_ci collation has only partial support for the Unicode Collation Algorithm. Some characters are not supported yet. Also, combining marks are not fully supported. This affects primarily Vietnamese, Yoruba, and some smaller languages such as Navajo.
The most significant feature in utf8_unicode_ci is that it supports expansions; that is, when one character compares as equal to combinations of other characters. For example, in German and some other languages ‘ß’ is equal to ‘ss’.
utf8_general_ci is a legacy collation that does not support expansions. It can make only one-to-one comparisons between characters. This means that comparisons for the utf8_general_ci collation are faster, but slightly less correct, than comparisons for utf8_unicode_ci.
For example, the following equalities hold in both utf8_general_ci and utf8_unicode_ci:
A difference between the collations is that this is true for utf8_general_ci:
Whereas this is true for utf8_unicode_ci:
MySQL implements language-specific collations for the utf8 character set only if the ordering with utf8_unicode_ci does not work well for a language. For example, utf8_unicode_ci works fine for German and French, so there is no need to create special utf8 collations for these two languages.
utf8_general_ci also is satisfactory for both German and French, except that ‘ß’ is equal to ‘s’, and not to ‘ss’. If this is acceptable for your application, then you should use utf8_general_ci because it is faster. Otherwise, use utf8_unicode_ci because it is more accurate.
utf8_swedish_ci, like other utf8 language-specific collations, is derived from utf8_unicode_ci with additional language rules. For example, in Swedish, the following relationship holds, which is not something expected by a German or French speaker:
Да, конечно, если в языке нет таких хитрых букв как в немецком.
В чем разница между utf8 general ci и utf8 unicode ci
5 ответов
эти две сортировки предназначены для кодировки символов UTF-8. Различия заключаются в том, как сортируется и сравнивается текст.
точность
utf8mb4_unicode_ci основан на стандарте Unicode для сортировки и сравнения, который сортирует точно в очень широком диапазоне языков.
utf8mb4_general_ci не удается реализовать все правила сортировки Unicode, что приведет к нежелательной Сортировке в некоторых ситуациях, например, при использовании определенных языков или символов.
производительность
utf8mb4_general_ci быстрее при сравнении и сортировке, потому что требуется куча производительности, связанных ярлыки.
на современных серверах это повышение производительности будет почти незначительным. Он был разработан в то время, когда серверы имели крошечную долю производительности процессора современных компьютеров.
что касается латинских (т. е. «европейских») языков, нет большой разницы между сортировкой Unicode и упрощенным utf8mb4_general_ci сортировка в MySQL, но есть еще несколько различий:
например, параметры сортировки Юникода сортируют » ß «как» ss «и» Œ «как» OE», как люди, использующие эти символы, обычно хотят, тогда как utf8mb4_general_ci сортирует их как одиночные символы (предположительно, как «s» и «e» соответственно).
некоторые символы Юникода определяются как игнорируемые, что означает, что они не должны рассчитывать на порядок сортировки, и сравнение должно перейти к следующему символу. utf8mb4_unicode_ci обрабатывает их должным образом.
в нелатинских языках, таких как азиатские языки или языки с разными алфавитами, может быть много больше различия между Unicode сортировка и упрощенная utf8mb4_general_ci сортировка. Пригодность utf8mb4_general_ci будет сильно зависеть от используемого языка. Для некоторых языков этого будет недостаточно.
что вы должны использовать?
почти наверняка нет причин использовать utf8mb4_general_ci больше, так как мы оставили позади точку, где скорость процессора достаточно низкая, что разница в производительности будет важна. Ваша база данных почти наверняка будет ограничена другими узкими местами, чем этот.
разница в производительности будет измеряться только в чрезвычайно специализированных ситуациях, и если это вы, вы, вероятно, уже знаете об этом. Если вы испытываете медленную сортировку, почти во всех случаях это будет проблема с вашим планом индексов/запросов. Изменение функции сортировки не должно быть высоким в списке вещей для устранения неполадок.
в прошлом, некоторые люди рекомендуют использовать utf8mb4_general_ci за исключением тех случаев, когда точная сортировка будет достаточно важно, чтобы оправдать затраты на производительность. Сегодня эта стоимость производительности практически исчезла, и разработчики относятся к интернационализации более серьезно.
еще одна вещь, которую я добавлю, что даже если вы знаете, что ваше приложение поддерживает только английский язык, ему все равно может потребоваться иметь дело с именами людей, которые часто могут содержать символы, используемые на других языках, в которых так же важно правильно сортировать. Использование правил Unicode для всего помогает добавьте душевное спокойствие, что очень умные люди Unicode очень много работали, чтобы сортировка работала правильно.
Я хотел знать, какова разница в производительности между использованием utf8_general_ci и utf8_unicode_ci, но я не нашел никаких тестов, перечисленных в интернете, поэтому я решил создать тесты сам.
Я создал очень простую таблицу с 500000 строк:
затем я заполнил его случайными данными, выполнив эту хранимую процедуру:
затем я создал следующие хранимые процедуры для проверки простого выбора, выбора с помощью LIKE и сортировка (выбрать по порядку):
в хранимых процедурах выше utf8_general_ci используется сортировка, но, конечно, во время тестов я использовал utf8_general_ci и utf8_unicode_ci.
я вызывал каждую хранимую процедуру 5 раз для каждой сортировки (5 раз для utf8_general_ci и 5 раз для utf8_unicode_ci), а затем вычислял средние значения.
мои результаты:
benchmark_simple_select() с utf8_general_ci: 9957 МС
benchmark_simple_select () с utf8_unicode_ci: 10271 ms
В этом тесте использовать utf8_unicode_ci медленнее, чем utf8_general_ci на 3,2%.
benchmark_select_like () с utf8_general_ci: 11441 ms
benchmark_select_like () с utf8_unicode_ci: 12811 ms
В этом тесте использование utf8_unicode_ci медленнее, чем utf8_general_ci на 12%.
benchmark_order_by () с utf8_general_ci: 11944 ms
benchmark_order_by() с utf8_unicode_ci: 12887 ms
В этом тесте использовать utf8_unicode_ci медленнее, чем utf8_general_ci на 7,9%.
этот пост описывает это очень красиво.
короче говоря: utf8_unicode_ci использует алгоритм сортировки Юникода, как определено в стандартах Юникода, тогда как utf8_general_ci-более простой порядок сортировки, который приводит к «менее точным» результатам сортировки.
для любого набора символов Юникода, операции, выполняемые с использованием _general_ci параметры сортировки быстрее, чем для _unicode_ci параметров сортировки. Например, сравнения для utf8_general_ci сортировки быстрее, но чуть менее правильно, чем сравнение utf8_unicode_ci. Этот причина этого в том, что utf8_unicode_ci поддерживает такие сопоставления как расширения; то есть, когда один персонаж сравнивает равным комбинации других персонажей. Для например, на немецком и некоторых других языках языки «ß» равны «ss». utf8_unicode_ci также поддерживает схватки и игнорируемые персонажи. utf8_general_ci-это устаревшие параметры сортировки это не поддерживает расширения, схватки, или игнорируемые персонажи. Это может сделать только один-к-одному сравнения между персонажами.
Итак, utf_general_ci использует меньший и менее правильные (согласно стандарту) набор сравнений, чем utf_unicode_ci, который должны выполнить весь стандарт. Набор general_ci будет быстрее, потому что меньше вычислений.
вкратце:
Если вам нужен лучший порядок сортировки-используйте utf8_unicode_ci (это предпочтительный способ),
различия с точки зрения производительности очень незначительны.
В чем разница между utf8_general_ci и utf8_unicode_ci?
Между utf8_general_ci и utf8_unicode_ci есть ли различия с точки зрения производительности?
Эти два сопоставления предназначены для кодировки символов UTF-8. Различия в том, как текст сортируется и сравнивается.
Ключевые отличия
utf8mb4_unicode_ci основан на официальных правилах Unicode для универсальной сортировки и сравнения, которая точно сортирует по широкому спектру языков.
На современных серверах это повышение производительности будет практически незначительным. Он был разработан в то время, когда серверы имели небольшую долю производительности ЦП современных компьютеров.
Преимущества utf8mb4_unicode_ci более utf8mb4_general_ci
Некоторые символы Юникода определены как игнорируемые, что означает, что они не должны учитываться в порядке сортировки, и сравнение должно перейти к следующему символу. utf8mb4_unicode_ci обращается с этим правильно.
В нелатинских языках, таких как азиатские языки или языки с разными алфавитами, может быть намного больше различий между сортировкой Unicode и упрощенной utf8mb4_general_ci сортировкой. Пригодность utf8mb4_general_ci будет сильно зависеть от используемого языка. Для некоторых языков это будет совершенно неадекватно.
Что вы должны использовать?
В прошлом некоторые люди рекомендовали использовать, utf8mb4_general_ci за исключением случаев, когда точная сортировка будет достаточно важной, чтобы оправдать затраты производительности. Сегодня эта производительность практически исчезла, и разработчики относятся к интернационализации более серьезно.
Можно привести аргумент, что если скорость важнее для вас, чем точность, вы также можете вообще ничего не делать. Тривиально сделать алгоритм быстрее, если вам не нужно, чтобы он был точным. Таким образом, utf8mb4_general_ci это компромисс, который, вероятно, не нужен по соображениям скорости и, вероятно, также не подходит по соображениям точности.
Что означают части
И, наконец, utf8mb4 конечно же, внутренняя кодировка символов. В этом ответе я говорю только о Unicode-кодировках.