Caractères étranges dans Request_Content des agents Domino
Nous avons sécurisé nos requêtes AJAX en passant les paramètres en POST et en utilisant la variable CGI request_content, cette variable est ensuite récupérée dans les agents Lotus.
Depuis cette mise en place sur tous les serveurs Domino, nous rencontrons un problème d'encodage/décodage des caractères spéciaux et accentués.
Exemple : ├ê pour è , ├ë pour é
- birthCity=ATHÈNE
- prenom=MÉLODIE
Après plusieurs recherches sur le WEB et tentatives de paramétrage serveur au niveau des documents de site, le problème persiste toujours (passage en UTF8 pour les entrées et sorties)
J'ai trouvé ce post sur le site d'IBM qui préconise de modifier le Javascript mais n'évoque pas l'encodage au niveau serveur :
question : http://www-10.lotus.com/ldd/nd6forum.ns ... enDocument
réponse : http://www-10.lotus.com/ldd/nd6forum.ns ... enDocument
Same problem here (7.0.1): when posting special characters to an agent, the text becomes unreadable.
The workaround that worked for us is :
- Before submitting, javascript "escape" the information
- In your LotusScript agent, do a @URLDecode() (using the Evaluate command) TWICE on the received values.
Nous avons testé cette solution qui fonctionne mais :
Auriez vous une piste de paramétrage serveur ?
Depuis cette mise en place sur tous les serveurs Domino, nous rencontrons un problème d'encodage/décodage des caractères spéciaux et accentués.
Exemple : ├ê pour è , ├ë pour é
- birthCity=ATHÈNE
- prenom=MÉLODIE
Après plusieurs recherches sur le WEB et tentatives de paramétrage serveur au niveau des documents de site, le problème persiste toujours (passage en UTF8 pour les entrées et sorties)
J'ai trouvé ce post sur le site d'IBM qui préconise de modifier le Javascript mais n'évoque pas l'encodage au niveau serveur :
question : http://www-10.lotus.com/ldd/nd6forum.ns ... enDocument
réponse : http://www-10.lotus.com/ldd/nd6forum.ns ... enDocument
Same problem here (7.0.1): when posting special characters to an agent, the text becomes unreadable.
The workaround that worked for us is :
- Before submitting, javascript "escape" the information
- In your LotusScript agent, do a @URLDecode() (using the Evaluate command) TWICE on the received values.
Nous avons testé cette solution qui fonctionne mais :
Auriez vous une piste de paramétrage serveur ?