Bonjour,

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/

On Mon, 10 Mar 2008, docanski wrote:

> Quel est donc le meilleur choix pour la meta à insérer dans l'en-tête
> des pages X(HTML) ?

Le meilleur choix est le bon choix. ;-)

Mais spécifier le codage (charset) dans le "HTTP header".
http://www.unics.uni-hannover.de/nht...a-http-equiv.1
http://www.unics.uni-hannover.de/nht...a-http-equiv.2

"docanski" <docanski_antispam@euphonynet.be> a écrit dans le message de
news: fr3mbv$tgv$1@kimsufi.gegeweb.org
> Bonjour,
>
> Quel est donc le meilleur choix pour la meta à insérer dans l'en-tête
> des pages X(HTML) ?

En bonne logique ça n'a pas beaucoup d'importance du moment que c'est
explicitement dit dans le Doctype. L'avantage de l'UTF-8 est qu'on peut
écrire son code HTML sans devoir passer par les tokens d'encodage
(l'histoire que cela soit validable W3C parce que les navigateurs, eux, s'en
foutent un peu)

> 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 ?
>
Pour avoir un gag similaire il faut utiliser le mail d'Outlook qui veut
recevoir du latin-1 (par défaut) et non de l'UTF-8. Donc si les pages Web
d'un site sont codées UTF-8 il est préférable, pour celle qui envoie du
courrier par script PHP de bien préciser qu'on veut dans ce cas du latin-1.

Le reste est peut-être sur le compte d'une config du manchot antarctique
(il faisait des caprices avec les minuscules accentuées dans ses versions
premières, mais cela a dû être arrangé depuis).
--
====================================
William Marie
Attention antiSpam remplacer trapellun.invalid
par free.fr
Web : http://wmarie.free.fr
http://www.pandemonium.dnsalias.org (site expérimental)
====================================

Le 10/03/2008 17:07, docanski a écrit :
>
> Quel est donc le meilleur choix pour la meta à insérer dans l'en-tête
> des pages X(HTML) ?

Le meilleur choix pour l'élément META, c'est de mettre exactement la
même valeur que dans l'entête HTTP. Et le meilleur choix pour l'entête
HTTP, c'est celui qui correspond au jeu de caractères choisi pour enre-
gistrer la page. Enfin, le meilleur choix pour enregistrer la page,
c'est celui que tu préfères -- du moins entre les différents choix
standards, c'est-à-dire UTF-8, ISO-8859-1, ISO-8859-15, US-ASCII, etc.,
mais pas Windows-1252, CP850, CP437 ou EBCDIC.

> 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 ?

Est-ce qu'il n'y aurait pas ISO-8859-1 dans les entêtes HTTP, ce qui
prendrait le pas sur l'UTF-8 de l'élément META ? Donne une URL, pour
voir.

docanski a écrit :
> Bonjour,
>
> Quel est donc le meilleur choix pour la meta à insérer dans l'en-tête
> des pages X(HTML) ?

Celle qui correspond à l'encodage effectif de ton fichier html.

Alors que les eleveurs et agriculteurs polluent toujours la Bretagne,
Olivier Miakinen nous narre ce qui suit en ce 10.03.2008 19:28 :
> Le 10/03/2008 17:07, docanski a écrit :
>> Quel est donc le meilleur choix pour la meta à insérer dans l'en-tête
>> des pages X(HTML) ?
>
> Le meilleur choix pour l'élément META, c'est de mettre exactement la
> même valeur que dans l'entête HTTP.

C'est ce que je fais toujours mais finalement c'est un problème de
paramétrage de l'éditeur Gedit (sous Linux) : il fait 2 propositions
d'encodage lors de l'enregistrement du document, UTF-8 et ISO-8859-15
.... et je ne l'avais pas remarqué.
Etant réglé par défaut sur le premier alors que mon FF l'est sur le
second (enfin, plutôt sur ISO-8859-1), le résultat se traduisait par des
accentués foireux.

