Pb encodage caractères suite migration mySQL 4 -> 5

Pause Café
#1

Bonjour,
J’ai passé mes bases de données mySQL version 4 à la 5 sur mon hébergement.
J’ai fait une sauvegarde de ma base version 4, supprimer ma version 4, initialiser une base version 5 et importé ma sauvegarde.

L’ennui vient avec les caractères accentués : ça donne par exemple

INSERT INTO `PAEA_wp_comments` VALUES (2, 24, 'Cyrille', 'cyrille@cbiot.fr', '', '83.198.214.45', '2009-10-27 16:02:38', '2009-10-27 15:02:38', 'Merci !\r\nMais ce ne sont juste que quelques pages et quelques clics, guère de grand mérite.', 0, '1', 'Mozilla/5.0 (X11; U; Linux x86_64; fr; rv:1.9.0.14) Gecko/2009091008 Iceweasel/3.0.9 (Debian-3.0.9-1)', '', 0, 1);
(édité avec leafpad, gedit, bluefish : même résultat)

Par contre si je fait un cat du fichier en console, les accents sont bien des accents

cat db.txt | grep PAEA_wp_comments INSERT INTO `PAEA_wp_comments` VALUES (2, 24, 'Cyrille', 'cyrille@cbiot.fr', '', '83.198.214.45', '2009-10-27 16:02:38', '2009-10-27 15:02:38', 'Merci !\r\nMais ce ne sont juste que quelques pages et quelques clics, guère de grand mérite.', 0, '1', 'Mozilla/5.0 (X11; U; Linux x86_64; fr; rv:1.9.0.14) Gecko/2009091008 Iceweasel/3.0.9 (Debian-3.0.9-1)', '', 0, 1);

Le problème c’est que sur mon site, bah j’ai plein de è et autres à la place des é, à, ê è
(problème d’utf8 et d’iso sans doute…)

Quelques saurait il comment convertir mon fichier pour que je puisse l’éditer correctement via gedit et qu’ensuite je puisse faire des copier / coller via l’éditeur SQL de phpmyadmin de mon hébergeur.

Thanx
Cyrille

(PS j’essayé d’utiliser iconv mais pas concluant)

#2

J’ai résolu le problème à gros renfort de sed et de regex mais si qq’un avait une solution CLEAN, je suis preneur ! :wink:

#3

Je ne comprends pas exactement le pb; mais si c’est du html, il faut spécifier le charset en utf-8 ou convertir les caractètes en html. Facile avec bluefish. On sélectionne le texte à convertir et dans editer on se sert de remplacement spécial. Je ne suis pas sûr d’avoir compris, je te le rappelle.

#4

Non ce n’est pas du html (ça je gère),
c’est un backup mysql,

D’ailleurs c’est marrant : quand je l’ai récupéré j’ai vu ce problème d’encodage… Par contre si via une console je copie ce fichier (cp monbackup.sql monbackup.sql2 , mes accents sont de nouveaux bien encodés !
Donc monbackup.sql (sorti via phpmyadmin de mon hébergeur) quand je le récupère : caractères accentués apparaissent sous cette forme é quand je l’ouvre (bluefish, gedit, leafpad…) mais apparaissant bien (é) si je fais un cat du fichier …

Donc quand je restaure ma base (copier coller des instruction SQL depuis leafpad via l’éditeur SQL de mon hébergeur, les accents foirent…)

Par contre, je me suis aperçu que si je crée un nouveau fichier depuis la commande cp, les accents réapparaissent bien même dans leafpad, bluefish,…

ça doit être un problème d’header dans l’entete du fichier qui doit stipuler un mauvais format…

M’enfin, va savoir !

Pour junichiro
PS : je reviens de la Biocoop avec 1 kg de farine de gluten :smiley: :smiley: :smiley: , soirée fabrication de seitan ! D’ailleurs connais tu la recette du jambon végétal depuis cette farine ?

++
Cyrille

#5

Si tu veux pas avoir de doute:

$ locale
LANG=fr_FR.UTF-8
[tout en utf-8]
$ file dump.txt
dump.txt ISO-8859 English text
$ iconv -f iso8859-15 -t utf8 dump.txt > dump.txt.utf8
$ file dump.txt.utf8
dump.txt.utf8: UTF-8 Unicode English text

Pourquoi ça ? Parce que si ça se trouve ton système est en ISO, ta base de donnée veux de l’UTF-8, et la police que tu utilises n’est pas forcément en utf8 :confused: File, lui, fait abstraction de tout ça, en revanche il risque de te dire que c’est un dump sql et pas l’encodage :-/

Iconv peut pas se louper, ou ça se saurait deja, l’intégralité des logiciels utilisant la libc6 l’utilise dès qu’il s’agit de convertir des caratères :wink: (à moins que tu sois sur Woody ou antérieur…).

#6

OK Merci beaucoup !
Je passe “cette astuce” dans mon pense-bête !
Thx,
Cyrille

#7

Pour info

cyrille@tuxpanic:~/Desktop$ file db1562.1and1.fr.sql db1562.1and1.fr.sql: Non-ISO extended-ASCII English text, with very long lines

:wink: , je le tronque :

cyrille@tuxpanic:~/Desktop$ file db1562.1and1.fr.sql db1562.1and1.fr.sql: ISO-8859 text

et mon système

cyrille@tuxpanic:~/Desktop$ locale LANG=fr_FR.UTF-8 LC_CTYPE="fr_FR.UTF-8" LC_NUMERIC="fr_FR.UTF-8" LC_TIME="fr_FR.UTF-8" LC_COLLATE="fr_FR.UTF-8" LC_MONETARY="fr_FR.UTF-8" LC_MESSAGES="fr_FR.UTF-8" LC_PAPER="fr_FR.UTF-8" LC_NAME="fr_FR.UTF-8" LC_ADDRESS="fr_FR.UTF-8" LC_TELEPHONE="fr_FR.UTF-8" LC_MEASUREMENT="fr_FR.UTF-8" LC_IDENTIFICATION="fr_FR.UTF-8" LC_ALL=

Et donc merci pour la gestion de ces commandes !

#8

T’as réussi à faire ce que tu voulais ?

Ca pourrait CP437 ou du CP850 - j’obtiens les mêmes résultats sur des fichiers que j’ai créé quand j’étais sous MS-DOS :smt005

Mais on est 2010, donc je pense pas que ça soit le cas de ton dump, mystère :smt017