web-dev-qa-db-fra.com

Restauration défectueuse de la base de données, problème d'encodage

J'ai foiré les paramètres avec W3 Total Cache (j'ai essayé d'importer tous les médias dans ma bibliothèque, ça n'a pas bien marché, j'ai cassé tous les liens vers chaque image). J'ai donc pris ma dernière sauvegarde de la base de données, copier/coller les tables _post et _postmeta dans mon phpmyadmin. Il a ramené les liens et les images comme prévu, mais maintenant tous les caractères français (à, é, è, etc.) ne sont pas affichés correctement.

J'ai pris la sauvegarde du plugin WP-DBManager, qui ne semble pas gérer correctement UTF-8. Quel est le moyen le plus rapide de corriger le problème?

Merci

Edité pour plus de détails: l'en-tête de sauvegarde SQL est

DROP TABLE IF EXISTS `hojd_posts`;
SET @saved_cs_client     = @@character_set_client;
SET character_set_client = utf8;

Cependant, j'ai ces caractères mal encodés venant directement dans mes commandes SQL (par exemple: français pour "français") ...

databasebackupencoding
2
Jonathan

Vous pourrez peut-être résoudre ce problème si vous avez un éditeur de texte offrant une bonne prise en charge de l'encodage. De cette façon, vous pouvez basculer entre les codages Latin 1 et UTF-8 jusqu'à obtenir la bonne combinaison. J'utilise SubEthaEdit qui permet de convertir mais également de réinterpréter un fichier lorsque vous modifiez l'encodage.

Le ç doit être codé en tant que c3 a7 en UTF-8 lorsque vous les affichez en octets. Ce qui pourrait se produire ici est que le fichier a d'abord été interprété comme étant Latin 1, où c3 a7 signifie ç, puis enregistré au format UTF-8, où ç est enregistré en tant que c3 83 c2 a7. Vous voulez la version c3 a7.

Pour revenir à un ç de Nice, ouvrez le fichier au format UTF-8, enregistrez-le au format Latin-1, puis rouvrez-le comme s'il s'agissait du format UTF-8.

Une fois que vous avez fait cela, vous pouvez importer le fichier dans MySQL, mais spécifiez-le au format UTF-8, sinon MySQL pourrait essayer de l'interpréter comme étant Latin 1 et vous conserverez les caractères ç.

0
Jan Fabry

J'ai eu un problème similaire avec les umlauts allemands. Le problème s'est également produit lors d'une exportation de base de données avec phpmyadmin. Ma solution consistait à exporter la base de données avec l'outil de ligne de commande mysql et le paramètre "--default-character-set =" utf8 ".

Une autre approche, si vous n’avez pas accès à un shell Linux: Installez et utilisez MySQLDumper

0
rofflox

Un problème courant avec les anciennes bases de données WordPress et même les plus récentes est que les tables de la base de données sont définies en tant que latin-1 mais que le contenu est en fait codé en tant que UTF-8. Si vous essayez d'exporter en UTF-8, MySQL essaiera de convertir les données (supposées) Latin-1 en UTF-8, ce qui produira un double codage des caractères car ces données étaient déjà au format UTF-8.

La solution consiste à exporter les tableaux au format latin-1. Depuis que MySQL pense qu'ils sont déjà latin-1, il effectuera une exportation directe.

  1. Modifiez le jeu de caractères de "latin1" à "utf8".

Comme les données vidées n’ont pas été converties au cours du processus d’exportation, il s’agit en fait de données codées UTF-8.

  1. Créez votre nouvelle table au format UTF-8 Si votre commande CREATE TABLE se trouve dans votre fichier de vidage SQL, remplacez le jeu de caractères "latin1" par "utf8".

  2. Importez vos données normalement. Étant donné que vous avez des données codées UTF-8 dans votre fichier de vidage, le jeu de caractères déclaré dans le fichier de vidage est maintenant UTF-8 et la table dans laquelle vous importez est UTF-8, tout se passera bien.

0
Chris_O