UTF-8: Общие? Бин? Юникод?

В целом utf8_general_ci быстрее, чем utf8_unicode_ci, но менее корректно.

Вот разница:

Для любого набора символов Юникода операции, выполняемые с использованием сопоставления _general_ci, быстрее, чем операции для сопоставления _unicode_ci. Например, сравнения для сортировки utf8_general_ci быстрее, но немного менее корректны, чем сравнения для utf8_unicode_ci. Причина этого в том, что utf8_unicode_ci поддерживает сопоставления, такие как расширения; то есть, когда один символ сравнивается как равный с комбинациями других символов. Например, в немецком и некоторых других языках «ß» равно «ss». utf8_unicode_ci также поддерживает сокращения и игнорируемые символы. utf8_general_ci - это устаревшее сопоставление, которое не поддерживает расширения, сокращения или игнорируемые символы. Он может производить только однозначное сравнение между персонажами.

Цитируется по: http://dev.mysql.com/doc/refman/5.0/en/charset-unicode-sets.html

Для более подробного объяснения, пожалуйста, прочтите следующее сообщение на форумах MySQL: http://forums.mysql.com/read.php?103,187048,188748

Что касается utf8_bin: и utf8_general_ci, и utf8_unicode_ci выполняют сравнение без учета регистра. Напротив, utf8_bin чувствителен к регистру (помимо других различий), потому что он сравнивает двоичные значения символов.

Вы также должны знать тот факт, что с utf8_general_ci при использовании поля varchar в качестве уникального или первичного индекса вставка двух значений, таких как 'a' и 'á', приведет к ошибке дублирования ключа.

• utf8_bin слепо сравнивает биты. Не складывается корпус, не снимаются акценты.
• utf8_general_ci сравнивает одну кодовую точку с одной кодовой точкой. Выполняется сворачивание регистра и удаление акцента, но без сравнения двух символов; например: ij не равно ij в этом сопоставлении.
• utf8_*_ci - это набор правил для конкретного языка, но в остальном похож на unicode_ci. Некоторые особые случаи: Ç, Č, ch, ll
• utf8_unicode_ci следует старому стандарту Unicode для сравнений. _12 _ = _ 13_, но ae! = æ
• utf8_unicode_520_ci следует новому стандарту Unicode. ae = æ

См. диаграмму сопоставления для получения подробной информации о том, что равно чему в различных сопоставлениях utf8.

utf8, в соответствии с определением MySQL ограничен 1–3-байтовыми кодами utf8. Это не учитывает Emoji и некоторые из китайских. Так что вам действительно стоит перейти на utf8mb4, если вы хотите выйти далеко за пределы Европы.

Вышеуказанные пункты относятся к utf8mb4 после соответствующего изменения написания. В дальнейшем предпочтительнее использовать utf8mb4 и utf8mb4_unicode_520_ci.

• utf16 и utf32 - варианты на utf8; они практически бесполезны.
• ucs2 ближе к Unicode, чем utf8; от него практически нет никакой пользы.

Принятый ответ устарел.

Если вы используете MySQL 5.5.3+, используйте utf8mb4_unicode_ci вместо utf8_unicode_ci, чтобы символы, вводимые вашими пользователями, не вызывали ошибок.

utf8mb4 поддерживает, например, смайлы, а utf8 может выдать сотни ошибок, связанных с кодированием, например:

Incorrect string value: ‘\xF0\x9F\x98\x81…’ for column ‘data’ at row 1

На самом деле, я тестировал сохранение таких значений, как «é» и «e» в столбце с индексом уникальный, и они вызывают повторяющуюся ошибку как для «utf8_unicode_ci», так и «utf8_general_ci». Вы можете сохранить их только в сопоставленном столбце utf8_bin.

И документы mysql (в http://dev.mysql.com/doc/refman/5.7/en/charset-applications.html) предлагает в своих примерах установить параметры сортировки utf8_general_ci.

[mysqld]
character-set-server=utf8
collation-server=utf8_general_ci