Forum Programmation.php Conversion de caractères

Posté par  (site web personnel) .
Étiquettes : aucune
0
23
juil.
2004
Bonjour,

voila mon problème:
lors d'extraction d'une base de données contenant des caractères accentués, j'obtiens systématiquement des ? à la place.
par exemple:
Flemming Søndergård
devient
Flemming S�nderg�rd
(ça marche aussi avec des bêtes é ou à, mais j'ai pris le premier exemple qui me tombait sous la main!)

Pour infos, la machine de dev est sous linux, apache 2, php 4.3 et mysql3.23, et le problème n'apparait pas si j'exécute la même requéte sur une simple install d'Easyphp sour W$. Le problème n'apparait pas non plus dans phpmyadmin.

Quelqu'un aurait-il déjà rencontré ce problème, j'ai eu beau chercher sur le site php.net mais je n'ai pas trouvé de réponse.

Merci.
  • # Re: Conversion de caracteres

    Posté par  . Évalué à 2.

    Plusieurs solutions : celle de phpMyAdmin par defaut : convertissez vos caracteres speciaux en entites avant de les enregistrer
    Plus éléguant : stockez vos données dans un charset multibytes, comme UTF8 ou UCS2 dans MySQL (ajoutez CHARSET UCS2 a votre requete de creation de table pour specifier ce charset), et prenez soin de convertir vos caractères en UCS2 avant de les enregistrer dans la base, par exemple avec l'extension iconv de PHP
  • # Pbm de locale ?

    Posté par  . Évalué à 3.

    C'est un problème de locale et de charset. PHP doit prendre par défaut le charset ISO-8859-15, et ne comprends donc pas tous les caractères qui sortent de cette définition. En l'occurence ici les caractères suédois. Mais apparemment le problème est bien plus poussé. Quoique le problème semble plus poussé. PHP doit vouloir fonctionner en unicode, alors que phpmyadmin bloque sur du ISO-8859-15, résultat : ça bloque.

    Si on utilises phpmyadmin, on ne peut pas l'utiliser dans un charset unicode (bien dommage d'ailleurs, ça règlerait le problème de façon simple et élégante). Donc il faut se taper la transformation en entités de tout ce qui n'est pas caractère ASCII ! Erf, pas glop du tout...

    Le mieux c'est de ne pas entrer de données dans la base en utilisant phpmyadmin, mais uniquement via le programme final en PHP, que l'on peut facilement gérer lui au moins. C'est-à-dire qu'on peut lui définir un charset de fonctionnement bien pratique : l'unicode.

    Moi j'utilise ça dans mon code PHP (à mettre au début du script) :

    <?php
    setlocale( LC_ALL, 'fr_FR.UTF-8' );
    mb_internal_encoding( 'UTF-8' );
    ?>

    Et bien entendu, il faut aussi indiquer au user-agent que ce qui va être affiché est de l'unicode, donc ne pas oublier de mettre ça dans le header de la page HTML : <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />

    Ou si c'est du XHTML Strict : <meta http-equiv="Content-Type" content="application/xhtml+xml; charset=UTF-8" />


    Avec tout ça, normalement le site devrait fonctionner correctement, et plus de problèmes de gestion des charsets (sauf dans phpmyadmin qui - quel idiot quand même - ne permet pas de fonctionner en unicode). Mais ça ne risque peut-être pas te d'aider grandement dans ton cas, car tu risques de devoir corriger tout ce qui est dans ta base de donnée... Bon courage...
    • [^] # Re: Pbm de locale ?

      Posté par  (site web personnel) . Évalué à 1.

      Je ne me sers de PhpMyAdmin qu'en dernier recours pour certaines manip sur la strucure des tables, toutes mes données ont quant à elles été tapées à la main (sur un amiga avec CygnusEd :) pour ceux qui connaissent) puis importées via un script PHP dans une base MySQL.

      Je vais tester ces solutions, merci à vous...
      • [^] # Re: Pbm de locale ?

        Posté par  . Évalué à 3.

        Tu peux aussi utiliser certaines fonctions de conversions de charset aussi, ça peut aider. utf8_encode() ou utf8decode() par exemple, ou encore iconv().

        Mais le plus simple reste l'utilisation de l'unicode du début à la fin, ça évite les pbms ^^

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.