UTF-8 est un codage de longueur variable. Dans le cas d'UTF-8, cela signifie que le stockage d'un point de code nécessite un à quatre octets. Cependant, l'encodage de MySQL appelé "utf8" (alias de "utf8mb3") ne stocke qu'un maximum de trois octets par point de code.
Ainsi, le jeu de caractères "utf8"/"utf8mb3" ne peut pas stocker tous les points de code Unicode :il ne prend en charge que la plage 0x000 à 0xFFFF, qui s'appelle le "Plan multilingue de base ".Voir aussi Comparaison des encodages Unicode .
C'est ce que (une version précédente de la même page à) la documentation MySQL a à dire à ce sujet :
Le jeu de caractères nommé utf8[/utf8mb3] utilise un maximum de trois octets par caractère et ne contient que des caractères BMP. Depuis MySQL 5.5.3, le jeu de caractères utf8mb4 utilise un maximum de quatre octets par caractère et prend en charge les caractères supplémentaires :
Pour un caractère BMP, utf8[/utf8mb3] et utf8mb4 ont des caractéristiques de stockage identiques :mêmes valeurs de code, même encodage, même longueur.
Pour un caractère supplémentaire, utf8[/utf8mb3] ne peut pas du tout stocker le caractère , tandis que utf8mb4 nécessite quatre octets pour le stocker. Étant donné que utf8[/utf8mb3] ne peut pas du tout stocker le caractère, vous n'avez aucun caractère supplémentaire dans les colonnes utf8[/utf8mb3] et vous n'avez pas à vous soucier de la conversion de caractères ou de la perte de données lors de la mise à niveau des données utf8[/utf8mb3] à partir d'anciennes versions de MySQL.
Donc, si vous souhaitez que votre colonne prenne en charge le stockage de caractères situés en dehors du BMP (et vous le souhaitez généralement), tels que émoji , utilisez "utf8mb4". Voir aussi Quels sont les caractères Unicode non BMP les plus couramment utilisés ? .