Merci pour ton intervention et désolé pour la fausse alerte.

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/

Alors que les eleveurs et agriculteurs polluent toujours la Bretagne,
Bruno Desthuilliers nous narre ce qui suit en ce 11.03.2008 09:01 :
> docanski a écrit :
>> Bonjour,
>>
>> Quel est donc le meilleur choix pour la meta à insérer dans l'en-tête
>> des pages X(HTML) ?
>
> Celle qui correspond à l'encodage effectif de ton fichier html.

C'est bien ce que je pensais mais cette petite mésaventure (voir ma
réponse à Olivier) m'avait fait douter.

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/

docanski a écrit :
> Bonjour,
>
> 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,
Léger HS :
il exsite deux formes de UTF-8 avec BOM ou sans BOM (premier caractère
non affichable). Beaucoup de traitements de texte ne savent générer que
de l'UTF8 avec BOM ce qui peut être la source de bug vicieux notamment
sous php.
Donc pour un site qui n'utilisera que des langues européennes il vaut
mieux se contenter de l'ISO-8859-1 (ou 15).

BertrandB <News.20.BertrandB@I.N.V.A.L.I.D.E.spamgourmet.com > wrote:

> Léger HS :
> il exsite deux formes de UTF-8 avec BOM ou sans BOM (premier caractère
> non affichable). Beaucoup de traitements de texte ne savent générer que
> de l'UTF8 avec BOM ce qui peut être la source de bug vicieux notamment
> sous php.
> Donc pour un site qui n'utilisera que des langues européennes il vaut
> mieux se contenter de l'ISO-8859-1 (ou 15).

En effet en utf8 BOM (Bite Order Mark), une séquence d'octets est
générés en tout début de fichier pour des raisons d'ordre de lecture de
la séquence et à la lecture par un navigateur (IE6 par ex mais pas tous)
ils vont apparaître et perturber l'affichage voire même l'en empêcher.
Mais à ma connaiissance, la plupart des éditeurs gèrent le utf8 sans BOM
donc le pb ne ne pose pas. Et s'ils le gérent par défaut, c'est que de
l'utf8 avec BOM est une aberration car dans ce cas, l'ordre de leture ne
se pose pas contrairement à de l'utf16 ou utf32. Certains éditeurs le
proposent (BBEdit) sans doute pour des raisons de compatibilité que je
ne connais pas.
--
A+

Romer

Le Sun, 16 Mar 2008 13:23:18 +0100, BertrandB a écrit:

> Léger HS :
> il exsite deux formes de UTF-8 avec BOM ou sans BOM (premier caractère
> non affichable). Beaucoup de traitements de texte ne savent générer que
> de l'UTF8 avec BOM ce qui peut être la source de bug vicieux notamment
> sous php.

On n'utilise pas un traitement de textes mais un éditeur de texte pour
développer.

Un truc qui se baserait sur le BOM UTF-8, on le jette.

> Donc pour un site qui n'utilisera que des langues européennes il vaut
> mieux se contenter de l'ISO-8859-1 (ou 15).

C'est sans grande importance pour le développement Web où on déclare le
jeu de caractères.
--
Patrick Texier

vim:syntax=mail:ai:ts=4:et:tw=72

Patrick Texier a écrit :

> On n'utilise pas un traitement de textes mais un éditeur de texte pour
> développer.
>
Tiens il y avait longtemps que je ne m'étais pas fait traité de demeuré.

> Un truc qui se baserait sur le BOM UTF-8, on le jette.

Le problème ne se pose pas effectivement quand on a les bons outils et
que l'on travaille seul sur un site.

Maintenant j'ai été confronté à des ajours sur un site qui ont été fait
avec notepad et wordpad. J'ai proposé à la personne concerné d'utiliser
un véritable éditeur de texte mais en attendant je me suis palucher
plusieurs page à devoir corriger les accents.

