"Hebdogiciel, les listings...": Oric1/Atmos

Olivier Miakinen

07/07/2013 à 23:01

Bonjour,

Le 06/07/2013 20:53, Denis Beauregard a écrit :

Quant au BOM, comment faire la différence autrement entre 2 jeux
de caractères ?

Le BOM sert à différencier, pour les jeux de caractères UTF-16 et
UTF-32, entre leurs versions Big Endian et Little Endian.

Il est inutile :
- si l'on déclare UTF-16BE ou UTF-16LE au lieu de UTF-16 ;
- si l'on déclare UTF-32BE ou UTF-32LE au lieu de UTF-32 ;
- si l'on déclare UTF-8 (il n'existe qu'une seule version
d'UTF-8.

Il est inutile (et de toute manière impossible à spécifier) :
- si l'on déclare un jeu 8 bits tel que ISO-8859-1.

Il est insuffisant :
- si l'on ne déclare rien.

Notons quand même que si l'on utilise UTF-8 sans le déclarer, il
est rarissime (quoique pas impossible) de confondre UTF-8 avec un
autre jeu de caractères. Le seul exemple dont j'ai eu connaissance
d'une confusion possible était sur un texte d'une demi-douzaine
d'octets, entre UTF-8 et un encodage du chinois.

L'énoncé dans les META est insuffisant.

Non. Ou alors seulement si tu déclares UTF-16 ou UTF-32. Avec UTF-8
il n'y a pas plus de problème qu'avec UTF-16BE, UTF-16LE, UTF-32BE ou
UTF-32LE.

Ajoutons qu'il est souvent une source d'emmerdes pas possibles, mais
ça on l'a déjà dit.

En résumé : même sur CD-ROM, il n'y a strictement aucune raison
d'utiliser un BOM pour des pages HTML, où un META http-equiv peut
remplacer les entêtes HTTP. Mais peut-être le problème que tu as
eu concernait-il de simples fichiers texte (sans aucune balise
HTML), et un visionneur de fichiers texte trop rudimentaire pour
détecter l'UTF-8 (alors que ce n'est vraiment pas difficile sauf
cas pathologique rarissime).

Cordialement,
--
Olivier Miakinen

Denis Beauregard

07/07/2013 à 23:41

Le Sun, 07 Jul 2013 23:01:35 +0200, Olivier Miakinen
<om+ écrivait dans fr.comp.infosystemes.www.auteurs:

Le BOM sert à différencier, pour les jeux de caractères UTF-16 et
UTF-32, entre leurs versions Big Endian et Little Endian.

Il est inutile :
- si l'on déclare UTF-16BE ou UTF-16LE au lieu de UTF-16 ;
- si l'on déclare UTF-32BE ou UTF-32LE au lieu de UTF-32 ;
- si l'on déclare UTF-8 (il n'existe qu'une seule version
d'UTF-8.

Il est inutile (et de toute manière impossible à spécifier) :
- si l'on déclare un jeu 8 bits tel que ISO-8859-1.

Il est insuffisant :
- si l'on ne déclare rien.

Alors, que l'on m'explique la différence entre ces deux pages :

http://www.francogene.com/test/test1.html
http://www.francogene.com/test/test2.html

test1 est une page qui sort directement de Seamonkey alors que
test2 a été relu avec Notepad++ qui y ajouté le BOM (à ma demande :
notepad s'aperçoit qu'il s'agit de UTF8 sans BOM).

J'ai légèrement modifié test2 pour avoir des commentaires
pertinents.

Avec Seamonkey 2.19, test1 n'est pas lisible.
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:22.0) Gecko/20100101
Firefox/22.0 SeaMonkey/2.19

Idem avec FF 19.0.2 et Chrome Version 27.0.1453.116 m

Contenu de test1 (via Seamonkey, lu en ligne)

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8"
http-equiv="Content-Type">
<title>Test 1</title>
</head>
<body>
Test numÃ©ro 1 - UTF 8 sortant directement de Seamonkey, donc sans
BOM 
 
Ã©Ã‰eEÃªÃŠÃ¢Ã‚Ã¶Ã–Ã§Ã‡  
 
 
</body>
</html>

Contenu de test1 lu sur PC via Seamonkey

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8"
http-equiv="Content-Type">
<title>Test 1</title>
</head>
<body>
Test numéro 1 - UTF 8 sortant directement de Seamonkey, donc sans
BOM 
 
éÉeEêÊâÂöÖçÇ  
 
 
</body>
</html>

