Problème UTF8 avec MySQL 5

Question

Je suis en train de migrer mon blog WordPress et mon forum phpBB vers un nouveau serveur d'hébergement. J'utilise phpMyAdmin pour importer le script SQL de la base de données du site précédent.

Lorsque j'ouvre le script .sql avec Kate, il indique qu’il utilise UTF8 comme encodage. Lorsque j'importe le sql dans le nouveau serveur, j'ai l'option dans phpMyAdmin de choisir le codage, où utf8 est sélectionné par défaut.

Malgré tout, quand j'ai fini d'importer la base de données, je lis le texte du message directement dans phpMyAdmin et vois des caractères tels que & "& # 233; &", & "; # 241; & ";", Etc. qui n'ont pas été & "Interprétés &"; et a été remplacé par des caractères étranges insted.

Je peux également voir que mon installation WordPress ne fonctionne pas. Apparemment, il y a un problème avec cet encodage, mais je pense que le problème vient de la base de données MySQL ou de phpMyAdmin et non de WordPress.

Les versions de MySQL sont pratiquement les mêmes, MySQL 5, mais une révision différente. En outre, la migration de la base de données du forum ne posait pas de problème, ce qui est encore plus étrange ...

Je ne sais pas comment résoudre ce problème ... Toutes les idées sont les bienvenues.

Answer 1

Avez-vous essayé d'ajouter

SET NAMES 'utf8';

à votre dump SQL?

Le problème avec utf8 ou les encodages en général est que pour réussir, vous devez vous assurer que:

• le fichier est encodé en utf8 sans signature
• le codage par défaut du serveur mysql est défini sur utf8
• la connexion est utf8 (c'est pourquoi vous avez mis SET NAMES 'utf8' dans votre fichier SQL).
• toutes les tables et colonnes ont le bon encodage et jeu de caractères
• tous vos fichiers web doivent également être encodés en utf8. Et cela ne fonctionne pas simplement d'ajouter le bon en-tête. Vous devez ouvrir le fichier, vérifier si le codage est utf8, sinon, tout couper, changer le codage en utf8 et tout coller à nouveau. Cela ne fonctionne pas si vous modifiez simplement le codage et enregistrez le fichier!

Answer 2

Merci beaucoup pour vos réponses. J'ai trouvé la solution et je me sens vraiment bête de ne pas l'avoir compris avant. Tout était supposé fonctionner correctement:

-File a été encodé avec utf8 -Les tables ont été déclarées avec utf8:

SET character_set_client = utf8;

-Le serveur MySQL a été configuré avec utf8 Etc.

Ce que je n'avais pas compris au départ, c'est que j'utilisais une sauvegarde de base de données à partir de l'assistant de sauvegarde de cPanel. Dès que j'ai réalisé cela, j'ai utilisé phpMyAdmin sur l'ancien serveur pour exporter la base de données, je l'ai importée dans le nouveau serveur et, presto, le problème a été résolu.

phpMyAdmin comprend mieux phpMyAdmin que cPanel: P Apparemment, cPanel exporte le script pour être importé avec cPanel lui-même. Cela aurait probablement aussi bien fonctionné, mais je me fie mieux à phpMyAdmin.

Merci beaucoup pour vos réponses cependant.

Answer 3

Je viens de rencontrer le même problème, puisque je me suis débattu dessus pendant environ une heure et que plusieurs de mes sites ont été cassés, je me suis dit que je regarderais et verrais si quelqu'un d'autre avait du mal à le résoudre et que je poste une solution: La solution Tout simplement consiste à spécifier le jeu de caractères à importer lors de l'importation.

Si vous avez un accès SSH à votre hôte, commencez par déposer à nouveau toutes vos tables dans une nouvelle base de données, puis exécutez cette commande dans la session SSH (en supposant que votre ancien fichier de vidage soit olddatabase.dump.sql ):

$ mysql -h hôte -u nom d'utilisateur -p mot de passe --default-character-set = utf8 base de données < olddatabase.dump.sql (remplacez l'hôte, le nom d'utilisateur, le mot de passe et la base de données par les valeurs appropriées)

C’est le moyen le plus simple et le plus direct de résoudre le problème.