Maison > base de données > tutoriel mysql > Quelle est la différence entre l'encodage utf8 et utf8mb4 dans MySQL ?

Quelle est la différence entre l'encodage utf8 et utf8mb4 dans MySQL ?

不言
Libérer: 2019-03-26 11:26:46
avant
2644 Les gens l'ont consulté

Le contenu de cet article concerne la différence entre l'encodage utf8 et utf8mb4 dans MySQL ? Il a une certaine valeur de référence. Les amis dans le besoin peuvent s'y référer. J'espère qu'il vous sera utile.

1. Introduction

MySQL a ajouté le codage utf8mb4 après 5.5.3 signifie la plupart des octets 4, qui est spécialement conçu pour être compatible avec quatre octets. Heureusement, utf8mb4 est un sur-ensemble de utf8 et aucune autre conversion n'est requise, à l'exception de 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 MySQL prend en charge l'encodage utf8 ? la longueur maximale des caractères est de 3 octets. Si un caractère de 4 octets de large est rencontré, une exception sera insérée. 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, 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.


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!

Étiquettes associées:
source:jouypub
Déclaration de ce site Web
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
Tutoriels populaires
Plus>
Derniers téléchargements
Plus>
effets Web
Code source du site Web
Matériel du site Web
Modèle frontal