UTF-8, Ajax et IE6
Posté par $Francois pro
Si il y a bien un sujet sur lequel on peut blogger a en perdre haleine, c'est bien UTF-8. Non pas que je n'aime pas l'UTF-8 et ses déclinaisons, il sauve des vies en matière d'i18n. Mais Dieu sait s'il réclame régulièrement son lot de vie de programmeur.
Pourtant la faucheuse dans ce cas-ci n'est pas la norme en elle-même mais plutôt les multiples implémentations par nos fournisseurs logiciels favoris.
Pourquoi ce sujet au départ d'ailleurs ? Parce que je me suis retrouvé le nez bien enfoncé dans un debugger VS.NET attaché à un iexplore.exe sur base du schéma suivant: un tchat style "shoutbox" qui récupère les lignes de tchat via des requêtes longues Ajax a-la-Comet sur un bus de messaging ActiveMQ.
Le contenu des messages est en UTF-8, tout fonctionne correctement sous FireFox mais régulièrement rien ne s'affiche sous IE6. Comment debugger çà ?
Déjà il y a le mythe qu'il n'y a pas de debugger Javascript correct sous IE6.
Sous Firefox, il y a le sublime Firebug et le vénérable et un peu poussif mais parfois encore utile Venkman. Sous IE, à part les boites de dialogues d'erreur Javascript, il n'y a rien. Faux. S'il n'y a rien dans IE, c'est parce que toute la partie de debugging Javascript a été externalisée dans un environnement bien connu des développeurs papillon: VS.NET.
Naïvement je me suis dis que la version Express de Visual Studio qui est gratuite devait permettre cette fonctionnalité. Pas exactement. La fonction permettant de s'attacher à un process iexplore.exe a été enlevée et on ne peut debugger que des projets ASP.NET réalisé avec Web Express. Ah bon?
Première étape, le debugger du pauvre qui s'appele "Script Debugger" et qui date de 1997. Il a une délicieuse interface MDI qui vous rend nostalgique du Visual Basic en quelques secondes. Mais au moins il est gratuit.
On commence par activer le deboggage externe dans les options:

Ensuite via le menu Affichage->Deboggage de Script, on lance le Script Debugger. Résultat, c'est inutilisable. On peut voir le source, la stack, poser des breakpoints mais il n'y a rien pour voir facilement le contenu des variables. Il y a juste une fenêtre "Command" dans lequel on peut taper des commandes Javascript pour "afficher" le contenu des variables. J'entends par là faire des "alert()". Passons et cherchons autre chose.
On me conseille ensuite de regarder le "Script Editor" qui livré avec Office 2003/XP. Ca tombe bien j'ai eu la bonne idée d'installer un Office sur mon PC (le compagnon idéal du hardcore developer). L'icone de MSE est celle de Visual Studio, on est sur la bonne piste! Et effectivement, je n'en reviens pas c'est le debugger de Visual Studio la fonctionnalité permettant de s'attacher à n'importe quel process dont iexplore.exe!
La fonction manquante de Visual Studio Web Express:
On peut égaler l'appeler directement depuis IE via Affichage->Deboggeur de Script à condition d'avoir au moins lancé une fois Microsoft Script Editor une fois et d'avoir choisi "Installer le deboggage Web" dans le menu Deboggage. (Il est nécessaire d'avoir désinstallé Microsoft Script Debbugger avant de tenter cette manipulation)
On ajoute un breakpoint manuellement au début du fichier amq.js, ensuite un autre breakpoint précisement sur la partie XHR et on termine avec un "espion" sur request.responseXML.parseError. Un coup de F5 et nous voici au coeur du problème:
- request.responseXML.parseError {...} Object
errorCode -1072896760 Long
reason "Un caractère incorrect a été trouvé dans un contenu de texte.
" String
srcText "1
Avec le parsing qui s'arrête net sur le premier caractère accentué UTF-8 de la réponse XML Ajax. Pourquoi IE refuse de faire le parsing de l'UTF8 dans ce message ? A cause du header HTTP Content-Type renvoyé par le serveur de servlets:
HTTP/1.1 200 OK
Date: Thu, 21 Dec 2006 17:29:40 GMT
Server: Apache-Coyote/1.1
Cache-Control: no-cache
Content-Type: text/xml;charset=ISO-8859-1
Content-Length: 269
Connection: close
1
Et oui. Si le charset n'est pas UTF-8, IE refuse de parser du UTF-8 dans les réponses XHR.
Pourtant le header de la requête HTTP le spécifait bien:
POST /activemq-web-console/amq HTTP/1.1
Accept: text/javascript, text/html, application/xml, text/xml, */*
x-prototype-version: 1.5.0_rc1
x-requested-with: XMLHttpRequest
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Host: localdev
Content-Length: 108
destination=topic://SHENZHOU.FEED?timeout=3&message=feeditem&type=listen&poll=true
L'erreur vient ici de la servlet AJAX de ActiveMQ qui ne précise aucun encodage spécifique lors de ces réponses et donc c'est le charset par défaut, soit iso-8859-1, qui est renvoyé par Tomcat.
J'ai résolu mon problème en recompilant la Servlet AJAX de ActiveMQ avec quelques setContentType('text/xml; charset=utf-8'); mais ca ne me parait pas très flexible.
Je n'ai pas trouvé dans la configuration de settings globale pour changer l'encodage par défaut de Tomcat. (si quelqu'un sait, qu'il parle!)
Moralité: Dans ce cas précis, IE est plus respectueux de la norme que FireFox qui parse allégrement le message malgré un conflit entre l'encodage précise et le contenu. Autrement dit j'ai été médisant avant de débugger le problème en profondeur. J'aurais au moins appris à debugger du javascript sous IE6, cette journée n'est pas donc perdue. Hmm.
Et si vous voulez voir le fruit des efforts au final: http://www.shenzhou.be/live






9 commentaires à cet article.
Pas mal comme résultat !
J'avais déja rencontrés des problémes similaire d'encodage avec ASP.NET qui ont été réglé de la meme maniere.
J'ai rien pigé meme en relisant 458 fois :o
C'est du chinois pour moi
ca va vyrus tu me rassure .... enfin bon pour moi c de l'espagnol je comprend un peu mais vraiment tres peu :o
Ah bah je me sens moins seul aussi (sauf que je me suis arrêté à la première lecture et encore... en plusieurs fois)
A pas compris !!!!!!!!!!!!!!!!
Tu peux mettre le même article ? Mais en français :-o Siouplé m'sieur
Ce ne serait pas modifiable avec une variable d'environnement ?
LANG=en_US.UTF-8; export LANG
Hmm ou encore dans le fichier XML de config. le paramètre : URIEncoding
Désolé pour le nb de commentaires à la suite :
Solution
* user des paramètres URIEncoding et useBodyEncodingForURI - voir la configuration connecteur HTTP de Tomcat - pour forcer, par configuration l'encodage utilisé dans les URI.
Source : http://anothergeekwebsite.com/fr/node/74
Lien proposé dans la source pour aller plus loin : http://tomcat.apache.org/tomcat-5.0-doc/config/http.html
Tenez moi au courant si cela fonctionne ou non, momobar-18119
Je me suis retrouvé l'autre jour avec un problème d'encodage du même type... Sauf, que c'était moins farfelu comme Bazar :)
Sinon, toi qui use et absuse de l'AJAX, avec beaucoup de style d'ailleurs, tu pourras pas nous en faire une petite demo facile parce que j'avais qu'exécuter des requetes PHP sans devoir recharger, ca peut s'avérer vachement utile et plus léger.
(J'ai juste peur de JS qui se cache derrière :D)