Maison  >  Article  >  base de données  >  Quelles sont les différences entre utf8 et utf8mb4 dans MySQL ?

Quelles sont les différences entre utf8 et utf8mb4 dans MySQL ?

不言
不言original
2018-08-22 10:00:531602parcourir

Ce que cet article vous apporte, c'est quelles sont les différences entre utf8 et utf8mb4 dans MySQL ? , a une certaine valeur de référence, les amis dans le besoin peuvent s'y référer, j'espère que cela vous sera utile.

1. Introduction

MySQL a ajouté le codage utf8mb4 après la version 5.5.3, ce qui signifie la plupart des octets 4, qui est spécialement conçu pour être compatible avec l'Unicode à quatre octets. Heureusement, utf8mb4 est un sur-ensemble de utf8, donc aucune autre conversion n'est requise sauf changer l'encodage en utf8mb4. Bien entendu, pour économiser de l'espace, il suffit généralement d'utiliser utf8.

2. Description du contenu

Comme mentionné ci-dessus, puisque utf8 peut stocker la plupart des caractères chinois, pourquoi devrions-nous utiliser utf8mb4 Il s'avère que la longueur maximale de caractères de l'encodage utf8 prise en charge par MySQL est de 3 ? caractères. Une exception sera insérée si un caractère de 4 octets de large est rencontré. Le caractère Unicode maximum pouvant être codé par UTF-8 à trois octets est 0xffff, qui est le plan multilingue de base (BMP) en Unicode. En d'autres termes, tous les caractères Unicode qui ne figurent pas dans le plan multitexte de base ne peuvent pas être stockés à l'aide du jeu de caractères utf8 de Mysql. Y compris les expressions Emoji (Emoji est un encodage Unicode spécial, courant sur les téléphones iOS et Android), de nombreux caractères chinois peu courants, ainsi que tout nouveau caractère Unicode, etc.

3. Source du problème

Le format UTF-8 d'origine utilise un à six octets et peut encoder jusqu'à 31 caractères. La dernière spécification UTF-8 n'utilise qu'un à quatre octets et peut coder jusqu'à 21 bits, ce qui est juste suffisant pour représenter les 17 plans Unicode.

utf8 est un jeu de caractères dans Mysql qui ne prend en charge que les caractères UTF-8 jusqu'à trois octets, qui est le plan multi-texte de base dans Unicode.

Pourquoi utf8 dans Mysql ne prend-il en charge que les caractères UTF-8 d'une longueur maximale de trois octets ?
J'y ai réfléchi pendant un moment, c'est peut-être parce que lorsque Mysql a commencé à être développé, Unicode n'avait pas de plan auxiliaire. A cette époque, le comité Unicode rêvait encore que « 65 535 caractères suffisent pour le monde entier ». La longueur de la chaîne dans Mysql est calculée en nombre de caractères plutôt qu'en nombre d'octets. Pour le type de données CHAR, une longueur suffisante doit être réservée pour la chaîne. Lors de l'utilisation du jeu de caractères utf8, la longueur qui doit être réservée est la longueur de caractère la plus longue de utf8 multipliée par la longueur de la chaîne, donc bien sûr la longueur maximale de utf8 est limitée à 3. Par exemple, CHAR(100) Mysql réservera 300 octets. Quant à savoir pourquoi les versions ultérieures ne prennent pas en charge les caractères UTF-8 de 4 octets, je pense que l'une est pour des raisons de compatibilité ascendante, et l'autre est que les caractères en dehors du plan multilingue de base sont rarement utilisés.

Pour enregistrer des caractères UTF-8 de 4 octets dans Mysql, vous devez utiliser le jeu de caractères utf8mb4, mais il n'est pris en charge qu'après la version 5.5.3 (afficher la version : sélectionner la version ();). Je pense que pour obtenir une meilleure compatibilité, vous devriez toujours utiliser utf8mb4 au lieu de utf8. Pour les données de type CHAR, utf8mb4 consommera plus d'espace. Selon les recommandations officielles de Mysql, utilisez VARCHAR au lieu de CHAR.

Recommandations associées :

Comment modifier la limite de longueur de la fonction group_conca dans MySQL

Utilisation de count() dans la grande table MySQL et count dans mysql Optimisation de ()

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!

Déclaration:
Le contenu de cet article est volontairement contribué par les internautes et les droits d'auteur appartiennent à l'auteur original. Ce site n'assume aucune responsabilité légale correspondante. Si vous trouvez un contenu suspecté de plagiat ou de contrefaçon, veuillez contacter admin@php.cn