Test1 lu avec Notapad++ qui détecte UTF8 sans BOM

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8"
http-equiv="Content-Type">
<title>Test 1</title>
</head>
<body>
Test numéro 1 - UTF 8 sortant directement de Seamonkey, donc sans
BOM 
 
éÉeEêÊâÂöÖçÇ  
 
 
</body>
</html>

Seamonkey me dit que test1.html est en windows-1252 (oui, 1252 et non
1250 ou UT8). Mais il détecte que test2.html est en UTF8 et la seule
différence, ce sont les BOM.

Mes fichiers ont été envoyé sur mon serveur Web avec la dernière
version de Filezilla 3.7.1 et j'utilise Windows 7 familial.

Je pense qu'il faut conclure que l'énoncé META charset ne fonctionne
tout simplement pas dans Internet. Avec pphpinfo(), je ne vois rien
qui force le jeu de caractère à être autre chose que UTF8.

J'ai eu ce même problème sur mon ancien serveur et sur celui que
j'utilise maintenant.

Denis

Le Sun, 07 Jul 2013 23:01:35 +0200, Olivier Miakinen
<om+news@miakinen.net> écrivait dans fr.comp.infosystemes.www.auteurs:

Le BOM sert à différencier, pour les jeux de caractères UTF-16 et
UTF-32, entre leurs versions Big Endian et Little Endian.

Il est inutile :
- si l'on déclare UTF-16BE ou UTF-16LE au lieu de UTF-16 ;
- si l'on déclare UTF-32BE ou UTF-32LE au lieu de UTF-32 ;
- si l'on déclare UTF-8 (il n'existe qu'une seule version
d'UTF-8.

Il est inutile (et de toute manière impossible à spécifier) :
- si l'on déclare un jeu 8 bits tel que ISO-8859-1.

Il est insuffisant :
- si l'on ne déclare rien.

Alors, que l'on m'explique la différence entre ces deux pages :

http://www.francogene.com/test/test1.html
http://www.francogene.com/test/test2.html

test1 est une page qui sort directement de Seamonkey alors que
test2 a été relu avec Notepad++ qui y ajouté le BOM (à ma demande :
notepad s'aperçoit qu'il s'agit de UTF8 sans BOM).

J'ai légèrement modifié test2 pour avoir des commentaires
pertinents.

Avec Seamonkey 2.19, test1 n'est pas lisible.
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:22.0) Gecko/20100101
Firefox/22.0 SeaMonkey/2.19

Idem avec FF 19.0.2 et Chrome Version 27.0.1453.116 m

Contenu de test1 (via Seamonkey, lu en ligne)

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8"
http-equiv="Content-Type">
<title>Test 1</title>
</head>
<body>
Test numÃ©ro 1 - UTF 8 sortant directement de Seamonkey, donc sans
BOM 
 
Ã©Ã‰eEÃªÃŠÃ¢Ã‚Ã¶Ã–Ã§Ã‡  
 
 
</body>
</html>

Contenu de test1 lu sur PC via Seamonkey

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8"
http-equiv="Content-Type">
<title>Test 1</title>
</head>
<body>
Test numéro 1 - UTF 8 sortant directement de Seamonkey, donc sans
BOM 
 
éÉeEêÊâÂöÖçÇ  
 
 
</body>
</html>

Test1 lu avec Notapad++ qui détecte UTF8 sans BOM

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8"
http-equiv="Content-Type">
<title>Test 1</title>
</head>
<body>
Test numéro 1 - UTF 8 sortant directement de Seamonkey, donc sans
BOM 
 
éÉeEêÊâÂöÖçÇ  
 
 
</body>
</html>

Seamonkey me dit que test1.html est en windows-1252 (oui, 1252 et non
1250 ou UT8). Mais il détecte que test2.html est en UTF8 et la seule
différence, ce sont les BOM.

Mes fichiers ont été envoyé sur mon serveur Web avec la dernière
version de Filezilla 3.7.1 et j'utilise Windows 7 familial.

Je pense qu'il faut conclure que l'énoncé META charset ne fonctionne
tout simplement pas dans Internet. Avec pphpinfo(), je ne vois rien
qui force le jeu de caractère à être autre chose que UTF8.

J'ai eu ce même problème sur mon ancien serveur et sur celui que
j'utilise maintenant.

Denis

Vous avez filtré cet utilisateur ! Consultez son message

Le Sun, 07 Jul 2013 23:01:35 +0200, Olivier Miakinen
<om+ écrivait dans fr.comp.infosystemes.www.auteurs:

Le BOM sert à différencier, pour les jeux de caractères UTF-16 et
UTF-32, entre leurs versions Big Endian et Little Endian.

