- Safari importe en iso-Latin (là je pense que c'est son réglage par défaut)
L'ISO-8859-1 est la valeur par défaut en HTTP/HTML.
-- 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>
Olivier Miakinen
Alors pourquoi, lorsqu'il n'y a pas de charset - Fx importe en je ne sais quoi
Je parierais qu'il importe en UTF-8 qui, si je ne m'abuse, est la valeur par défaut pour XML. Cela expliquerait que j'obtienne des points d'interrogation pour chaque octet 8 bits reçu ne faisant pas partie d'un codage UTF-8 valide.
- Safari importe en iso-Latin (là je pense que c'est son réglage par défaut)
Cf. réponse de Patrick Mevzek.
Alors pourquoi, lorsqu'il n'y a pas de charset
- Fx importe en je ne sais quoi
Je parierais qu'il importe en UTF-8 qui, si je ne m'abuse, est la valeur
par défaut pour XML. Cela expliquerait que j'obtienne des points
d'interrogation pour chaque octet 8 bits reçu ne faisant pas partie d'un
codage UTF-8 valide.
Alors pourquoi, lorsqu'il n'y a pas de charset - Fx importe en je ne sais quoi
Je parierais qu'il importe en UTF-8 qui, si je ne m'abuse, est la valeur par défaut pour XML. Cela expliquerait que j'obtienne des points d'interrogation pour chaque octet 8 bits reçu ne faisant pas partie d'un codage UTF-8 valide.
- Safari importe en iso-Latin (là je pense que c'est son réglage par défaut)
Cf. réponse de Patrick Mevzek.
Pierre Goiffon
Patrick Mevzek wrote:
- Safari importe en iso-Latin (là je pense que c'est son réglage par défaut)
L'ISO-8859-1 est la valeur par défaut en HTTP/HTML.
Je ne suis pas sûr qu'en pratique cela ait dépassé la RFC et les peut être 2 tous premiers clients : depuis que j'utilise un navigateur j'ai toujours vu un charset par défaut paramétrable.
Patrick Mevzek wrote:
- Safari importe en iso-Latin
(là je pense que c'est son réglage par défaut)
L'ISO-8859-1 est la valeur par défaut en HTTP/HTML.
Je ne suis pas sûr qu'en pratique cela ait dépassé la RFC et les peut
être 2 tous premiers clients : depuis que j'utilise un navigateur j'ai
toujours vu un charset par défaut paramétrable.
- Safari importe en iso-Latin (là je pense que c'est son réglage par défaut)
L'ISO-8859-1 est la valeur par défaut en HTTP/HTML.
Je ne suis pas sûr qu'en pratique cela ait dépassé la RFC et les peut être 2 tous premiers clients : depuis que j'utilise un navigateur j'ai toujours vu un charset par défaut paramétrable.
Pierre Goiffon
ASM wrote:
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)
Non, ta page (pour mémoire : <http://stephane.moriaux.perso.wanadoo.fr/truc/accent_non_charset.html> ) ne contenait aucune information de codage (ni en entête HTTP, ni en meta) Mon Firefox la lit comme du Windows-1252...
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)
Les hypothèses conjointes de Olivier et Patrick (en HTTP codage par défaut dans la RFC ISO Latin-1, et en XML c'est UTF-8) me semblent assez bonnes pour expliquer cette différence d'implémentation.
De toute façon dans tous les cas, il faut _toujours_ indiquer le codage utilisé.
ASM wrote:
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)
Non, ta page (pour mémoire :
<http://stephane.moriaux.perso.wanadoo.fr/truc/accent_non_charset.html>
) ne contenait aucune information de codage (ni en entête HTTP, ni en meta)
Mon Firefox la lit comme du Windows-1252...
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)
Les hypothèses conjointes de Olivier et Patrick (en HTTP codage par
défaut dans la RFC ISO Latin-1, et en XML c'est UTF-8) me semblent assez
bonnes pour expliquer cette différence d'implémentation.
De toute façon dans tous les cas, il faut _toujours_ indiquer le codage
utilisé.
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)
Non, ta page (pour mémoire : <http://stephane.moriaux.perso.wanadoo.fr/truc/accent_non_charset.html> ) ne contenait aucune information de codage (ni en entête HTTP, ni en meta) Mon Firefox la lit comme du Windows-1252...
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)
Les hypothèses conjointes de Olivier et Patrick (en HTTP codage par défaut dans la RFC ISO Latin-1, et en XML c'est UTF-8) me semblent assez bonnes pour expliquer cette différence d'implémentation.
De toute façon dans tous les cas, il faut _toujours_ indiquer le codage utilisé.
Pierre Goiffon
Olivier Miakinen wrote:
(...)
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.
Oui, tout à fait.
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.
Plus précisément pour les 127 premiers caractères, ceux qui sont contenus dans us-ascii. L'exemple repris de ASM utilise é et ç, soit respectivement U+00E9 et U+00E7, soit respectivement les caractères 233 et 231 en ISO Latin-1 : ces caractères sont en-dehors d'us-ascii et ne sont pas codés de la même manière en ISO Latin-1 et en UTF-8 (encore une fois l'outil d'Olivier est parfait pour ce genre de choses : http://www.miakinen.net/vrac/charsets/)
Olivier Miakinen wrote:
(...)
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.
Oui, tout à fait.
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.
Plus précisément pour les 127 premiers caractères, ceux qui sont
contenus dans us-ascii. L'exemple repris de ASM utilise é et ç, soit
respectivement U+00E9 et U+00E7, soit respectivement les caractères 233
et 231 en ISO Latin-1 : ces caractères sont en-dehors d'us-ascii et ne
sont pas codés de la même manière en ISO Latin-1 et en UTF-8 (encore une
fois l'outil d'Olivier est parfait pour ce genre de choses :
http://www.miakinen.net/vrac/charsets/)
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.
Oui, tout à fait.
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.
Plus précisément pour les 127 premiers caractères, ceux qui sont contenus dans us-ascii. L'exemple repris de ASM utilise é et ç, soit respectivement U+00E9 et U+00E7, soit respectivement les caractères 233 et 231 en ISO Latin-1 : ces caractères sont en-dehors d'us-ascii et ne sont pas codés de la même manière en ISO Latin-1 et en UTF-8 (encore une fois l'outil d'Olivier est parfait pour ce genre de choses : http://www.miakinen.net/vrac/charsets/)
Jean-Marc Desperrier
Patrick Mevzek wrote:
- Safari importe en iso-Latin (là je pense que c'est son réglage par défaut)
L'ISO-8859-1 est la valeur par défaut en HTTP/HTML.
Non, c'est la valeur par défaut en HTTP à condition que le format transporté n'ait pas une autre norme (ce qui est le cas de xml, norme UTF-8).
Corrigé par les évolutions suivantes de RFC qui disent "surtout si vous ne savez pas, ne supposez rien" (ce qui n'est pas très applicable en pratique il faut bien choisir quelquechose).
Patrick Mevzek wrote:
- Safari importe en iso-Latin
(là je pense que c'est son réglage par défaut)
L'ISO-8859-1 est la valeur par défaut en HTTP/HTML.
Non, c'est la valeur par défaut en HTTP à condition que le format
transporté n'ait pas une autre norme (ce qui est le cas de xml, norme
UTF-8).
Corrigé par les évolutions suivantes de RFC qui disent "surtout si vous
ne savez pas, ne supposez rien" (ce qui n'est pas très applicable en
pratique il faut bien choisir quelquechose).
- Safari importe en iso-Latin (là je pense que c'est son réglage par défaut)
L'ISO-8859-1 est la valeur par défaut en HTTP/HTML.
Non, c'est la valeur par défaut en HTTP à condition que le format transporté n'ait pas une autre norme (ce qui est le cas de xml, norme UTF-8).
Corrigé par les évolutions suivantes de RFC qui disent "surtout si vous ne savez pas, ne supposez rien" (ce qui n'est pas très applicable en pratique il faut bien choisir quelquechose).
Olivier Miakinen
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.
Plus précisément pour les 127 premiers caractères, ceux qui sont contenus dans us-ascii. L'exemple repris de ASM utilise é et ç, soit respectivement U+00E9 et U+00E7, soit respectivement les caractères 233 et 231 en ISO Latin-1 : ces caractères sont en-dehors d'us-ascii et ne sont pas codés de la même manière en ISO Latin-1 et en UTF-8 (encore une fois l'outil d'Olivier est parfait pour ce genre de choses : http://www.miakinen.net/vrac/charsets/)
Puisque tu en parles, j'en profite pour signaler que j'ai amélioré ma page. Par exemple on peut afficher les tables verticalement, et surtout on peut référencer directement un caractère donné d'une table donnée (même si l'utilisateur n'a pas JavaScript, car c'est alors PHP qui pré-remplit les tableaux de droite).
Exemple pour le ç d'ISO Latin-1, en orientation verticale : http://www.miakinen.net/vrac/charsets/?hv=v&or=2&pr#1
Par ailleurs, j'ai corrigé mon code JavaScript qui déclenchait un bug dans Internet Explorer, le faisant passer de plus en plus de temps à chaque appel.
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.
Plus précisément pour les 127 premiers caractères, ceux qui sont
contenus dans us-ascii. L'exemple repris de ASM utilise é et ç, soit
respectivement U+00E9 et U+00E7, soit respectivement les caractères 233
et 231 en ISO Latin-1 : ces caractères sont en-dehors d'us-ascii et ne
sont pas codés de la même manière en ISO Latin-1 et en UTF-8 (encore une
fois l'outil d'Olivier est parfait pour ce genre de choses :
http://www.miakinen.net/vrac/charsets/)
Puisque tu en parles, j'en profite pour signaler que j'ai amélioré ma
page. Par exemple on peut afficher les tables verticalement, et surtout
on peut référencer directement un caractère donné d'une table donnée
(même si l'utilisateur n'a pas JavaScript, car c'est alors PHP qui
pré-remplit les tableaux de droite).
Exemple pour le ç d'ISO Latin-1, en orientation verticale :
http://www.miakinen.net/vrac/charsets/?hv=v&or=2&pr#1
Par ailleurs, j'ai corrigé mon code JavaScript qui déclenchait un bug
dans Internet Explorer, le faisant passer de plus en plus de temps à
chaque appel.
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.
Plus précisément pour les 127 premiers caractères, ceux qui sont contenus dans us-ascii. L'exemple repris de ASM utilise é et ç, soit respectivement U+00E9 et U+00E7, soit respectivement les caractères 233 et 231 en ISO Latin-1 : ces caractères sont en-dehors d'us-ascii et ne sont pas codés de la même manière en ISO Latin-1 et en UTF-8 (encore une fois l'outil d'Olivier est parfait pour ce genre de choses : http://www.miakinen.net/vrac/charsets/)
Puisque tu en parles, j'en profite pour signaler que j'ai amélioré ma page. Par exemple on peut afficher les tables verticalement, et surtout on peut référencer directement un caractère donné d'une table donnée (même si l'utilisateur n'a pas JavaScript, car c'est alors PHP qui pré-remplit les tableaux de droite).
Exemple pour le ç d'ISO Latin-1, en orientation verticale : http://www.miakinen.net/vrac/charsets/?hv=v&or=2&pr#1
Par ailleurs, j'ai corrigé mon code JavaScript qui déclenchait un bug dans Internet Explorer, le faisant passer de plus en plus de temps à chaque appel.
Pierre Goiffon
Olivier Miakinen wrote:
http://www.miakinen.net/vrac/charsets/
Puisque tu en parles, j'en profite pour signaler que j'ai amélioré ma page. Par exemple on peut afficher les tables verticalement, et surtout on peut référencer directement un caractère donné d'une table donnée (même si l'utilisateur n'a pas JavaScript, car c'est alors PHP qui pré-remplit les tableaux de droite).
Excellente idée ! Ca va être très pratique pour les différents post usenet |-)
Euh par contre de ce je comprend de ton exemple, la position de référence est en décimal... ce n'est pas très pratique ! En fait en lisant le début de ton mail j'ai ouvert ta page et essayé d'afficher le caractère de Windows-1252. J'ai donc entré 80 dans position de référence... mais c'est la valeur hexa ! Vu que tout est exprimé en hexa dans cette page, la position de référence ne pourrait elle pas être elle aussi en hexa ?
Olivier Miakinen wrote:
http://www.miakinen.net/vrac/charsets/
Puisque tu en parles, j'en profite pour signaler que j'ai amélioré ma
page. Par exemple on peut afficher les tables verticalement, et surtout
on peut référencer directement un caractère donné d'une table donnée
(même si l'utilisateur n'a pas JavaScript, car c'est alors PHP qui
pré-remplit les tableaux de droite).
Excellente idée ! Ca va être très pratique pour les différents post
usenet |-)
Euh par contre de ce je comprend de ton exemple, la position de
référence est en décimal... ce n'est pas très pratique ! En fait en
lisant le début de ton mail j'ai ouvert ta page et essayé d'afficher le
caractère de Windows-1252. J'ai donc entré 80 dans position de
référence... mais c'est la valeur hexa ! Vu que tout est exprimé en hexa
dans cette page, la position de référence ne pourrait elle pas être elle
aussi en hexa ?
Puisque tu en parles, j'en profite pour signaler que j'ai amélioré ma page. Par exemple on peut afficher les tables verticalement, et surtout on peut référencer directement un caractère donné d'une table donnée (même si l'utilisateur n'a pas JavaScript, car c'est alors PHP qui pré-remplit les tableaux de droite).
Excellente idée ! Ca va être très pratique pour les différents post usenet |-)
Euh par contre de ce je comprend de ton exemple, la position de référence est en décimal... ce n'est pas très pratique ! En fait en lisant le début de ton mail j'ai ouvert ta page et essayé d'afficher le caractère de Windows-1252. J'ai donc entré 80 dans position de référence... mais c'est la valeur hexa ! Vu que tout est exprimé en hexa dans cette page, la position de référence ne pourrait elle pas être elle aussi en hexa ?
Olivier Miakinen
http://www.miakinen.net/vrac/charsets/
Euh par contre de ce je comprend de ton exemple, la position de référence est en décimal... ce n'est pas très pratique ! En fait en lisant le début de ton mail j'ai ouvert ta page et essayé d'afficher le caractère ¤ de Windows-1252. J'ai donc entré 80 dans position de référence... mais c'est la valeur hexa ! Vu que tout est exprimé en hexa dans cette page, la position de référence ne pourrait elle pas être elle aussi en hexa ?
C'est une excellente suggestion. En fait j'envisage de faire encore plus simple (mais qui ne fonctionnera qu'avec JavaScript), c'est que les deux champs de saisie se pré-remplissent quand on clique sur un caractère donné d'une table donnée. Je ferai peut-être les deux.
(Et note que c'est maintenant MacRoman qui est la table par défaut pour le 6e onglet, ainsi que je l'explique dans ma doc remaniée).
http://www.miakinen.net/vrac/charsets/
Euh par contre de ce je comprend de ton exemple, la position de
référence est en décimal... ce n'est pas très pratique ! En fait en
lisant le début de ton mail j'ai ouvert ta page et essayé d'afficher le
caractère ¤ de Windows-1252. J'ai donc entré 80 dans position de
référence... mais c'est la valeur hexa ! Vu que tout est exprimé en hexa
dans cette page, la position de référence ne pourrait elle pas être elle
aussi en hexa ?
C'est une excellente suggestion. En fait j'envisage de faire encore plus
simple (mais qui ne fonctionnera qu'avec JavaScript), c'est que les deux
champs de saisie se pré-remplissent quand on clique sur un caractère
donné d'une table donnée. Je ferai peut-être les deux.
(Et note que c'est maintenant MacRoman qui est la table par défaut pour
le 6e onglet, ainsi que je l'explique dans ma doc remaniée).
Euh par contre de ce je comprend de ton exemple, la position de référence est en décimal... ce n'est pas très pratique ! En fait en lisant le début de ton mail j'ai ouvert ta page et essayé d'afficher le caractère ¤ de Windows-1252. J'ai donc entré 80 dans position de référence... mais c'est la valeur hexa ! Vu que tout est exprimé en hexa dans cette page, la position de référence ne pourrait elle pas être elle aussi en hexa ?
C'est une excellente suggestion. En fait j'envisage de faire encore plus simple (mais qui ne fonctionnera qu'avec JavaScript), c'est que les deux champs de saisie se pré-remplissent quand on clique sur un caractère donné d'une table donnée. Je ferai peut-être les deux.
(Et note que c'est maintenant MacRoman qui est la table par défaut pour le 6e onglet, ainsi que je l'explique dans ma doc remaniée).
Olivier Miakinen
C'est une excellente suggestion. En fait j'envisage de faire encore plus simple (mais qui ne fonctionnera qu'avec JavaScript), [...]
Oh, j'ai une idée encore meilleure ! Mais chut, j'en parlerai plus tard... ;-)
C'est une excellente suggestion. En fait j'envisage de faire encore plus
simple (mais qui ne fonctionnera qu'avec JavaScript), [...]
Oh, j'ai une idée encore meilleure ! Mais chut, j'en parlerai plus
tard... ;-)
