[Résolu] Récupérer une base de données mal encodée

Bonsoir,

Je dois travailler sur une base de donnée que je n'ai pas touché depuis longtemps. C'est une base utilisée par DotClear 1.x

DotClear est configuré en UTF-8 et les pages du site Web sont envoyés en UTF-8 sans que ça pose problème vu que le site s'affiche correctement. Cependant les champs textuels des tables MySQL sont en latin1_swedish_ci... D'ailleurs si j'affiche les tables avec phpMyAdmin les caractères sont mal affichés : "Nouveau départ". phpMyAdmin envoie les pages en UTF-8.

J'essaye tant bien que mal de récupèrer cette base de données pour la mettre sur un site en local mais l'encodage reste mauvais. J'ai tenté un :
iconv -f iso-8859-15 -t utf8 fichier.sql > fichier-utf8.sql
car la sauvegarde fichier.sql m'affichait quand même les mauvais caractères quand je l'aouvrait avec un éditeur de texte. Sauf que fichier-utf8.sql n'est pas mieux. Les mauvais caractères se sont transformés en nouveaux...

Comment expliquer que mon site et phpMyAdmin envoyant des pages en UTF-8 n'arrive pas à afficher de la même façon mon texte ?
Comment corriger l'affichage phpMyAdmin et/ou l'exporter de la bonne façon ?

Merci d'avance.
Modifié par ThomasB (06 Dec 2008 - 12:14)

ThomasB a écrit :
DotClear est configuré en UTF-8 et les pages du site Web sont envoyés en UTF-8 sans que ça pose problème vu que le site s'affiche correctement. Cependant les champs textuels des tables MySQL sont en latin1_swedish_ci... D'ailleurs si j'affiche les tables avec phpMyAdmin les caractères sont mal affichés : "Nouveau départ". phpMyAdmin envoie les pages en UTF-8.

Si tu as des données en UTF-8 mais marquées comme étant en ISO-8859-1 (latin1_swedish_ci est un interclassement, pas un encodage, mais en l'occurrence il indique du latin1 soit de l'ISO-8859-1), et que phpMyAdmin est en UTF-8, les choses se passent ainsi:

1. phpMyAdmin se connecte au serveur MySQL en demandant de l'UTF-8.
2. Le serveur MySQL constate que les champs/colonnes/tables demandées sont indiquées comme étant en ISO-8859-1.
3. MySQL fait la conversion de ISO-8859-1 vers UTF-8.
4. Les données retournées sont corrompues (double encoding).

Même chose lors d'un mysqldump, qui se fait par défaut en UTF-8, c'est à dire que tes données UTF-8 mais marquées en ISO-8859-1 vont être réencodées en UTF-8, et donc corrompues.

ThomasB a écrit :
J'ai tenté un :
iconv -f iso-8859-15 -t utf8 fichier.sql > fichier-utf8.sql

Si tu es sûr que tes données sont réellement en UTF-8 dans la base, et ont donc été corrompues à l'export, il faudrait faire l'inverse: convertir le fichier corrompu de UTF-8 à ISO-8859-1, et tu devrais retomber sur de l'UTF-8 pour tes données.

Ou bien refaire l'export avec mysqldump en précisant que tu veux du latin1 pour qu'il ne fasse pas de conversion (et que tu récupères donc de l'UTF-8).

a écrit :
Comment expliquer que mon site et phpMyAdmin envoyant des pages en UTF-8 n'arrive pas à afficher de la même façon mon texte ?

Le site, ou plutôt Dotclear, se contente sans doute de l'encodage par défaut pour les connexions MySQL sur la plupart des serveurs, soit ISO-8859-1 (latin1), et récupère alors des données non converties. De même il place des données brutes en UTF-8 en base, sans conversion. À l'inverse phpMyAdmin utilise sans doute une connexion en UTF-8 (via un SET NAMES 'utf-8').

a écrit :
l'exporter de la bonne façon ?

En passant le bon paramètre à mysqldump. Par contre je ne suis pas sûr que ça soit possible ne passant par phpMyAdmin.

Bête question : ton phpmyadmin est bien configuré en utf8 pour l'affichage? Ton éditeur de texte également?

Sinon il existe un moyen simple de récupérer le contenu : installer la dernière version de DC1 (1.2.8) et exporter le contenu dans un fichier texte. Par contre je ne crois pas que ce soit possible de l'importer, à part dans DC2. D'ailleurs il faudrait sérieusement penser à passer à la version 2.

Merci pour vos réponses.

Le "problème" c'est que je ne suis sûr de rien concernant l'encodage des données dans MySQL. Je suppose juste fortement que c'est du latin1. Je vais tenter un iconv "inverse". De toute façon je n'ai pas accès à mysqldump, ce n'est pas mon serveur

@Patidou : oui phpMyAdmin et l'éditeur son bien configuré en UTF-8

Je vais aussi tenter un export via dotClear 1.2.8. Le module d'export a été changé ? Sinon j'essayerai le plugin flatExport : http://fr.dotclear.org/documentation/2.0/admin/1-to-2
Et justement j'envisage de passer sur DotClear 2, mais sur un autre serveur à mois et plus carré niveau configuration (full UTF-8 entre autre).

Je vous tiens au courant, merci.

Un iconv "inverse" s'arrête avant d'avoir fini. Un export via le plugin flatExport donner un fichier texte mal encodé aussi MAIS si j'importe ce fichier dans un DotClear2 tout frais, configuré en UTF-8 comme ses tables MySQL, tout rentre dans l'ordre. Les billets s'affichent bien dans le blog et dans phpMyAdmin

Base SQL de Dotclear 1 en UTF-8.
Gros problème d'accents dans la base des commentaires (alors que ça s'affichait bien sur le blog).
J'ai voulu migrer vers Wordpress, en utilisant "Outils>>Import>>Dotclear" dans le panneau de Wordpress. MAis toujours problème d'accent dans les commentaires.

J'ai essayé avec FlatExport (pour DC) et FlatImport (pour WP). Et là ça a tout bien fonctionné !
Le lien miracle pour retrouver vos accents : http://www.wordpress-fr.net/support/sujet-2944-import-dotclear-fichier-texte