BertrandB a écrit :
> docanski a écrit :
>> Bonjour,
>>
>> 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,
> Léger HS :
> il exsite deux formes de UTF-8 avec BOM ou sans BOM (premier caractère
> non affichable). Beaucoup de traitements de texte ne savent générer que
> de l'UTF8 avec BOM ce qui peut être la source de bug vicieux notamment
> sous php.

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.

Quand à ton "traitement de texte" (je suppose que tu veux dire "éditeur
de code", parce que je ne vois pas le rapport entre traitement de texte
et programmation...), s'il ne sait pas reconnaître et afficher un BOM,
c'est qu'il ne vaut pas tripette => mauvais éditeur, changer d'éditeur.

> 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.

BertrandB a écrit :
> Patrick Texier a écrit :
>
>> On n'utilise pas un traitement de textes mais un éditeur de texte pour
>> développer.
>>
> Tiens il y avait longtemps que je ne m'étais pas fait traité de demeuré.
>
>> Un truc qui se baserait sur le BOM UTF-8, on le jette.
>
> Le problème ne se pose pas effectivement quand on a les bons outils et
> que l'on travaille seul sur un site.

???

> Maintenant j'ai été confronté à des ajours sur un site qui ont été fait
> avec notepad et wordpad. J'ai proposé à la personne concerné d'utiliser
> un véritable éditeur de texte mais en attendant je me suis palucher
> plusieurs page à devoir corriger les accents.

man iconv

Le 17/03/2008 10:12, Bruno Desthuilliers a écrit :
>
> [ la réponse que je m'apprétais à faire, que ce soit à propos de
> l'ânerie qu'est un BOM pour UTF-8, de sa mauvaise opinion des
> éditeurs de texte qui ne savent pas les gérer comme il faut, ou
> de l'intérêt d'utiliser UTF-8 à toutes les étapes de la chaîne ]

Je n'ai donc rien à ajouter.

Bruno Desthuilliers <bruno.42.desthuilliers@wtf.websiteburo.oops.com >
wrote:

> 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.

TaF.
Et en plus que les utilisateurs des navigateurs aient l'idée de placer
la commande "encodage de texte" sur "defaut" sinon charabia assuré.
--
A+

Romer

Le 17/03/2008 19:18, Bernd a écrit :
>
>> [ utiliser systématiquement utf8 ]
>
> Et en plus que les utilisateurs des navigateurs aient l'idée de placer
> la commande "encodage de texte" sur "defaut" sinon charabia assuré.

Tu veux dire qu'il existerait des utilisateurs qui forceraient un jeu de
caractères particulier en lecture, différent de UTF-8, indépendamment de
ce qu'annoncent les entêtes HTTP ? Si vraiment il en existe, ils doivent
être bien malheureux à ne pouvoir surfer nulle part (à commencer par les
moteurs de recherche comme Google ou les portails comme Yahoo).

Olivier Miakinen <om+news@miakinen.net> wrote:

> Tu veux dire qu'il existerait des utilisateurs qui forceraient un jeu de
> caractères particulier en lecture, différent de UTF-8, indépendamment de
> ce qu'annoncent les entêtes HTTP ?

Le entêtes ne sont pas vérifiés par beaucoup de monde.
J'ai vu pas mal de navigateurs où iso-latin-1 était sélectionné.
Je suppose que un jour ou l'autre, ces utilisateurs sont tombés sur un
ou plusieurs site mal ou pas encodés du tout et ils ont remarqué les
signes cabalistiques habituels. En bricolant l'encodage, ils ont trouvé
que ça marchait avec iso-latin-1 et du coup ils se sont dit que c'était
cela qui convenait le moins mal même si les sites bien encodés
présentaient à leur tour les glyphes bizarres.

La preuve ici par exemple :

<http://www.e-leclerc.com/voyages/ete2008/index.asp>

Chez moi ça déjante côté accents...
--
A+

Romer

