UTF-8: Général? Poubelle? Unicode?

J'essaie de comprendre quel classement je devrais utiliser pour différents types de données. 100% du contenu que je vais stocker est soumis par l'utilisateur.

Ma compréhension est que je devrais utiliser UTF-8 General CI (insensible à la casse) au lieu de UTF-8 Binary. Cependant, je ne trouve pas de distinction claire entre UTF-8 General CI et UTF-8 Unicode CI.

1. Dois-je stocker du contenu soumis par l'utilisateur dans des colonnes CI UTF-8 Général ou UTF-8 Unicode?
2. À quel type de données le binaire UTF-8 serait-il applicable?

En général, utf8_general_ci est plus rapide que utf8_unicode_ci , mais moins correct.

Voici la différence:

Pour tout jeu de caractères Unicode, les opérations effectuées à l'aide du classement _general_ci sont plus rapides que celles du classement _unicode_ci . Par exemple, les comparaisons pour le classement utf8_general_ci sont plus rapides, mais légèrement moins correctes, que les comparaisons pour utf8_unicode_ci. La raison en est que utf8_unicode_ci prend en charge les mappages tels que les extensions; c'est-à-dire lorsqu'un caractère se compare comme étant égal à des combinaisons d'autres caractères. Par exemple, en allemand et dans d'autres langues, «ß» est égal à «ss». utf8_unicode_ci prend également en charge les contractions et les caractères ignorables. utf8_general_ci est un classement hérité qui ne prend pas en charge les extensions, les contractions ou les caractères ignorables. Il ne peut faire que des comparaisons un à un entre les caractères.

Cité de: http://dev.mysql.com/doc/refman/5.0/en/charset-unicode-sets.html

Pour une explication plus détaillée, veuillez lire l'article suivant sur les forums MySQL: http://forums.mysql.com/read.php?103,187048,188748

Quant à utf8_bin: utf8_general_ci et utf8_unicode_ci effectuent tous deux une comparaison insensible à la casse. En contraste , utf8_bin est sensible à la casse (entre autres différences), car il compare les valeurs binaires des caractères.

Vous devez également être conscient du fait qu'avec utf8_general_ci lorsque vous utilisez un champ varchar comme index unique ou primaire, l'insertion de 2 valeurs comme 'a' et 'á' donnerait une erreur de clé en double.

• utf8_bincompare les bits à l'aveugle. Pas de pliage de boîtier, pas de décapage d'accent.
• utf8_general_cicompare un octet à un octet. Il inclut le pliage et la suppression d'accentuation, mais aucune comparaison à 2 caractères: ijn'est pas égal ijdans ce classement.
• utf8_*_ciest un ensemble de règles spécifiques à la langue, mais sinon comme unicode_ci. Quelques cas particuliers: Ç, Č, ch,ll
• utf8_unicode_cisuit un ancien standard Unicode pour les comparaisons. ij= ij, mais ae! =æ
• utf8_unicode_520_cisuit une nouvelle norme Unicode. ae=æ

Voir le tableau de classement pour plus de détails sur ce qui est égal à quoi dans divers classements utf8.

utf8, tel que défini par MySQL, est limité aux codes utf8 de 1 à 3 octets. Cela laisse de côté Emoji et certains chinois. Vous devriez donc vraiment passer à utf8mb4si vous voulez aller bien au-delà de l'Europe.

Les points ci-dessus s'appliquent à utf8mb4, après un changement d'orthographe approprié. Aller de l'avant, utf8mb4et utf8mb4_unicode_520_cisont préférés.

• utf16 et utf32 sont des variantes de utf8; il n'y a pratiquement aucune utilité pour eux.
• ucs2 est plus proche de "Unicode" que de "utf8"; il est pratiquement inutile.

Vraiment, j'ai testé les valeurs de sauvegarde comme 'é' et 'e' dans la colonne avec un index unique et elles provoquent des erreurs en double sur 'utf8_unicode_ci' et 'utf8_general_ci'. Vous ne pouvez les enregistrer que dans la colonne assemblée «utf8_bin».

Et les documents mysql (dans http://dev.mysql.com/doc/refman/5.7/en/charset-applications.html ) suggèrent dans ses exemples un ensemble de collations 'utf8_general_ci'.

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

La réponse acceptée est obsolète.

Si vous utilisez MySQL 5.5.3+, utilisez utf8mb4_unicode_ciplutôt que utf8_unicode_cipour vous assurer que les caractères saisis par vos utilisateurs ne vous donneront pas d'erreurs.

utf8mb4prend en charge les emojis par exemple, alors qu'il utf8pourrait vous donner des centaines de bogues liés à l'encodage comme:

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