Forum Programmation.php Problème d'encodage

Posté par matteli le 22 janvier 2015 à 14:14. Licence CC By‑SA.

Étiquettes :

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 lolop (site web personnel) le 22 janvier 2015 à 16:11. É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 dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
# Et si le problème était ailleurs ? Genre je pense savoir où....

Posté par ze_lionix (site web personnel) le 22 janvier 2015 à 17:00. Évalué à 3. Dernière modification le 22 janvier 2015 à 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 hervé Couvelard le 22 janvier 2015 à 17:04. É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 ze_lionix (site web personnel) le 22 janvier 2015 à 17:15. É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 matteli le 22 janvier 2015 à 17:36. É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 hervé Couvelard le 22 janvier 2015 à 18:03. É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 matteli le 22 janvier 2015 à 21:15. É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 NeoX le 22 janvier 2015 à 20:48. É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 matteli le 22 janvier 2015 à 21:15. É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 NeoX le 22 janvier 2015 à 21:45. É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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.