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

Question

Я пытаюсь выяснить, какую сортировку я должен использовать для различных типов данных. 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?

Answer 1

Как правило, 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 чувствителен к регистру (среди прочих различий), потому что он сравнивает двоичные значения символов.

Answer 2

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

Answer 3

• 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 ограничено кодами utf8 длиной от 1 до 3 байтов. Это оставляет эмодзи и некоторые китайцы. Так что вам действительно стоит переключиться на utf8mb4, если вы хотите выйти далеко за пределы Европы.

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

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

Answer 4

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

Answer 5

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

Если вы используете 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