1. Introduction
MySQL a ajouté ce codage utf8mb4 après la version 5.5.3, ce qui signifie la plupart des octets 4, et est spécifiquement utilisé pour être compatible avec l’unicode quatre octets. Heureusement, utf8mb4 est un surensemble de utf8, et aucune autre conversion n’est nécessaire à part changer l’encodage en utf8mb4. Bien sûr, pour économiser de la place, il suffit généralement d’utiliser utf8.
2. Description du contenu
Comme mentionné plus haut, puisque l’utf8 peut sauvegarder la plupart des caractères chinois, pourquoi utiliser l’utf8mb4 ? La longueur maximale de caractères du codage UTF8 pris en charge par MySQL est de 3 octets, et si vous rencontrez un caractère large de 4 octets, vous insérerez une exception. Le caractère Unicode maximum encodé par UTF-8 de trois octets est 0xffff, qui est le plan multilingue de base (BMP) dans Unicode. C’est-à-dire que tout caractère Unicode qui ne se trouve pas dans le plan multitexte de base ne peut pas être stocké en utilisant le jeu de caractères utf8 de Mysql. Cela inclut les emojis (Emoji est un encodage Unicode spécial couramment trouvé sur les téléphones iOS et Android), ainsi que de nombreux caractères chinois peu utilisés, ainsi que tout nouveau caractère Unicode, et bien d’autres.
3. La cause profonde du problème
Le format original UTF-8 utilisait de un à six octets et pouvait encoder jusqu’à 31 caractères. La dernière spécification UTF-8 n’utilise que un à quatre octets et peut encoder jusqu’à 21 bits, ce qui représente exactement 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, ce qui constitue le plan multitexte de base dans Unicode.
Pourquoi UTF8 dans MySQL ne supporte-t-il que les caractères UTF-8 avec un maximum de trois octets ? J’y ai réfléchi, peut-être parce que lorsque MySQL a été développé, Unicode n’avait pas de plan auxiliaire. À cette époque, le Comité Unicode rêvait encore de « 65 535 caractères suffisent pour le monde entier ». Les longueurs de chaînes dans MySQL comptent les caractères plutôt que les octets, et pour les types de données CHAR, les chaînes doivent être suffisamment longues. Lors de l’utilisation du jeu de caractères utf8, la longueur à préserver est la longueur de caractère la plus longue de l’utf8 multipliée par la longueur de la chaîne, il est donc naturel de limiter la longueur maximale utf8 à 3, par exemple, CHAR(100) Mysql conservera 300 octets. Quant à la raison pour laquelle les versions suivantes 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 sauvegarder des caractères UTF-8 de 4 octets dans Mysql, le jeu de caractères utf8mb4 est nécessaire, mais il n’est pris en charge qu’après la version 5.5.3 (voir version : select version() ; )。 Je pense que pour une meilleure compatibilité, il faut toujours utiliser utf8mb4 au lieu d’utf8. Pour les données de type CHAR, utf8mb4 prend plus d’espace, et selon la recommandation officielle de Mysql, utilisez VARCHAR au lieu de CHAR.
|
Publié le 2021-4-21 à 18:01:22
|
|
|
|