Il est inutile :
- si l'on déclare UTF-16BE ou UTF-16LE au lieu de UTF-16 ;
- si l'on déclare UTF-32BE ou UTF-32LE au lieu de UTF-32 ;
- si l'on déclare UTF-8 (il n'existe qu'une seule version
d'UTF-8.

Il est inutile (et de toute manière impossible à spécifier) :
- si l'on déclare un jeu 8 bits tel que ISO-8859-1.

Il est insuffisant :
- si l'on ne déclare rien.

Alors, que l'on m'explique la différence entre ces deux pages :

http://www.francogene.com/test/test1.html
http://www.francogene.com/test/test2.html

test1 est une page qui sort directement de Seamonkey alors que
test2 a été relu avec Notepad++ qui y ajouté le BOM (à ma demande :
notepad s'aperçoit qu'il s'agit de UTF8 sans BOM).

J'ai légèrement modifié test2 pour avoir des commentaires
pertinents.

Avec Seamonkey 2.19, test1 n'est pas lisible.
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:22.0) Gecko/20100101
Firefox/22.0 SeaMonkey/2.19

Idem avec FF 19.0.2 et Chrome Version 27.0.1453.116 m

Contenu de test1 (via Seamonkey, lu en ligne)

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8"
http-equiv="Content-Type">
<title>Test 1</title>
</head>
<body>
Test numÃ©ro 1 - UTF 8 sortant directement de Seamonkey, donc sans
BOM 
 
Ã©Ã‰eEÃªÃŠÃ¢Ã‚Ã¶Ã–Ã§Ã‡  
 
 
</body>
</html>

Contenu de test1 lu sur PC via Seamonkey

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8"
http-equiv="Content-Type">
<title>Test 1</title>
</head>
<body>
Test numéro 1 - UTF 8 sortant directement de Seamonkey, donc sans
BOM 
 
éÉeEêÊâÂöÖçÇ  
 
 
</body>
</html>

Test1 lu avec Notapad++ qui détecte UTF8 sans BOM

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8"
http-equiv="Content-Type">
<title>Test 1</title>
</head>
<body>
Test numéro 1 - UTF 8 sortant directement de Seamonkey, donc sans
BOM 
 
éÉeEêÊâÂöÖçÇ  
 
 
</body>
</html>

Seamonkey me dit que test1.html est en windows-1252 (oui, 1252 et non
1250 ou UT8). Mais il détecte que test2.html est en UTF8 et la seule
différence, ce sont les BOM.

Mes fichiers ont été envoyé sur mon serveur Web avec la dernière
version de Filezilla 3.7.1 et j'utilise Windows 7 familial.

Je pense qu'il faut conclure que l'énoncé META charset ne fonctionne
tout simplement pas dans Internet. Avec pphpinfo(), je ne vois rien
qui force le jeu de caractère à être autre chose que UTF8.

J'ai eu ce même problème sur mon ancien serveur et sur celui que
j'utilise maintenant.

Denis

Olivier Miakinen

08/07/2013 à 00:58

Le 07/07/2013 23:41, Denis Beauregard a écrit :

Alors, que l'on m'explique la différence entre ces deux pages :

http://www.francogene.com/test/test1.html
http://www.francogene.com/test/test2.html

Elles sont aussi désastreuses l'une que l'autre, la différence
principale étant le « ï»¿ » en plus :
http://cjoint.com/13ju/CGiaPG9Pswr_capture_du_2013-07-08_00:40:56.png

Mais bien sûr, si tu ne les déclarais pas dans les entêtes HTTP comme
du Latin1 cela n'arriverait pas :
==================================================================== http://www.francogene.com/test/test2.html
Date: Sun, 07 Jul 2013 22:43:32 GMT
Server: Apache
Last-Modified: Sun, 07 Jul 2013 21:24:14 GMT
Accept-Ranges: bytes
Content-Length: 350
Content-Type: text/html; charset=Latin1
X-Pad: avoid browser bug

200 OK
====================================================================
Et soit dit en passant, sur le CD-ROM ces entêtes seront absents (seule
restera la balise META), c'est donc en ligne et pas sur CD-ROM que tu
as le problème.

