UTF-8: генерал? Бен? Unicode?

Я пытаюсь выяснить, какую сортировку я должен использовать для различных типов данных. 100% содержимого, которое я буду хранить, отправлено пользователем.

Насколько я понимаю, я должен использовать UTF-8 General CI (без учета регистра) вместо UTF-8 Binary. Однако я не могу найти четкого различия между UTF-8 General CI и UTF-8 Unicode CI.

1. Должен ли я хранить пользовательский контент в столбцах UTF-8 General или UTF-8 Unicode CI?
2. К какому типу данных будет применяться UTF-8 Binary?

В общем, utf8_general_ci быстрее, чем utf8_unicode_ci , но менее правильно.

Вот разница:

Для любого набора символов Unicode операции, выполняемые с использованием параметров сортировки _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 для сравнения. ij= ij, но ae! =æ
• utf8_unicode_520_ciследует более новому стандарту Unicode. aeзнак равноæ

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

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

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

• utf16 и utf32 являются вариантами на utf8; для них практически нет смысла.
• ucs2 ближе к "Unicode", чем "utf8"; это практически бесполезно.

Действительно, я протестировал сохранение значений, таких как 'é' и '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

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

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

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

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