[Résolu]Problème de caractères spéciaux dans une base données

Bonjour, je pense avoir un problème d'interclassement, mais je ne sais pas comment le résoudre...

J'ai reçu une base de données dont je dois extraire quelques tables et leurs données pour les réintégrer dans une autre DB ...

Dans la DB que j'ai reçue tous les caractères spéciaux sont écrits en clair (é =é) php my admin m'indique un interclassement des tables "latin1_swedish_ci".

tandis que dans la db ou je dois importer ces nouvelles tables les caractères spéciaux sont codés (é=é)

le résultat est quand j'importe mes tables, les caractères spéciaux restent écrits en clair dans la DB et tous ces caractères qui restent en clair dans la db me donnent des erreurs (des petits rectangles avec des écritures dedans) sur le site en ligne codé en utf-8.

Le gros problème la dedans c'est que c'est un gros mélange...les données me viennent de deux clients qui souhaitent créer un site en commun , donc je récupère des Db de deux webmasters qui n'ont pas trop l'air de vouloir m'aider...



j'espère que vous arrivez +- à comprendre ce que j'essaye d'expliquer?
Et si vous aviez une solution à ce problème, ça serait génial!!!

merci d'avance pour votre aide!
Modifié par foxprox (10 Nov 2009 - 16:28)

foxprox a écrit :
Bonjour, je pense avoir un problème d'interclassement

Si tu as un problème de tri des données, par exemple la lettre «é» n'est pas placée entre «e» et «f» lors d'un tri alphabétique, ok. Sinon, rien à voir.

foxprox a écrit :
mais je ne sais pas comment le résoudre...

Le plus dur est d'analyser le problème. C'est dur parce que ça demande d'avoir une bonne compréhension de ce que sont les jeu de caractères, les codages de caractères, et dans le cas de MySQL les interclassements. Ça demande aussi de savoir comment sont gérés ces aspects avec le langage de programmation utilisé (PHP, Python, etc.).

foxprox a écrit :
J'ai reçu une base de données

Est-ce que tu parles d'un export au format texte (notamment un fichier .sql, ou une archive contenant un fichier .sql)? Si oui, as-tu vérifié quel est le codage des caractères de ce fichier? Toutes les données sont-elles bien encodées, ou bien est-ce que cet export contient des données corrompues? Si l'export contient des données corrompues, ça va pas être simple à réparer (si c'est possible).

foxprox a écrit :
Dans la DB que j'ai reçue tous les caractères spéciaux sont écrits en clair (é =é)

La notion de caractère spécial n'existe pas. La notion de caractère écrit en clair n'existe pas. Désolé.

foxprox a écrit :
php my admin m'indique un interclassement des tables "latin1_swedish_ci".

Après import? Ou bien tu as reçu des fichiers «source» de la base de données?

foxprox a écrit :
tandis que dans la db ou je dois importer ces nouvelles tables les caractères spéciaux sont codés (é=é)

La notion de caractère spécial n'existe pas (bis repetita). Par ailleurs un caractère n'est jamais codé «é» ou «Ã©»: un caractère est codé comme une valeur numérique (sur un ou plusieurs octets).

Pour ajouter à la confusion: l'affichage des données dans phpMyAdmin n'est pas fiable. Ou plutôt, il est fiable mais dépend de plusieurs paramètres: le codage réel des données dans la base, les paramètres de la connexion MySQL initiée par phpMyAdmin, le codage déclaré par phpMyAdmin au navigateur. Tu peux tirer des conclusions sur le codage réel des données (ce que tu cherches à faire ici) uniquement si tu connais à la fois le codage déclaré par phpMyAdmin et les paramètres de la connexion MySQL initiée par phpMyAdmin.

foxprox a écrit :
les caractères spéciaux restent écrits en clair dans la DB et tous ces caractères qui restent en clair dans la db me donnent des erreurs (des petits rectangles avec des écritures dedans) sur le site en ligne codé en utf-8.

Suppositions en chaine:
- les «caractères spéciaux» dont tu parles sont tous les caractères n'appartenant pas au jeu de caractères ASCII (c'est ce que l'on entend en général quand on utilise cet abus de langage);
- phpMyAdmin ouvre une connexion MySQL en ISO-8859-1 (dit aussi latin1), et déclare les pages affichées en ISO-8859-1;
- tes tables marquées avec un interclassement "latin1_blabla" contiennent réellement des données en ISO-8859-1;
- tes autres tables contiennent des données en UTF-8, et sont marquées comme telles (avec un interclassement tel que "utf8_general_ci" ou "utf8_unicode_ci";
- les données ne sont pas corrompues;
- MySQL est configuré pour ne pas réaliser de transcodage des données (douteux...);
- dans phpMyAdmin, les données en UTF-8 s'affichent mal (forcément, la page est déclarée en ISO-8859-1) et celles en ISO-8859-1 s'affichent correctement;
- le site a des pages déclarées en UTF-8;
- sur le site, les données en UTF-8 s'affichent correctement, mais pas celles en ISO-8859-1.

Voilà un scénario possible qui expliquerait tes problèmes. La solution serait de convertir les données importées en UTF-8, afin de n'avoir que des données en UTF-8. Ou bien de configurer MySQL pour qu'il transcode les données pour livrer de l'UTF-8, c'est à dire que les données en UTF-8 seraient envoyées telles quelles tandis que celles en ISO-8859-1 seraient converties, à la volée, en UTF-8. Cette deuxième solution est moins intéressante.

Mais ce n'est qu'un scénario. Je trouve par exemple douteux que MySQL ne fasse pas déjà la conversion à la volée des données, alors que c'est dans les réglages par défaut. Le serveur a peut-être été configuré autrement? Ou bien c'est une ancienne version de MySQL?

Agylus a écrit :
Apparemment ta première base de données est pourrie jusqu'à la moelle

Tu n'as pas les informations pour le dire.
Pour ma part ça me semble peu probable.

Agylus a écrit :
dans un interclassement dont on ne connait rien.

Une base de données n'est pas dans un interclassement donné. Elle n'est pas non plus dans un codage de caractères donné. Une base de données stocke des données, et peut comporter des informations sur le codage de ces données et les ordres de tri «alphabétique» à utiliser. Ces informations sur le codage des données ne sont pas forcément fidèles à la réalité (le codage réel des données dans la base).

Merci Florent V. de t'être penché sur mon cas!

Ce matin, j'ai pu obtenir les accès aux serveurs de ces deux sites et j'ai refait moi même des exports des db, tout fonctionne correctement maintenant!