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

1 Introduction

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.

2 problèmes binaires

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 :

CREATE TABLE `t1`(
`iNetbarId` int(11) NOT NULL DEFAULT '0',
`iUin` bigint(20) NOT NULL DEFAULT '0',
`vNetbarName` varchar(80) NOT NULL DEFAULT '“-”',
PRIMARY KEY (`iNetbarId`)
) ENGINE=InnoDB DEFAULT CHARSET=gbk;
 
insert into t1 values(1,1,'xxxx');

Comme vous pouvez le constater, la table qui a été exportée normalement a été importée avec une erreur de 1067 Valeur par défaut non valide.

3 Solution

Lors de l'utilisation de mysqldump, ajoutez le paramètre Character_set_connection avant d'exécuter l'instruction create table.

/*!40101 SET Character_set_connection = utf8 */

Ceci est également considéré comme un bug MySQL, puisque le informations sur le schéma Utilisez utf8 du début à la fin. Avant d'exécuter create table, vous devez définir la variable de jeu de caractères de connexion sur utf8 au lieu de simplement définir la variable de jeu de caractères du client.

Ce qui précède est une brève discussion sur la question du jeu de caractères de sauvegarde MySQL. Pour plus de contenu connexe, veuillez faire attention au site Web PHP chinois (www.php.cn) !