Discussion :

[ska_root]

Bonjour,

aprés cherchage et pas trouvage, je me tourne vers la communauté pour tenter de résoudre mon problème.

Nous avons en place une DMZ dans laquelle est instancié un serveur apache2.2. celui-ci a pour objectif de rediriger les requêtes vers un autre serveur applicatif. choix est fait de mettre en place un module mod_proxy_http, puis mod_proxy_html.

Le serveur applicatif dispense une appli php gérant le charset ISO-8859-1.
Nous savons que le mod_proxy_html repose sur libxml2 qui par défaut renvoie de l'UTF-8, le mod_proxy_html force donc l'entête HTTP en UTF-8.

Le poste client reçoit donc cette entête :

Date: Wed, 10 Jan 2007 15:40:25 GMT
Server: Apache/2.2.3 (Linux/SUSE)
X-Powered-By: PHP/5.1.2
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Content-Type: text/html;charset=utf-8
Transfer-Encoding: chunked

200 OK

La balise méta du document est toujours positionnée sur ISO-8859-1 mais comme le navigateur regarde d'abord l'entête du document, il affiche donc le bon charset, (UTF-8 pour ceux qui suivent plus...).

mon souci est lié à la saisie d'un formulaire, le contenu de celui-ci est envoyé en UTF-8, alors que l'applicatif attend de l'ISO-8859-1, il procède donc à l'update SGBD dans ce jeu de caractères. Ce qui se traduit par un affichage corrompu.

j'ai déjà essayé de compiler la version bêta 3.0 du module, de modifier la source du module 2.5, et de jouer avec mod_charset_lite, tout ceci en vain. Je ne vois toujours pas comment je peux modifier à la volée le flux envoyé vers le serveur applicatif.
Peut-être me manque-t-il une pièce du puzzle ?

merci à ceux qui ont au moins pris le temps de me lire...

[mathieu]

Dans ton application PHP il suffit d'envoyer l'entête avant la sortie PHP

Code PHP :

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

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

[ska_root]

alors là, merci mathieu... bien essayé petit scarabé

Je ne parle pas du charset applicatif, que je ne peux imposer d'ailleurs, puisqu'il s'agit du travail de plusieurs prestataires, donc plusieurs applications différentes.
Je ne remet pas en cause leurs développements, ils ont fait ce que je leur avais demandé, à savoir gérer le charset.
Et pas la peine non plus de me proposer l'utf8_decode...

le problème n'est donc pas là, mais sur le serveur DMZ qui sert de proxy. Lui devrait savoir ce qui lui est envoyé et paramétrer le parseur libxml2. ce qu'il fait a priori (vu les logs obtenu en mode debug), mais libxml2 doit être bogué.

pour être clair :

serveur applicatif (ntiers)
|
| flux (charset ISO)
|
serveur proxy (mod_proxy_html)
|
| flux (UTF-8 après traitement libxml2 du module)
|
navigateur

après saisie dans un formulaire : le flux montant arrive directement UTF-8 sur le serveur applicatif qui intègre telquel dans la SGBD.

Je pense que la solution est d'utiliser le mod_charset_lite afin de modifier à la volée le flux en sortie du module, mais j'attendais une confirmation sur le sujet.

si quelqu'un a déjà une expérience de ce module, qu'il n'hésite surtout pas à nous en parler...

merci

[mathieu]

alors là, merci mathieu... bien essayé petit scarabé

Je ne parle pas du charset applicatif, que je ne peux imposer d'ailleurs, puisqu'il s'agit du travail de plusieurs prestataires, donc plusieurs applications différentes.
Je ne remet pas en cause leurs développements, ils ont fait ce que je leur avais demandé, à savoir gérer le charset.

je proposais ça parce que si l'application ne défini pas une entête HTTP avec son encodage, la librairie ne savait peut-être pas trouver l'encodage dans le code html (ça tombe bien, je vois mal demander à un proxy de savoir analyser de l'html, ce n'est pas son travail)

Et pas la peine non plus de me proposer l'utf8_decode...

je n'aurais jamais osé, je n'utilise jamais cette fonction