Quel est donc le meilleur choix pour la meta à insérer dans l'en-tête
des pages X(HTML) ?
La question peut paraître bizarre mais je constate, depuis que j'utilise
une distribution Linux, que ce dernier me donne toujours un affichage
zarbi lorsque j'affiche avec Firefox un page codée sous Gedit. Lorsque
je force (dans les options d'affichage de FF) l'affichage en UTF-8, le
texte est respecté ... mais cette option se remet toujours à ISO-8859-1
lorsque je rafraîchis la page.
Je n'avais jamais constaté un tel problème sous Win, avec un paramétrage
pourtant parfaitement identique.
Une idée ?
Cordialement,
--
docanski
Portail et annuaire du nord-Bretagne : http://armorance.free.fr/
Guide des champignons d'Europe : http://mycorance.free.fr/
La vallée de la Rance maritime : http://valderance.free.fr/
Les côtes du nord de la Bretagne : http://docarmor/free.fr/
- pas de charset dans un entête HTTP - pas de charset dans une déclaration XML - pas de charset dans un élément META
(...)
Note qu'un contournement existe *aussi* dans certains navigateurs. Dans Mozilla, SeaMonkey et Firefox, c'est : View / Character Encoding / Auto-detect / Universal
Pas activé par défaut, et c'est très dommage
L'équivalent sur MSIE est il me semble activé par défaut, quelqu'un pourrait confirmer ?
- pas de charset dans un entête HTTP
- pas de charset dans une déclaration XML
- pas de charset dans un élément META
(...)
Note qu'un contournement existe *aussi* dans certains navigateurs. Dans
Mozilla, SeaMonkey et Firefox, c'est :
View / Character Encoding / Auto-detect / Universal
Pas activé par défaut, et c'est très dommage
L'équivalent sur MSIE est il me semble activé par défaut, quelqu'un
pourrait confirmer ?
- pas de charset dans un entête HTTP - pas de charset dans une déclaration XML - pas de charset dans un élément META
(...)
Note qu'un contournement existe *aussi* dans certains navigateurs. Dans Mozilla, SeaMonkey et Firefox, c'est : View / Character Encoding / Auto-detect / Universal
Pas activé par défaut, et c'est très dommage
L'équivalent sur MSIE est il me semble activé par défaut, quelqu'un pourrait confirmer ?
Pierre Goiffon
Bruno Desthuilliers wrote:
Mettre un BOM (nb : Byte Order Mark) sur de l'UTF-8 est une ânerie monumentale comme seule une certaine firme de Redmond sait en inventer.
J'ai entendu plusieurs fois comme raison de procéder ainsi que le fichier ainsi généré sera très facile à reconnaître par un processus automatique : s'il y a BOM c'est que c'est un codage d'Unicode. Ca ne me parait une bonne raison ?
Bruno Desthuilliers wrote:
Mettre un BOM (nb : Byte Order Mark) sur de l'UTF-8 est une ânerie
monumentale comme seule une certaine firme de Redmond sait en inventer.
J'ai entendu plusieurs fois comme raison de procéder ainsi que le
fichier ainsi généré sera très facile à reconnaître par un processus
automatique : s'il y a BOM c'est que c'est un codage d'Unicode. Ca ne me
parait une bonne raison ?
Mettre un BOM (nb : Byte Order Mark) sur de l'UTF-8 est une ânerie monumentale comme seule une certaine firme de Redmond sait en inventer.
J'ai entendu plusieurs fois comme raison de procéder ainsi que le fichier ainsi généré sera très facile à reconnaître par un processus automatique : s'il y a BOM c'est que c'est un codage d'Unicode. Ca ne me parait une bonne raison ?
Pierre Goiffon
Mes excuses, réponse précédente partie bien trop vite...
Bruno Desthuilliers wrote:
Donc pour un site qui n'utilisera que des langues européennes il vaut mieux se contenter de l'ISO-8859-1 (ou 15).
Pas mon avis. Le meilleur moyen que je connaisse à ce jour pour ne pas avoir de pb d'encodage est d'utiliser systématiquement utf8 à toutes les étapes de la chaine.
Je n'aime vraiment les solutions qui apparaissent idéales et que l'on applique sans trop réfléchir "parce que ça marche" (jusqu'au jour ou... ça ne marche plus)
UTF-8 ne peut pas toujours être utilisé ! Dans un site dynamique où le contenu vient disons de loin, cela peut devenir délicat...
Pour les langues d'Europe de l'Ouest il y a UTF-8 certes, mais aussi ISO Latin-9 (fortement décrié après sa création mais à ma connaissance largement supporté aujourd'hui), Windows-1252 (Microsoft mais aussi visiblement très bien supporté). UTF-8 peut être disproportionné pour certains contenus... et attention à l'augmentation de volume ! (un jour je finirai la rédaction de http://pgoiffon.free.fr/info/i18n/web-charset_codages_latin.php)
Il reste le problème de la récupération de contenus dans des formulaires... C'est là qu'un codage Unicode prend son intérêt, et vu le support des navigateurs actuels, ce codage sera UTF-8.
Tout ça pour dire qu'un choix de codage doit être réfléchi et effectué en prenant en considération nombre de paramètres.
Mes excuses, réponse précédente partie bien trop vite...
Bruno Desthuilliers wrote:
Donc pour un site qui n'utilisera que des langues européennes il vaut
mieux se contenter de l'ISO-8859-1 (ou 15).
Pas mon avis. Le meilleur moyen que je connaisse à ce jour pour ne pas
avoir de pb d'encodage est d'utiliser systématiquement utf8 à toutes les
étapes de la chaine.
Je n'aime vraiment les solutions qui apparaissent idéales et que l'on
applique sans trop réfléchir "parce que ça marche" (jusqu'au jour ou...
ça ne marche plus)
UTF-8 ne peut pas toujours être utilisé ! Dans un site dynamique où le
contenu vient disons de loin, cela peut devenir délicat...
Pour les langues d'Europe de l'Ouest il y a UTF-8 certes, mais aussi ISO
Latin-9 (fortement décrié après sa création mais à ma connaissance
largement supporté aujourd'hui), Windows-1252 (Microsoft mais aussi
visiblement très bien supporté). UTF-8 peut être disproportionné pour
certains contenus... et attention à l'augmentation de volume !
(un jour je finirai la rédaction de
http://pgoiffon.free.fr/info/i18n/web-charset_codages_latin.php)
Il reste le problème de la récupération de contenus dans des
formulaires... C'est là qu'un codage Unicode prend son intérêt, et vu le
support des navigateurs actuels, ce codage sera UTF-8.
Tout ça pour dire qu'un choix de codage doit être réfléchi et effectué
en prenant en considération nombre de paramètres.
Mes excuses, réponse précédente partie bien trop vite...
Bruno Desthuilliers wrote:
Donc pour un site qui n'utilisera que des langues européennes il vaut mieux se contenter de l'ISO-8859-1 (ou 15).
Pas mon avis. Le meilleur moyen que je connaisse à ce jour pour ne pas avoir de pb d'encodage est d'utiliser systématiquement utf8 à toutes les étapes de la chaine.
Je n'aime vraiment les solutions qui apparaissent idéales et que l'on applique sans trop réfléchir "parce que ça marche" (jusqu'au jour ou... ça ne marche plus)
UTF-8 ne peut pas toujours être utilisé ! Dans un site dynamique où le contenu vient disons de loin, cela peut devenir délicat...
Pour les langues d'Europe de l'Ouest il y a UTF-8 certes, mais aussi ISO Latin-9 (fortement décrié après sa création mais à ma connaissance largement supporté aujourd'hui), Windows-1252 (Microsoft mais aussi visiblement très bien supporté). UTF-8 peut être disproportionné pour certains contenus... et attention à l'augmentation de volume ! (un jour je finirai la rédaction de http://pgoiffon.free.fr/info/i18n/web-charset_codages_latin.php)
Il reste le problème de la récupération de contenus dans des formulaires... C'est là qu'un codage Unicode prend son intérêt, et vu le support des navigateurs actuels, ce codage sera UTF-8.
Tout ça pour dire qu'un choix de codage doit être réfléchi et effectué en prenant en considération nombre de paramètres.
BertrandB
Pierre Goiffon a écrit :
Bruno Desthuilliers wrote:
Mettre un BOM (nb : Byte Order Mark) sur de l'UTF-8 est une ânerie monumentale comme seule une certaine firme de Redmond sait en inventer.
J'ai entendu plusieurs fois comme raison de procéder ainsi que le fichier ainsi généré sera très facile à reconnaître par un processus automatique : s'il y a BOM c'est que c'est un codage d'Unicode. Ca ne me parait une bonne raison ?
Les éditeurs de textes peuvent reconnaître d'autre manière plus explicite l'encodage, alors que le BOM est *invisible*. Et c'est ce que je lui reproche !
un exemple d'arrachage de cheveu. Dans un fichier php on veut envoyer des entêtes personnalisés. La présence du BOM avant <?php fait que les entêtes standards sont envoyés -> bug
explicit is better than implicit
Pierre Goiffon a écrit :
Bruno Desthuilliers wrote:
Mettre un BOM (nb : Byte Order Mark) sur de l'UTF-8 est une ânerie
monumentale comme seule une certaine firme de Redmond sait en inventer.
J'ai entendu plusieurs fois comme raison de procéder ainsi que le
fichier ainsi généré sera très facile à reconnaître par un processus
automatique : s'il y a BOM c'est que c'est un codage d'Unicode. Ca ne me
parait une bonne raison ?
Les éditeurs de textes peuvent reconnaître d'autre manière plus
explicite l'encodage, alors que le BOM est *invisible*. Et c'est ce que
je lui reproche !
un exemple d'arrachage de cheveu. Dans un fichier php on veut envoyer
des entêtes personnalisés. La présence du BOM avant <?php fait que les
entêtes standards sont envoyés -> bug
Mettre un BOM (nb : Byte Order Mark) sur de l'UTF-8 est une ânerie monumentale comme seule une certaine firme de Redmond sait en inventer.
J'ai entendu plusieurs fois comme raison de procéder ainsi que le fichier ainsi généré sera très facile à reconnaître par un processus automatique : s'il y a BOM c'est que c'est un codage d'Unicode. Ca ne me parait une bonne raison ?
Les éditeurs de textes peuvent reconnaître d'autre manière plus explicite l'encodage, alors que le BOM est *invisible*. Et c'est ce que je lui reproche !
un exemple d'arrachage de cheveu. Dans un fichier php on veut envoyer des entêtes personnalisés. La présence du BOM avant <?php fait que les entêtes standards sont envoyés -> bug
explicit is better than implicit
Olivier Miakinen
Le 19/03/2008 16:31, Pierre Goiffon a écrit :
UTF-8 peut être disproportionné pour certains contenus... et attention à l'augmentation de volume ! (un jour je finirai la rédaction de http://pgoiffon.free.fr/info/i18n/web-charset_codages_latin.php)
<cit.> UTF-8 : codage à nombre d'octets variables (entre 1 et 6). </cit.>
Noter que la plupart des caractères sont définis dans le « Basic Multilingual Plane (BMP) » de 0x0000 à 0xFFFD, et sont donc encodés en 3 octets au maximum, et surtout qu'il est maintenant établi que l'on n'ira jamais au delà de 0x10FFFF, ce qui se code en 4 octets au maximum.
Alors oui, UTF-8 peut être disproportionné pour l'écriture de certaines langues dans lesquelles chaque caractère prend 3 octets en UTF-8 contre seulement 2 dans des encodages spécifiques (tels que Shift-JIS pour le japonais), mais ça n'ira jamais beaucoup plus loin.
Le 19/03/2008 16:31, Pierre Goiffon a écrit :
UTF-8 peut être disproportionné pour
certains contenus... et attention à l'augmentation de volume !
(un jour je finirai la rédaction de
http://pgoiffon.free.fr/info/i18n/web-charset_codages_latin.php)
<cit.>
UTF-8 : codage à nombre d'octets variables (entre 1 et 6).
</cit.>
Noter que la plupart des caractères sont définis dans le « Basic
Multilingual Plane (BMP) » de 0x0000 à 0xFFFD, et sont donc encodés
en 3 octets au maximum, et surtout qu'il est maintenant établi que
l'on n'ira jamais au delà de 0x10FFFF, ce qui se code en 4 octets
au maximum.
Alors oui, UTF-8 peut être disproportionné pour l'écriture de certaines
langues dans lesquelles chaque caractère prend 3 octets en UTF-8 contre
seulement 2 dans des encodages spécifiques (tels que Shift-JIS pour le
japonais), mais ça n'ira jamais beaucoup plus loin.
UTF-8 peut être disproportionné pour certains contenus... et attention à l'augmentation de volume ! (un jour je finirai la rédaction de http://pgoiffon.free.fr/info/i18n/web-charset_codages_latin.php)
<cit.> UTF-8 : codage à nombre d'octets variables (entre 1 et 6). </cit.>
Noter que la plupart des caractères sont définis dans le « Basic Multilingual Plane (BMP) » de 0x0000 à 0xFFFD, et sont donc encodés en 3 octets au maximum, et surtout qu'il est maintenant établi que l'on n'ira jamais au delà de 0x10FFFF, ce qui se code en 4 octets au maximum.
Alors oui, UTF-8 peut être disproportionné pour l'écriture de certaines langues dans lesquelles chaque caractère prend 3 octets en UTF-8 contre seulement 2 dans des encodages spécifiques (tels que Shift-JIS pour le japonais), mais ça n'ira jamais beaucoup plus loin.
Olivier Miakinen
Le 19/03/2008 19:24, BertrandB répondait à Pierre Goiffon :
[ Mettre un BOM sur de l'UTF-8 ]
J'ai entendu plusieurs fois comme raison de procéder ainsi que le fichier ainsi généré sera très facile à reconnaître par un processus automatique : s'il y a BOM c'est que c'est un codage d'Unicode. Ca ne me parait une bonne raison ?
Sauf que le codage Unicode est vraiment *très* facile à détecter, et surtout à « falsifier ». Je veux dire que les chances sont quasi-nulles qu'un texte qui ne serait pas en UTF-8 soit pris pour de l'UTF-8. Il n'y a absolument pas besoin d'un BOM UTF-8 pour cela.
un exemple d'arrachage de cheveu. Dans un fichier php on veut envoyer des entêtes personnalisés. La présence du BOM avant <?php fait que les entêtes standards sont envoyés -> bug
[OUI]
Le 19/03/2008 19:24, BertrandB répondait à Pierre Goiffon :
[ Mettre un BOM sur de l'UTF-8 ]
J'ai entendu plusieurs fois comme raison de procéder ainsi que le
fichier ainsi généré sera très facile à reconnaître par un processus
automatique : s'il y a BOM c'est que c'est un codage d'Unicode. Ca ne me
parait une bonne raison ?
Sauf que le codage Unicode est vraiment *très* facile à détecter, et
surtout à « falsifier ». Je veux dire que les chances sont quasi-nulles
qu'un texte qui ne serait pas en UTF-8 soit pris pour de l'UTF-8. Il
n'y a absolument pas besoin d'un BOM UTF-8 pour cela.
un exemple d'arrachage de cheveu. Dans un fichier php on veut envoyer
des entêtes personnalisés. La présence du BOM avant <?php fait que les
entêtes standards sont envoyés -> bug
Le 19/03/2008 19:24, BertrandB répondait à Pierre Goiffon :
[ Mettre un BOM sur de l'UTF-8 ]
J'ai entendu plusieurs fois comme raison de procéder ainsi que le fichier ainsi généré sera très facile à reconnaître par un processus automatique : s'il y a BOM c'est que c'est un codage d'Unicode. Ca ne me parait une bonne raison ?
Sauf que le codage Unicode est vraiment *très* facile à détecter, et surtout à « falsifier ». Je veux dire que les chances sont quasi-nulles qu'un texte qui ne serait pas en UTF-8 soit pris pour de l'UTF-8. Il n'y a absolument pas besoin d'un BOM UTF-8 pour cela.
un exemple d'arrachage de cheveu. Dans un fichier php on veut envoyer des entêtes personnalisés. La présence du BOM avant <?php fait que les entêtes standards sont envoyés -> bug
[OUI]
Sergio
BertrandB a formulé la demande :
Mettre un BOM (nb : Byte Order Mark) sur de l'UTF-8 est une ânerie monumentale comme seule une certaine firme de Redmond sait en inventer.
J'ai entendu plusieurs fois comme raison de procéder ainsi que le fichier ainsi généré sera très facile à reconnaître par un processus automatique : s'il y a BOM c'est que c'est un codage d'Unicode. Ca ne me parait une bonne raison ?
Les éditeurs de textes peuvent reconnaître d'autre manière plus explicite l'encodage, alors que le BOM est *invisible*. Et c'est ce que je lui reproche !
un exemple d'arrachage de cheveu. Dans un fichier php on veut envoyer des entêtes personnalisés. La présence du BOM avant <?php fait que les entêtes standards sont envoyés -> bug
Bug dans le processeur PHP ou dans le serveur Web ?
AMHA, le BOM est une très bonne chose, qui permet de connaître (par un programme) l'encodage d'un fichier. Pourquoi le couple PHP/Apache n'en tient pas compte ?
-- Serge http://leserged.online.fr/ Mon blog: http://cahierdesergio.free.fr/ Soutenez le libre: http://www.framasoft.org
BertrandB a formulé la demande :
Mettre un BOM (nb : Byte Order Mark) sur de l'UTF-8 est une ânerie
monumentale comme seule une certaine firme de Redmond sait en inventer.
J'ai entendu plusieurs fois comme raison de procéder ainsi que le fichier
ainsi généré sera très facile à reconnaître par un processus automatique :
s'il y a BOM c'est que c'est un codage d'Unicode. Ca ne me parait une bonne
raison ?
Les éditeurs de textes peuvent reconnaître d'autre manière plus explicite
l'encodage, alors que le BOM est *invisible*. Et c'est ce que je lui reproche
!
un exemple d'arrachage de cheveu. Dans un fichier php on veut envoyer des
entêtes personnalisés. La présence du BOM avant <?php fait que les entêtes
standards sont envoyés -> bug
Bug dans le processeur PHP ou dans le serveur Web ?
AMHA, le BOM est une très bonne chose, qui permet de connaître (par un
programme) l'encodage d'un fichier. Pourquoi le couple PHP/Apache n'en
tient pas compte ?
--
Serge http://leserged.online.fr/
Mon blog: http://cahierdesergio.free.fr/
Soutenez le libre: http://www.framasoft.org
Mettre un BOM (nb : Byte Order Mark) sur de l'UTF-8 est une ânerie monumentale comme seule une certaine firme de Redmond sait en inventer.
J'ai entendu plusieurs fois comme raison de procéder ainsi que le fichier ainsi généré sera très facile à reconnaître par un processus automatique : s'il y a BOM c'est que c'est un codage d'Unicode. Ca ne me parait une bonne raison ?
Les éditeurs de textes peuvent reconnaître d'autre manière plus explicite l'encodage, alors que le BOM est *invisible*. Et c'est ce que je lui reproche !
un exemple d'arrachage de cheveu. Dans un fichier php on veut envoyer des entêtes personnalisés. La présence du BOM avant <?php fait que les entêtes standards sont envoyés -> bug
Bug dans le processeur PHP ou dans le serveur Web ?
AMHA, le BOM est une très bonne chose, qui permet de connaître (par un programme) l'encodage d'un fichier. Pourquoi le couple PHP/Apache n'en tient pas compte ?
-- Serge http://leserged.online.fr/ Mon blog: http://cahierdesergio.free.fr/ Soutenez le libre: http://www.framasoft.org
Sergio
Olivier Miakinen avait soumis l'idée :
J'ai entendu plusieurs fois comme raison de procéder ainsi que le fichier ainsi généré sera très facile à reconnaître par un processus automatique : s'il y a BOM c'est que c'est un codage d'Unicode. Ca ne me parait une bonne raison ?
Sauf que le codage Unicode est vraiment *très* facile à détecter,
explique ? Lire les deux premiers octets du BOM c'est pas plus facile que de lire tout le fichier et détecter d'éventuels caractères UTF-8, UTF16 ou que sais-je ?
et surtout à « falsifier ».
Quel est l'intérêt de falsifier l'encodage d'un fichier sinon pour socratiser les diptères ?
-- Serge http://leserged.online.fr/ Mon blog: http://cahierdesergio.free.fr/ Soutenez le libre: http://www.framasoft.org
Olivier Miakinen avait soumis l'idée :
J'ai entendu plusieurs fois comme raison de procéder ainsi que le
fichier ainsi généré sera très facile à reconnaître par un processus
automatique : s'il y a BOM c'est que c'est un codage d'Unicode. Ca ne me
parait une bonne raison ?
Sauf que le codage Unicode est vraiment *très* facile à détecter,
explique ? Lire les deux premiers octets du BOM c'est pas plus facile
que de lire tout le fichier et détecter d'éventuels caractères UTF-8,
UTF16 ou que sais-je ?
et surtout à « falsifier ».
Quel est l'intérêt de falsifier l'encodage d'un fichier sinon pour
socratiser les diptères ?
--
Serge http://leserged.online.fr/
Mon blog: http://cahierdesergio.free.fr/
Soutenez le libre: http://www.framasoft.org
J'ai entendu plusieurs fois comme raison de procéder ainsi que le fichier ainsi généré sera très facile à reconnaître par un processus automatique : s'il y a BOM c'est que c'est un codage d'Unicode. Ca ne me parait une bonne raison ?
Sauf que le codage Unicode est vraiment *très* facile à détecter,
explique ? Lire les deux premiers octets du BOM c'est pas plus facile que de lire tout le fichier et détecter d'éventuels caractères UTF-8, UTF16 ou que sais-je ?
et surtout à « falsifier ».
Quel est l'intérêt de falsifier l'encodage d'un fichier sinon pour socratiser les diptères ?
-- Serge http://leserged.online.fr/ Mon blog: http://cahierdesergio.free.fr/ Soutenez le libre: http://www.framasoft.org
Bruno Desthuilliers
BertrandB a écrit :
Bruno Desthuilliers a écrit :
va dire ça à ma cliente tiens ... petit plaisantin
Non, je te le dis à toi. Mais bon, si tu préfères continuer à te "palucher" ça à la mano, hein...
Bon il faudra que je teste la prochaine fois que je me récupère encore un mélange d'UTF et de Latin1 avec un peu de CP-232.
Heu... Le tout dans le même fichier ??? Là, je déclare forfait (et AMHA, tous les convertisseurs existant aussi).
BertrandB a écrit :
Bruno Desthuilliers a écrit :
va dire ça à ma cliente tiens ... petit plaisantin
Non, je te le dis à toi. Mais bon, si tu préfères continuer à te
"palucher" ça à la mano, hein...
Bon il faudra que je teste la prochaine fois que je me récupère encore
un mélange d'UTF et de Latin1 avec un peu de CP-232.
Heu... Le tout dans le même fichier ??? Là, je déclare forfait (et AMHA,
tous les convertisseurs existant aussi).
