Forum Programmation.php Problème d'encodage

Posté par . Licence CC by-sa
Tags :
1
22
jan.
2015

Bonjour,

j'ai installé un site pour valider des compétences pour des étudiants de BTS AM sur un LAMP (debian 7 + apache 2 + mysql + php).

J'ai des problèmes d'encodage et j'aimerais pouvoir les résoudre sans toucher au code PHP. A noter que ce site fonctionnait avant sa migration mais était installé sur une version plus ancienne de debian (5 ou 6). A noter aussi que j'en ai installé un autre sans migration de base et que le problème est toujours là.

Voilà mon problème :
Tout mes caractères accentués s'affichent très bien dans mes pages.
Mais quand je veux envoyer un formulaire avec des caractères accentués dans une zone de texte, toute ma chaîne de caractère est ignorée (comprendre elle est remplacée par une chaîne vide dans la BDD et la zone de texte devient blanche). Si ma chaîne ne comprend aucun caractère accentué, alors pas de problème.

J'ai bien sur regarder le code et le créateur semble avoir mélangé allégrement différents encodages. Je ne suis pas un spécialiste de l'affaire mais quand les BDD sont créées en utf-8, les fichiers PHP en latin1 et que les headers sont envoyé aussi en latin1, j'imagine que ça peut poser problème.

Je me suis dis qu'en modifiant la conf de php, je pourrais arriver au bon résultat mais je n'ai pas réussi et je me répète mais je n'ai pas envie de toucher au code.

Merci de vos conseils

