Discussion :

[nicopulse]

Bonjour à tous,

Je travaille actuellement sur un projet web iPhone (HTML/PHP/SQL/JS/AJAX avec FrameWork WebApp) avec une base Oracle et Apache le tout hébergé sous Windows Server 2003.

Après avoir résolu les erreurs d’encodage des fichiers à l’enregistrement
⇨ encoder en ISO 8859-1 et pas en UTF-8
Utiliser la fonction entête au début des pages php :
⇨ header('Content-Type: text/xml; charset=ISO-8859-1');

Je me heurte maintenant à des problèmes d’encodage au niveau du passage des variables d’un formulaire à une page de traitement (requête POST en AJAX). Je viens de passer une journée entière à essayer de le résoudre en vain.

Exemples :
( é ) coté formulaire devient ( é ) sur la page de traitement
( ‘ ) coté formulaire devient ( \‘ ) coté traitement

Je m’en suis aperçu car lors du traitement j’utilise :
⇨ htmlentities()
⇨ htmlspecialchar()
Ces deux fonctions ne font absolument rien sur les variables que je voudrais traiter.

En effectuant des tests (echo), je me suis aperçu que les variables qui contienne des caractères spéciaux sont directement mal encodé dans le $_POST !

Voici le problème sur un test simple (méthode GET) :



J’en déduis que c’est un problème au niveau du passage des variables !

Et je ne sais pas comment résoudre ce problème. Mais je pense qu’il faut forcer le navigateur (ici Safari) à passer des variables en ISO-8859-1 et non pas en UTF-8 comme il à l’air de le faire.
Et il faut le forcer à deux endroits :
⇨ Passer les requêtes POST en ISO-8859-1 au niveau d'une requête AJAX.
⇨ Passer les requêtes POST en ISO-8859-1 au niveau du problème simple illustré ci-dessus.

Voilà donc si quelqu'un à une idée ou à l'expérience de ce genre d'aventure ! Je suis preneur d'explications !

Merci d'avance !

[Séb.]

Exemples :
( é ) coté formulaire devient ( é ) sur la page de traitement

Problème lié à l'UTF-8, comme tu le soupçonnais.

( ‘ ) coté formulaire devient ( \‘ ) coté traitement

Problème lié aux magic-quotes, à lire attentivement http://fr.php.net/manual/fr/security.magicquotes.php notamment http://fr.php.net/manual/fr/security....disabling.php

Je m’en suis aperçu car lors du traitement j’utilise :
⇨ htmlentities()
⇨ htmlspecialchar()
Ces deux fonctions ne font absolument rien sur les variables que je voudrais traiter.

Ces fonctions servent à l'affichage, uniquement.

J’en déduis que c’est un problème au niveau du passage des variables !

Un formulaire tout simple tel que celui ci-dessous donne quoi ??

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
<?php
    header('Content-Type: text/html; charset=ISO-8859-1') ;
    print_r($_GET) ;
?>
<form>
<input type="text" name="s">
<input type="submit">
</form>

[nicopulse]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
<?php
    header('Content-Type: text/html; charset=ISO-8859-1') ;
    print_r($_GET) ;
?>
<form>
<input type="text" name="s">
<input type="submit">
</form>

J'ai rentré : ( testé l'e ) dans le formulaire, voilà le résultat :

[Séb.]

OK, dans quel cas obtiens-tu :

( é ) coté formulaire devient ( é ) sur la page de traitement

?? Quand tu passes par Ajax ?

[nicopulse]

Oui !

(Quelle rapidité !)

Oui, c'est donc bien en utilisant une requête AJAX que j'ai des passages de variables mal encodées.

J'utilise les fonctionnalités du Framework WebApp.net.free.fr. Peut être qu'il va falloir que je touche au fonctionnement de l'AJAX dans le framework ? Rajouter une fonctionnalité pour passer des variables en ISO-8859-1 ?

[Séb.]

Doit y avoir une directive dans ton framework pour sortir les données en ISO-8859-1 plutôt qu'en UTF-8.
Si tu ne la trouves pas tu peux les passer en ISO-8859-1 avec utf8_decode( ).

[nicopulse]

Doit y avoir une directive dans ton framework pour sortir les données en ISO-8859-1 plutôt qu'en UTF-8.
Si tu ne la trouves pas tu peux les passer en ISO-8859-1 avec utf8_decode( ).

Oki, je vais regarder ça !
Pour utf8_decode(), tu parles de la fonction PHP ? JS au niveau de l'url ?

htmlentities()
htmlspecialchar()

Ces fonctions servent à l'affichage, uniquement.
[/code]

J'utilise également les ExpRég vérifier les contraintes des variables mais est-ce que tu peu préciser ce que tu emplois toi pour sécuriser des variables texte, ou est-ce que tu connais un tuto qui parle des ces fonctionnalités ?

[Séb.]

Oki, je vais regarder ça !
Pour utf8_decode(), tu parles de la fonction PHP ? JS au niveau de l'url ?

PHP, à la réception du POST. Mais à utiliser en dernier recours

J'utilise également les ExpRég vérifier les contraintes des variables mais est-ce que tu peu préciser ce que tu emplois toi pour sécuriser des variables texte

Je désactive les magic-quotes et j'utilise mysql_real_escape_string( ) à l'insertion.
A l'affichage : htmlspecialchars($html, ENT_QUOTES).

ou est-ce que tu connais un tuto qui parle des ces fonctionnalités ?

Non, mais ça doit bien exister.

[Djakisback]

Tu peux forcer l'encodage du fichier php que t'appelles en Ajax avec :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

header('Content-Type: text/html; charset=ISO-8859-1');

[nicopulse]

PHP, à la réception du POST. Mais à utiliser en dernier recours

Oui, je ne l'utiliserai qu'en dernier recours.
Après y avoir jeté un coup d'œil (source : webapp.net.free.fr), j'ai trouvé les fonctions suivantes à proximité de l'envoi de la requête AJAX :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
ajax.setRequestHeader("Content-Type", "application/x-www-form-urlencoded");
url = .... encodeURIComponent(values[i]) ....

Je pense que c'est dans ce coin là que doit se gérer l'encodage de l'URL POST mais je vais contacter l'auteur du Framework WebApp.net pour requérir son aide (il est français ).


Merci beaucoup pour ton aide !

Tu peux forcer l'encodage du fichier php que t'appelles en Ajax avec :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

header('Content-Type: text/html; charset=ISO-8859-1');

Ouép, j'avais déjà mis ce header mais le problème vient carrément de l'encodage des paramètres passés dans le $_POST.

Je vous tien au courrant pour la suite.