Problème caractères accentués (encore)

Savoy · 13 Mars 2009

Bonjour,
Je viens de réinjecter dans un forum une ancienne base de donnée dont le contenu était encodé en UTF8.

Mon actuel forum étant en iso les caractères accentués sont donc mal affichés.
Si je passe mon forum actuel en UTF8 les caractères accentués issus de la base de donnée sont ok mais c'est le forum qui ne s'affiche plus correctement...

Je voudrais donc remplacer dans ma base de donnée, tous les caractères accentués par des caractères normaux.

Je cherche donc une sorte de dictionnaire dans lequel je pourrais trouver la correspondance des caractères par exemple :

Ã© = é, Ã = à etc...

Avez vous quelque info à me fournir ?
Merci

ortolojf · 14 Mars 2009

Bonjour

Faut faire un script PHP, qui lisent toutes tes tables de ta bdd, et enregistrent des tables de noms similaires avec modification de même type, tout en modifiant le codage de utf-8 en iso-8859-1, grâce à la fonction iconv() ( à supposer que la configuration PHP de ton hébergement supporte cette fonction.

Pour le savoir, tu met dans le script suivant: phpinfo.php, le code suivant:

<?php
phpinfo();
?>

C'est tout, tu télécharge ce script, puis tu le lances à distance, et tu as les caractéristiques de ton hébergement, en particulier, la config php.

Ensuite, pour adapter le charset, il faudrait je pense, lire le contenu de la requête sql: "show tables", puis pour chaque table figurant dans le résultat, créer la même table avec le même nom de table avec par exemple le préfixe: "tmp_", en utilisant le résultat de la requête sql: "desc ta ble_name", qui donne les noms et les types des champs de la table. Puis pour chaque table lue donc, créer les index identiques à ceux initiaux, en lisant le résultat de la requête sql suivante: "show index from table_name" ou table_name est le nom de la table initiale.

A charge pour toi, de faire des tests d'abord en direct par exemple sous mysql, pour examiner la syntaxe des données rendues par ces deux requêtes sql.

Pour faire un traitement automatique, il faut donc d'abord préalablement, créer les tables et les index secondaires, ( encore que pour les index on devrait pouvoir s'en passer, vu que ce seront les tables initiales qui recevront les données modifiées ).

Pour les créations de tables, cela ne mangerait pas de pain, de rajouter l'indication de charset latin1 ( équivalent de iso-8859-1 ).

Et puis, il ne faut convertir par iconv, que les champs des tables qui ne soient pas numériques, ce qui impose de les identifier de manière automatique, donc reconnaissance automatique du caractère numérique de chaque champs des tables initiales, par leurs types figurant dans le résultat de la requête "desc table_name".

Donc, il te faut contruire une requête de lecture "SELECT champ1_ champ1, etc... FROM table_name", et mettre pour chaque ligne lue, ces données dans des variables.

C'est là qu'intervient la fonction iconv()

La fonction iconv() a cette syntaxe ( voir le site PHP Manual )

$str = iconv("charset_source", "charset_cible", $str_source);

C'est à vérifier sur le PHP Manual, je ne suis pas sûr de l'ordre des paramètres.

Pour le cas où des traductions de codage ne seraient pas évidents pour PHP, il faut ajouter un suffixe à "charset_cible", c'est également dans le PHP Manual.

Donc, tu n'appliques cette fonction iconv(), qu'aux données caractères ou chaînes de caractères, suivant l'évaluation automatique que tu auras faite champ par champ, d'après le type de chaque champ. Dur, dur mais possible...

Donc, après pour chaque ligne lue de la table tu as les même variables converties, que tu peux assembler en ordre SQL INSERT... Voir la syntaxe des requêtes INSERT, c'est facile.

Tu applique donc en boucle rapide, la lecture dans la table source, et l'insertion dans la table cible ( avec préfixe "tmp_" ) des données converties.

Après, tu dois donc recopier les données vers les tables initiales, après les avoir vidées, puisque tu va remplacer les contenus initiaux, par les contenus convertis.

Donc, d'abord tu vide toutes les tables intiiales ( après avoir vérifié que les données sont bien dans les tables secondaires, et sont correctes ), puis de préférence, tu fait un ordre SQL "ALTER TABLE" pour changer le charset par défaut des tables initiales, à latin1.

Ensuite, tu n'as plus qu'à lire les tables secondaires, et enfourner directement leur contenus, dans les tables initiales...

Voilà c'est tout, et c'est suffisant.

Si quelqu'un a une autre solution, je suis preneur...

Ma dernière recommandation: Ne jamais supprimer un contenu initial sans être sûr et certain, qu'il pourra être remplacé avec certitude, par son contenu converti, et correct.

Bien à vous.

Amicalement.

Jean-François Ortolo

Savoy · 14 Mars 2009

Pfiouuu !
Ca c'est une réponse !
Merci d'avoir pris le temps d'écrire tout ça !

Malgré tout ce que je recherche c'est une solution beaucoup plus simple, par exemple faire un simple rechercher/remplacer dans mon export .sql puis réinjecter le tout.

