Je n'ai pas bien le temps de le vérifier, mais je suis assez persuadé qu'entre la déclaration charset dans le prologue XML et la déclaration dans l'entête HTTP, c'est la 2eme qui l'emporte... comme toujours !
Sur http://www.w3.org/International/O-charset il est dit : Ensure that there is no conflict between what you declare in the document and what the server automatically applies, since server settings override in-document declarations.
Oui, bon, y sont gentils mais ...
soit : - un fichier sur un serveur qui sert en ISO-8859-1 - un fichier sur un autre serveur inséré via XHR après chargement du 1er et servi en utf-8 comment gérer le "conflict" ?
et pourquoi, avec les 2 fichiers sur le même serveur (donc théoriquement de même charset, par exemple: Latin-1) on a le fichier requesté servi en : - utf-8 (ou je ne sais quoi) avec FF - Latin-1 avec Safari (un peu comme si les brouteurs ne lisaient pas l'en-tête du response)
L'entête HTTP de quoi ?
De la réponse. Tout message HTTP a des en-têtes, et une réponse d'un serveur doit avoir l'en-tête Content-Type.
Je n'arrive pas à voir les en-têtes du serveur. Du moins je ne vois pas qu'il envoie un charset (chez free.fr par ex), il me semble qu'à Content-Type il se contente de 'text/html'. Ou alors c'est l'extension Web Developer de FF qui me cache des choses ?
-- Stephane Moriaux et son (moins) vieux Mac déjà dépassé
Je n'ai pas bien le temps de le vérifier, mais je suis assez persuadé
qu'entre la déclaration charset dans le prologue XML et la déclaration
dans l'entête HTTP, c'est la 2eme qui l'emporte... comme toujours !
Sur http://www.w3.org/International/O-charset il est dit :
Ensure that there is no conflict between what you declare in the document
and what the server automatically applies, since server settings override
in-document declarations.
Oui, bon, y sont gentils mais ...
soit :
- un fichier sur un serveur qui sert en ISO-8859-1
- un fichier sur un autre serveur
inséré via XHR après chargement du 1er et servi en utf-8
comment gérer le "conflict" ?
et pourquoi, avec les 2 fichiers sur le même serveur
(donc théoriquement de même charset, par exemple: Latin-1)
on a le fichier requesté servi en :
- utf-8 (ou je ne sais quoi) avec FF
- Latin-1 avec Safari
(un peu comme si les brouteurs ne lisaient pas l'en-tête du response)
L'entête HTTP de quoi ?
De la réponse. Tout message HTTP a des en-têtes, et une réponse d'un
serveur doit avoir l'en-tête Content-Type.
Je n'arrive pas à voir les en-têtes du serveur.
Du moins je ne vois pas qu'il envoie un charset (chez free.fr par ex),
il me semble qu'à Content-Type il se contente de 'text/html'.
Ou alors c'est l'extension Web Developer de FF qui me cache des choses ?
--
Stephane Moriaux et son (moins) vieux Mac déjà dépassé
Je n'ai pas bien le temps de le vérifier, mais je suis assez persuadé qu'entre la déclaration charset dans le prologue XML et la déclaration dans l'entête HTTP, c'est la 2eme qui l'emporte... comme toujours !
Sur http://www.w3.org/International/O-charset il est dit : Ensure that there is no conflict between what you declare in the document and what the server automatically applies, since server settings override in-document declarations.
Oui, bon, y sont gentils mais ...
soit : - un fichier sur un serveur qui sert en ISO-8859-1 - un fichier sur un autre serveur inséré via XHR après chargement du 1er et servi en utf-8 comment gérer le "conflict" ?
et pourquoi, avec les 2 fichiers sur le même serveur (donc théoriquement de même charset, par exemple: Latin-1) on a le fichier requesté servi en : - utf-8 (ou je ne sais quoi) avec FF - Latin-1 avec Safari (un peu comme si les brouteurs ne lisaient pas l'en-tête du response)
L'entête HTTP de quoi ?
De la réponse. Tout message HTTP a des en-têtes, et une réponse d'un serveur doit avoir l'en-tête Content-Type.
Je n'arrive pas à voir les en-têtes du serveur. Du moins je ne vois pas qu'il envoie un charset (chez free.fr par ex), il me semble qu'à Content-Type il se contente de 'text/html'. Ou alors c'est l'extension Web Developer de FF qui me cache des choses ?
-- Stephane Moriaux et son (moins) vieux Mac déjà dépassé
Patrick Mevzek
- un fichier sur un serveur qui sert en ISO-8859-1 - un fichier sur un autre serveur inséré via XHR après chargement du 1er et servi en utf-8 comment gérer le "conflict" ?
Quel conflit ?
et pourquoi, avec les 2 fichiers sur le même serveur (donc théoriquement de même charset, par exemple: Latin-1)
Non, pas forcément.
on a le fichier requesté servi en : - utf-8 (ou je ne sais quoi) avec FF - Latin-1 avec Safari (un peu comme si les brouteurs ne lisaient pas l'en-tête du response)
Ils peuvent essayer l'auto-détection, si l'information n'est pas présente...
Je n'arrive pas à voir les en-têtes du serveur. Du moins je ne vois
Pourtant plus haut vous parlez des en-têtes envoyés par le serveur... Je m'y perds dans votre histoire.
pas qu'il envoie un charset (chez free.fr par ex), il me semble qu'à Content-Type il se contente de 'text/html'.
Il y a des serveurs et des applications mal configurés partout... C'est bien le drame du web moderne, tout le monde croît que, armé de son SPIP ou de son PHP, on est les rois du monde, en se foutant des problèmes linguistiques, d'accessibilité, etc...
-- Patrick Mevzek . . . . . . . . . . . . . . Dot and Co <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
- un fichier sur un serveur qui sert en ISO-8859-1
- un fichier sur un autre serveur
inséré via XHR après chargement du 1er et servi en utf-8
comment gérer le "conflict" ?
Quel conflit ?
et pourquoi, avec les 2 fichiers sur le même serveur
(donc théoriquement de même charset, par exemple: Latin-1)
Non, pas forcément.
on a le fichier requesté servi en :
- utf-8 (ou je ne sais quoi) avec FF
- Latin-1 avec Safari
(un peu comme si les brouteurs ne lisaient pas l'en-tête du response)
Ils peuvent essayer l'auto-détection, si l'information n'est pas
présente...
Je n'arrive pas à voir les en-têtes du serveur. Du moins je ne vois
Pourtant plus haut vous parlez des en-têtes envoyés par le serveur... Je
m'y perds dans votre histoire.
pas qu'il envoie un charset (chez free.fr par ex), il me semble qu'à
Content-Type il se contente de 'text/html'.
Il y a des serveurs et des applications mal configurés partout...
C'est bien le drame du web moderne, tout le monde croît que, armé de son
SPIP ou de son PHP, on est les rois du monde, en se foutant des problèmes
linguistiques, d'accessibilité, etc...
--
Patrick Mevzek . . . . . . . . . . . . . . Dot and Co
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
- un fichier sur un serveur qui sert en ISO-8859-1 - un fichier sur un autre serveur inséré via XHR après chargement du 1er et servi en utf-8 comment gérer le "conflict" ?
Quel conflit ?
et pourquoi, avec les 2 fichiers sur le même serveur (donc théoriquement de même charset, par exemple: Latin-1)
Non, pas forcément.
on a le fichier requesté servi en : - utf-8 (ou je ne sais quoi) avec FF - Latin-1 avec Safari (un peu comme si les brouteurs ne lisaient pas l'en-tête du response)
Ils peuvent essayer l'auto-détection, si l'information n'est pas présente...
Je n'arrive pas à voir les en-têtes du serveur. Du moins je ne vois
Pourtant plus haut vous parlez des en-têtes envoyés par le serveur... Je m'y perds dans votre histoire.
pas qu'il envoie un charset (chez free.fr par ex), il me semble qu'à Content-Type il se contente de 'text/html'.
Il y a des serveurs et des applications mal configurés partout... C'est bien le drame du web moderne, tout le monde croît que, armé de son SPIP ou de son PHP, on est les rois du monde, en se foutant des problèmes linguistiques, d'accessibilité, etc...
-- Patrick Mevzek . . . . . . . . . . . . . . Dot and Co <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Pierre Goiffon
ASM wrote:
soit : - un fichier sur un serveur qui sert en ISO-8859-1 - un fichier sur un autre serveur inséré via XHR après chargement du 1er et servi en utf-8 comment gérer le "conflict" ?
Je ne sais pas ce que ça donne de mélanger les charset sur la page originale et sur une page récupérée par XML Http Request. Logiquement, ça devrait fonctionner sans prb - voir le fil que j'avais lancé il y a quelques temps sur un script servit en windows-1252 alors que la page originale était en utf-8
et pourquoi, avec les 2 fichiers sur le même serveur (donc théoriquement de même charset, par exemple: Latin-1) on a le fichier requesté servi en : - utf-8 (ou je ne sais quoi) avec FF - Latin-1 avec Safari (un peu comme si les brouteurs ne lisaient pas l'en-tête du response)
J'ai aussi du mal à te suivre. Pense tu à un exemple particulier ? Pourrais tu le mettre en ligne que l'on voit ça ?
L'entête HTTP de quoi ?
De la réponse.
Exactement : c'est le sous type charset à l'entête HTTP content-type auquel je pensais
ASM wrote:
soit :
- un fichier sur un serveur qui sert en ISO-8859-1
- un fichier sur un autre serveur
inséré via XHR après chargement du 1er et servi en utf-8
comment gérer le "conflict" ?
Je ne sais pas ce que ça donne de mélanger les charset sur la page
originale et sur une page récupérée par XML Http Request. Logiquement,
ça devrait fonctionner sans prb - voir le fil que j'avais lancé il y a
quelques temps sur un script servit en windows-1252 alors que la page
originale était en utf-8
et pourquoi, avec les 2 fichiers sur le même serveur
(donc théoriquement de même charset, par exemple: Latin-1)
on a le fichier requesté servi en :
- utf-8 (ou je ne sais quoi) avec FF
- Latin-1 avec Safari
(un peu comme si les brouteurs ne lisaient pas l'en-tête du response)
J'ai aussi du mal à te suivre. Pense tu à un exemple particulier ?
Pourrais tu le mettre en ligne que l'on voit ça ?
L'entête HTTP de quoi ?
De la réponse.
Exactement : c'est le sous type charset à l'entête HTTP content-type
auquel je pensais
soit : - un fichier sur un serveur qui sert en ISO-8859-1 - un fichier sur un autre serveur inséré via XHR après chargement du 1er et servi en utf-8 comment gérer le "conflict" ?
Je ne sais pas ce que ça donne de mélanger les charset sur la page originale et sur une page récupérée par XML Http Request. Logiquement, ça devrait fonctionner sans prb - voir le fil que j'avais lancé il y a quelques temps sur un script servit en windows-1252 alors que la page originale était en utf-8
et pourquoi, avec les 2 fichiers sur le même serveur (donc théoriquement de même charset, par exemple: Latin-1) on a le fichier requesté servi en : - utf-8 (ou je ne sais quoi) avec FF - Latin-1 avec Safari (un peu comme si les brouteurs ne lisaient pas l'en-tête du response)
J'ai aussi du mal à te suivre. Pense tu à un exemple particulier ? Pourrais tu le mettre en ligne que l'on voit ça ?
L'entête HTTP de quoi ?
De la réponse.
Exactement : c'est le sous type charset à l'entête HTTP content-type auquel je pensais
vicnet
En tout cas, j'ai regardée la page que je cherche à récupérer, il n 'y a rien de définit !!!! Pas de xml-charset, ni de http-equiv, rien au niveau serveur (je pense)...
Du coup, je comprends que FF soit bien embêté pour trouver le bon charset et que cela diffère entre une lecture normale et une lecture par ajax. Car, c'est une supposition, dans le 1er cas, lecture par la voie normale, il y a une interprétation du code html avec autodetection eventuelle. En ajax, ces mécanismes ne doivent pas fonctionner...
Après comment convertir du utf-8 en iso-8859 en javascript ? Par un iframe correctement codé ?
En tout cas, je commence à mieux comprendre les charset demandé/envoy é/ découvert...
a+ Vincent
En tout cas, j'ai regardée la page que je cherche à récupérer, il n 'y
a rien de définit !!!!
Pas de xml-charset, ni de http-equiv, rien au niveau serveur (je
pense)...
Du coup, je comprends que FF soit bien embêté pour trouver le bon
charset et que cela diffère entre une lecture normale et une lecture
par ajax.
Car, c'est une supposition, dans le 1er cas, lecture par la voie
normale, il y a une interprétation du code html avec autodetection
eventuelle. En ajax, ces mécanismes ne doivent pas fonctionner...
Après comment convertir du utf-8 en iso-8859 en javascript ?
Par un iframe correctement codé ?
En tout cas, je commence à mieux comprendre les charset demandé/envoy é/
découvert...
En tout cas, j'ai regardée la page que je cherche à récupérer, il n 'y a rien de définit !!!! Pas de xml-charset, ni de http-equiv, rien au niveau serveur (je pense)...
Du coup, je comprends que FF soit bien embêté pour trouver le bon charset et que cela diffère entre une lecture normale et une lecture par ajax. Car, c'est une supposition, dans le 1er cas, lecture par la voie normale, il y a une interprétation du code html avec autodetection eventuelle. En ajax, ces mécanismes ne doivent pas fonctionner...
Après comment convertir du utf-8 en iso-8859 en javascript ? Par un iframe correctement codé ?
En tout cas, je commence à mieux comprendre les charset demandé/envoy é/ découvert...
a+ Vincent
Pierre Goiffon
vicnet wrote:
En tout cas, j'ai regardée la page que je cherche à récupérer, il n'y a rien de définit !!!! Pas de xml-charset, ni de http-equiv, rien au niveau serveur (je pense)...
Du coup, je comprends que FF soit bien embêté pour trouver le bon charset et que cela diffère entre une lecture normale et une lecture par ajax. (...)
Après comment convertir du utf-8 en iso-8859 en javascript ? Par un iframe correctement codé ?
Si la page principale est servie en UTF-8 et la page appelée par XHR en ISO Latin-1... Je suppose qu'il n'y aura pas besoin de conversion, les chaines JS étant stockées de la même manière. J'ai déjà expérimenté d'avoir des variables définies dans un .js servit en windows-1252, ces variables étant utilisées dans les script d'une page servie en UTF-8 : pas de prb. Je serai très heureux d'avoir un retour d'expérience sur ce qu'il se produit pour une requete XHR !
vicnet wrote:
En tout cas, j'ai regardée la page que je cherche à récupérer, il n'y
a rien de définit !!!!
Pas de xml-charset, ni de http-equiv, rien au niveau serveur (je
pense)...
Du coup, je comprends que FF soit bien embêté pour trouver le bon
charset et que cela diffère entre une lecture normale et une lecture
par ajax.
(...)
Après comment convertir du utf-8 en iso-8859 en javascript ?
Par un iframe correctement codé ?
Si la page principale est servie en UTF-8 et la page appelée par XHR en
ISO Latin-1... Je suppose qu'il n'y aura pas besoin de conversion, les
chaines JS étant stockées de la même manière.
J'ai déjà expérimenté d'avoir des variables définies dans un .js servit
en windows-1252, ces variables étant utilisées dans les script d'une
page servie en UTF-8 : pas de prb.
Je serai très heureux d'avoir un retour d'expérience sur ce qu'il se
produit pour une requete XHR !
En tout cas, j'ai regardée la page que je cherche à récupérer, il n'y a rien de définit !!!! Pas de xml-charset, ni de http-equiv, rien au niveau serveur (je pense)...
Du coup, je comprends que FF soit bien embêté pour trouver le bon charset et que cela diffère entre une lecture normale et une lecture par ajax. (...)
Après comment convertir du utf-8 en iso-8859 en javascript ? Par un iframe correctement codé ?
Si la page principale est servie en UTF-8 et la page appelée par XHR en ISO Latin-1... Je suppose qu'il n'y aura pas besoin de conversion, les chaines JS étant stockées de la même manière. J'ai déjà expérimenté d'avoir des variables définies dans un .js servit en windows-1252, ces variables étant utilisées dans les script d'une page servie en UTF-8 : pas de prb. Je serai très heureux d'avoir un retour d'expérience sur ce qu'il se produit pour une requete XHR !
ASM
Je serai très heureux d'avoir un retour d'expérience sur ce qu'il se produit pour une requete XHR !
<http://stephane.moriaux.perso.wanadoo.fr/truc/accent_non_charset.html> (normalement sans aucun charset d'où que ce soit)
-- Stephane Moriaux et son (moins) vieux Mac déjà dépassé
Je serai très heureux d'avoir un retour d'expérience sur ce qu'il se
produit pour une requete XHR !
<http://stephane.moriaux.perso.wanadoo.fr/truc/accent_non_charset.html>
(normalement sans aucun charset d'où que ce soit)
--
Stephane Moriaux et son (moins) vieux Mac déjà dépassé
Je serai très heureux d'avoir un retour d'expérience sur ce qu'il se produit pour une requete XHR !
<http://stephane.moriaux.perso.wanadoo.fr/truc/accent_non_charset.html> (normalement sans aucun charset d'où que ce soit)
-- Stephane Moriaux et son (moins) vieux Mac déjà dépassé
Pierre Goiffon
Pierre Goiffon wrote:
Si la page principale est servie en UTF-8 et la page appelée par XHR en ISO Latin-1... Je suppose qu'il n'y aura pas besoin de conversion, les chaines JS étant stockées de la même manière.
Suite à ta réponse Stéphane, j'ai repris ton exemple ici : http://pgoiffon.free.fr/_temp/XHR_charset.html
La page elle-même est servie en UTF-8 (uniquement l'entête HTTP) Le lien "cliquer ici" appelle une page par XHR qui est servie en ISO Latin-1 (idem, déclaration uniquement dans l'entête HTTP) Sur mon poste XP SP2, l'exemple tourne sans prb sur Firefox 2.0.0.3, Opera 8.10, IE 6
Pierre Goiffon wrote:
Si la page principale est servie en UTF-8 et la page appelée par XHR en
ISO Latin-1... Je suppose qu'il n'y aura pas besoin de conversion, les
chaines JS étant stockées de la même manière.
Suite à ta réponse Stéphane, j'ai repris ton exemple ici :
http://pgoiffon.free.fr/_temp/XHR_charset.html
La page elle-même est servie en UTF-8 (uniquement l'entête HTTP)
Le lien "cliquer ici" appelle une page par XHR qui est servie en ISO
Latin-1 (idem, déclaration uniquement dans l'entête HTTP)
Sur mon poste XP SP2, l'exemple tourne sans prb sur Firefox 2.0.0.3,
Opera 8.10, IE 6
Si la page principale est servie en UTF-8 et la page appelée par XHR en ISO Latin-1... Je suppose qu'il n'y aura pas besoin de conversion, les chaines JS étant stockées de la même manière.
Suite à ta réponse Stéphane, j'ai repris ton exemple ici : http://pgoiffon.free.fr/_temp/XHR_charset.html
La page elle-même est servie en UTF-8 (uniquement l'entête HTTP) Le lien "cliquer ici" appelle une page par XHR qui est servie en ISO Latin-1 (idem, déclaration uniquement dans l'entête HTTP) Sur mon poste XP SP2, l'exemple tourne sans prb sur Firefox 2.0.0.3, Opera 8.10, IE 6
Olivier Miakinen
Après comment convertir du utf-8 en iso-8859 en javascript ?
D'après ce que j'ai compris, JavaScript fonctionne en interne avec une représentation Unicode (UTF-16 probablement), et tout document reçu dans un jeu donné sera converti par le navigateur avant de le transmettre à JavaScript -- du moins s'il est correctement annoncé dans les entêtes HTTP. Il n'y a donc rien à faire.
Cela dit, si de l'UTF-8 est reçu et traduit comme si on avait de l'ISO-8859-1 il doit y avoir moyen de faire quelque chose mais ce sera certainement plus complexe que de simplement transmettre un entête HTTP. En outre, si l'encodage contient des octets dont la valeur est comprise entre 128 et 159, il n'est pas dit que la transformation marche très bien. Par exemple, un octet valant 128 (80 hexa) peut être compris comme un code de contrôle de la zone C1 (U+0080), mais un navigateur « trop » intelligent pourrait considérer que c'est un caractère ¤ CP1252 et le transformer en U+20AC au lieu de U+0080. Après, bonjour le script de conversion en sens inverse !
Après comment convertir du utf-8 en iso-8859 en javascript ?
D'après ce que j'ai compris, JavaScript fonctionne en interne avec une
représentation Unicode (UTF-16 probablement), et tout document reçu dans
un jeu donné sera converti par le navigateur avant de le transmettre à
JavaScript -- du moins s'il est correctement annoncé dans les entêtes
HTTP. Il n'y a donc rien à faire.
Cela dit, si de l'UTF-8 est reçu et traduit comme si on avait de
l'ISO-8859-1 il doit y avoir moyen de faire quelque chose mais ce sera
certainement plus complexe que de simplement transmettre un entête HTTP.
En outre, si l'encodage contient des octets dont la valeur est comprise
entre 128 et 159, il n'est pas dit que la transformation marche très
bien. Par exemple, un octet valant 128 (80 hexa) peut être compris comme
un code de contrôle de la zone C1 (U+0080), mais un navigateur « trop »
intelligent pourrait considérer que c'est un caractère ¤ CP1252 et le
transformer en U+20AC au lieu de U+0080. Après, bonjour le script de
conversion en sens inverse !
Après comment convertir du utf-8 en iso-8859 en javascript ?
D'après ce que j'ai compris, JavaScript fonctionne en interne avec une représentation Unicode (UTF-16 probablement), et tout document reçu dans un jeu donné sera converti par le navigateur avant de le transmettre à JavaScript -- du moins s'il est correctement annoncé dans les entêtes HTTP. Il n'y a donc rien à faire.
Cela dit, si de l'UTF-8 est reçu et traduit comme si on avait de l'ISO-8859-1 il doit y avoir moyen de faire quelque chose mais ce sera certainement plus complexe que de simplement transmettre un entête HTTP. En outre, si l'encodage contient des octets dont la valeur est comprise entre 128 et 159, il n'est pas dit que la transformation marche très bien. Par exemple, un octet valant 128 (80 hexa) peut être compris comme un code de contrôle de la zone C1 (U+0080), mais un navigateur « trop » intelligent pourrait considérer que c'est un caractère ¤ CP1252 et le transformer en U+20AC au lieu de U+0080. Après, bonjour le script de conversion en sens inverse !
Olivier Miakinen
(...)
Après comment convertir du utf-8 en iso-8859 en javascript ? Par un iframe correctement codé ?
Si la page principale est servie en UTF-8 et la page appelée par XHR en ISO Latin-1... Je suppose qu'il n'y aura pas besoin de conversion, les chaines JS étant stockées de la même manière.
Euh... avec un entête correct, je suis d'accord, mais ce n'est pas propre à UTF-8 et ISO Latin-1. Entre MacRoman en CP437 ce serait la même chose.
En revanche, si les octets ne sont pas traduits en UTF-16 ou équivalent, alors l'encodage UTF-8 n'est identique à l'encodage ISO Latin-1 que pour la partie basse (ASCII), même si les numéros Unicode et Latin-1 sont, eux, identiques.
(...)
Après comment convertir du utf-8 en iso-8859 en javascript ?
Par un iframe correctement codé ?
Si la page principale est servie en UTF-8 et la page appelée par XHR en
ISO Latin-1... Je suppose qu'il n'y aura pas besoin de conversion, les
chaines JS étant stockées de la même manière.
Euh... avec un entête correct, je suis d'accord, mais ce n'est pas
propre à UTF-8 et ISO Latin-1. Entre MacRoman en CP437 ce serait la
même chose.
En revanche, si les octets ne sont pas traduits en UTF-16 ou équivalent,
alors l'encodage UTF-8 n'est identique à l'encodage ISO Latin-1 que pour
la partie basse (ASCII), même si les numéros Unicode et Latin-1 sont,
eux, identiques.
Après comment convertir du utf-8 en iso-8859 en javascript ? Par un iframe correctement codé ?
Si la page principale est servie en UTF-8 et la page appelée par XHR en ISO Latin-1... Je suppose qu'il n'y aura pas besoin de conversion, les chaines JS étant stockées de la même manière.
Euh... avec un entête correct, je suis d'accord, mais ce n'est pas propre à UTF-8 et ISO Latin-1. Entre MacRoman en CP437 ce serait la même chose.
En revanche, si les octets ne sont pas traduits en UTF-16 ou équivalent, alors l'encodage UTF-8 n'est identique à l'encodage ISO Latin-1 que pour la partie basse (ASCII), même si les numéros Unicode et Latin-1 sont, eux, identiques.
ASM
Pierre Goiffon wrote:
Si la page principale est servie en UTF-8 et la page appelée par XHR en ISO Latin-1... Je suppose qu'il n'y aura pas besoin de conversion, les chaines JS étant stockées de la même manière.
Suite à ta réponse Stéphane, j'ai repris ton exemple ici : http://pgoiffon.free.fr/_temp/XHR_charset.html
et dans mon exemple as-tu vu s'il y avait un charset qque part ? (je crois que non)
La page elle-même est servie en UTF-8 (uniquement l'entête HTTP) Le lien "cliquer ici" appelle une page par XHR qui est servie en ISO Latin-1 (idem, déclaration uniquement dans l'entête HTTP) Sur mon poste XP SP2, l'exemple tourne sans prb sur Firefox 2.0.0.3, Opera 8.10, IE 6
Chez moi aussi.
Alors pourquoi, lorsqu'il n'y a pas de charset - Fx importe en je ne sais quoi - Safari importe en iso-Latin (là je pense que c'est son réglage par défaut)
-- Stephane Moriaux et son (moins) vieux Mac déjà dépassé
Pierre Goiffon wrote:
Si la page principale est servie en UTF-8 et la page appelée par XHR
en ISO Latin-1... Je suppose qu'il n'y aura pas besoin de conversion,
les chaines JS étant stockées de la même manière.
Suite à ta réponse Stéphane, j'ai repris ton exemple ici :
http://pgoiffon.free.fr/_temp/XHR_charset.html
et dans mon exemple as-tu vu s'il y avait un charset qque part ?
(je crois que non)
La page elle-même est servie en UTF-8 (uniquement l'entête HTTP)
Le lien "cliquer ici" appelle une page par XHR qui est servie en ISO
Latin-1 (idem, déclaration uniquement dans l'entête HTTP)
Sur mon poste XP SP2, l'exemple tourne sans prb sur Firefox 2.0.0.3,
Opera 8.10, IE 6
Chez moi aussi.
Alors pourquoi, lorsqu'il n'y a pas de charset
- Fx importe en je ne sais quoi
- Safari importe en iso-Latin
(là je pense que c'est son réglage par défaut)
--
Stephane Moriaux et son (moins) vieux Mac déjà dépassé
Si la page principale est servie en UTF-8 et la page appelée par XHR en ISO Latin-1... Je suppose qu'il n'y aura pas besoin de conversion, les chaines JS étant stockées de la même manière.
Suite à ta réponse Stéphane, j'ai repris ton exemple ici : http://pgoiffon.free.fr/_temp/XHR_charset.html
et dans mon exemple as-tu vu s'il y avait un charset qque part ? (je crois que non)
La page elle-même est servie en UTF-8 (uniquement l'entête HTTP) Le lien "cliquer ici" appelle une page par XHR qui est servie en ISO Latin-1 (idem, déclaration uniquement dans l'entête HTTP) Sur mon poste XP SP2, l'exemple tourne sans prb sur Firefox 2.0.0.3, Opera 8.10, IE 6
Chez moi aussi.
Alors pourquoi, lorsqu'il n'y a pas de charset - Fx importe en je ne sais quoi - Safari importe en iso-Latin (là je pense que c'est son réglage par défaut)
-- Stephane Moriaux et son (moins) vieux Mac déjà dépassé
