j'ai un souci l'accent par ajax. je suis dessus depuis plusieurs jours
et ca commence à faire bien long.
en gros :
- j'ai une page php qui comporte un champ html input (dont l'id est test)
- pour les tests, je met dans le champ input par exemple le caractère "é"
- j'envoi au serveur le contenu de ce champ par un bouton submit et
le serveur me trouve la valeur asci 233 ce qui en iso-8859-1 est bien le
caractère "é" qui a été envoyé : normal
- j'envoi le contenu de ce champ par ajax, et là le serveur me détecte 2
caractères : 195 et 169 : pas mormal
j'ai positionné partout ou j'ai pu le charset iso-8859-1, à savoir :
- dans la page html, partie php
- dans le head de la page html
- dans le mode d'encodage de l'objet XMLHttpRequest
- dans le php.ini : default_charset = "iso-8859-1"
- dans le httpd.conf d'apache : AddDefaultCharset iso-8859-1
environnement
- Xp
- apache 2.0.59
- php 5.1.2
le problème est le même quelque soit le navigateur (IE5,6,7 firefox)
function getXMLHttpRequest(){
var http_request = null;
if(window.XMLHttpRequest) {// Firefox et autres
http_request = new XMLHttpRequest();
if (http_request.overrideMimeType) {
// set type accordingly to anticipated content type
//http_request.overrideMimeType('text/xml');
http_request.overrideMimeType('text/html');
}
}
else if(window.ActiveXObject){ // Internet Explorer
try {
http_request = new ActiveXObject("Msxml2.XMLHTTP");
} catch (e) {
try {
http_request = new ActiveXObject("Microsoft.XMLHTTP");
} catch (e1) {
http_request = null;
}
}
}
return http_request;
}
function go() {
var http_request = getXMLHttpRequest();
var txt = document.getElementById('test').value;
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Olivier Miakinen
j'ai un souci l'accent par ajax. je suis dessus depuis plusieurs jours et ca commence à faire bien long.
En effet.
en gros : - j'ai une page php qui comporte un champ html input (dont l'id est test) - pour les tests, je met dans le champ input par exemple le caractère "é" - j'envoi au serveur le contenu de ce champ par un bouton submit et le serveur me trouve la valeur asci 233 ce qui en iso-8859-1 est bien le caractère "é" qui a été envoyé : normal
Ok.
- j'envoi le contenu de ce champ par ajax, et là le serveur me détecte 2 caractères : 195 et 169 : pas mormal
Il ne s'agit en fait pas de deux caractères, mais d'un seul caractère encodé sur deux octets en UTF-8.
j'ai positionné partout ou j'ai pu le charset iso-8859-1, à savoir :
- dans la page html, partie php - dans le head de la page html - dans le mode d'encodage de l'objet XMLHttpRequest - dans le php.ini : default_charset = "iso-8859-1" - dans le httpd.conf d'apache : AddDefaultCharset iso-8859-1
Ben oui, mais XML est par défaut en UTF-8, et d'après ce que tu décris il semble difficile d'aller contre. Pourquoi ne ferais-tu pas un utf8_decode() en réception, si vraiment tu tiens à ISO-8859-1 ?
[ crosspost respecté, mais suivi dans un seul groupe ]
j'ai un souci l'accent par ajax. je suis dessus depuis plusieurs jours
et ca commence à faire bien long.
En effet.
en gros :
- j'ai une page php qui comporte un champ html input (dont l'id est test)
- pour les tests, je met dans le champ input par exemple le caractère "é"
- j'envoi au serveur le contenu de ce champ par un bouton submit et
le serveur me trouve la valeur asci 233 ce qui en iso-8859-1 est bien le
caractère "é" qui a été envoyé : normal
Ok.
- j'envoi le contenu de ce champ par ajax, et là le serveur me détecte 2
caractères : 195 et 169 : pas mormal
Il ne s'agit en fait pas de deux caractères, mais d'un seul caractère
encodé sur deux octets en UTF-8.
j'ai positionné partout ou j'ai pu le charset iso-8859-1, à savoir :
- dans la page html, partie php
- dans le head de la page html
- dans le mode d'encodage de l'objet XMLHttpRequest
- dans le php.ini : default_charset = "iso-8859-1"
- dans le httpd.conf d'apache : AddDefaultCharset iso-8859-1
Ben oui, mais XML est par défaut en UTF-8, et d'après ce que tu
décris il semble difficile d'aller contre. Pourquoi ne ferais-tu pas
un utf8_decode() en réception, si vraiment tu tiens à ISO-8859-1 ?
[ crosspost respecté, mais suivi dans un seul groupe ]
j'ai un souci l'accent par ajax. je suis dessus depuis plusieurs jours et ca commence à faire bien long.
En effet.
en gros : - j'ai une page php qui comporte un champ html input (dont l'id est test) - pour les tests, je met dans le champ input par exemple le caractère "é" - j'envoi au serveur le contenu de ce champ par un bouton submit et le serveur me trouve la valeur asci 233 ce qui en iso-8859-1 est bien le caractère "é" qui a été envoyé : normal
Ok.
- j'envoi le contenu de ce champ par ajax, et là le serveur me détecte 2 caractères : 195 et 169 : pas mormal
Il ne s'agit en fait pas de deux caractères, mais d'un seul caractère encodé sur deux octets en UTF-8.
j'ai positionné partout ou j'ai pu le charset iso-8859-1, à savoir :
- dans la page html, partie php - dans le head de la page html - dans le mode d'encodage de l'objet XMLHttpRequest - dans le php.ini : default_charset = "iso-8859-1" - dans le httpd.conf d'apache : AddDefaultCharset iso-8859-1
Ben oui, mais XML est par défaut en UTF-8, et d'après ce que tu décris il semble difficile d'aller contre. Pourquoi ne ferais-tu pas un utf8_decode() en réception, si vraiment tu tiens à ISO-8859-1 ?
[ crosspost respecté, mais suivi dans un seul groupe ]
Pierre Goiffon
Olivier Miakinen wrote:
en gros : - j'ai une page php qui comporte un champ html input (dont l'id est test) - pour les tests, je met dans le champ input par exemple le caractère "é" - j'envoi au serveur le contenu de ce champ par un bouton submit et le serveur me trouve la valeur asci 233 ce qui en iso-8859-1 est bien le caractère "é" qui a été envoyé : normal (...)
- j'envoi le contenu de ce champ par ajax, et là le serveur me détecte 2 caractères : 195 et 169 : pas mormal
Il ne s'agit en fait pas de deux caractères, mais d'un seul caractère encodé sur deux octets en UTF-8.
Olivier tu aura été plus rapide que moi à répondre :)
j'ai positionné partout ou j'ai pu le charset iso-8859-1, à savoir :
- dans la page html, partie php - dans le head de la page html - dans le mode d'encodage de l'objet XMLHttpRequest - dans le php.ini : default_charset = "iso-8859-1" - dans le httpd.conf d'apache : AddDefaultCharset iso-8859-1
Ben oui, mais XML est par défaut en UTF-8, et d'après ce que tu décris il semble difficile d'aller contre. Pourquoi ne ferais-tu pas un utf8_decode() en réception, si vraiment tu tiens à ISO-8859-1 ?
Nous en avons parlé plusieurs fois notamment dans f.c.i.w.auteurs, et nous avions mis en ligne plusieurs exemples qui récupéraient des contenus en ISO Latin-1 par XHR, ça fonctionnait très bien... à condition évidemment que le charset soit correctement déclaré pour la page récupérée !
Tiens je trouve que l'exemple que j'avais mis en ligne est toujours là : http://pgoiffon.free.fr/_temp/XHR_charset.html
[ crosspost respecté, mais suivi dans un seul groupe ]
Je ne lis pas le groupe PHP, et il me parait absolument pas approprié (?!!?!!). Suivi et copie sur fr.comp.infosystemes.www.auteurs, puisque c'est un prb générique de déclaration de charset et de XHR.
Olivier Miakinen wrote:
en gros :
- j'ai une page php qui comporte un champ html input (dont l'id est test)
- pour les tests, je met dans le champ input par exemple le caractère "é"
- j'envoi au serveur le contenu de ce champ par un bouton submit et
le serveur me trouve la valeur asci 233 ce qui en iso-8859-1 est bien le
caractère "é" qui a été envoyé : normal
(...)
- j'envoi le contenu de ce champ par ajax, et là le serveur me détecte 2
caractères : 195 et 169 : pas mormal
Il ne s'agit en fait pas de deux caractères, mais d'un seul caractère
encodé sur deux octets en UTF-8.
Olivier tu aura été plus rapide que moi à répondre :)
j'ai positionné partout ou j'ai pu le charset iso-8859-1, à savoir :
- dans la page html, partie php
- dans le head de la page html
- dans le mode d'encodage de l'objet XMLHttpRequest
- dans le php.ini : default_charset = "iso-8859-1"
- dans le httpd.conf d'apache : AddDefaultCharset iso-8859-1
Ben oui, mais XML est par défaut en UTF-8, et d'après ce que tu
décris il semble difficile d'aller contre. Pourquoi ne ferais-tu pas
un utf8_decode() en réception, si vraiment tu tiens à ISO-8859-1 ?
Nous en avons parlé plusieurs fois notamment dans f.c.i.w.auteurs, et
nous avions mis en ligne plusieurs exemples qui récupéraient des
contenus en ISO Latin-1 par XHR, ça fonctionnait très bien... à
condition évidemment que le charset soit correctement déclaré pour la
page récupérée !
Tiens je trouve que l'exemple que j'avais mis en ligne est toujours là :
http://pgoiffon.free.fr/_temp/XHR_charset.html
[ crosspost respecté, mais suivi dans un seul groupe ]
Je ne lis pas le groupe PHP, et il me parait absolument pas approprié
(?!!?!!). Suivi et copie sur fr.comp.infosystemes.www.auteurs, puisque
c'est un prb générique de déclaration de charset et de XHR.
en gros : - j'ai une page php qui comporte un champ html input (dont l'id est test) - pour les tests, je met dans le champ input par exemple le caractère "é" - j'envoi au serveur le contenu de ce champ par un bouton submit et le serveur me trouve la valeur asci 233 ce qui en iso-8859-1 est bien le caractère "é" qui a été envoyé : normal (...)
- j'envoi le contenu de ce champ par ajax, et là le serveur me détecte 2 caractères : 195 et 169 : pas mormal
Il ne s'agit en fait pas de deux caractères, mais d'un seul caractère encodé sur deux octets en UTF-8.
Olivier tu aura été plus rapide que moi à répondre :)
j'ai positionné partout ou j'ai pu le charset iso-8859-1, à savoir :
- dans la page html, partie php - dans le head de la page html - dans le mode d'encodage de l'objet XMLHttpRequest - dans le php.ini : default_charset = "iso-8859-1" - dans le httpd.conf d'apache : AddDefaultCharset iso-8859-1
Ben oui, mais XML est par défaut en UTF-8, et d'après ce que tu décris il semble difficile d'aller contre. Pourquoi ne ferais-tu pas un utf8_decode() en réception, si vraiment tu tiens à ISO-8859-1 ?
Nous en avons parlé plusieurs fois notamment dans f.c.i.w.auteurs, et nous avions mis en ligne plusieurs exemples qui récupéraient des contenus en ISO Latin-1 par XHR, ça fonctionnait très bien... à condition évidemment que le charset soit correctement déclaré pour la page récupérée !
Tiens je trouve que l'exemple que j'avais mis en ligne est toujours là : http://pgoiffon.free.fr/_temp/XHR_charset.html
[ crosspost respecté, mais suivi dans un seul groupe ]
Je ne lis pas le groupe PHP, et il me parait absolument pas approprié (?!!?!!). Suivi et copie sur fr.comp.infosystemes.www.auteurs, puisque c'est un prb générique de déclaration de charset et de XHR.
ASM
j'ai positionné partout ou j'ai pu le charset iso-8859-1, à savoir :
- dans la page html, partie php - dans le head de la page html - dans le mode d'encodage de l'objet XMLHttpRequest - dans le php.ini : default_charset = "iso-8859-1" - dans le httpd.conf d'apache : AddDefaultCharset iso-8859-1
Ben oui, mais XML est par défaut en UTF-8,
il paraît.
et d'après ce que tu décris il semble difficile d'aller contre.
Je ne comprends pas, il paraîtrait qu'il suffirait d'envoyer les bons en-têtes ? Et là on a un très net commandement php de ces en-têtes me semble-ce. Pourquoi n'est-ce point suivi ?
Serait-ce le XMLHttpRequest qui poste en utf-8 ? (au lieu de simplement se cantonner à la réception dans ce charset si omission).
Serait-ce le JS du brouteur qui s'obstine au utf-8 alors qu'on lui a indiqué autre chose ? (par exemple mon Safari me cracrabouille en iso-latin ce qui lui a été envoyé en utf-8 si l'envoi n'est pas précédé de la déclaration xhtml de charset utf-8 et ce même si la page hôte est en utf-8)
Pourquoi ne ferais-tu pas un utf8_decode() en réception, si vraiment tu tiens à ISO-8859-1 ?
[ crosspost respecté, mais suivi dans un seul groupe ]
Bon, je ne saurai pas si cette ficelle lui aura réussi.
-- Stephane Moriaux et son (moins) vieux Mac déjà dépassé
j'ai positionné partout ou j'ai pu le charset iso-8859-1, à savoir :
- dans la page html, partie php
- dans le head de la page html
- dans le mode d'encodage de l'objet XMLHttpRequest
- dans le php.ini : default_charset = "iso-8859-1"
- dans le httpd.conf d'apache : AddDefaultCharset iso-8859-1
Ben oui, mais XML est par défaut en UTF-8,
il paraît.
et d'après ce que tu
décris il semble difficile d'aller contre.
Je ne comprends pas, il paraîtrait qu'il suffirait d'envoyer les bons
en-têtes ?
Et là on a un très net commandement php de ces en-têtes me semble-ce.
Pourquoi n'est-ce point suivi ?
Serait-ce le XMLHttpRequest qui poste en utf-8 ?
(au lieu de simplement se cantonner à la réception dans ce charset si
omission).
Serait-ce le JS du brouteur qui s'obstine au utf-8 alors qu'on lui a
indiqué autre chose ?
(par exemple mon Safari me cracrabouille en iso-latin ce qui lui a été
envoyé en utf-8 si l'envoi n'est pas précédé de la déclaration xhtml de
charset utf-8 et ce même si la page hôte est en utf-8)
Pourquoi ne ferais-tu pas
un utf8_decode() en réception, si vraiment tu tiens à ISO-8859-1 ?
[ crosspost respecté, mais suivi dans un seul groupe ]
Bon, je ne saurai pas si cette ficelle lui aura réussi.
--
Stephane Moriaux et son (moins) vieux Mac déjà dépassé
j'ai positionné partout ou j'ai pu le charset iso-8859-1, à savoir :
- dans la page html, partie php - dans le head de la page html - dans le mode d'encodage de l'objet XMLHttpRequest - dans le php.ini : default_charset = "iso-8859-1" - dans le httpd.conf d'apache : AddDefaultCharset iso-8859-1
Ben oui, mais XML est par défaut en UTF-8,
il paraît.
et d'après ce que tu décris il semble difficile d'aller contre.
Je ne comprends pas, il paraîtrait qu'il suffirait d'envoyer les bons en-têtes ? Et là on a un très net commandement php de ces en-têtes me semble-ce. Pourquoi n'est-ce point suivi ?
Serait-ce le XMLHttpRequest qui poste en utf-8 ? (au lieu de simplement se cantonner à la réception dans ce charset si omission).
Serait-ce le JS du brouteur qui s'obstine au utf-8 alors qu'on lui a indiqué autre chose ? (par exemple mon Safari me cracrabouille en iso-latin ce qui lui a été envoyé en utf-8 si l'envoi n'est pas précédé de la déclaration xhtml de charset utf-8 et ce même si la page hôte est en utf-8)
Pourquoi ne ferais-tu pas un utf8_decode() en réception, si vraiment tu tiens à ISO-8859-1 ?
[ crosspost respecté, mais suivi dans un seul groupe ]
Bon, je ne saurai pas si cette ficelle lui aura réussi.
-- Stephane Moriaux et son (moins) vieux Mac déjà dépassé
ownowl
j'ai positionné partout ou j'ai pu le charset iso-8859-1, à savoir :
- dans la page html, partie php - dans le head de la page html - dans le mode d'encodage de l'objet XMLHttpRequest - dans le php.ini : default_charset = "iso-8859-1" - dans le httpd.conf d'apache : AddDefaultCharset iso-8859-1
Ben oui, mais XML est par défaut en UTF-8, et d'après ce que tu décris il semble difficile d'aller contre. Pourquoi ne ferais-tu pas un utf8_decode() en réception, si vraiment tu tiens à ISO-8859-1 ?
merci de ta réponse.
en effet l'envoi est en UTF-8, apparament le paramètre charset de setRequestHeader n'est pas pris en compte. entre temps (2 jours entre l'écriture du message et sa diffusion) j'ai fait quelque tests en passant mes paramètres post coté client par la fonction javascript escape, et ca marche correctement. Je préfère l'encodage coté client car dans mon cas toutes les requetes sont construites en passant par une même fonction, coté serveur c'est un peu moins vrai a+ Olivier
j'ai positionné partout ou j'ai pu le charset iso-8859-1, à savoir :
- dans la page html, partie php
- dans le head de la page html
- dans le mode d'encodage de l'objet XMLHttpRequest
- dans le php.ini : default_charset = "iso-8859-1"
- dans le httpd.conf d'apache : AddDefaultCharset iso-8859-1
Ben oui, mais XML est par défaut en UTF-8, et d'après ce que tu
décris il semble difficile d'aller contre. Pourquoi ne ferais-tu pas
un utf8_decode() en réception, si vraiment tu tiens à ISO-8859-1 ?
merci de ta réponse.
en effet l'envoi est en UTF-8, apparament le paramètre charset de
setRequestHeader n'est pas pris en compte.
entre temps (2 jours entre l'écriture du message et sa diffusion) j'ai
fait quelque tests en passant mes paramètres post coté client par la
fonction javascript escape, et ca marche correctement.
Je préfère l'encodage coté client car dans mon cas toutes les requetes
sont construites en passant par une même fonction, coté serveur c'est un
peu moins vrai
a+
Olivier
j'ai positionné partout ou j'ai pu le charset iso-8859-1, à savoir :
- dans la page html, partie php - dans le head de la page html - dans le mode d'encodage de l'objet XMLHttpRequest - dans le php.ini : default_charset = "iso-8859-1" - dans le httpd.conf d'apache : AddDefaultCharset iso-8859-1
Ben oui, mais XML est par défaut en UTF-8, et d'après ce que tu décris il semble difficile d'aller contre. Pourquoi ne ferais-tu pas un utf8_decode() en réception, si vraiment tu tiens à ISO-8859-1 ?
merci de ta réponse.
en effet l'envoi est en UTF-8, apparament le paramètre charset de setRequestHeader n'est pas pris en compte. entre temps (2 jours entre l'écriture du message et sa diffusion) j'ai fait quelque tests en passant mes paramètres post coté client par la fonction javascript escape, et ca marche correctement. Je préfère l'encodage coté client car dans mon cas toutes les requetes sont construites en passant par une même fonction, coté serveur c'est un peu moins vrai a+ Olivier
Olivier Miakinen
- dans la page html, partie php - dans le head de la page html - dans le mode d'encodage de l'objet XMLHttpRequest - dans le php.ini : default_charset = "iso-8859-1" - dans le httpd.conf d'apache : AddDefaultCharset iso-8859-1
Ben oui, mais XML est par défaut en UTF-8,
il paraît.
et d'après ce que tu décris il semble difficile d'aller contre.
Je ne comprends pas, il paraîtrait qu'il suffirait d'envoyer les bons en-têtes ?
La question est de savoir comment envoyer ces entêtes, non pas du serveur vers le client, mais du client vers le serveur.
Et là on a un très net commandement php de ces en-têtes me semble-ce. Pourquoi n'est-ce point suivi ?
Je suis d'accord pour les quatre qui concernent l'encodage de la page envoyée par le serveur au navigateur, mais ce n'est pas ce qui pose problème ici :
- dans la page html, partie php - dans le head de la page html - dans le php.ini : default_charset = "iso-8859-1" - dans le httpd.conf d'apache : AddDefaultCharset iso-8859-1
Éventuellement, la solution pourrait être ici si ce « mode d'encodage » concernait ce qu'envoie le navigateur au serveur, mais je ne connais pas assez l'objet XMLHttpRequest pour savoir ce qu'il en est effectivement :
- dans le mode d'encodage de l'objet XMLHttpRequest
Serait-ce le XMLHttpRequest qui poste en utf-8 ?
Visiblement, oui.
Serait-ce le JS du brouteur qui s'obstine au utf-8 alors qu'on lui a indiqué autre chose ?
Peut-être, mais ownowl a essayé plusieurs versions d'IE et une de Firefox qui font toutes la même chose.
(par exemple mon Safari me cracrabouille en iso-latin ce qui lui a été envoyé en utf-8 si l'envoi n'est pas précédé de la déclaration xhtml de charset utf-8 et ce même si la page hôte est en utf-8)
C'est drôle, parce que là c'est l'inverse : le navigateur renvoie de l'UTF-8 alors qu'il a reçu du Latin1.
- dans la page html, partie php
- dans le head de la page html
- dans le mode d'encodage de l'objet XMLHttpRequest
- dans le php.ini : default_charset = "iso-8859-1"
- dans le httpd.conf d'apache : AddDefaultCharset iso-8859-1
Ben oui, mais XML est par défaut en UTF-8,
il paraît.
et d'après ce que tu
décris il semble difficile d'aller contre.
Je ne comprends pas, il paraîtrait qu'il suffirait d'envoyer les bons
en-têtes ?
La question est de savoir comment envoyer ces entêtes, non pas du
serveur vers le client, mais du client vers le serveur.
Et là on a un très net commandement php de ces en-têtes me semble-ce.
Pourquoi n'est-ce point suivi ?
Je suis d'accord pour les quatre qui concernent l'encodage de la page
envoyée par le serveur au navigateur, mais ce n'est pas ce qui pose
problème ici :
- dans la page html, partie php
- dans le head de la page html
- dans le php.ini : default_charset = "iso-8859-1"
- dans le httpd.conf d'apache : AddDefaultCharset iso-8859-1
Éventuellement, la solution pourrait être ici si ce « mode d'encodage »
concernait ce qu'envoie le navigateur au serveur, mais je ne connais pas
assez l'objet XMLHttpRequest pour savoir ce qu'il en est effectivement :
- dans le mode d'encodage de l'objet XMLHttpRequest
Serait-ce le XMLHttpRequest qui poste en utf-8 ?
Visiblement, oui.
Serait-ce le JS du brouteur qui s'obstine au utf-8 alors qu'on lui a
indiqué autre chose ?
Peut-être, mais ownowl a essayé plusieurs versions d'IE et une de
Firefox qui font toutes la même chose.
(par exemple mon Safari me cracrabouille en iso-latin ce qui lui a été
envoyé en utf-8 si l'envoi n'est pas précédé de la déclaration xhtml de
charset utf-8 et ce même si la page hôte est en utf-8)
C'est drôle, parce que là c'est l'inverse : le navigateur renvoie de
l'UTF-8 alors qu'il a reçu du Latin1.
- dans la page html, partie php - dans le head de la page html - dans le mode d'encodage de l'objet XMLHttpRequest - dans le php.ini : default_charset = "iso-8859-1" - dans le httpd.conf d'apache : AddDefaultCharset iso-8859-1
Ben oui, mais XML est par défaut en UTF-8,
il paraît.
et d'après ce que tu décris il semble difficile d'aller contre.
Je ne comprends pas, il paraîtrait qu'il suffirait d'envoyer les bons en-têtes ?
La question est de savoir comment envoyer ces entêtes, non pas du serveur vers le client, mais du client vers le serveur.
Et là on a un très net commandement php de ces en-têtes me semble-ce. Pourquoi n'est-ce point suivi ?
Je suis d'accord pour les quatre qui concernent l'encodage de la page envoyée par le serveur au navigateur, mais ce n'est pas ce qui pose problème ici :
- dans la page html, partie php - dans le head de la page html - dans le php.ini : default_charset = "iso-8859-1" - dans le httpd.conf d'apache : AddDefaultCharset iso-8859-1
Éventuellement, la solution pourrait être ici si ce « mode d'encodage » concernait ce qu'envoie le navigateur au serveur, mais je ne connais pas assez l'objet XMLHttpRequest pour savoir ce qu'il en est effectivement :
- dans le mode d'encodage de l'objet XMLHttpRequest
Serait-ce le XMLHttpRequest qui poste en utf-8 ?
Visiblement, oui.
Serait-ce le JS du brouteur qui s'obstine au utf-8 alors qu'on lui a indiqué autre chose ?
Peut-être, mais ownowl a essayé plusieurs versions d'IE et une de Firefox qui font toutes la même chose.
(par exemple mon Safari me cracrabouille en iso-latin ce qui lui a été envoyé en utf-8 si l'envoi n'est pas précédé de la déclaration xhtml de charset utf-8 et ce même si la page hôte est en utf-8)
C'est drôle, parce que là c'est l'inverse : le navigateur renvoie de l'UTF-8 alors qu'il a reçu du Latin1.
