UTF8 problème avec MySQL 5

Je suis la migration de mon blog WordPress et phpBB Forum dans un nouveau serveur d'hébergement. J'utilise phpMyAdmin pour importer le script SQL à partir de la base de données dans le site précédent.

Quand j'ouvre le .sql script avec Kate, il dit qu'il utilise l'utf-8 comme encodage. Lorsque j'importe le sql dans le nouveau serveur, j'ai l'option dans phpMyAdmin pour choisir l'encodage, où utf8 est sélectionnée par défaut.

Encore, quand j'ai fini de l'importation de la base de données, j'ai lu les messages texte directement dans phpMyAdmin, et de voir des caractères tels que "é", "ñ", etc. qui n'a pas été "interprété" et ont été remplacés par des caractères bizarres place.

Je peux voir mon installation de WordPress ne fonctionne pas également. Il y a apparemment un problème avec ce codage chose, mais je pense que le problème est dans la base de données MySQL ou phpMyAdmin et pas WordPress.

Les versions de MySQL sont pratiquement les mêmes, MySQL 5, mais d'une autre révision. Aussi, il n'y a pas de problème lors de la migration du forum base de données, donc c'est encore plus étrange...

Je suis perdu quant à la façon de résoudre ce problème... Toutes les idées sont les bienvenue.

OriginalL'auteur Fernando Briano | 2008-12-06

  1. 10

    Avez-vous essayé d'ajouter

    SET NAMES 'utf8';

    à votre dump sql?

    La chose avec l'utf8 ou d'encodages en général, c'est que pour être réussie, vous devez vous assurer que:

    • le fichier est encodé en utf8 sans signature
    • l'encodage par défaut de mysql server est défini en utf8
    • la connexion est de l'utf-8 (c'est pourquoi vous mettez SET NAMES 'utf8' dans votre sql-fichier).
    • toutes les tables et les colonnes ont le droit d'encodage et le jeu de caractères
    • tous vos webfiles doivent être encodés en utf-8. Et ça ne fonctionne pas tout simplement à ajouter l'en-tête correcte. Vous devez ouvrir le fichier, vérifiez si l'encodage est utf-8, sinon, coupé de tout, change l'encodage en utf8 et coller le tout. Il ne fonctionne pas, si vous venez de changer l'encodage et enregistrez le fichier!
    C'est un bon résumé des exigences, mais le dernier n'est pas vraiment nécessaire si les fichiers sont en Latin1 et vous n'avez pas le coller dans le non-Latin1 caractères (c'est à dire les coder comme &livre; au lieu de cela). J'ai beaucoup d'héritage Latin1 matériau qui génère encore comme valide UTF8, parce que Latin1 est un sous-ensemble de l'UTF8. De sorte que la migration vers l'UTF8 n'est pas vraiment difficile.

    OriginalL'auteur markus

  2. 1

    Merci beaucoup pour vos réponses. J'ai trouvé la solution, et je me sens vraiment stupide de ne pas l'avoir réalisé avant. Tout devait fonctionner correctement:

    Fichier est encodé en utf8
    Les Tables ont été déclarés avec l'utf8: 

    SET character_set_client = utf8;

    -MySQL server a été configuré avec l'utf8
    Etc.

    Ce que je ne savais pas, en premier lieu, j'ai été en utilisant une base de données de sauvegarde à partir de cPanel de l'assistant de sauvegarde. Dès que j'ai réalisé cela, j'ai utilisé phpMyAdmin sur l'ancien serveur pour exporter la base de données, de son importation dans le nouveau serveur, et hop, problème résolu.

    phpMyAdmin comprend phpMyAdmin mieux que cPanel 😛 Apparemment cPanel exportations le script pour qu'il soit importé avec cPanel lui-même. Cela aurait probablement fonctionné aussi bien, mais je fais confiance à phpMyAdmin mieux.

    Merci beaucoup pour vos réponses.

    OriginalL'auteur Fernando Briano

  3. 1

    Je viens de tombé sur le même problème, depuis que je me suis battu avec lui pendant environ une heure et il s'est cassé plusieurs de mes sites, j'ai pensé de regarder et de voir si quelqu'un d'autre a été aux prises avec elle et après une solution: La solution, c'est tout simplement spécifier l'importation jeu de caractères lors de l'importation.

    Si vous avez un accès SSH à votre machine, commencez par supprimer toutes vos tables dans la base de données de nouveau, puis exécutez cette commande dans la session SSH (en supposant que votre ancien fichier de vidage est 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
    (remplacer hôte, nom d'utilisateur, mot de passe et base de données avec des valeurs appropriées)

    C'est la plus simple et la plus simple pour résoudre le problème.

    OriginalL'auteur Joel.Kotarski