Maison >base de données >tutoriel mysql >Une brève discussion sur la question du jeu de caractères de sauvegarde MySQL
[Introduction] 1 Introduction Le choix du jeu de caractères lors de la sauvegarde de MySQL est un problème difficile, en particulier pour les entreprises disposant de jeux de caractères variables. Mysqldump utilise utf8 par défaut, et utf8 est également officiellement recommandé. Mais en fait, pour le chinois, un nombre considérable de caractères codés gbk n'ont pas d'encodages Unicode correspondants, ce qui signifie que cette partie du jeu de caractères
Sélection du jeu de caractères lors de la sauvegarde up MySQL est un problème difficile, en particulier pour les entreprises avec des jeux de caractères variables. mysqldump utilise utf8 par défaut, et utf8 est également officiellement recommandé. Mais en fait, pour le chinois, une partie considérable des caractères codés en gbk n'ont pas de codage Unicode correspondant, ce qui signifie que l'utilisation d'une sauvegarde utf8 pour cette partie du jeu de caractères entraînera une perte de données. Alors y a-t-il une solution ?
Bien sûr, le moyen le plus direct est d'ajouter le mappage de cette partie de l'encodage. Cependant, le nombre de cette partie du jeu de caractères n'est pas un petit nombre, et ce qui est encore plus ennuyeux, c'est qu'il ne semble pas y avoir de norme de mappage faisant autorité pour cette partie du jeu de caractères. Alors, y a-t-il un autre moyen ?
En fait, si vous utilisez le binaire pour la sauvegarde, il n'y aura pas de processus de conversion du jeu de caractères et les problèmes ci-dessus n'existeront pas. Alors, l’utilisation du binaire résout-elle tous les problèmes de gbk ? La réponse est NON.
Avant de parler des problèmes binaires. Il y a 2 questions qui doivent être clarifiées. Pour la sauvegarde MySQL, elle est divisée en deux parties : les informations de schéma et les données réelles. Les informations de schéma sont toujours codées en utf8, à l'exception de la valeur par défaut. C'est de là que vient le problème.
Sauvegarde 2.1 utf8
(1) Le fichier .frm stockera les informations de schéma de la table et stockera la valeur par défaut de chaque champ via un enregistrement réel. Les informations correspondant au schéma (y compris les commentaires) sont stockées en utilisant utf8, mais la valeur par défaut est stockée en utilisant le jeu de caractères spécifié par la table.
(2) Lors de l'exécution de l'instruction show create table, mysqld convertira la valeur par défaut en frm de l'encodage spécifié par la table en encodage utf8.
(3) Lorsque mysqld exécute l'instruction create table, la valeur par défaut sera convertie de utf8 au jeu de caractères spécifié par la table.
2.2 sauvegarde binaire
Si le binaire est spécifié pour la sauvegarde. Lors de l'importation, avant de créer la table, bien que Character_set_client soit spécifié comme utf8, collation_connection est toujours binaire. Par conséquent, la conversion de utf8 vers le jeu de caractères spécifié par la table ne sera pas effectuée lors du stockage de la valeur par défaut. Si la table est spécifiée comme encodée gbk, l'importation échouera inévitablement.
Exemple :
`iNetbarId ` int(11) NON NULL PAR DÉFAUT '0', `iUin` bigint(20) NON NULL PAR DÉFAUT '0', `vNetbarName` varchar(80) NON NULL PAR DÉFAUT '" -"',CLÉ PRIMAIRE (`iNetbarId`) ) ENGINE=InnoDB DEFAULT CHARSET=gbk; insérer dans les valeurs t1 (1 ,1,'xxxx'); |
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!