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

Discussion dans 'Développement d'un site Web ou d'une appli mobile' créé par Savoy, 13 Mars 2009.

  1. Savoy
    Savoy WRInaute occasionnel
    Inscrit:
    22 Février 2007
    Messages:
    274
    J'aime reçus:
    0
    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
     
  2. ortolojf
    ortolojf WRInaute accro
    Inscrit:
    14 Août 2002
    Messages:
    3 596
    J'aime reçus:
    34
    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
     
  3. Savoy
    Savoy WRInaute occasionnel
    Inscrit:
    22 Février 2007
    Messages:
    274
    J'aime reçus:
    0
    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...
     
  4. ortolojf
    ortolojf WRInaute accro
    Inscrit:
    14 Août 2002
    Messages:
    3 596
    J'aime reçus:
    34

    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
     
  5. RiPSO
    RiPSO WRInaute impliqué
    Inscrit:
    5 Octobre 2007
    Messages:
    948
    J'aime reçus:
    0
    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!! ;)
     
  6. ortolojf
    ortolojf WRInaute accro
    Inscrit:
    14 Août 2002
    Messages:
    3 596
    J'aime reçus:
    34

    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
     
  7. RiPSO
    RiPSO WRInaute impliqué
    Inscrit:
    5 Octobre 2007
    Messages:
    948
    J'aime reçus:
    0
    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 ;)
     
  8. ortolojf
    ortolojf WRInaute accro
    Inscrit:
    14 Août 2002
    Messages:
    3 596
    J'aime reçus:
    34

    J'ai bien compris

    Je laisse tomber...

    C'est pas un problème.

    Bien à vous.

    Amicalement.

    Jean-François Ortolo
     
  9. erestrebian
    erestrebian WRInaute occasionnel
    Inscrit:
    15 Juin 2007
    Messages:
    411
    J'aime reçus:
    0
    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!
     
Chargement...
Similar Threads - Problème caractères accentués Forum Date
Passage à PHP5.6, problème sur caractères accentués Développement d'un site Web ou d'une appli mobile 24 Juin 2015
Problème caractères accentués dans l'index google Crawl et indexation Google, sitemaps 4 Août 2013
Problèmes avec les caractères accentués. Développement d'un site Web ou d'une appli mobile 11 Décembre 2009
Problème de caractères dans l'outil d'analyse des balises h1 h2 h3 Rédaction web et référencement 4 Août 2019
Problème de caractères Développement d'un site Web ou d'une appli mobile 12 Décembre 2017
Problème de lecture des caractères Développement d'un site Web ou d'une appli mobile 28 Juin 2012
problème lors d'une recherche en SQL et caractères spéciaux Développement d'un site Web ou d'une appli mobile 9 Août 2011
Simplepie problème caractères spéciaux rss iso Développement d'un site Web ou d'une appli mobile 4 Août 2011
Formulaire de contact en UTF-8 - problème caractères russe Développement d'un site Web ou d'une appli mobile 6 Juin 2011
Problème de caractères Développement d'un site Web ou d'une appli mobile 17 Juin 2010
Problème caractères avec include externe Développement d'un site Web ou d'une appli mobile 19 Mai 2010
Problème de URL indexé Google - suite de chiffres et caractères inconnue Débuter en référencement 16 Janvier 2010
Problème d'encodage de caractères Développement d'un site Web ou d'une appli mobile 3 Juin 2008
problème avec caractères accentué Développement d'un site Web ou d'une appli mobile 26 Mars 2008
Problème caractères bizzares dans Google (encodage...?) Problèmes de référencement spécifiques à vos sites 14 Février 2008
Problème avec les caracteres spéciaux URL Rewriting et .htaccess 12 Février 2008
Problème de caractères spéciaux Demandes d'avis et de conseils sur vos sites 21 Janvier 2008
Problème sur Opera : Drôles de caractères... Développement d'un site Web ou d'une appli mobile 22 Avril 2007
Problème de caractères dans un .pdf issu d'oscommerce Développement d'un site Web ou d'une appli mobile 26 Mars 2007
problème de validaité de script: caractères illégaux windows Développement d'un site Web ou d'une appli mobile 7 Juin 2006