C'est une _très_ mauvaise idée, car ce jeu de caractères, spécifique à Ms-Windows, risque d'être mal interprété sur MacOs, Linux, etc.
J'ai lu très souvent cette assertion... Sans jamais trouver d'exemple concret.
ça tend à se raréfier mais ... je dois avouer que je rencontre encore des pages pleines de [?] tant l'emploi du latin-windows n'est pas "naturel" à mon environnement.
Cordialement, -- Stéphane Moriaux avec/with iMac-intel 27" & Mac OS X 10.6.8
Le 07/05/13 11:55, Pierre Goiffon a écrit :
Le 19/04/2013 17:23, Eric Demeester a écrit :
Je reste donc en windows-1252, non mais !
C'est une _très_ mauvaise idée, car ce jeu de caractères, spécifique à
Ms-Windows, risque d'être mal interprété sur MacOs, Linux, etc.
J'ai lu très souvent cette assertion... Sans jamais trouver d'exemple
concret.
ça tend à se raréfier mais ... je dois avouer que je rencontre encore
des pages pleines de [?]
tant l'emploi du latin-windows n'est pas "naturel" à mon environnement.
Cordialement,
--
Stéphane Moriaux avec/with iMac-intel 27" & Mac OS X 10.6.8
C'est une _très_ mauvaise idée, car ce jeu de caractères, spécifique à Ms-Windows, risque d'être mal interprété sur MacOs, Linux, etc.
J'ai lu très souvent cette assertion... Sans jamais trouver d'exemple concret.
ça tend à se raréfier mais ... je dois avouer que je rencontre encore des pages pleines de [?] tant l'emploi du latin-windows n'est pas "naturel" à mon environnement.
Cordialement, -- Stéphane Moriaux avec/with iMac-intel 27" & Mac OS X 10.6.8
SAM
Le 07/05/13 11:52, Pierre Goiffon a écrit :
Le 20/04/2013 11:51, Sergio a écrit :
vous aurez beau mettre une balise html <meta charset="utf-8" /> c'est la déclaration du serveur qui prévaudra.
(belle absurdité, en passant)
Pour lire la balise meta, il faut savoir lire le flux html, et pour lire ce dernier il faut connaitre son charset !
ja na rien comprendre là dis donc !
n'est-ce point du bête ascii à ce niveau ? (ou, au plus fort du compliqué, de l'iso-latin-1 dont on emploie ici rien d'autre que sa partie commune avec l'ascii)
une fois lu ce meta il sera loisible ensuite de passer au décodage suivant la bonne table de cacactères y spécifiée, non ?
Si l'on n'avait que la balise meta, il faudrait donc que tous agents utilisateurs se débrouillent à essayer de deviner le charset pour pouvoir enfin avoir confirmation qu'ils ne se sont pas trompés en lisant la valeur de la balise meta !
n'importe quoi ! paske le serveur ne pourrait pas se "tromper" ?
Il y a plusieurs cas assez tordus, je n'ai pas retrouvé trace des pages sur lesquelles j'étais tombé en me posant moi même cette question il y a plusieurs années... Mais déjà, songez qu'il y a de nombreux charset qui ne sont pas DU TOUT dérivés de ascii (toute la famille EBCDIC par exemple) ou aussi simples à détecter qu'un UTF-16 avec BOM, et que bien sûr il existe des recouvrements (des suites de bits valides dans plusieurs charsets).
M'enfin ! on met le meta charset en début et puis hop!
En tous cas en local ça fonctionne parfaitement (forcément alors sans en-tête de serveur).
Il est donc naturel que l'information de charset soit en meta dans le protocole de transport. Dans le cas de http, vous constaterez d'ailleurs que l'entête utilisé est... content-type.
Ouaip ! "text/html" !!!
... et ... dermerdenzizich !
Oui mais comment intervenir sur le serveur ?
Soit dans le .htaccess avec la directive "CharsetDefault", soit en balançant le header adhoc en PHP.
Ha! Tu vois bien que le serveur peut alors envoyer une info erronée ! (si on confie le truc à un humain (stagiaire ? ))
Cordialement, -- Stéphane Moriaux avec/with iMac-intel 27" & Mac OS X 10.6.8
Le 07/05/13 11:52, Pierre Goiffon a écrit :
Le 20/04/2013 11:51, Sergio a écrit :
vous aurez beau mettre une balise html <meta charset="utf-8" />
c'est la déclaration du serveur qui prévaudra.
(belle absurdité, en passant)
Pour lire la balise meta, il faut savoir lire le flux html, et pour lire
ce dernier il faut connaitre son charset !
ja na rien comprendre là dis donc !
n'est-ce point du bête ascii à ce niveau ?
(ou, au plus fort du compliqué, de l'iso-latin-1 dont on emploie ici
rien d'autre que sa partie commune avec l'ascii)
une fois lu ce meta il sera loisible ensuite de passer au décodage
suivant la bonne table de cacactères y spécifiée, non ?
Si l'on n'avait que la balise meta, il faudrait donc que tous agents
utilisateurs se débrouillent à essayer de deviner le charset pour
pouvoir enfin avoir confirmation qu'ils ne se sont pas trompés en lisant
la valeur de la balise meta !
n'importe quoi !
paske le serveur ne pourrait pas se "tromper" ?
Il y a plusieurs cas assez tordus, je n'ai pas retrouvé trace des pages
sur lesquelles j'étais tombé en me posant moi même cette question il y a
plusieurs années... Mais déjà, songez qu'il y a de nombreux charset qui
ne sont pas DU TOUT dérivés de ascii (toute la famille EBCDIC par
exemple) ou aussi simples à détecter qu'un UTF-16 avec BOM, et que bien
sûr il existe des recouvrements (des suites de bits valides dans
plusieurs charsets).
M'enfin !
on met le meta charset en début et puis hop!
En tous cas en local ça fonctionne parfaitement (forcément alors sans
en-tête de serveur).
Il est donc naturel que l'information de charset soit en meta dans le
protocole de transport. Dans le cas de http, vous constaterez d'ailleurs
que l'entête utilisé est... content-type.
Ouaip !
"text/html" !!!
... et ...
dermerdenzizich !
Oui mais comment intervenir sur le serveur ?
Soit dans le .htaccess avec la directive "CharsetDefault", soit en
balançant le header adhoc en PHP.
Ha! Tu vois bien que le serveur peut alors envoyer une info erronée !
(si on confie le truc à un humain (stagiaire ? ))
Cordialement,
--
Stéphane Moriaux avec/with iMac-intel 27" & Mac OS X 10.6.8
vous aurez beau mettre une balise html <meta charset="utf-8" /> c'est la déclaration du serveur qui prévaudra.
(belle absurdité, en passant)
Pour lire la balise meta, il faut savoir lire le flux html, et pour lire ce dernier il faut connaitre son charset !
ja na rien comprendre là dis donc !
n'est-ce point du bête ascii à ce niveau ? (ou, au plus fort du compliqué, de l'iso-latin-1 dont on emploie ici rien d'autre que sa partie commune avec l'ascii)
une fois lu ce meta il sera loisible ensuite de passer au décodage suivant la bonne table de cacactères y spécifiée, non ?
Si l'on n'avait que la balise meta, il faudrait donc que tous agents utilisateurs se débrouillent à essayer de deviner le charset pour pouvoir enfin avoir confirmation qu'ils ne se sont pas trompés en lisant la valeur de la balise meta !
n'importe quoi ! paske le serveur ne pourrait pas se "tromper" ?
Il y a plusieurs cas assez tordus, je n'ai pas retrouvé trace des pages sur lesquelles j'étais tombé en me posant moi même cette question il y a plusieurs années... Mais déjà, songez qu'il y a de nombreux charset qui ne sont pas DU TOUT dérivés de ascii (toute la famille EBCDIC par exemple) ou aussi simples à détecter qu'un UTF-16 avec BOM, et que bien sûr il existe des recouvrements (des suites de bits valides dans plusieurs charsets).
M'enfin ! on met le meta charset en début et puis hop!
En tous cas en local ça fonctionne parfaitement (forcément alors sans en-tête de serveur).
Il est donc naturel que l'information de charset soit en meta dans le protocole de transport. Dans le cas de http, vous constaterez d'ailleurs que l'entête utilisé est... content-type.
Ouaip ! "text/html" !!!
... et ... dermerdenzizich !
Oui mais comment intervenir sur le serveur ?
Soit dans le .htaccess avec la directive "CharsetDefault", soit en balançant le header adhoc en PHP.
Ha! Tu vois bien que le serveur peut alors envoyer une info erronée ! (si on confie le truc à un humain (stagiaire ? ))
Cordialement, -- Stéphane Moriaux avec/with iMac-intel 27" & Mac OS X 10.6.8
Eric Demeester
Pierre Goiffon (Tue, 07 May 2013 11:55:34 +0200 - fr.comp.infosystemes.www.auteurs) :
Bonsoir Pierre,
Le 19/04/2013 17:23, Eric Demeester a écrit : >> Je reste donc en windows-1252, non mais ! > C'est une _très_ mauvaise idée, car ce jeu de caractères, spécifique à > Ms-Windows, risque d'être mal interprété sur MacOs, Linux, etc. J'ai lu très souvent cette assertion... Sans jamais trouver d'exemple concret.
Des exemples concrets, j'en ai eu à la pelle, de moins en moins à présent, pour être honnête.
Mes explications, qui valent ce qu'elles valent, à savoir pas grand-chose, sont que :
- le cp-1252 de Windows étant très proche d'ISO-8859-1(5), globalement, ça passe, sauf pour une petite poignée de caractères spécifiques ;
- cet encodage pourri étant massivement utilisé pour cause de suprématie écrasante de Ms-Windows comme OS, le reste du monde, plutôt que de se battre contre un moulin à vent, a intégré ses particularités ;
- on éradique le problème en remplaçant les caractères potentiellement nuisibles par ceux normalisés, genre pour les espaces insécables.
Est-ce que vous auriez plus de détails Eric ?
Au delà ce ce que j'évoquais ci-dessus, non.
-- Eric
Pierre Goiffon (Tue, 07 May 2013 11:55:34 +0200 -
fr.comp.infosystemes.www.auteurs) :
Bonsoir Pierre,
Le 19/04/2013 17:23, Eric Demeester a écrit :
>> Je reste donc en windows-1252, non mais !
> C'est une _très_ mauvaise idée, car ce jeu de caractères, spécifique à
> Ms-Windows, risque d'être mal interprété sur MacOs, Linux, etc.
J'ai lu très souvent cette assertion... Sans jamais trouver d'exemple
concret.
Des exemples concrets, j'en ai eu à la pelle, de moins en moins à
présent, pour être honnête.
Mes explications, qui valent ce qu'elles valent, à savoir pas
grand-chose, sont que :
- le cp-1252 de Windows étant très proche d'ISO-8859-1(5), globalement,
ça passe, sauf pour une petite poignée de caractères spécifiques ;
- cet encodage pourri étant massivement utilisé pour cause de
suprématie écrasante de Ms-Windows comme OS, le reste du monde, plutôt
que de se battre contre un moulin à vent, a intégré ses
particularités ;
- on éradique le problème en remplaçant les caractères potentiellement
nuisibles par ceux normalisés, genre pour les espaces
insécables.
Pierre Goiffon (Tue, 07 May 2013 11:55:34 +0200 - fr.comp.infosystemes.www.auteurs) :
Bonsoir Pierre,
Le 19/04/2013 17:23, Eric Demeester a écrit : >> Je reste donc en windows-1252, non mais ! > C'est une _très_ mauvaise idée, car ce jeu de caractères, spécifique à > Ms-Windows, risque d'être mal interprété sur MacOs, Linux, etc. J'ai lu très souvent cette assertion... Sans jamais trouver d'exemple concret.
Des exemples concrets, j'en ai eu à la pelle, de moins en moins à présent, pour être honnête.
Mes explications, qui valent ce qu'elles valent, à savoir pas grand-chose, sont que :
- le cp-1252 de Windows étant très proche d'ISO-8859-1(5), globalement, ça passe, sauf pour une petite poignée de caractères spécifiques ;
- cet encodage pourri étant massivement utilisé pour cause de suprématie écrasante de Ms-Windows comme OS, le reste du monde, plutôt que de se battre contre un moulin à vent, a intégré ses particularités ;
- on éradique le problème en remplaçant les caractères potentiellement nuisibles par ceux normalisés, genre pour les espaces insécables.
Est-ce que vous auriez plus de détails Eric ?
Au delà ce ce que j'évoquais ci-dessus, non.
-- Eric
Olivier Miakinen
Le 08/05/2013 23:39, Eric Demeester répondait à Pierre Goiffon :
>> Je reste donc en windows-1252, non mais ! > C'est une _très_ mauvaise idée, car ce jeu de caractères, spécifique à > Ms-Windows, risque d'être mal interprété sur MacOs, Linux, etc. J'ai lu très souvent cette assertion... Sans jamais trouver d'exemple concret.
L'exemple concret que j'avais pour ma part était Netscape 4 sur AIX, mais cela date d'un paquet d'années. D'ailleurs il n'y a pas que Windows-1252 qu'il ne supportait pas, je crois qu'il ne s'en sortait pas beaucoup mieux avec ISO-8859-15 ou UTF-8. Sans parler des CSS !
Des exemples concrets, j'en ai eu à la pelle, de moins en moins à présent, pour être honnête.
Mes explications, qui valent ce qu'elles valent, à savoir pas grand-chose, sont que :
- le cp-1252 de Windows étant très proche d'ISO-8859-1(5), globalement, ça passe, sauf pour une petite poignée de caractères spécifiques ;
Oui.
- cet encodage pourri étant massivement utilisé pour cause de suprématie écrasante de Ms-Windows comme OS, le reste du monde, plutôt que de se battre contre un moulin à vent, a intégré ses particularités ;
Oui, et c'est ce qui fait que la remarque de Pierre est pertinente : en pratique, le Windows-1252 ne risque plus guère d'être mal géré, pourvu qu'il soit correctement déclaré. Pire que ça, cela fonctionne aussi assez souvent quand il est incorrectement déclaré comme de l'ISO-8859-1, voire pas déclaré du tout. :-(
En revanche, ta remarque à propos de la suprématie écrasante d'un OS propriétaire est pertinente aussi, et c'est que qui me fait pour ma part rejeter le Windows-1252 comme un encodage pourri. Ce n'est donc pas pour des raisons pratiques que je le déconseille, mais pour des raisons philosophiques. Et qu'on ne vienne pas me dire que ce sont de mauvaises raisons !
- on éradique le problème en remplaçant les caractères potentiellement nuisibles par ceux normalisés, genre pour les espaces insécables.
En l'occurrence, l'espace insécable est un mauvais exemple : elle fait partie de ISO-8859-1, ISO-8859-15 et UTF-8 aussi bien que de Win-1252, et à la même position. Mais il se trouve que l'éditeur de texte intégré dans les logiciels tels que Firefox la remplace par une espace simple, ce qui peut être une raison de l'éviter... seulement ce n'est en rien la faute de Microsoft.
Est-ce que vous auriez plus de détails Eric ?
Au delà ce ce que j'évoquais ci-dessus, non.
Pas mieux.
Cordialement, -- Olivier Miakinen
Le 08/05/2013 23:39, Eric Demeester répondait à Pierre Goiffon :
>> Je reste donc en windows-1252, non mais !
> C'est une _très_ mauvaise idée, car ce jeu de caractères, spécifique à
> Ms-Windows, risque d'être mal interprété sur MacOs, Linux, etc.
J'ai lu très souvent cette assertion... Sans jamais trouver d'exemple
concret.
L'exemple concret que j'avais pour ma part était Netscape 4 sur AIX,
mais cela date d'un paquet d'années. D'ailleurs il n'y a pas que
Windows-1252 qu'il ne supportait pas, je crois qu'il ne s'en sortait
pas beaucoup mieux avec ISO-8859-15 ou UTF-8. Sans parler des CSS !
Des exemples concrets, j'en ai eu à la pelle, de moins en moins à
présent, pour être honnête.
Mes explications, qui valent ce qu'elles valent, à savoir pas
grand-chose, sont que :
- le cp-1252 de Windows étant très proche d'ISO-8859-1(5), globalement,
ça passe, sauf pour une petite poignée de caractères spécifiques ;
Oui.
- cet encodage pourri étant massivement utilisé pour cause de
suprématie écrasante de Ms-Windows comme OS, le reste du monde, plutôt
que de se battre contre un moulin à vent, a intégré ses
particularités ;
Oui, et c'est ce qui fait que la remarque de Pierre est pertinente :
en pratique, le Windows-1252 ne risque plus guère d'être mal géré,
pourvu qu'il soit correctement déclaré. Pire que ça, cela fonctionne
aussi assez souvent quand il est incorrectement déclaré comme de
l'ISO-8859-1, voire pas déclaré du tout. :-(
En revanche, ta remarque à propos de la suprématie écrasante d'un
OS propriétaire est pertinente aussi, et c'est que qui me fait pour
ma part rejeter le Windows-1252 comme un encodage pourri. Ce n'est
donc pas pour des raisons pratiques que je le déconseille, mais pour
des raisons philosophiques. Et qu'on ne vienne pas me dire que ce
sont de mauvaises raisons !
- on éradique le problème en remplaçant les caractères potentiellement
nuisibles par ceux normalisés, genre pour les espaces
insécables.
En l'occurrence, l'espace insécable est un mauvais exemple : elle fait
partie de ISO-8859-1, ISO-8859-15 et UTF-8 aussi bien que de Win-1252,
et à la même position. Mais il se trouve que l'éditeur de texte intégré
dans les logiciels tels que Firefox la remplace par une espace simple,
ce qui peut être une raison de l'éviter... seulement ce n'est en rien
la faute de Microsoft.
Le 08/05/2013 23:39, Eric Demeester répondait à Pierre Goiffon :
>> Je reste donc en windows-1252, non mais ! > C'est une _très_ mauvaise idée, car ce jeu de caractères, spécifique à > Ms-Windows, risque d'être mal interprété sur MacOs, Linux, etc. J'ai lu très souvent cette assertion... Sans jamais trouver d'exemple concret.
L'exemple concret que j'avais pour ma part était Netscape 4 sur AIX, mais cela date d'un paquet d'années. D'ailleurs il n'y a pas que Windows-1252 qu'il ne supportait pas, je crois qu'il ne s'en sortait pas beaucoup mieux avec ISO-8859-15 ou UTF-8. Sans parler des CSS !
Des exemples concrets, j'en ai eu à la pelle, de moins en moins à présent, pour être honnête.
Mes explications, qui valent ce qu'elles valent, à savoir pas grand-chose, sont que :
- le cp-1252 de Windows étant très proche d'ISO-8859-1(5), globalement, ça passe, sauf pour une petite poignée de caractères spécifiques ;
Oui.
- cet encodage pourri étant massivement utilisé pour cause de suprématie écrasante de Ms-Windows comme OS, le reste du monde, plutôt que de se battre contre un moulin à vent, a intégré ses particularités ;
Oui, et c'est ce qui fait que la remarque de Pierre est pertinente : en pratique, le Windows-1252 ne risque plus guère d'être mal géré, pourvu qu'il soit correctement déclaré. Pire que ça, cela fonctionne aussi assez souvent quand il est incorrectement déclaré comme de l'ISO-8859-1, voire pas déclaré du tout. :-(
En revanche, ta remarque à propos de la suprématie écrasante d'un OS propriétaire est pertinente aussi, et c'est que qui me fait pour ma part rejeter le Windows-1252 comme un encodage pourri. Ce n'est donc pas pour des raisons pratiques que je le déconseille, mais pour des raisons philosophiques. Et qu'on ne vienne pas me dire que ce sont de mauvaises raisons !
- on éradique le problème en remplaçant les caractères potentiellement nuisibles par ceux normalisés, genre pour les espaces insécables.
En l'occurrence, l'espace insécable est un mauvais exemple : elle fait partie de ISO-8859-1, ISO-8859-15 et UTF-8 aussi bien que de Win-1252, et à la même position. Mais il se trouve que l'éditeur de texte intégré dans les logiciels tels que Firefox la remplace par une espace simple, ce qui peut être une raison de l'éviter... seulement ce n'est en rien la faute de Microsoft.
Est-ce que vous auriez plus de détails Eric ?
Au delà ce ce que j'évoquais ci-dessus, non.
Pas mieux.
Cordialement, -- Olivier Miakinen
Pierre Goiffon
Le 08/05/2013 01:41, SAM a écrit :
Pour lire la balise meta, il faut savoir lire le flux html, et pour lire ce dernier il faut connaitre son charset !
ja na rien comprendre là dis donc !
n'est-ce point du bête ascii à ce niveau ?
C'est ce que je disais plus bas :
Il y a plusieurs cas assez tordus, je n'ai pas retrouvé trace des pages sur lesquelles j'étais tombé en me posant moi même cette question il y a plusieurs années... Mais déjà, songez qu'il y a de nombreux charset qui ne sont pas DU TOUT dérivés de ascii (toute la famille EBCDIC par exemple) ou aussi simples à détecter qu'un UTF-16 avec BOM, et que bien sûr il existe des recouvrements (des suites de bits valides dans plusieurs charsets).
on met le meta charset en début et puis hop!
Ca enlèverai un peu de complexité, mais ça reste costaud à gérer ! En gros, s'appuyer uniquement sur le content-type text/html pour lire le flux, ça serait comme de récupérer un flux de type simplement image au lieu de image/jpg ou image/png : avec un contenu texte sans charset, il faut deviner comment lire ce que l'on reçoit.
Ha! Tu vois bien que le serveur peut alors envoyer une info erronée !
Je n'ai jamais dit l'inverse !
Le 08/05/2013 01:41, SAM a écrit :
Pour lire la balise meta, il faut savoir lire le flux html, et pour lire
ce dernier il faut connaitre son charset !
ja na rien comprendre là dis donc !
n'est-ce point du bête ascii à ce niveau ?
C'est ce que je disais plus bas :
Il y a plusieurs cas assez tordus, je n'ai pas retrouvé trace des pages
sur lesquelles j'étais tombé en me posant moi même cette question il y a
plusieurs années... Mais déjà, songez qu'il y a de nombreux charset qui
ne sont pas DU TOUT dérivés de ascii (toute la famille EBCDIC par
exemple) ou aussi simples à détecter qu'un UTF-16 avec BOM, et que bien
sûr il existe des recouvrements (des suites de bits valides dans
plusieurs charsets).
on met le meta charset en début et puis hop!
Ca enlèverai un peu de complexité, mais ça reste costaud à gérer !
En gros, s'appuyer uniquement sur le content-type text/html pour lire le
flux, ça serait comme de récupérer un flux de type simplement image au
lieu de image/jpg ou image/png : avec un contenu texte sans charset, il
faut deviner comment lire ce que l'on reçoit.
Ha! Tu vois bien que le serveur peut alors envoyer une info erronée !
Pour lire la balise meta, il faut savoir lire le flux html, et pour lire ce dernier il faut connaitre son charset !
ja na rien comprendre là dis donc !
n'est-ce point du bête ascii à ce niveau ?
C'est ce que je disais plus bas :
Il y a plusieurs cas assez tordus, je n'ai pas retrouvé trace des pages sur lesquelles j'étais tombé en me posant moi même cette question il y a plusieurs années... Mais déjà, songez qu'il y a de nombreux charset qui ne sont pas DU TOUT dérivés de ascii (toute la famille EBCDIC par exemple) ou aussi simples à détecter qu'un UTF-16 avec BOM, et que bien sûr il existe des recouvrements (des suites de bits valides dans plusieurs charsets).
on met le meta charset en début et puis hop!
Ca enlèverai un peu de complexité, mais ça reste costaud à gérer ! En gros, s'appuyer uniquement sur le content-type text/html pour lire le flux, ça serait comme de récupérer un flux de type simplement image au lieu de image/jpg ou image/png : avec un contenu texte sans charset, il faut deviner comment lire ce que l'on reçoit.
Ha! Tu vois bien que le serveur peut alors envoyer une info erronée !
Je n'ai jamais dit l'inverse !
Pierre Goiffon
Le 10/05/2013 12:28, Olivier Miakinen a écrit :
- cet encodage pourri étant massivement utilisé pour cause de suprématie écrasante de Ms-Windows comme OS, le reste du monde, plutôt que de se battre contre un moulin à vent, a intégré ses particularités ;
Oui, et c'est ce qui fait que la remarque de Pierre est pertinente : en pratique, le Windows-1252 ne risque plus guère d'être mal géré, pourvu qu'il soit correctement déclaré.
Ca me semble extrêmement discutable, ça serait oublier l'histoire de ISO Latin-9, qui est arrivé très, très, très (...) en retard. En 2001 de mon expérience ISO Latin-9 n'était supporté/implémenté quasiment nulle part alors que Windows-1252 dans quasiment tous les outils que j'utilisais (Windows en poste et serveur, Linux en serveur).
Pire que ça, cela fonctionne aussi assez souvent quand il est incorrectement déclaré comme de l'ISO-8859-1, voire pas déclaré du tout. :-(
En effet, beaucoup de navigateurs ont intégré ce fallback dès qu'ils détectent un caractère des plages 80..9F
- on éradique le problème en remplaçant les caractères potentiellement nuisibles par ceux normalisés, genre pour les espaces insécables.
En l'occurrence, l'espace insécable est un mauvais exemple
Merci de la correction :)
Le 10/05/2013 12:28, Olivier Miakinen a écrit :
- cet encodage pourri étant massivement utilisé pour cause de
suprématie écrasante de Ms-Windows comme OS, le reste du monde, plutôt
que de se battre contre un moulin à vent, a intégré ses
particularités ;
Oui, et c'est ce qui fait que la remarque de Pierre est pertinente :
en pratique, le Windows-1252 ne risque plus guère d'être mal géré,
pourvu qu'il soit correctement déclaré.
Ca me semble extrêmement discutable, ça serait oublier l'histoire de ISO
Latin-9, qui est arrivé très, très, très (...) en retard. En 2001 de mon
expérience ISO Latin-9 n'était supporté/implémenté quasiment nulle part
alors que Windows-1252 dans quasiment tous les outils que j'utilisais
(Windows en poste et serveur, Linux en serveur).
Pire que ça, cela fonctionne
aussi assez souvent quand il est incorrectement déclaré comme de
l'ISO-8859-1, voire pas déclaré du tout. :-(
En effet, beaucoup de navigateurs ont intégré ce fallback dès qu'ils
détectent un caractère des plages 80..9F
- on éradique le problème en remplaçant les caractères potentiellement
nuisibles par ceux normalisés, genre pour les espaces
insécables.
En l'occurrence, l'espace insécable est un mauvais exemple
- cet encodage pourri étant massivement utilisé pour cause de suprématie écrasante de Ms-Windows comme OS, le reste du monde, plutôt que de se battre contre un moulin à vent, a intégré ses particularités ;
Oui, et c'est ce qui fait que la remarque de Pierre est pertinente : en pratique, le Windows-1252 ne risque plus guère d'être mal géré, pourvu qu'il soit correctement déclaré.
Ca me semble extrêmement discutable, ça serait oublier l'histoire de ISO Latin-9, qui est arrivé très, très, très (...) en retard. En 2001 de mon expérience ISO Latin-9 n'était supporté/implémenté quasiment nulle part alors que Windows-1252 dans quasiment tous les outils que j'utilisais (Windows en poste et serveur, Linux en serveur).
Pire que ça, cela fonctionne aussi assez souvent quand il est incorrectement déclaré comme de l'ISO-8859-1, voire pas déclaré du tout. :-(
En effet, beaucoup de navigateurs ont intégré ce fallback dès qu'ils détectent un caractère des plages 80..9F
- on éradique le problème en remplaçant les caractères potentiellement nuisibles par ceux normalisés, genre pour les espaces insécables.
En l'occurrence, l'espace insécable est un mauvais exemple
Merci de la correction :)
Pierre Goiffon
Le 08/05/2013 01:37, SAM a écrit :
C'est une _très_ mauvaise idée, car ce jeu de caractères, spécifique à Ms-Windows, risque d'être mal interprété sur MacOs, Linux, etc.
J'ai lu très souvent cette assertion... Sans jamais trouver d'exemple concret.
ça tend à se raréfier mais ... je dois avouer que je rencontre encore des pages pleines de [?] tant l'emploi du latin-windows n'est pas "naturel" à mon environnement.
Je suis preneur d'une URL où tu reproduirai le prb... Avec quel navigateur l'as-tu constaté ?
Le 08/05/2013 01:37, SAM a écrit :
C'est une _très_ mauvaise idée, car ce jeu de caractères, spécifique à
Ms-Windows, risque d'être mal interprété sur MacOs, Linux, etc.
J'ai lu très souvent cette assertion... Sans jamais trouver d'exemple
concret.
ça tend à se raréfier mais ... je dois avouer que je rencontre encore
des pages pleines de [?]
tant l'emploi du latin-windows n'est pas "naturel" à mon environnement.
Je suis preneur d'une URL où tu reproduirai le prb...
Avec quel navigateur l'as-tu constaté ?
C'est une _très_ mauvaise idée, car ce jeu de caractères, spécifique à Ms-Windows, risque d'être mal interprété sur MacOs, Linux, etc.
J'ai lu très souvent cette assertion... Sans jamais trouver d'exemple concret.
ça tend à se raréfier mais ... je dois avouer que je rencontre encore des pages pleines de [?] tant l'emploi du latin-windows n'est pas "naturel" à mon environnement.
Je suis preneur d'une URL où tu reproduirai le prb... Avec quel navigateur l'as-tu constaté ?
Olivier Miakinen
Le 10/05/2013 17:02, Pierre Goiffon m'a répondu :
> > Oui, et c'est ce qui fait que la remarque de Pierre est pertinente : > en pratique, le Windows-1252 ne risque plus guère d'être mal géré, > pourvu qu'il soit correctement déclaré.
Ca me semble extrêmement discutable,
Ah ?
ça serait oublier l'histoire de ISO Latin-9, qui est arrivé très, très, très (...) en retard. En 2001 de mon expérience ISO Latin-9 n'était supporté/implémenté quasiment nulle part alors que Windows-1252 dans quasiment tous les outils que j'utilisais (Windows en poste et serveur, Linux en serveur).
C'est bien ce que je voulais dire. Je suppose que tu n'avais pas compris à cause de mon style ampoulé et de mon goût des doubles négations « plus guère / mal géré ». ;-)
-- Olivier Miakinen
Le 10/05/2013 17:02, Pierre Goiffon m'a répondu :
>
> Oui, et c'est ce qui fait que la remarque de Pierre est pertinente :
> en pratique, le Windows-1252 ne risque plus guère d'être mal géré,
> pourvu qu'il soit correctement déclaré.
Ca me semble extrêmement discutable,
Ah ?
ça serait oublier l'histoire de ISO
Latin-9, qui est arrivé très, très, très (...) en retard. En 2001 de mon
expérience ISO Latin-9 n'était supporté/implémenté quasiment nulle part
alors que Windows-1252 dans quasiment tous les outils que j'utilisais
(Windows en poste et serveur, Linux en serveur).
C'est bien ce que je voulais dire. Je suppose que tu n'avais pas
compris à cause de mon style ampoulé et de mon goût des doubles
négations « plus guère / mal géré ». ;-)
> > Oui, et c'est ce qui fait que la remarque de Pierre est pertinente : > en pratique, le Windows-1252 ne risque plus guère d'être mal géré, > pourvu qu'il soit correctement déclaré.
Ca me semble extrêmement discutable,
Ah ?
ça serait oublier l'histoire de ISO Latin-9, qui est arrivé très, très, très (...) en retard. En 2001 de mon expérience ISO Latin-9 n'était supporté/implémenté quasiment nulle part alors que Windows-1252 dans quasiment tous les outils que j'utilisais (Windows en poste et serveur, Linux en serveur).
C'est bien ce que je voulais dire. Je suppose que tu n'avais pas compris à cause de mon style ampoulé et de mon goût des doubles négations « plus guère / mal géré ». ;-)
-- Olivier Miakinen
SAM
Le 10/05/13 17:03, Pierre Goiffon a écrit :
Le 08/05/2013 01:37, SAM a écrit :
C'est une _très_ mauvaise idée, car ce jeu de caractères, spécifique à Ms-Windows, risque d'être mal interprété sur MacOs, Linux, etc.
J'ai lu très souvent cette assertion... Sans jamais trouver d'exemple concret.
ça tend à se raréfier mais ... je dois avouer que je rencontre encore des pages pleines de [?] tant l'emploi du latin-windows n'est pas "naturel" à mon environnement.
Je suis preneur d'une URL où tu reproduirai le prb...
en général ce sont plutôt de vieux articles ou posts de forum web
Je ne les ais pas archivés et n'ai pas cherché à savoir en quel encodage ça avait été écrit ou servi.
Avec quel navigateur l'as-tu constaté ?
Usuellement j'utilise Firefox
Cordialement, -- Stéphane Moriaux avec/with iMac-intel 27" & Mac OS X 10.6.8
Le 10/05/13 17:03, Pierre Goiffon a écrit :
Le 08/05/2013 01:37, SAM a écrit :
C'est une _très_ mauvaise idée, car ce jeu de caractères, spécifique à
Ms-Windows, risque d'être mal interprété sur MacOs, Linux, etc.
J'ai lu très souvent cette assertion... Sans jamais trouver d'exemple
concret.
ça tend à se raréfier mais ... je dois avouer que je rencontre encore
des pages pleines de [?]
tant l'emploi du latin-windows n'est pas "naturel" à mon environnement.
Je suis preneur d'une URL où tu reproduirai le prb...
en général ce sont plutôt de vieux articles ou posts de forum web
Je ne les ais pas archivés
et n'ai pas cherché à savoir en quel encodage ça avait été écrit ou servi.
Avec quel navigateur l'as-tu constaté ?
Usuellement j'utilise Firefox
Cordialement,
--
Stéphane Moriaux avec/with iMac-intel 27" & Mac OS X 10.6.8
C'est une _très_ mauvaise idée, car ce jeu de caractères, spécifique à Ms-Windows, risque d'être mal interprété sur MacOs, Linux, etc.
J'ai lu très souvent cette assertion... Sans jamais trouver d'exemple concret.
ça tend à se raréfier mais ... je dois avouer que je rencontre encore des pages pleines de [?] tant l'emploi du latin-windows n'est pas "naturel" à mon environnement.
Je suis preneur d'une URL où tu reproduirai le prb...
en général ce sont plutôt de vieux articles ou posts de forum web
Je ne les ais pas archivés et n'ai pas cherché à savoir en quel encodage ça avait été écrit ou servi.
Avec quel navigateur l'as-tu constaté ?
Usuellement j'utilise Firefox
Cordialement, -- Stéphane Moriaux avec/with iMac-intel 27" & Mac OS X 10.6.8
Pierre Goiffon
Le 11/05/2013 01:50, SAM a écrit :
ça tend à se raréfier mais ... je dois avouer que je rencontre encore des pages pleines de [?] tant l'emploi du latin-windows n'est pas "naturel" à mon environnement.
Je suis preneur d'une URL où tu reproduirai le prb...
en général ce sont plutôt de vieux articles ou posts de forum web
Je ne les ais pas archivés et n'ai pas cherché à savoir en quel encodage ça avait été écrit ou servi.
Ok... A l'occasion, n'hésite pas à en parler ici si tu retombe sur un prb identique !
Le 11/05/2013 01:50, SAM a écrit :
ça tend à se raréfier mais ... je dois avouer que je rencontre encore
des pages pleines de [?]
tant l'emploi du latin-windows n'est pas "naturel" à mon environnement.
Je suis preneur d'une URL où tu reproduirai le prb...
en général ce sont plutôt de vieux articles ou posts de forum web
Je ne les ais pas archivés
et n'ai pas cherché à savoir en quel encodage ça avait été écrit ou servi.
Ok...
A l'occasion, n'hésite pas à en parler ici si tu retombe sur un prb
identique !
ça tend à se raréfier mais ... je dois avouer que je rencontre encore des pages pleines de [?] tant l'emploi du latin-windows n'est pas "naturel" à mon environnement.
Je suis preneur d'une URL où tu reproduirai le prb...
en général ce sont plutôt de vieux articles ou posts de forum web
Je ne les ais pas archivés et n'ai pas cherché à savoir en quel encodage ça avait été écrit ou servi.
Ok... A l'occasion, n'hésite pas à en parler ici si tu retombe sur un prb identique !
