[Définitivement résolu, merci :)]Json, requête http et encodage...

Salut,

Avec un script moteur en js et un autre en json (lequel me sert de base de données - l'hébergeur n'ayant pas ouvert de bdd avec mysql).

Jusqu'à présent, j'attachais les scripts directement avec la page HTML mais le script json commençant à prendre du poids, j'appelle le script avec une requête http.

Lorsque les fichiers étaient directement attachés à la page HTML, l'affichage sortait correctement pour les signes accentués même si dans le fichier brut ils étaient écrits avec les accents sans passer par un encodage pour ces caractères.

Depuis que j'ai transformé le script et lance une requête http, la sortie des caractères accentués se transforme en un joli point d'interrogation sous ff. [Ces résultats sont obtenus sur un serveur local, ie : mon pc]

J'ai consulté plusieurs pages de ce forum, modifié les entêtes pour la réponse en précisant le charset (utf-8, iso-88-59...) avec le caractère test suivant :

é é é

Rien n'y fait toujours l'affichage brut avec les caractères non traduits. La seule solution trouvée est de passer par l'unicode :

ç --> \u00e7

Et la sortie devient effectivement un "ç".

Mes questions :

-Lorsque les scripts sont directement attachés à la page HTML, pourquoi la sortie est-elle bonne (en admettant que le non encodage des caractères accentués soit suffisant) ?
-Lorsque, pour les mêmes scripts, on lance une requête http, la sortie n'est plus la même : qu'est-ce qu'il manque entre les deux ? C'est ce point que je n'arrive pas à résoudre ni à comprendre ?
-Pour ce cas précis, seul l'unicode est à envisager ?
Modifié par jean-marc (30 May 2007 - 15:34)

Salut,

Personne n'a une idée sur la différence de sortie entre les deux scripts attachés à la page HTML et l'un appelé depuis une requête http ?

Néanmoins j'ai entièrement passé cette petite bdd avec les unicodes (\u00e9, \u00e8, etc). J'avais un peu peur que le moteur de recherche que j'utilisais dessus ne fonctionne pas mais cela n'est pas gênant. Mais maintenant c'est ie version 6 qui n'aime pas le 'eval' pour json mais c'est une autre histoire. Je vais tenter d'installer le firebug lite pour ie, que je ne connaissais pas et que je découvre grâce à vous et qui tombe à point nommé.

A bientôt.

Bonjour,

Lorsqu'un script est intégré directement dans la page HTML (élément script), il hérite de l'encodage de la page. Lorsqu'il est inclus dans un fichier externe, il faut gérer l'encodage pour ce fichier (et il peut être différent de celui de la page).

Je ne connais pas trop le support des différents navigateurs pour les caractères non ASCII dans un fichier JavaScript, mais je suis étonné que ça ne marche pas avec Firefox. As-tu un exemple simple en ligne ?

Pour ma part, j'évite de mettre des caractères non ASCII dans les fichiers JavaScript, car en dehors du contexte (le serveur), il n'y a pas de moyen de spécifier l'encodage du fichier.

Salut julien,

Merci pour ta réponse. Et c'est ta réponse qui me donne la clef... En le testant en ligne directement non pas en local sur un pc, il n'y a pas de problèmes... Puisque tout se passe bien, je considère le problème comme résolu.

Le problème vient bien de ff et en mode local ; j'ai fait des tests sous linux et windows : même problème alors qu'avec opera tout se passe bien.

Néanmoins voici un lien test : http://www.perigord.tm.fr/~apcd/news2.htm#
(il suffit de naviguer sur les deux premiers textes).

Il y a quelque chose que je ne comprends pas : comment fais-tu pour faire du XHR en local ?

Julien Royer a écrit :
Il y a quelque chose que je ne comprends pas : comment fais-tu pour faire du XHR en local ?

Ben, j'installe wamp pour windows qui inclut un serveur apache + php + mysql. Pour linux, j'installe apache. Voilà, c'est tout. J'active les services pour linux (httpd et network) et hop tout fonctionne. Pour windows, il suffit de lancer wampserver. Ensuite tu places tes fichiers dans le dossier www puis tu lances le site avec l'adresse 127.0.0.1/www/monsite.htm de n'importe quel navigateur.