Matt

  • # [HS] PHP et Unicode…

    Posté par (page perso) . Évalué à 2.

    C'est un des trucs qui me font fuir ce langage.

    Et quand on voit comment la tentative d'intégrer Unicode a échouée:
    http://www.slideshare.net/andreizm/the-good-the-bad-and-the-ugly-what-happened-to-unicode-and-php-6

    Ça ne donne pas envie. Python2 avait un côté boiteux entre str et Unicode, qui a été corrigé et éclairci avec Python3; un changement de version majeur dans PHP pour supporter enfin Unicode correctement (+utiliser mieux les espaces de noms plutôt que tout avoir à plat), quitte à conserver temporairement les deux versions, aurait été une grande évolution. Mais non.

    Bon courage, surtout si tu ne veux pas toucher au code. Peut-être qu'il y a moyen de spécifier côté serveur que les données des formulaires doivent être encodées en latin1… Google me donne une piste:

    <form accept-charset="ISO-8859-1" .... >
    

    Voir la discussion dans http://stackoverflow.com/questions/153527/setting-the-character-encoding-in-form-submit-for-internet-explorer

    Python 3 - Apprendre à programmer en Python avec PyZo et Jupyter Notebook → https://www.dunod.com/sciences-techniques/python-3

  • # Et si le problème était ailleurs ? Genre je pense savoir où....

    Posté par (page perso) . Évalué à 3. Dernière modification le 22/01/15 à 17:02.

    Salut,

    Après une première lecture je me suis dit "il va pleurer"….

    Et puis j'ai relue et la il y a un truc qui me fait tiquer :

    • A noter que ce site fonctionnait avant sa migration mais était installé sur une version plus ancienne de debian (5 ou 6).
    • A noter aussi que j'en ai installé un autre sans migration de base et que le problème est toujours là.

    Ton deuxième test est particulièrement intéressant, pertinant et révélateur !
    En effet il écarte la piste de l'encodage au niveau du SGBD, et tous le reste du blabla de fausse piste….

    Donc tu as un site qui tourne sur une debian 5, avec un php4 qui ne passe pas sur une debian 7 avec un php 5.
    Sans déconner ?

    Ce qu'il y a de notable si tu connais un peu ce langage comme moi :
    - version 3 : on mix les variables du script avec celle des formulaires
    - version 4 : introduction de _GET et _POST, mais on autorise toujours la soupe de mix qui est une hérésie de sécurité
    - version 5 : bon les gars, cela fait 4 ans qu'on vous dit de corriger votre code, maintenant les variables de formulaire comme on le dit depuis 4 ans c'est _GET et _POST.

    => Conclusion : ton champs est vide, car la variable est vide !
    Tu dois pouvoir le vérifier avec un simple echo ou var_dump

    Partant de cette conclusion tu as deux solutions :

    1) Gros porc : tu touches pas au code comme tu le souhaites, et tu regardes du coté des variables globales s'ils ont encore en version 5.4 gardé le paramètre de gestion des super globales.

    2) Correct : tu corriges ton code, depuis 4 ans que tu dois le faire.

    Fuse : j'en Use et Abuse !

    • [^] # Re: Et si le problème était ailleurs ? Genre je pense savoir où....

      Posté par (page perso) . Évalué à 3.

      euh…

      Mais quand je veux envoyer un formulaire avec des caractères accentués dans une zone de texte, toute ma chaîne de caractère est ignorée (comprendre elle est remplacée par une chaîne vide dans la BDD et la zone de texte devient blanche). Si ma chaîne ne comprend aucun caractère accentué, alors pas de problème.

      => Conclusion : NAN, essaie encore une fois

      • [^] # Re: Et si le problème était ailleurs ? Genre je pense savoir où....

        Posté par (page perso) . Évalué à 2.

        Dudiou, cella la aussi j'aurais du la relire une seconde fois…

        Alors ok, sans toucher au code : php.ini default_charset, mais tu as déjà essayé non ?

        Sinon, franchement essaye en ajoutant juste un meta sur une des pages :

        <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
        

        Fuse : j'en Use et Abuse !

        • [^] # Re: Et si le problème était ailleurs ? Genre je pense savoir où....

          Posté par . Évalué à 1.

          Merci pour l'aide.

          J'ai en effet essayé le default_charset=utf8

          ça marchotte, c'est à dire que :
          si je rentre des caractères accentués, il revienne dans le textaera mais pour un é par exemple la BDD affiche é (double encodage) par contre il revient bien en é dans le textaera.
          Ça pourrait faire l'affaire, le problème étant que le reste du site affiche des ? à la place des accents.

  • # use case ?

    Posté par (page perso) . Évalué à 2.

    Je pense que cela vient de la base de donnée qui attend un certain encodage et qui ne le trouve pas et du coup remplit le champ à vide. Si c'était juste un soucis latin1 et utf8, les données serait en base mais avec des caractères bizarres, cela vient probablement un peu d'autre chose.

    Il faut un "use case" pour comprendre ce qui peut être fait.

    • [^] # Re: use case ?

      Posté par . Évalué à 2.

      Oui, c'est ça qui est étonnant. Toute la chaîne de caractères disparaît au moindre caractère spécial.

  • # refaire la migration

    Posté par . Évalué à 2.

    1°) exporter la base de l'ancien serveur, et verifier le format avec file ou un editeur de texte multiformat

    2°) convertir dans le nouveau format 'UTF8'

    3°) rechercher/remplacer les chaines qui ont besoin de l'etre (je crois qu'il a des infos de type de caracteres ISO-8859-1 ou UTF8 dans certains parametres

    4°) reimporter la base.

    Apres il restera les problemes deja cités de PHP 3/4 -> PHP5
    et meme pire, de 5.2 à 5.4/5.5 j'ai pété des sites.

    bon courage.

    • [^] # Re: refaire la migration

      Posté par . Évalué à 1.

      Oui, mais le problème est présent sans migration de base.

      Je penche plutôt vers un problème de compatibilité PHP.

      • [^] # Re: refaire la migration

        Posté par . Évalué à 3.

        regarde aussi les options defaultcharset dans apache
        à l'epoque ca devait etre ISO-8859-1 ou ISO-ISO8859-15 maintenant c'est UTF-8

        du coup quand il n'y a rien dans le code web, c'est ce charset qui est envoyé par apache

Suivre le flux des commentaires

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