test1 est une page qui sort directement de Seamonkey alors que
test2 a été relu avec Notepad++ qui y ajouté le BOM (à ma demande :
notepad s'aperçoit qu'il s'agit de UTF8 sans BOM).

Ne me dis pas qu'on ne t'a jamais appris que les entêtes HTTP réels
prennent le pas sur l'« équivalent HTTP » de la balise META...

D'ailleurs le validateur w3c est très clair à ce sujet :

http://validator.w3.org/check?uri=http%3A%2F%2Fwww.francogene.com%2Ftest%2Ftest2.html&charset=%28detect+automatically%29&doctype=Inline&group=0

<cit.>
Warning Character Encoding mismatch!

The character encoding specified in the HTTP header (latin1) is
different from the value in the XML declaration (utf-8). I will use the
value from the HTTP header (latin1).
</cit.>

Seamonkey me dit que test1.html est en windows-1252 (oui, 1252 et non
1250 ou UT8). Mais il détecte que test2.html est en UTF8 et la seule
différence, ce sont les BOM.

J'ai la version 2.15 de SeaMonkey, et son comportement est correct. Si
SeaMonkey 2.19 se met à copier les vieilles version d'Internet Explorer
qui décidaient d'outrepasser les entêtes HTTP, c'est une régression.

Mes fichiers ont été envoyé sur mon serveur Web avec la dernière
version de Filezilla 3.7.1 et j'utilise Windows 7 familial.

Je pense qu'il faut conclure que l'énoncé META charset ne fonctionne
tout simplement pas dans Internet.

Pffff... Je ne compte plus le nombre de fois où on l'a dit et répété
dans fciw.auteurs. Ou alors c'est que tu plonkes tous ceux qui le
disent (Pierre Goiffon, SAM, et tant d'autres).

Avec p[]hpinfo(), je ne vois rien
qui force le jeu de caractère à être autre chose que UTF8.

Gnîîî ??? Que vient faire phpinfo pour une page en pur HTML ne passant
pas le moins du monde par PHP ?

J'ai eu ce même problème sur mon ancien serveur et sur celui que
j'utilise maintenant.

Ben oui, mais si tu ne lis pas les solutions et que tu continues à
partir sur de fausses pistes (le BOM qui *est* un problème et pas
une solution)... :-(

Le 07/07/2013 23:41, Denis Beauregard a écrit :

Alors, que l'on m'explique la différence entre ces deux pages :

http://www.francogene.com/test/test1.html
http://www.francogene.com/test/test2.html

Elles sont aussi désastreuses l'une que l'autre, la différence
principale étant le « ï»¿ » en plus :
http://cjoint.com/13ju/CGiaPG9Pswr_capture_du_2013-07-08_00:40:56.png

Mais bien sûr, si tu ne les déclarais pas dans les entêtes HTTP comme
du Latin1 cela n'arriverait pas :
==================================================================== http://www.francogene.com/test/test2.html
Date: Sun, 07 Jul 2013 22:43:32 GMT
Server: Apache
Last-Modified: Sun, 07 Jul 2013 21:24:14 GMT
Accept-Ranges: bytes
Content-Length: 350
Content-Type: text/html; charset=Latin1
X-Pad: avoid browser bug

200 OK
====================================================================
Et soit dit en passant, sur le CD-ROM ces entêtes seront absents (seule
restera la balise META), c'est donc en ligne et pas sur CD-ROM que tu
as le problème.

test1 est une page qui sort directement de Seamonkey alors que
test2 a été relu avec Notepad++ qui y ajouté le BOM (à ma demande :
notepad s'aperçoit qu'il s'agit de UTF8 sans BOM).

Ne me dis pas qu'on ne t'a jamais appris que les entêtes HTTP réels
prennent le pas sur l'« équivalent HTTP » de la balise META...

D'ailleurs le validateur w3c est très clair à ce sujet :

http://validator.w3.org/check?uri=http%3A%2F%2Fwww.francogene.com%2Ftest%2Ftest2.html&charset=%28detect+automatically%29&doctype=Inline&group=0

<cit.>
Warning Character Encoding mismatch!

The character encoding specified in the HTTP header (latin1) is
different from the value in the XML declaration (utf-8). I will use the
value from the HTTP header (latin1).
</cit.>

Seamonkey me dit que test1.html est en windows-1252 (oui, 1252 et non
1250 ou UT8). Mais il détecte que test2.html est en UTF8 et la seule
différence, ce sont les BOM.

J'ai la version 2.15 de SeaMonkey, et son comportement est correct. Si
SeaMonkey 2.19 se met à copier les vieilles version d'Internet Explorer
qui décidaient d'outrepasser les entêtes HTTP, c'est une régression.

Mes fichiers ont été envoyé sur mon serveur Web avec la dernière
version de Filezilla 3.7.1 et j'utilise Windows 7 familial.

Je pense qu'il faut conclure que l'énoncé META charset ne fonctionne
tout simplement pas dans Internet.

Pffff... Je ne compte plus le nombre de fois où on l'a dit et répété
dans fciw.auteurs. Ou alors c'est que tu plonkes tous ceux qui le
disent (Pierre Goiffon, SAM, et tant d'autres).

Avec p[]hpinfo(), je ne vois rien
qui force le jeu de caractère à être autre chose que UTF8.

Gnîîî ??? Que vient faire phpinfo pour une page en pur HTML ne passant
pas le moins du monde par PHP ?

J'ai eu ce même problème sur mon ancien serveur et sur celui que
j'utilise maintenant.

Ben oui, mais si tu ne lis pas les solutions et que tu continues à
partir sur de fausses pistes (le BOM qui *est* un problème et pas
une solution)... :-(

Vous avez filtré cet utilisateur ! Consultez son message

Le 07/07/2013 23:41, Denis Beauregard a écrit :

Alors, que l'on m'explique la différence entre ces deux pages :

http://www.francogene.com/test/test1.html
http://www.francogene.com/test/test2.html

Elles sont aussi désastreuses l'une que l'autre, la différence
principale étant le « ï»¿ » en plus :
http://cjoint.com/13ju/CGiaPG9Pswr_capture_du_2013-07-08_00:40:56.png

Mais bien sûr, si tu ne les déclarais pas dans les entêtes HTTP comme
du Latin1 cela n'arriverait pas :
==================================================================== http://www.francogene.com/test/test2.html
Date: Sun, 07 Jul 2013 22:43:32 GMT
Server: Apache
Last-Modified: Sun, 07 Jul 2013 21:24:14 GMT
Accept-Ranges: bytes
Content-Length: 350
Content-Type: text/html; charset=Latin1
X-Pad: avoid browser bug

200 OK
====================================================================
Et soit dit en passant, sur le CD-ROM ces entêtes seront absents (seule
restera la balise META), c'est donc en ligne et pas sur CD-ROM que tu
as le problème.

test1 est une page qui sort directement de Seamonkey alors que
test2 a été relu avec Notepad++ qui y ajouté le BOM (à ma demande :
notepad s'aperçoit qu'il s'agit de UTF8 sans BOM).

Ne me dis pas qu'on ne t'a jamais appris que les entêtes HTTP réels
prennent le pas sur l'« équivalent HTTP » de la balise META...

D'ailleurs le validateur w3c est très clair à ce sujet :

http://validator.w3.org/check?uri=http%3A%2F%2Fwww.francogene.com%2Ftest%2Ftest2.html&charset=%28detect+automatically%29&doctype=Inline&group=0

<cit.>
Warning Character Encoding mismatch!

The character encoding specified in the HTTP header (latin1) is
different from the value in the XML declaration (utf-8). I will use the
value from the HTTP header (latin1).
</cit.>

Seamonkey me dit que test1.html est en windows-1252 (oui, 1252 et non
1250 ou UT8). Mais il détecte que test2.html est en UTF8 et la seule
différence, ce sont les BOM.

J'ai la version 2.15 de SeaMonkey, et son comportement est correct. Si
SeaMonkey 2.19 se met à copier les vieilles version d'Internet Explorer
qui décidaient d'outrepasser les entêtes HTTP, c'est une régression.

Mes fichiers ont été envoyé sur mon serveur Web avec la dernière
version de Filezilla 3.7.1 et j'utilise Windows 7 familial.

Je pense qu'il faut conclure que l'énoncé META charset ne fonctionne
tout simplement pas dans Internet.

Pffff... Je ne compte plus le nombre de fois où on l'a dit et répété
dans fciw.auteurs. Ou alors c'est que tu plonkes tous ceux qui le
disent (Pierre Goiffon, SAM, et tant d'autres).

Avec p[]hpinfo(), je ne vois rien
qui force le jeu de caractère à être autre chose que UTF8.

Gnîîî ??? Que vient faire phpinfo pour une page en pur HTML ne passant
pas le moins du monde par PHP ?

J'ai eu ce même problème sur mon ancien serveur et sur celui que
j'utilise maintenant.

Ben oui, mais si tu ne lis pas les solutions et que tu continues à
partir sur de fausses pistes (le BOM qui *est* un problème et pas
une solution)... :-(

Denis Beauregard

08/07/2013 à 01:44

Le Mon, 08 Jul 2013 00:58:25 +0200, Olivier Miakinen
<om+ écrivait dans fr.comp.infosystemes.www.auteurs:

Le 07/07/2013 23:41, Denis Beauregard a écrit :

Alors, que l'on m'explique la différence entre ces deux pages :

http://www.francogene.com/test/test1.html
http://www.francogene.com/test/test2.html

Elles sont aussi désastreuses l'une que l'autre, la différence
principale étant le « ï»¿ » en plus :
http://cjoint.com/13ju/CGiaPG9Pswr_capture_du_2013-07-08_00:40:56.png

Ouf, je viens de trouver mon erreur !!!

Dans le .htaccess, j'ai cette ligne :

<FilesMatch ".(htm|html|php)$">
AddDefaultCharset Latin1
</FilesMatch>

Je me demande si je peux remplacer ces lignes par

<FilesMatch ".(htm|html|php)$">
AddDefaultCharset UTF8
</FilesMatch>

sachant que mon site a 18 ans, qu'il y a des pages de générations
variées et donc peut-être du latin1 en quelque part. En fait, je
pense que j'avais ajouté ces lignes parce qu'il y en avait...

Par contre, je ne comprends pas pourquoi j'arrive à lire mes fichiers
de façon différente par rapport à toi. Dans FF, par exemple, j'ai le
même résultat avec, dans about:config intl.charset.default,
ISO-8859-1, UTF-8 (ou chacun séparément).

Denis

Olivier Miakinen

08/07/2013 à 12:20

Le 08/07/2013 01:44, Denis Beauregard a écrit :

Ouf, je viens de trouver mon erreur !!!

Dans le .htaccess, j'ai cette ligne :

<FilesMatch ".(htm|html|php)$">
AddDefaultCharset Latin1
</FilesMatch>

Soit dit en passant, je me demande où tu es allé pêcher ce nom
« Latin1 ». C'est l'un des nombreux alias pour ISO-8859-1, mais
il aurait mieux valu choisir un nom un peu plus officiel.

Je me demande si je peux remplacer ces lignes par

<FilesMatch ".(htm|html|php)$">
AddDefaultCharset UTF8
</FilesMatch>

Non, car « UTF8 » n'est *pas* un alias enregistré pour « UTF-8 ».
Mais bien sûr tu peux mettre UTF-8.

sachant que mon site a 18 ans, qu'il y a des pages de générations
variées et donc peut-être du latin1 en quelque part. En fait, je
pense que j'avais ajouté ces lignes parce qu'il y en avait...

C'est à toi de savoir où sont les fichiers en ISO-8859-1 et où sont
ceux en UTF-8, et à adapter les .htaccess en conséquence (ou, plus
simplement, à les convertir tous en UTF-8).

Sais tu qu'avec l'option d'Apache Multiviews tu peux même cacher
les extensions de fichier, et mettre dans ces extensions cachées
l'info pour le serveur lui permettant de choisir le bon charset ?

En gros, tu aurais un truc comme ça dans le .htaccess :

=========================== Options +MultiViews

<FilesMatch ".l1$">
AddDefaultCharset ISO-8859-1
</FilesMatch>

<FilesMatch ".u8$">
AddDefaultCharset UTF-8
</FilesMatch>
===========================
Du coup, avec l'URL suivante :

http://www.francogene.com/test/machintruc

Si tu as un fichier machintruc.html.l1, c'est lui qui sera servi, en
ISO-Latin-1. Si tu as un fichier machintruc.html.u8, c'est lui qui
sera servi, en UTF-8. Et si tu as un fichier machintruc.php il sera
envoyé à l'interpréteur PHP.

Enfin bon, c'est très grossièrement expliqué car je n'ai pas touché à
ça depuis plus de dix ans, mais lis la doc ou va te renseigner sur
fciw.serveurs pour en savoir plus.

Par contre, je ne comprends pas pourquoi j'arrive à lire mes fichiers
de façon différente par rapport à toi. Dans FF, par exemple, j'ai le
même résultat avec, dans about:config intl.charset.default,
ISO-8859-1, UTF-8 (ou chacun séparément).

Ce que j'imagine, c'est que, tout comme le faisait Internet Explorer
dans ses versions 5 et 6 (peut-être d'autres aussi mais je ne l'avais
pas testé), tes versions de SeaMonkey et Firefox tentent d'être plus
intelligents que l'auteur des pages web.

L'idée doit être grosso modo « Ok, la page est déclarée en Latin1 dans
les entêtes HTTP, et la norme dit que c'est ça qui *doit* faire foi,
mais le contenu contient une balise meta qui suggère que ça pourrait
être de l'UTF-8, et en plus il y a une crotte au début qui correspond
à la traduction en UTF-8 de ce qui sert de BOM en UTF-16 et UTF-32.
On va donc supposer que l'auteur de la page web voulait en fait de
l'UTF-8 mais qu'il n'a pas su comment le faire correctement, et on
va afficher la page en UTF-8. »

Ce genre de comportement est ÀMHA parfaitement stupide, d'autant
plus que c'est l'une des raisons qui ont donné une si mauvaise image
d'Internet Explorer : les auteurs de pages web qui n'utilisaient
que IE croyaient que leurs pages étaient correctes vu qu'ils les
voyaient dans IE comme ils le souhaitaient, ce qui les dispensait
de corriger les bugs, alors que c'était illisible dans les autres
navigateurs.

En bref : tant qu'il y a des erreurs ou des avertissements lors
de la validation W3C, même si cela semble s'afficher correctement
dans ton ou tes navigateurs, ta page peut être une bouillie infâme
chez les autres.

Le 08/07/2013 01:44, Denis Beauregard a écrit :

Ouf, je viens de trouver mon erreur !!!

Dans le .htaccess, j'ai cette ligne :

<FilesMatch ".(htm|html|php)$">
AddDefaultCharset Latin1
</FilesMatch>

Soit dit en passant, je me demande où tu es allé pêcher ce nom
« Latin1 ». C'est l'un des nombreux alias pour ISO-8859-1, mais
il aurait mieux valu choisir un nom un peu plus officiel.

Je me demande si je peux remplacer ces lignes par

<FilesMatch ".(htm|html|php)$">
AddDefaultCharset UTF8
</FilesMatch>

Non, car « UTF8 » n'est *pas* un alias enregistré pour « UTF-8 ».
Mais bien sûr tu peux mettre UTF-8.

sachant que mon site a 18 ans, qu'il y a des pages de générations
variées et donc peut-être du latin1 en quelque part. En fait, je
pense que j'avais ajouté ces lignes parce qu'il y en avait...

C'est à toi de savoir où sont les fichiers en ISO-8859-1 et où sont
ceux en UTF-8, et à adapter les .htaccess en conséquence (ou, plus
simplement, à les convertir tous en UTF-8).

Sais tu qu'avec l'option d'Apache Multiviews tu peux même cacher
les extensions de fichier, et mettre dans ces extensions cachées
l'info pour le serveur lui permettant de choisir le bon charset ?

En gros, tu aurais un truc comme ça dans le .htaccess :

=========================== Options +MultiViews

<FilesMatch ".l1$">
AddDefaultCharset ISO-8859-1
</FilesMatch>

<FilesMatch ".u8$">
AddDefaultCharset UTF-8
</FilesMatch>
===========================
Du coup, avec l'URL suivante :

http://www.francogene.com/test/machintruc

Si tu as un fichier machintruc.html.l1, c'est lui qui sera servi, en
ISO-Latin-1. Si tu as un fichier machintruc.html.u8, c'est lui qui
sera servi, en UTF-8. Et si tu as un fichier machintruc.php il sera
envoyé à l'interpréteur PHP.

Enfin bon, c'est très grossièrement expliqué car je n'ai pas touché à
ça depuis plus de dix ans, mais lis la doc ou va te renseigner sur
fciw.serveurs pour en savoir plus.

Par contre, je ne comprends pas pourquoi j'arrive à lire mes fichiers
de façon différente par rapport à toi. Dans FF, par exemple, j'ai le
même résultat avec, dans about:config intl.charset.default,
ISO-8859-1, UTF-8 (ou chacun séparément).

Ce que j'imagine, c'est que, tout comme le faisait Internet Explorer
dans ses versions 5 et 6 (peut-être d'autres aussi mais je ne l'avais
pas testé), tes versions de SeaMonkey et Firefox tentent d'être plus
intelligents que l'auteur des pages web.

L'idée doit être grosso modo « Ok, la page est déclarée en Latin1 dans
les entêtes HTTP, et la norme dit que c'est ça qui *doit* faire foi,
mais le contenu contient une balise meta qui suggère que ça pourrait
être de l'UTF-8, et en plus il y a une crotte au début qui correspond
à la traduction en UTF-8 de ce qui sert de BOM en UTF-16 et UTF-32.
On va donc supposer que l'auteur de la page web voulait en fait de
l'UTF-8 mais qu'il n'a pas su comment le faire correctement, et on
va afficher la page en UTF-8. »

Ce genre de comportement est ÀMHA parfaitement stupide, d'autant
plus que c'est l'une des raisons qui ont donné une si mauvaise image
d'Internet Explorer : les auteurs de pages web qui n'utilisaient
que IE croyaient que leurs pages étaient correctes vu qu'ils les
voyaient dans IE comme ils le souhaitaient, ce qui les dispensait
de corriger les bugs, alors que c'était illisible dans les autres
navigateurs.

En bref : tant qu'il y a des erreurs ou des avertissements lors
de la validation W3C, même si cela semble s'afficher correctement
dans ton ou tes navigateurs, ta page peut être une bouillie infâme
chez les autres.

Vous avez filtré cet utilisateur ! Consultez son message

Le 08/07/2013 01:44, Denis Beauregard a écrit :

Ouf, je viens de trouver mon erreur !!!

Dans le .htaccess, j'ai cette ligne :

<FilesMatch ".(htm|html|php)$">
AddDefaultCharset Latin1
</FilesMatch>

Soit dit en passant, je me demande où tu es allé pêcher ce nom
« Latin1 ». C'est l'un des nombreux alias pour ISO-8859-1, mais
il aurait mieux valu choisir un nom un peu plus officiel.

Je me demande si je peux remplacer ces lignes par

<FilesMatch ".(htm|html|php)$">
AddDefaultCharset UTF8
</FilesMatch>

Non, car « UTF8 » n'est *pas* un alias enregistré pour « UTF-8 ».
Mais bien sûr tu peux mettre UTF-8.

sachant que mon site a 18 ans, qu'il y a des pages de générations
variées et donc peut-être du latin1 en quelque part. En fait, je
pense que j'avais ajouté ces lignes parce qu'il y en avait...

C'est à toi de savoir où sont les fichiers en ISO-8859-1 et où sont
ceux en UTF-8, et à adapter les .htaccess en conséquence (ou, plus
simplement, à les convertir tous en UTF-8).

Sais tu qu'avec l'option d'Apache Multiviews tu peux même cacher
les extensions de fichier, et mettre dans ces extensions cachées
l'info pour le serveur lui permettant de choisir le bon charset ?

En gros, tu aurais un truc comme ça dans le .htaccess :

=========================== Options +MultiViews

<FilesMatch ".l1$">
AddDefaultCharset ISO-8859-1
</FilesMatch>

<FilesMatch ".u8$">
AddDefaultCharset UTF-8
</FilesMatch>
===========================
Du coup, avec l'URL suivante :

http://www.francogene.com/test/machintruc

Si tu as un fichier machintruc.html.l1, c'est lui qui sera servi, en
ISO-Latin-1. Si tu as un fichier machintruc.html.u8, c'est lui qui
sera servi, en UTF-8. Et si tu as un fichier machintruc.php il sera
envoyé à l'interpréteur PHP.

Enfin bon, c'est très grossièrement expliqué car je n'ai pas touché à
ça depuis plus de dix ans, mais lis la doc ou va te renseigner sur
fciw.serveurs pour en savoir plus.

Par contre, je ne comprends pas pourquoi j'arrive à lire mes fichiers
de façon différente par rapport à toi. Dans FF, par exemple, j'ai le
même résultat avec, dans about:config intl.charset.default,
ISO-8859-1, UTF-8 (ou chacun séparément).

Ce que j'imagine, c'est que, tout comme le faisait Internet Explorer
dans ses versions 5 et 6 (peut-être d'autres aussi mais je ne l'avais
pas testé), tes versions de SeaMonkey et Firefox tentent d'être plus
intelligents que l'auteur des pages web.

L'idée doit être grosso modo « Ok, la page est déclarée en Latin1 dans
les entêtes HTTP, et la norme dit que c'est ça qui *doit* faire foi,
mais le contenu contient une balise meta qui suggère que ça pourrait
être de l'UTF-8, et en plus il y a une crotte au début qui correspond
à la traduction en UTF-8 de ce qui sert de BOM en UTF-16 et UTF-32.
On va donc supposer que l'auteur de la page web voulait en fait de
l'UTF-8 mais qu'il n'a pas su comment le faire correctement, et on
va afficher la page en UTF-8. »

Ce genre de comportement est ÀMHA parfaitement stupide, d'autant
plus que c'est l'une des raisons qui ont donné une si mauvaise image
d'Internet Explorer : les auteurs de pages web qui n'utilisaient
que IE croyaient que leurs pages étaient correctes vu qu'ils les
voyaient dans IE comme ils le souhaitaient, ce qui les dispensait
de corriger les bugs, alors que c'était illisible dans les autres
navigateurs.

En bref : tant qu'il y a des erreurs ou des avertissements lors
de la validation W3C, même si cela semble s'afficher correctement
dans ton ou tes navigateurs, ta page peut être une bouillie infâme
chez les autres.

"Hebdogiciel, les listings...": Oric1/Atmos

5 réponses

Veuillez sélectionner un problème