Souvent Moz passe l'affichage du jeu de caractères de l'ISO-8859-1 à
l'Unicode UTF-8.
Exemble:
- Visitez la page suivante:
http://www.ixus.net/ qui déclare son charset en ISO-8859-1
- Cliquez sur le lien à mi-page au centre, dont le libellé est:
21/10 : Etude : Les quatre lois sur les vulnérabilités selon Qualys -
k-otik.com
--> page de redirection sans déclaration de charset
--> arrivée sur k-otik.com où le charset n'est pas déclaré non plus
Les accents sont transformés en '?', et Moz/Affichage/Jeu de caractères
est placé sur Unicode :( bien que Préférences/Langue soit sur
Français/France ([fr-fr] et Encodage par défaut sur Occidental ISO-8859-1.
Il faut donc aller dans le menu Affichage/Jeu... pour remettre sur le
bon charset.
Ce bug a été signalé 2 ou 3 fois ici, mais est resté sans réponse. Une
solution ?
Steph
--
Enlever l'adresse bidon invalide pour m'écrire
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
Jean-Marc Desperrier
Steph wrote:
Exemble: - Visitez la page suivante: http://www.ixus.net/ qui déclare son charset en ISO-8859-1 - Cliquez sur le lien à mi-page au centre, dont le libellé est: 21/10 : Etude : Les quatre lois sur les vulnérabilités selon Qualys - k-otik.com
C'est bien gentil, mais le lien a déjà disparu ... Pas terrible pour reproduire le problème et analyser ce qu'il peut se passer exactement. Si tu peux trouver un cas qui reste présent plus de quelques heures ...
Ce bug a été signalé 2 ou 3 fois ici, mais est resté sans réponse. Une solution ?
La dernière fois qu'il a été signalé, avec une description plus précise que d'habitude qui permettait de regarder exactement, il est apparu qu'il s'agissait d'une transition d'une page en UTF-8 vers une page en ISO-8858-1 qui ne déclarait pas le charset.
Il est probablement abusif que Mozilla garde le charset alors qu'on est plus sur le même domaine, mais je vois assez facilement qu'il y a aussi des cas où c'est légitime, et que changer ce comportement risque, en sens inverse, de mécontenter quelques personnes. Statistiquement, revenir au charset par défaut quand on change de domaine est surement la solution le plus souvent juste, mais reste à le prouver.
D'après ta description, ton cas serait autre chose, et entièrement injustifiable. Reste à le reproduire, et là malheureusement je ne peux pas.
Steph wrote:
Exemble:
- Visitez la page suivante:
http://www.ixus.net/ qui déclare son charset en ISO-8859-1
- Cliquez sur le lien à mi-page au centre, dont le libellé est:
21/10 : Etude : Les quatre lois sur les vulnérabilités selon Qualys -
k-otik.com
C'est bien gentil, mais le lien a déjà disparu ...
Pas terrible pour reproduire le problème et analyser ce qu'il peut se
passer exactement.
Si tu peux trouver un cas qui reste présent plus de quelques heures ...
Ce bug a été signalé 2 ou 3 fois ici, mais est resté sans réponse. Une
solution ?
La dernière fois qu'il a été signalé, avec une description plus précise
que d'habitude qui permettait de regarder exactement, il est apparu
qu'il s'agissait d'une transition d'une page en UTF-8 vers une page en
ISO-8858-1 qui ne déclarait pas le charset.
Il est probablement abusif que Mozilla garde le charset alors qu'on est
plus sur le même domaine, mais je vois assez facilement qu'il y a aussi
des cas où c'est légitime, et que changer ce comportement risque, en
sens inverse, de mécontenter quelques personnes.
Statistiquement, revenir au charset par défaut quand on change de
domaine est surement la solution le plus souvent juste, mais reste à le
prouver.
D'après ta description, ton cas serait autre chose, et entièrement
injustifiable.
Reste à le reproduire, et là malheureusement je ne peux pas.
Exemble: - Visitez la page suivante: http://www.ixus.net/ qui déclare son charset en ISO-8859-1 - Cliquez sur le lien à mi-page au centre, dont le libellé est: 21/10 : Etude : Les quatre lois sur les vulnérabilités selon Qualys - k-otik.com
C'est bien gentil, mais le lien a déjà disparu ... Pas terrible pour reproduire le problème et analyser ce qu'il peut se passer exactement. Si tu peux trouver un cas qui reste présent plus de quelques heures ...
Ce bug a été signalé 2 ou 3 fois ici, mais est resté sans réponse. Une solution ?
La dernière fois qu'il a été signalé, avec une description plus précise que d'habitude qui permettait de regarder exactement, il est apparu qu'il s'agissait d'une transition d'une page en UTF-8 vers une page en ISO-8858-1 qui ne déclarait pas le charset.
Il est probablement abusif que Mozilla garde le charset alors qu'on est plus sur le même domaine, mais je vois assez facilement qu'il y a aussi des cas où c'est légitime, et que changer ce comportement risque, en sens inverse, de mécontenter quelques personnes. Statistiquement, revenir au charset par défaut quand on change de domaine est surement la solution le plus souvent juste, mais reste à le prouver.
D'après ta description, ton cas serait autre chose, et entièrement injustifiable. Reste à le reproduire, et là malheureusement je ne peux pas.
Steph
Jean-Marc Desperrier a écrit :
Steph wrote:
Exemble: - Visitez la page suivante: http://www.ixus.net/ qui déclare son charset en ISO-8859-1 - Cliquez sur le lien à mi-page au centre, dont le libellé est: 21/10 : Etude : Les quatre lois sur les vulnérabilités selon Qualys - k-otik.com
C'est bien gentil, mais le lien a déjà disparu ...
En effet... Clic sur un lien au centre (revue de presse) comportant des lettres accentuées: sur la page de redirection, elles sont remplacées en '?'. Si la page obtenue ensuite n'a pas de charset déclaré, les accents -> '?'
La dernière fois qu'il a été signalé, avec une description plus précise que d'habitude qui permettait de regarder exactement, il est apparu qu'il s'agissait d'une transition d'une page en UTF-8 vers une page en ISO-8858-1 qui ne déclarait pas le charset.
Le contraire: ISO -> UTF
Steph
-- Enlever l'adresse bidon invalide pour m'écrire
Jean-Marc Desperrier a écrit :
Steph wrote:
Exemble:
- Visitez la page suivante:
http://www.ixus.net/ qui déclare son charset en ISO-8859-1
- Cliquez sur le lien à mi-page au centre, dont le libellé est:
21/10 : Etude : Les quatre lois sur les vulnérabilités selon Qualys -
k-otik.com
C'est bien gentil, mais le lien a déjà disparu ...
En effet...
Clic sur un lien au centre (revue de presse) comportant des lettres
accentuées: sur la page de redirection, elles sont remplacées en '?'. Si
la page obtenue ensuite n'a pas de charset déclaré, les accents -> '?'
La dernière fois qu'il a été signalé, avec une description plus précise
que d'habitude qui permettait de regarder exactement, il est apparu
qu'il s'agissait d'une transition d'une page en UTF-8 vers une page en
ISO-8858-1 qui ne déclarait pas le charset.
Exemble: - Visitez la page suivante: http://www.ixus.net/ qui déclare son charset en ISO-8859-1 - Cliquez sur le lien à mi-page au centre, dont le libellé est: 21/10 : Etude : Les quatre lois sur les vulnérabilités selon Qualys - k-otik.com
C'est bien gentil, mais le lien a déjà disparu ...
En effet... Clic sur un lien au centre (revue de presse) comportant des lettres accentuées: sur la page de redirection, elles sont remplacées en '?'. Si la page obtenue ensuite n'a pas de charset déclaré, les accents -> '?'
La dernière fois qu'il a été signalé, avec une description plus précise que d'habitude qui permettait de regarder exactement, il est apparu qu'il s'agissait d'une transition d'une page en UTF-8 vers une page en ISO-8858-1 qui ne déclarait pas le charset.
Le contraire: ISO -> UTF
Steph
-- Enlever l'adresse bidon invalide pour m'écrire
Olivier Miakinen
Le 21/10/2003 20:10, Jean-Marc Desperrier a écrit :
Il est probablement abusif que Mozilla garde le charset alors qu'on est plus sur le même domaine, mais je vois assez facilement qu'il y a aussi des cas où c'est légitime, et que changer ce comportement risque, en sens inverse, de mécontenter quelques personnes.
Je ne vois pas de cas où ce serait légitime. Cela voudrait dire que l'apparence d'une page dépendrait de l'encodage d'une autre page. C'est-à-dire que, selon que l'on vienne à la page A à partir de la page B ou à partir de la page C (ou d'aucune page du tout), la page A ne sera pas la même.
Statistiquement, revenir au charset par défaut quand on change de domaine est surement la solution le plus souvent juste, mais reste à le prouver.
Ben non, la solution la plus juste est celle du standard HTTP : une page sans déclaration de charset est réputée être en ISO-8859-1.
Le 21/10/2003 20:10, Jean-Marc Desperrier a écrit :
Il est probablement abusif que Mozilla garde le charset alors qu'on est
plus sur le même domaine, mais je vois assez facilement qu'il y a aussi
des cas où c'est légitime, et que changer ce comportement risque, en
sens inverse, de mécontenter quelques personnes.
Je ne vois pas de cas où ce serait légitime. Cela voudrait dire que
l'apparence d'une page dépendrait de l'encodage d'une autre page.
C'est-à-dire que, selon que l'on vienne à la page A à partir de la page
B ou à partir de la page C (ou d'aucune page du tout), la page A ne sera
pas la même.
Statistiquement, revenir au charset par défaut quand on change de
domaine est surement la solution le plus souvent juste, mais reste à le
prouver.
Ben non, la solution la plus juste est celle du standard HTTP : une page
sans déclaration de charset est réputée être en ISO-8859-1.
Le 21/10/2003 20:10, Jean-Marc Desperrier a écrit :
Il est probablement abusif que Mozilla garde le charset alors qu'on est plus sur le même domaine, mais je vois assez facilement qu'il y a aussi des cas où c'est légitime, et que changer ce comportement risque, en sens inverse, de mécontenter quelques personnes.
Je ne vois pas de cas où ce serait légitime. Cela voudrait dire que l'apparence d'une page dépendrait de l'encodage d'une autre page. C'est-à-dire que, selon que l'on vienne à la page A à partir de la page B ou à partir de la page C (ou d'aucune page du tout), la page A ne sera pas la même.
Statistiquement, revenir au charset par défaut quand on change de domaine est surement la solution le plus souvent juste, mais reste à le prouver.
Ben non, la solution la plus juste est celle du standard HTTP : une page sans déclaration de charset est réputée être en ISO-8859-1.
Si tu préfère efficace ... Il y a une jolie série d'exemple de page en russe ou en hebreux ou en japonais qui regroupe des séries de lien, et de nombreux utilisateurs comptent sur le fait qu'il n'auront pas besoin à chaque fois de changer le jeu de caractère après les avoir ouvert.
Cela voudrait dire que l'apparence d'une page dépendrait de l'encodage d'une autre page.
Une page qui ne précise pas d'encodage s'en remet au hasard et à la chance pour être affichée correctement. Sur d'anciens navigateurs, l'utilisateur réglait son encodage, et le navigateur restait dedans jusqu'à ce que l'utilisateur le change à nouveau. Pense-y, tu verras que cela donne le même résultat que cela.
Ben non, la solution la plus juste est celle du standard HTTP : une page sans déclaration de charset est réputée être en ISO-8859-1.
La spécification HTML 4 précise qu'il ne faut jamais supposer un jeu de caractères par défaut si rien n'est indiqué dans le document.
La spécification XML précise que le format par défaut est UTF-8.
HTTP prétend imposer une référence universelle pour tous les types de fichiers texte, mais il est évident que les normes spécifique à chaque format de fichiers prenne en fait le devant.
Si on en revient à la pratique, on constate que lorsqu'un document n'est pas écrit en latin1, il n'a pas plus souvent un marquage d'encodage. Heureusement je constate avec joie que cette très mauvaise idée de ne pas mettre de déclaration de jeu de caractère commence à être moins répandue. Sur les doc latin1 en tout cas.
Imposer le jeu de caractère par défaut n'est pas une mauvaise chose pour les utilisateurs qui utilisent un seul encodage, et où la méthode Mozilla marche mal. Je pensais au départ que ce moyen marchait mieux globalement que celui que suit actuellement Mozilla, mais finalement je ne suis plus très sûr, sauf pour quelques cas spéciaux (google en utf-8).
J'ai sondé sur irc, j'ai eu une réponse très négative de timeless sur le fait de changer quoi que ce soit au comportement actuel, hixie était plus intéressé.
Donc finalement, je pense que le mieux serait une option pour forcer l'encodage par défaut sur les pages sans encodage explicite, mais il sera difficile d'obtenir qu'elle soit validée par défaut.
Olivier Miakinen wrote:
Je ne vois pas de cas où ce serait légitime.
Si tu préfère efficace ...
Il y a une jolie série d'exemple de page en russe ou en hebreux ou en
japonais qui regroupe des séries de lien, et de nombreux utilisateurs
comptent sur le fait qu'il n'auront pas besoin à chaque fois de changer
le jeu de caractère après les avoir ouvert.
Cela voudrait dire que
l'apparence d'une page dépendrait de l'encodage d'une autre page.
Une page qui ne précise pas d'encodage s'en remet au hasard et à la
chance pour être affichée correctement.
Sur d'anciens navigateurs, l'utilisateur réglait son encodage, et le
navigateur restait dedans jusqu'à ce que l'utilisateur le change à
nouveau. Pense-y, tu verras que cela donne le même résultat que cela.
Ben non, la solution la plus juste est celle du standard HTTP : une page
sans déclaration de charset est réputée être en ISO-8859-1.
La spécification HTML 4 précise qu'il ne faut jamais supposer un jeu de
caractères par défaut si rien n'est indiqué dans le document.
La spécification XML précise que le format par défaut est UTF-8.
HTTP prétend imposer une référence universelle pour tous les types de
fichiers texte, mais il est évident que les normes spécifique à chaque
format de fichiers prenne en fait le devant.
Si on en revient à la pratique, on constate que lorsqu'un document n'est
pas écrit en latin1, il n'a pas plus souvent un marquage d'encodage.
Heureusement je constate avec joie que cette très mauvaise idée de ne
pas mettre de déclaration de jeu de caractère commence à être moins
répandue. Sur les doc latin1 en tout cas.
Imposer le jeu de caractère par défaut n'est pas une mauvaise chose pour
les utilisateurs qui utilisent un seul encodage, et où la méthode
Mozilla marche mal. Je pensais au départ que ce moyen marchait mieux
globalement que celui que suit actuellement Mozilla, mais finalement je
ne suis plus très sûr, sauf pour quelques cas spéciaux (google en utf-8).
J'ai sondé sur irc, j'ai eu une réponse très négative de timeless sur le
fait de changer quoi que ce soit au comportement actuel, hixie était
plus intéressé.
Donc finalement, je pense que le mieux serait une option pour forcer
l'encodage par défaut sur les pages sans encodage explicite, mais il
sera difficile d'obtenir qu'elle soit validée par défaut.
Si tu préfère efficace ... Il y a une jolie série d'exemple de page en russe ou en hebreux ou en japonais qui regroupe des séries de lien, et de nombreux utilisateurs comptent sur le fait qu'il n'auront pas besoin à chaque fois de changer le jeu de caractère après les avoir ouvert.
Cela voudrait dire que l'apparence d'une page dépendrait de l'encodage d'une autre page.
Une page qui ne précise pas d'encodage s'en remet au hasard et à la chance pour être affichée correctement. Sur d'anciens navigateurs, l'utilisateur réglait son encodage, et le navigateur restait dedans jusqu'à ce que l'utilisateur le change à nouveau. Pense-y, tu verras que cela donne le même résultat que cela.
Ben non, la solution la plus juste est celle du standard HTTP : une page sans déclaration de charset est réputée être en ISO-8859-1.
La spécification HTML 4 précise qu'il ne faut jamais supposer un jeu de caractères par défaut si rien n'est indiqué dans le document.
La spécification XML précise que le format par défaut est UTF-8.
HTTP prétend imposer une référence universelle pour tous les types de fichiers texte, mais il est évident que les normes spécifique à chaque format de fichiers prenne en fait le devant.
Si on en revient à la pratique, on constate que lorsqu'un document n'est pas écrit en latin1, il n'a pas plus souvent un marquage d'encodage. Heureusement je constate avec joie que cette très mauvaise idée de ne pas mettre de déclaration de jeu de caractère commence à être moins répandue. Sur les doc latin1 en tout cas.
Imposer le jeu de caractère par défaut n'est pas une mauvaise chose pour les utilisateurs qui utilisent un seul encodage, et où la méthode Mozilla marche mal. Je pensais au départ que ce moyen marchait mieux globalement que celui que suit actuellement Mozilla, mais finalement je ne suis plus très sûr, sauf pour quelques cas spéciaux (google en utf-8).
J'ai sondé sur irc, j'ai eu une réponse très négative de timeless sur le fait de changer quoi que ce soit au comportement actuel, hixie était plus intéressé.
Donc finalement, je pense que le mieux serait une option pour forcer l'encodage par défaut sur les pages sans encodage explicite, mais il sera difficile d'obtenir qu'elle soit validée par défaut.
Jean-Marc Desperrier
Steph wrote:
Jean-Marc Desperrier a écrit :
Steph wrote:
- Visitez la page suivante: http://www.ixus.net/ qui déclare son charset en ISO-8859-1
Clic sur un lien au centre (revue de presse) comportant des lettres accentuées: sur la page de redirection, elles sont remplacées en '?'. Si la page obtenue ensuite n'a pas de charset déclaré, les accents -> '?'
Impose à reproduire. La page de redirection est en ISO-8859-9 comme celle d'accueuil. Aucun des sites destination n'aparait chez moi avec ce problème.
Se pourrait-il, pour une raison que j'ignore, que c'est la page intermédiaire qui est mémorisée chez toi comme étant en UTF-8 ?
J'arrive à reproduire ton comportement si je force manuellement cette page intermédiaire à être en UTF-8. Pour les fois suivantes, c'est mémorisé. Enfin, plus ou moin, maintenant c'est revenu à latin1.
[...] il est apparu qu'il s'agissait d'une transition d'une page en UTF-8 vers une page en ISO-8858-1 qui ne déclarait pas le charset.
Le contraire: ISO -> UTF
Quel page serait en UTF-8 sans déclarer d'encodage ? Cela parait extrêmement rare ... Et le résultat dans ce cas, n'est pas un point d'interrogation, mais des caractère curieux.
Steph wrote:
Jean-Marc Desperrier a écrit :
Steph wrote:
- Visitez la page suivante:
http://www.ixus.net/ qui déclare son charset en ISO-8859-1
Clic sur un lien au centre (revue de presse) comportant des lettres
accentuées: sur la page de redirection, elles sont remplacées en '?'. Si
la page obtenue ensuite n'a pas de charset déclaré, les accents -> '?'
Impose à reproduire. La page de redirection est en ISO-8859-9 comme
celle d'accueuil. Aucun des sites destination n'aparait chez moi avec ce
problème.
Se pourrait-il, pour une raison que j'ignore, que c'est la page
intermédiaire qui est mémorisée chez toi comme étant en UTF-8 ?
J'arrive à reproduire ton comportement si je force manuellement cette
page intermédiaire à être en UTF-8. Pour les fois suivantes, c'est
mémorisé. Enfin, plus ou moin, maintenant c'est revenu à latin1.
[...] il est
apparu qu'il s'agissait d'une transition d'une page en UTF-8 vers une
page en ISO-8858-1 qui ne déclarait pas le charset.
Le contraire: ISO -> UTF
Quel page serait en UTF-8 sans déclarer d'encodage ? Cela parait
extrêmement rare ... Et le résultat dans ce cas, n'est pas un point
d'interrogation, mais des caractère curieux.
- Visitez la page suivante: http://www.ixus.net/ qui déclare son charset en ISO-8859-1
Clic sur un lien au centre (revue de presse) comportant des lettres accentuées: sur la page de redirection, elles sont remplacées en '?'. Si la page obtenue ensuite n'a pas de charset déclaré, les accents -> '?'
Impose à reproduire. La page de redirection est en ISO-8859-9 comme celle d'accueuil. Aucun des sites destination n'aparait chez moi avec ce problème.
Se pourrait-il, pour une raison que j'ignore, que c'est la page intermédiaire qui est mémorisée chez toi comme étant en UTF-8 ?
J'arrive à reproduire ton comportement si je force manuellement cette page intermédiaire à être en UTF-8. Pour les fois suivantes, c'est mémorisé. Enfin, plus ou moin, maintenant c'est revenu à latin1.
[...] il est apparu qu'il s'agissait d'une transition d'une page en UTF-8 vers une page en ISO-8858-1 qui ne déclarait pas le charset.
Le contraire: ISO -> UTF
Quel page serait en UTF-8 sans déclarer d'encodage ? Cela parait extrêmement rare ... Et le résultat dans ce cas, n'est pas un point d'interrogation, mais des caractère curieux.
Olivier Miakinen
Le 23/10/2003 18:59, Jean-Marc Desperrier a écrit :
Je ne vois pas de cas où ce serait légitime.
Si tu préfère efficace ...
Ok. Oui, je préfère, surtout en lisant l'exemple qui suit.
Il y a une jolie série d'exemple de page en russe ou en hebreux ou en japonais qui regroupe des séries de lien, et de nombreux utilisateurs comptent sur le fait qu'il n'auront pas besoin à chaque fois de changer le jeu de caractère après les avoir ouvert.
Ok.
Cela voudrait dire que l'apparence d'une page dépendrait de l'encodage d'une autre page.
Sur d'anciens navigateurs, l'utilisateur réglait son encodage, et le navigateur restait dedans jusqu'à ce que l'utilisateur le change à nouveau. Pense-y, tu verras que cela donne le même résultat que cela.
C'est une solution qui me conviendrait. J'ai choisi ISO-8859-1 par défaut (ou peut-être ISO-8859-15, je ne sais plus). La plupart des pages que je visite sont : - soit en ISO-8859-1(15) ou Windows-1252 non déclaré - soit en ISO-8859-1(15) ou Windows-1252 déclaré - soit en UTF-8 déclaré Du coup, je ne rencontre des problèmes que quand je passe d'une page en UTF-8 déclarée à une page en Latin1 non déclaré, mais je n'aurais plus ces problèmes si mon choix par défaut était pris en compte pour les nouvelles pages.
Mais je reconnais que si je visitais souvent des pages en deux encodages différents non déclarés, je serais gêné (difficulté de choisir *deux* valeurs par défaut).
Ben non, la solution la plus juste est celle du standard HTTP : une page sans déclaration de charset est réputée être en ISO-8859-1.
La spécification HTML 4 précise qu'il ne faut jamais supposer un jeu de caractères par défaut si rien n'est indiqué dans le document.
C'est dommage. Quel que soit le défaut choisi (je ne défends pas le choix de Latin1), si tous les navigateurs choisissaient ce défaut pour afficher des pages au charset non déclaré, cela aurait peut-être incité davantage de webmasters à en déclarer un...
La spécification XML précise que le format par défaut est UTF-8.
C'est un excellent choix, bien sûr. Mais ça ne nous aide pas beaucoup aujourd'hui où la majorité des sites web sont en tag-soup HTML sans doctype.
HTTP prétend imposer une référence universelle pour tous les types de fichiers texte, mais il est évident que les normes spécifique à chaque format de fichiers prenne en fait le devant.
Oui, encore faudrait-il qu'il y en ait une.
[...]
Donc finalement, je pense que le mieux serait une option pour forcer l'encodage par défaut sur les pages sans encodage explicite,
[OUI]
mais il sera difficile d'obtenir qu'elle soit validée par défaut.
Ça, c'est un moindre mal. Je m'en contenterais.
Le 23/10/2003 18:59, Jean-Marc Desperrier a écrit :
Je ne vois pas de cas où ce serait légitime.
Si tu préfère efficace ...
Ok. Oui, je préfère, surtout en lisant l'exemple qui suit.
Il y a une jolie série d'exemple de page en russe ou en hebreux ou en
japonais qui regroupe des séries de lien, et de nombreux utilisateurs
comptent sur le fait qu'il n'auront pas besoin à chaque fois de changer
le jeu de caractère après les avoir ouvert.
Ok.
Cela voudrait dire que
l'apparence d'une page dépendrait de l'encodage d'une autre page.
Sur d'anciens navigateurs, l'utilisateur réglait son encodage, et le
navigateur restait dedans jusqu'à ce que l'utilisateur le change à
nouveau. Pense-y, tu verras que cela donne le même résultat que cela.
C'est une solution qui me conviendrait. J'ai choisi ISO-8859-1 par
défaut (ou peut-être ISO-8859-15, je ne sais plus). La plupart des pages
que je visite sont :
- soit en ISO-8859-1(15) ou Windows-1252 non déclaré
- soit en ISO-8859-1(15) ou Windows-1252 déclaré
- soit en UTF-8 déclaré
Du coup, je ne rencontre des problèmes que quand je passe d'une page en
UTF-8 déclarée à une page en Latin1 non déclaré, mais je n'aurais plus
ces problèmes si mon choix par défaut était pris en compte pour les
nouvelles pages.
Mais je reconnais que si je visitais souvent des pages en deux encodages
différents non déclarés, je serais gêné (difficulté de choisir *deux*
valeurs par défaut).
Ben non, la solution la plus juste est celle du standard HTTP : une page
sans déclaration de charset est réputée être en ISO-8859-1.
La spécification HTML 4 précise qu'il ne faut jamais supposer un jeu de
caractères par défaut si rien n'est indiqué dans le document.
C'est dommage. Quel que soit le défaut choisi (je ne défends pas le
choix de Latin1), si tous les navigateurs choisissaient ce défaut pour
afficher des pages au charset non déclaré, cela aurait peut-être incité
davantage de webmasters à en déclarer un...
La spécification XML précise que le format par défaut est UTF-8.
C'est un excellent choix, bien sûr. Mais ça ne nous aide pas beaucoup
aujourd'hui où la majorité des sites web sont en tag-soup HTML sans doctype.
HTTP prétend imposer une référence universelle pour tous les types de
fichiers texte, mais il est évident que les normes spécifique à chaque
format de fichiers prenne en fait le devant.
Oui, encore faudrait-il qu'il y en ait une.
[...]
Donc finalement, je pense que le mieux serait une option pour forcer
l'encodage par défaut sur les pages sans encodage explicite,
[OUI]
mais il sera difficile d'obtenir qu'elle soit validée par défaut.
Le 23/10/2003 18:59, Jean-Marc Desperrier a écrit :
Je ne vois pas de cas où ce serait légitime.
Si tu préfère efficace ...
Ok. Oui, je préfère, surtout en lisant l'exemple qui suit.
Il y a une jolie série d'exemple de page en russe ou en hebreux ou en japonais qui regroupe des séries de lien, et de nombreux utilisateurs comptent sur le fait qu'il n'auront pas besoin à chaque fois de changer le jeu de caractère après les avoir ouvert.
Ok.
Cela voudrait dire que l'apparence d'une page dépendrait de l'encodage d'une autre page.
Sur d'anciens navigateurs, l'utilisateur réglait son encodage, et le navigateur restait dedans jusqu'à ce que l'utilisateur le change à nouveau. Pense-y, tu verras que cela donne le même résultat que cela.
C'est une solution qui me conviendrait. J'ai choisi ISO-8859-1 par défaut (ou peut-être ISO-8859-15, je ne sais plus). La plupart des pages que je visite sont : - soit en ISO-8859-1(15) ou Windows-1252 non déclaré - soit en ISO-8859-1(15) ou Windows-1252 déclaré - soit en UTF-8 déclaré Du coup, je ne rencontre des problèmes que quand je passe d'une page en UTF-8 déclarée à une page en Latin1 non déclaré, mais je n'aurais plus ces problèmes si mon choix par défaut était pris en compte pour les nouvelles pages.
Mais je reconnais que si je visitais souvent des pages en deux encodages différents non déclarés, je serais gêné (difficulté de choisir *deux* valeurs par défaut).
Ben non, la solution la plus juste est celle du standard HTTP : une page sans déclaration de charset est réputée être en ISO-8859-1.
La spécification HTML 4 précise qu'il ne faut jamais supposer un jeu de caractères par défaut si rien n'est indiqué dans le document.
C'est dommage. Quel que soit le défaut choisi (je ne défends pas le choix de Latin1), si tous les navigateurs choisissaient ce défaut pour afficher des pages au charset non déclaré, cela aurait peut-être incité davantage de webmasters à en déclarer un...
La spécification XML précise que le format par défaut est UTF-8.
C'est un excellent choix, bien sûr. Mais ça ne nous aide pas beaucoup aujourd'hui où la majorité des sites web sont en tag-soup HTML sans doctype.
HTTP prétend imposer une référence universelle pour tous les types de fichiers texte, mais il est évident que les normes spécifique à chaque format de fichiers prenne en fait le devant.
Oui, encore faudrait-il qu'il y en ait une.
[...]
Donc finalement, je pense que le mieux serait une option pour forcer l'encodage par défaut sur les pages sans encodage explicite,
[OUI]
mais il sera difficile d'obtenir qu'elle soit validée par défaut.
Ça, c'est un moindre mal. Je m'en contenterais.
Steph
Jean-Marc Desperrier a écrit :
Impose à reproduire. La page de redirection est en ISO-8859-9 comme celle d'accueuil. Aucun des sites destination n'aparait chez moi avec ce problème.
Oui c'est tout à fait *aléatoire* :( je viens de tester à l'instant et plus de '?' Je ne sais pas où tu vois la déclaration sur la page de redirection: ======== <html> <head><title>Des correctifs pour Exchange et...</title> <meta http-equiv="refresh" content="5;URL=http://www.echu.org/..."> <meta NAME="KEYWORDS" CONTENT="Des,correctifs,pour,Exchange..."> <meta NAME="DESCRIPTION" CONTENT="Des correctifs pour..."> </head> ======== Malgré tout, si une page n'a pas de charset déclaré, ce ne devrait pas être par défaut le charset déclaré dans ses Préférences/Langues ? Pourquoi je me retrouve parfois avec le Affichage/Code de caractères sur UTF-8 sur des pages sans déclaration ??? À quoi sevent ces préférences alors ?
Steph
-- Enlever l'adresse bidon invalide pour m'écrire
Jean-Marc Desperrier a écrit :
Impose à reproduire. La page de redirection est en ISO-8859-9 comme
celle d'accueuil. Aucun des sites destination n'aparait chez moi avec ce
problème.
Oui c'est tout à fait *aléatoire* :( je viens de tester à l'instant et
plus de '?'
Je ne sais pas où tu vois la déclaration sur la page de redirection:
======== <html>
<head><title>Des correctifs pour Exchange et...</title>
<meta http-equiv="refresh" content="5;URL=http://www.echu.org/...">
<meta NAME="KEYWORDS" CONTENT="Des,correctifs,pour,Exchange...">
<meta NAME="DESCRIPTION" CONTENT="Des correctifs pour...">
</head>
======== Malgré tout, si une page n'a pas de charset déclaré, ce ne devrait pas
être par défaut le charset déclaré dans ses Préférences/Langues ?
Pourquoi je me retrouve parfois avec le Affichage/Code de caractères sur
UTF-8 sur des pages sans déclaration ??? À quoi sevent ces préférences
alors ?
Impose à reproduire. La page de redirection est en ISO-8859-9 comme celle d'accueuil. Aucun des sites destination n'aparait chez moi avec ce problème.
Oui c'est tout à fait *aléatoire* :( je viens de tester à l'instant et plus de '?' Je ne sais pas où tu vois la déclaration sur la page de redirection: ======== <html> <head><title>Des correctifs pour Exchange et...</title> <meta http-equiv="refresh" content="5;URL=http://www.echu.org/..."> <meta NAME="KEYWORDS" CONTENT="Des,correctifs,pour,Exchange..."> <meta NAME="DESCRIPTION" CONTENT="Des correctifs pour..."> </head> ======== Malgré tout, si une page n'a pas de charset déclaré, ce ne devrait pas être par défaut le charset déclaré dans ses Préférences/Langues ? Pourquoi je me retrouve parfois avec le Affichage/Code de caractères sur UTF-8 sur des pages sans déclaration ??? À quoi sevent ces préférences alors ?