Jusqu'à présent c'était relativement fiable mais là il y a un problème entre le mode local et le mode en ligne pour xhr d'où mes questions.

En fait, il doit y avoir un paramétrage pour apache que je n'ai pas activé puisque le même problème se réitère et pour linux et pour windows. Je laisse les configs par défaut donc le problème de rendu doit venir de là quand bien même si on lit les paramètres pour les entêtes http pour ff, il accepte les iso-88-59-1, utf-8, text/plain, text/html, etc.
Modifié par jean-marc (21 May 2007 - 16:34)

Ah d'accord, je pensais que par "en local", tu entendais en passant directement par le système de fichiers.

Dans ce cas-là la réponse à ta question est sans doute dans la configuration du serveur Apache, et donc des en-têtes HTTP qui sont envoyés pour le fichier contenant les données JSON.

Julien Royer a écrit :
Ah d'accord, je pensais que par "en local", tu entendais en passant directement par le système de fichiers.

Dans ce cas-là la réponse à ta question est sans doute dans la configuration du serveur Apache, et donc des en-têtes HTTP qui sont envoyés pour le fichier contenant les données JSON.

Nos réponses se sont croisées, j'ai édité la réponse précédent avec la même conclusion. Si jamais tu as une idée...

Première chose à faire : vérifier que l'en-tête Content-Type est correctement défini pour ton fichier, par exemple avec l'extension Web Developer pour Firefox (dans la version anglaise : Information > View Response Headers).

Julien Royer a écrit :
Première chose à faire : vérifier que l'en-tête Content-Type est correctement défini pour ton fichier, par exemple avec l'extension Web Developer pour Firefox (dans la version anglaise : Information > View Response Headers).

Pour l'instant, je ne suis pas chez moi. Et de chez moi, je n'ai pas de connexion internet. Donc je regarderai cela ce soir plus en profondeur.

En tout cas de mémoire, j'avais essayé avec plusieurs entêtes différentes sans grand résultat :

xmlobj.setRequestHeader('Content-Type','text/plain;charset=UTF-8')
 xmlobj.setRequestHeader('Content-Type','text/plain;charset=iso-8859-1')
et même avec charset=unicode (on ne sait jamais...)

Puis j'ai essayé en appliquant le charset directement au bloc conteneur, en désespoir de cause :

document.charset="iso-8859-1", "utf-8".

Mais, à chaque fois toujours le même résultat.
Modifié par jean-marc (21 May 2007 - 16:59)

Salut julien,

Je te donne les tests effectués hier soir bien qu'on sorte un peu du sujet...

Suivant l'extension lors de l'envoi de la requête, le content type des "response headers" se modifie mais cela ne change rien...

Je rappelle la problématique : les lettres accentuées avec un appel xhr ne ressortent pas normalement sous ff. Nous en avons déduit que cela provenait des serveurs locaux (sur un pc) qui étaient mal configurés avec l'exception notable du navigateur opera qui ne génère pas ce problème interne. Toutefois, lorsque le script est mis sur internet (que j'appelle serveur distant) le problème ne se produit pas d'où la mention résolue.

attention : tests faits en local avec le serveur apache sur mon pc.

a écrit :

Pour webdevelopper, la réponse est text/html.

a écrit :

storeHeadlines('chambres/js/search_db_json_exemple.txt');

ff 1.5 sur pc
response headers (firebug / xhr) : content-type = text/plain
portable ff 2.0.0.3
response headers (firebug / xhr) : content-type = text/plain


Lorsque je place pour cet exemple un setRequestHeader de type

load_quest.setRequestHeader('Content-Type','text/plain;charset=iso-8859-1');

affiche toujours les points d'interrogation

load_quest.setRequestHeader('Content-Type','text/plain;charset=utf-8');

idem pour l'affichage en sortie

a écrit :

storeHeadlines('chambres/js/search_db_json_exemple.json');

ff 1.5 sur pc :
response headers (firebug / xhr) : content type = text/html
portable ff 2.0.0.3 sur clé usb :
response headers (firebug / xhr) : content type = text/plain

idem pour l'affichage en sortie pour utf et iso

C'est la seule différence à retenir pour l'extension json.

a écrit :

