UTF-8: général? Ben? Unicode?

j'essaie de comprendre quelle compilation je devrais utiliser pour différents types de données. 100% du contenu que je stockerai est soumis par l'utilisateur.

ma compréhension est que je devrais utiliser UTF-8 générale CI (insensible à la casse) au lieu de UTF-8 binaire. Cependant, je ne trouve pas de distinction claire entre L'IC général UTF-8 et L'IC Unicode UTF-8.

  1. si je stocke du contenu soumis par l'utilisateur dans UTF-8 general ou UTF-8 Unicode CI les colonnes?
  2. à quel type de données le binaire UTF-8 serait-il applicable?
260
demandé sur hjpotter92 2010-02-26 22:03:55

4 réponses

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 de la collation _general_ci sont plus rapides que celles de la collation _unicode_ci . Par exemple, les comparaisons pour la collation utf8_general_ci sont plus rapides, mais légèrement moins rapides. correct, que les comparaisons pour utf8_unicode_ci. La raison en est que utf8_unicode_ci supporte les mappages tels que les extensions, c'est-à-dire lorsqu'un caractère se compare à des combinaisons d'autres caractères. Par exemple, en allemand et dans d'autres langues "ß" est égal à "ss". utf8_unicode_ci supporte aussi les contractions et les caractères ignorables. utf8_general_ci est une compilation héritée qui ne supporte pas les expansions, les contractions ou les caractères ignorables. Il ne peut faire qu'un contre un comparaisons 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

comme pour utf8_bin: À la fois utf8_general_ci et utf8_unicode_ci effectuer une comparaison non sensible à la casse. En constrast, utf8_bin est sensible à la casse (entre autres différences), parce qu'il compare les valeurs binaires des caractères.

280
répondu Sagi 2011-09-16 16:41:51

vous devez également être conscient du fait qu'avec utf8_general_ci en utilisant un champ varchar comme index unique ou primaire, l'insertion de 2 valeurs comme 'A' et 'á' donnerait une erreur clé dupliquée.

85
répondu Alex Hepp 2011-01-19 14:11:30
  • utf8_bin compare les bits aveuglément. Pas de pliage d'étui, pas de strip-tease d'accent.
  • utf8_general_ci compare un octet avec un octet. Il n'y a pas de comparaison à deux caractères: ij n'est pas égal à ij dans cette collation.
  • utf8_*_ci est un ensemble de règles spécifiques à la langue, mais par ailleurs comme unicode_ci . Quelques cas particuliers: Ç , Č , ch , ll
  • utf8_unicode_ci suit une ancienne norme Unicode pour les comparaisons. ij = ij , mais ae != æ
  • utf8_unicode_520_ci suit une nouvelle norme Unicode. ae = æ

Voir classement graphique pour plus de détails sur ce qui est égal à ce qui, dans divers utf8 classements.

utf8 , tel que défini par MySQL est limité aux codes utf8 de 1 à 3 octets. Il n'y a pas D'Emoji ni de Chinois. Vous devriez donc passer à utf8mb4 si vous voulez aller bien au-delà de l'Europe.

les points ci-dessus s'appliquent à utf8mb4 , après un changement d'orthographe approprié. À l'avenir, utf8mb4 et utf8mb4_unicode_520_ci sont préférables.

  • utf16 et utf32 sont des variantes sur utf8; il y a pratiquement aucune utilité pour eux.
  • ucs2 est plus proche de" Unicode "que" utf8"; il est pratiquement inutile pour elle.
23
répondu Rick James 2016-07-29 17:54:16

en fait, j'ai testé des valeurs de sauvegarde comme "é" et "e" dans la colonne avec l'index unique et ils causent une erreur de duplication sur 'utf8_unicode_ci' et 'utf8_general_ci'. Vous pouvez les enregistrer seulement dans la colonne' utf8_bin ' collated.

et mysql docs (in http://dev.mysql.com/doc/refman/5.7/en/charset-applications.html ) suggère dans ses exemples l'ensemble 'utf8_general_ci' collation. 

[mysqld]
character-set-server=utf8
collation-server=utf8_general_ci
6
répondu vitalii 2015-07-01 07:11:34