Bruno Desthuilliers a écrit :
> BertrandB a écrit :
>> Patrick Texier a écrit :
>>
>>> On n'utilise pas un traitement de textes mais un éditeur de texte pour
>>> développer.
>>>
>> Tiens il y avait longtemps que je ne m'étais pas fait traité de demeuré.
>>
>>> Un truc qui se baserait sur le BOM UTF-8, on le jette.
>>
>> Le problème ne se pose pas effectivement quand on a les bons outils et
>> que l'on travaille seul sur un site.
>
> ???

oui lorsque q'une partie du site est mis à jour par une ou plusieurs
personnes qui utilise une ou plusieurs plateforme ...

>
>> Maintenant j'ai été confronté à des ajours sur un site qui ont été
>> fait avec notepad et wordpad. J'ai proposé à la personne concerné
>> d'utiliser un véritable éditeur de texte mais en attendant je me suis
>> palucher plusieurs page à devoir corriger les accents.
>
> man iconv
>

va dire ça à ma cliente tiens ... petit plaisantin

Bruno Desthuilliers a écrit :
>
> Quand à ton "traitement de texte" (je suppose que tu veux dire "éditeur
> de code", parce que je ne vois pas le rapport entre traitement de texte
> et programmation...), s'il ne sait pas reconnaître et afficher un BOM,
> c'est qu'il ne vaut pas tripette => mauvais éditeur, changer d'éditeur.
>
Oh si je n'ai pas fourchelangué ...
Ma cliente a réussi à me modifier un ficher avec word ... et je ne
racontes pas tout.

Le 17/03/2008 19:58, Bernd a écrit :
>
>> Tu veux dire qu'il existerait des utilisateurs qui forceraient un jeu de
>> caractères particulier en lecture, différent de UTF-8, indépendamment de
>> ce qu'annoncent les entêtes HTTP ?
>
> Le entêtes ne sont pas vérifiés par beaucoup de monde.

Mais si, il suffit qu'il y en ait.

> La preuve ici par exemple :
>
> <http://www.e-leclerc.com/voyages/ete2008/index.asp>

- pas de charset dans un entête HTTP
- pas de charset dans une déclaration XML
- pas de charset dans un élément META

Ce n'est pas de la faute des visiteurs si le site est mal foutu ! Et la
solution, pour l'auteur du site, n'est évidemment pas de se restreindre
à ISO-8859-1 : c'est d'abord de renseigner l'entête HTTP correctement.

Note qu'un contournement existe *aussi* dans certains navigateurs. Dans
Mozilla, SeaMonkey et Firefox, c'est :
View / Character Encoding / Auto-detect / Universal
ou :
Affichage / Encodage des caractères / Détection automatique / Universel

BertrandB a écrit :
> Bruno Desthuilliers a écrit :
>> BertrandB a écrit :
>>> Patrick Texier a écrit :
>>>
>>>> On n'utilise pas un traitement de textes mais un éditeur de texte pour
>>>> développer.
>>>>
>>> Tiens il y avait longtemps que je ne m'étais pas fait traité de demeuré.
>>>
>>>> Un truc qui se baserait sur le BOM UTF-8, on le jette.
>>>
>>> Le problème ne se pose pas effectivement quand on a les bons outils
>>> et que l'on travaille seul sur un site.
>>
>> ???
>
> oui lorsque q'une partie du site est mis à jour par une ou plusieurs
> personnes qui utilise une ou plusieurs plateforme ...

J'ai l'habitude de travailler à plusieur sur les mêmes sites, certains
sous Windows (différentes variantes), certains sous MacOS X, certains
sous Linux (différentes distribs).

>>
>>> Maintenant j'ai été confronté à des ajours sur un site qui ont été
>>> fait avec notepad et wordpad. J'ai proposé à la personne concerné
>>> d'utiliser un véritable éditeur de texte mais en attendant je me suis
>>> palucher plusieurs page à devoir corriger les accents.
>>
>> man iconv
>>
>
> 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...

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.

Olivier Miakinen wrote:
>> <http://www.e-leclerc.com/voyages/ete2008/index.asp>
>
> - 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 ?

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 ?

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/we...ages_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.