storeHeadlines('chambres/js/search_db_json_exemple.js');
ff 1.5 sur pc :
response headers (firebug / xhr) : content type=application/x-javascript
portable ff 2.0.0.3 sur clé usb :
response headers (firebug / xhr) : content tpe=application/x-javascript

idem pour l'affichage de sortie pour utf et iso

J'ai remplacé dans le httpd.conf pour le serveur apache le default mime type text/plain par text/html
mais le résultat est le même ;
Je repasse en text/plain par défaut, pas de changement. Je suppose qu'il faudrait creusait un peu plus la config du serveur Apache pour obtenir un résultat correct.

Hello,

Si j'ai bien compris ton problème, setRequestHeader n'est pas du tout la bonne solution : ça modifie les en-têtes de ta requête et non pas de la réponse (le fichier JSON).

Il faut donc changer l'en-tête au niveau du serveur, soit en utilisant header en PHP, soit en modifiant comme tu l'as fait la configuration du serveur Apache : il ne faut pas que tu passes en text/html par défaut, mais plutôt que tu spécifies un encodage par défaut (éventuellement avec un .htaccess).

Julien Royer a écrit :
Hello,

Si j'ai bien compris ton problème, setRequestHeader n'est pas du tout la bonne solution : ça modifie les en-têtes de ta requête et non pas de la réponse (le fichier JSON).

Il faut donc changer l'en-tête au niveau du serveur, soit en utilisant header en PHP, soit en modifiant comme tu l'as fait la configuration du serveur Apache : il ne faut pas que tu passes en text/html par défaut, mais plutôt que tu spécifies un encodage par défaut (éventuellement avec un .htaccess).

Ok ! Je vais essayer ça. Et puis la solution php, à force de regarder à droite et à gauche, me semblait, au final, la plus connue pour l'histoire du header. Bon, il y aussi le fait de repasser la base de json vers xml (cas non étudié et qui ne pose pas problèmes par rapport aux caractères encodés). Comme souvent, il y a un ensemble de solutions à étudier.

Certaines sont bonnes pour une tâche, d'autres moins, etc

Sinon j'avais pensé aussi à faire une requête sans passer par ajax mais avec du php ; je crois que c'est possible à réaliser (je dois avoir un tuto sur le sujet dans mes archives ; oui php ne m'est pas très familier...) mais je trouverai bien une solution transversale. Je jetterai aussi un oeil sur le tout nouveau tuto d'alsacréations qui rejoint un peu la problématique du header avec php, en le parcourant vite fait c'est ce que j'ai retenu bien que ce soit pour autre chose mais il doit être possible de l'adapter .

En tout cas merci pour tout.

Julien Royer a écrit :
Hello,

Si j'ai bien compris ton problème, setRequestHeader n'est pas du tout la bonne solution : ça modifie les en-têtes de ta requête et non pas de la réponse (le fichier JSON).

Il faut donc changer l'en-tête au niveau du serveur, soit en utilisant header en PHP, soit en modifiant comme tu l'as fait la configuration du serveur Apache : il ne faut pas que tu passes en text/html par défaut, mais plutôt que tu spécifies un encodage par défaut (éventuellement avec un .htaccess).

Salut Julien,

C'est définitivement résolu ! La solution avec le .htaccess est la plus simple quand bien même une première piste avait été trouvée en modifiant le httpd.conf et en ajoutant AddDefaultCharset ISO-8859-1.

Puis je me suis penché un tantinet sur le .htaccess, et ai ajouté la même directive avec un petit plus pour la fameuse erreur 404. Je m'étais souvent demandé comment cela était possible... de personnaliser cette fameuse page !

Le truc qui m'ennuyait le plus c'était le "eval" de la fonction. Internet explorer version 6 me le refusait systématiquement. Je me suis tordu les neurones pendant quelques heures croyant que cela venait du script...

Puis finalement non ! C'était bien à la response header qui manquait l'encodage ; heureusement que cette directive est arrivée à point nommée puisque du même coup ie accepte, désormais, le script. deux problèmes résolus en un !!! Wow !

Du coup je laisse sur la version en ligne un fichier .htaccess avec un AddDefaulCharset.

Bonjour,

jean-marc a écrit :
C'est définitivement résolu !

Tant mieux.