Ce que vous avez est EXTRATERRESTRIAL ALIEN (U+1F47D)
et BROKEN HEART (U+1F494)
qui ne sont pas dans le plan multilingue de base. Ils ne peuvent même pas être représentés en Java par un seul caractère, "👽💔".length() == 4 . Ce ne sont certainement pas des caractères nuls et vous verrez des carrés si vous n'utilisez pas de polices qui les prennent en charge.
Pour un caractère supplémentaire, utf8 ne peut pas du tout stocker le caractère, tandis que utf8mb4 nécessite quatre octets pour le stocker. Étant donné que utf8 ne peut pas du tout stocker le caractère, vous n'avez pas de caractères supplémentaires dans les colonnes utf8 et vous n'avez pas à vous soucier de la conversion des caractères ou de la perte de données lors de la mise à niveau des données utf8 à partir d'anciennes versions de MySQL.
Donc, pour prendre en charge ces caractères, votre MySQL doit être 5.5+ et vous devez utiliser utf8mb4 partout. L'encodage de connexion doit être utf8mb4 , le jeu de caractères doit être utf8mb4 et la collecte doit être utf8mb4 . Pour Java, c'est toujours "utf-8" , mais MySQL a besoin d'une distinction.
Je ne sais pas quel pilote vous utilisez, mais un moyen indépendant du pilote pour définir le jeu de caractères de connexion consiste à envoyer la requête :
SET NAMES 'utf8mb4'
Juste après avoir fait la connexion.
Voir aussi ceci pour Connector/J :
14.14 :Comment puis-je utiliser UTF8 4 octets, utf8mb4 avec Connector/J ?
Pour utiliser UTF8 à 4 octets avec Connector/J, configurez le serveur MySQL aveccharacter_set_server=utf8mb4. Connector/J utilisera alors ce paramètretant que characterEncoding n'a pas été défini dans la chaîne de connexion . Cela équivaut à la détection automatique du jeu de caractères.
Ajustez également vos colonnes et votre base de données :
var1 varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NOT NULL
Encore une fois, votre version de MySQL doit être relativement à jour pour la prise en charge d'utf8mb4.