En fait une fois que le fichier aura et modifié, il n'y aura plus ce problème d'encodage puisque qu'il sera à chaque fois encodé d'une seule façon...

ortolojf · 14 Mars 2009

Savoy a dit:
Pfiouuu !
Ca c'est une réponse !
Merci d'avoir pris le temps d'écrire tout ça !

Malgré tout ce que je recherche c'est une solution beaucoup plus simple, par exemple faire un simple rechercher/remplacer dans mon export .sql puis réinjecter le tout.

En fait une fois que le fichier aura et modifié, il n'y aura plus ce problème d'encodage puisque qu'il sera à chaque fois encodé d'une seule façon...

Erreur...

Ton fichier export.sql serait théoriquement un fichier de dump, produit par l'utilitaire mysqldump.

Je ne crois pas q'uil soit possible de faire du remplacer avec une expression rationnelle...

Par ailleurs, si tu cherches à traiter ce fichier avec un programme itératif en php, la fonction iconv serait ton amie, mais la sélection des données suivant leurs types, est beaucoup plus problématique, sinon infaisable, que celle d'après les champs d'une table.

...Et à supposer qu'il n'y ait pas besoin de faire un traitement différent suivant les types de données ( c'est possible aussi ), celà simplifierait d'autant ma propre solution.

Enfin, la conversion de ton fichier export.sql , comportant évidemment les instructions de suppression/recréation des tables et des index, devrait mentionner le charset latin1 par défaut pour chaque table, c'est plus prudent.

Last but not least, le blème serait que tu ne pourrais que très difficilement vérifier que tes données sont correctement converties, avant de remplacer l'ancien contenu, par le nouveau. S'il y a une erreur, galère...

Je reconnais que ma solution est plus compliquée à programmer, mais tu ne fais que rempalcer des instructions SQL, par des instructions de lecture et écriture dans des fichiers, alors...

Le concept de Base de données, a justement été fait, pour répondre à cette problématique de gestion des données structurées, ce qui est le cas ici.

Ceci dit, je comprend bien ta réaction face à l'apparente complexité de ma solution. Si tu y réfléchis, tu verras que sous l'angle de la sécurité, ma solution est préférable.

Dans toute entreprise de conception en amont de la programmation proprement dite, il faut procéder de manière condensatoire, en shématisant le problème de manière globalisante et diagnostique, puis en résolvant chaque difficulté au fur et à mesure qu'elles se présentent... Des difficultés essentiellement de programmation, donc facilement résolvables.

Bien à vous.

Amicalement.

Jean-François Ortolo

RiPSO · 14 Mars 2009

je ne connais pas la taille de ta base mais une boucle php qui parcours chaque ligne de ta base et qui fais un UPDATE avec ton texte qui passe dans un utf8_decode ou utf8_encode (je sais jamais c'est lequel, a chaque fois je test les deux :lol: ) ça passerais peut être...

Inutile de préciser qu'avant toute modif oublies pas de faire un backup de ta base!!

ortolojf · 14 Mars 2009

RiPSO a dit:
je ne connais pas la taille de ta base mais une boucle php qui parcours chaque ligne de ta base et qui fais un UPDATE avec ton texte qui passe dans un utf8_decode ou utf8_encode (je sais jamais c'est lequel, a chaque fois je test les deux :lol: ) ça passerais peut être...

Inutile de préciser qu'avant toute modif oublies pas de faire un backup de ta base!!

Bonjour

Cà marche, une requête SELECT sur une table sur laquelle on fait en même temps des UPDATE ?

Et puis, ne pas oublier après de faire un ALTER TABLE pour changer le charset par défaut... :?

Bien à vous.

Amicalement.

Jean-François Ortolo

RiPSO · 14 Mars 2009

non,

si ta base ne fait pas plusieurs Go je te disais que tu pouvais faire un SELECT * FROM table
et ensuite un truc du style :

boucle de 0 à nLignes :
"UPDATE table SET texte='".utf8_decode($tonTextePourChaque ligne)."' WHERE id=".$idDeTaLigne

a toi de juger si le temps de travail durera moins que ton timeout... (d'où le fait de dire que si t'as une grosse base faut te méfier)

[edit] je répète surtout sauvegarde ta table avant je voudrais aps te faire faire de betises

ortolojf · 14 Mars 2009

RiPSO a dit:
non,

si ta base ne fait pas plusieurs Go je te disais que tu pouvais faire un SELECT * FROM table
et ensuite un truc du style :

boucle de 0 à nLignes :
"UPDATE table SET texte='".utf8_decode($tonTextePourChaque ligne)."' WHERE id=".$idDeTaLigne

a toi de juger si le temps de travail durera moins que ton timeout... (d'où le fait de dire que si t'as une grosse base faut te méfier)

[edit] je répète surtout sauvegarde ta table avant je voudrais aps te faire faire de betises

J'ai bien compris

Je laisse tomber...

C'est pas un problème.

Bien à vous.

Amicalement.

Jean-François Ortolo

erestrebian · 15 Mars 2009

n'est-ce pas plus facile de passer ton forum en utf-8... perso, j'avais eu le même souci pour creationdeperso.com et l'utf-8 avait été plus satisfaisant!