Quelle est la différence entre utf8_general_ci et utf8_unicode_ci ?

Pour les personnes qui arrivent encore à cette question en 2020 ou plus tard, il existe de nouvelles options qui peuvent être meilleures que les deux de ceux-ci. Par exemple, utf8mb4_0900_ai_ci .

Tous ces classements sont destinés au codage de caractères UTF-8. Les différences résident dans la manière dont le texte est trié et comparé.

_unicode_ci et _general_ci sont deux ensembles différents de règles pour trier et comparer le texte selon la manière attendue. Les nouvelles versions de MySQL introduisent également de nouveaux ensembles de règles, telles que _0900_ai_ci pour des règles équivalentes basées sur Unicode 9.0 - et sans équivalent _general_ci une variante. Les personnes qui lisent ceci maintenant devraient probablement utiliser l'un de ces nouveaux classements au lieu de l'un ou l'autre de _unicode_ci ou _general_ci . La description de ces anciens classements ci-dessous est fournie à titre indicatif uniquement.

MySQL s'éloigne actuellement d'une implémentation UTF-8 plus ancienne et défectueuse. Pour l'instant, vous devez utiliser utf8mb4 au lieu de utf8 pour la partie encodage des caractères, pour vous assurer d'obtenir la version corrigée. La version défectueuse reste pour la rétrocompatibilité, bien qu'elle soit obsolète.

Principales différences

• utf8mb4_unicode_ci est basé sur les règles officielles Unicode pour le tri et la comparaison universels, qui trie avec précision dans un large éventail de langues.

• utf8mb4_general_ci est un ensemble simplifié de règles de tri qui vise à faire de son mieux tout en empruntant de nombreux raccourcis destinés à gagner en rapidité. Il ne respecte pas les règles Unicode et entraînera un tri ou une comparaison indésirable dans certaines situations, par exemple lors de l'utilisation de langues ou de caractères particuliers.

  Sur les serveurs modernes, cette amélioration des performances sera pratiquement négligeable. Il a été conçu à une époque où les serveurs n'avaient qu'une infime partie des performances du processeur des ordinateurs d'aujourd'hui.

Avantages de utf8mb4_unicode_ci sur utf8mb4_general_ci

utf8mb4_unicode_ci , qui utilise les règles Unicode pour le tri et la comparaison, utilise un algorithme assez complexe pour un tri correct dans un large éventail de langues et lors de l'utilisation d'un large éventail de caractères spéciaux. Ces règles doivent tenir compte des conventions spécifiques à la langue; tout le monde ne trie pas ses caractères dans ce que nous appellerions "l'ordre alphabétique".

En ce qui concerne les langues latines (c'est-à-dire "européennes"), il n'y a pas beaucoup de différence entre le tri Unicode et le tri simplifié utf8mb4_general_ci tri dans MySQL, mais il y a encore quelques différences :

• Par exemple, le classement Unicode trie "ß" comme "ss" et "Œ" comme "OE" comme le voudraient normalement les personnes utilisant ces caractères, alors que utf8mb4_general_ci les trie comme des caractères uniques (vraisemblablement comme "s" et "e" respectivement).

• Certains caractères Unicode sont définis comme ignorables, ce qui signifie qu'ils ne doivent pas être pris en compte dans l'ordre de tri et que la comparaison doit passer au caractère suivant à la place. utf8mb4_unicode_ci les gère correctement.

Dans les langues non latines, telles que les langues asiatiques ou les langues avec des alphabets différents, il peut y en avoir beaucoup plus différences entre le tri Unicode et le utf8mb4_general_ci simplifié tri. La pertinence de utf8mb4_general_ci dépendra fortement de la langue utilisée. Pour certaines langues, ce sera tout à fait insuffisant.

Que devez-vous utiliser ?

Il n'y a presque certainement aucune raison d'utiliser utf8mb4_general_ci plus, car nous avons laissé derrière nous le point où la vitesse du processeur est suffisamment faible pour que la différence de performances soit importante. Votre base de données sera presque certainement limitée par d'autres goulots d'étranglement que celui-ci.

Dans le passé, certaines personnes recommandaient d'utiliser utf8mb4_general_ci sauf lorsqu'un tri précis allait être suffisamment important pour justifier le coût des performances. Aujourd'hui, ce coût de performance a pratiquement disparu, et les développeurs prennent l'internationalisation plus au sérieux.

Il y a un argument à faire valoir que si la vitesse est plus importante pour vous que la précision, vous pouvez tout aussi bien ne pas faire de tri du tout. Il est trivial de rendre un algorithme plus rapide si vous n'en avez pas besoin pour être précis. Alors, utf8mb4_general_ci est un compromis qui n'est probablement pas nécessaire pour des raisons de vitesse et probablement aussi inapproprié pour des raisons de précision.

Une autre chose que j'ajouterai est que même si vous savez que votre application ne prend en charge que la langue anglaise, il se peut qu'elle ait encore besoin de traiter les noms des personnes, qui peuvent souvent contenir des caractères utilisés dans d'autres langues dans lesquelles il est tout aussi important de trier correctement . L'utilisation des règles Unicode pour tout aide à ajouter la tranquillité d'esprit que les personnes très intelligentes d'Unicode ont travaillé très dur pour que le tri fonctionne correctement.

Ce que signifient les pièces

Tout d'abord, ci est pour insensible à la casse tri et comparaison. Cela signifie qu'il convient aux données textuelles et que la casse n'est pas importante. Les autres types de classement sont cs (sensible à la casse) pour les données textuelles où la casse est importante, et bin , où l'encodage doit correspondre, bit pour bit, ce qui convient aux champs qui sont réellement des données binaires encodées (y compris, par exemple, Base64). Le tri sensible à la casse conduit à des résultats étranges et la comparaison sensible à la casse peut entraîner des valeurs en double ne différant que par la casse des lettres, de sorte que les classements sensibles à la casse ne sont plus prisés pour les données textuelles - si la casse est importante pour vous, alors sinon ponctuation ignorable et ainsi de suite est probablement aussi significatif, et un classement binaire pourrait être plus approprié.

Ensuite, unicode ou general fait référence aux règles spécifiques de tri et de comparaison - en particulier, la manière dont le texte est normalisé ou comparé. Il existe de nombreux ensembles de règles différents pour le codage de caractères utf8mb4, avec unicode et general étant deux qui tentent de bien fonctionner dans toutes les langues possibles plutôt qu'une seule spécifique. Les différences entre ces deux ensembles de règles font l'objet de cette réponse. Notez que unicode utilise les règles d'Unicode 4.0. Les versions récentes de MySQL ajoutent les ensembles de règles unicode_520 en utilisant les règles d'Unicode 5.2 et 0900 (en supprimant la partie "unicode_") en utilisant les règles d'Unicode 9.0.

Et enfin, utf8mb4 est bien entendu l'encodage des caractères utilisé en interne. Dans cette réponse, je ne parle que des encodages basés sur Unicode.