HTTP/HTML Priorité des instructions de charset - Page 1

J'ai une petite question qui me taraude, ça touche autant au protocole HTTP qu'au langage HTML mais il me semble qu'il n'y a pas de catégorie mieux adaptée pour ce topic.

Vous savez déjà que quand on accède à une page HTML avec un navigateur web, l'information sur l'encodage peut venir de deux endroits différents :

- De l'en-tête HTTP, avec l'instruction "Content-Type" (par exemple "Content-Type: text/html; charset=UTF-8
")
- De l'en-tête HTML, avec la balise "<meta>" (par exemple <meta http-equiv="Content-Type" content="application/xhtml+xml;charset=UTF-8" />)

Ce qui m'étonne c'est que dans le cas où les deux informations sont présentes et contradictoires (l'une indique UTF-8 et l'autre Latin-1 par exemple), les navigateurs semblent donner priorité à celle de l'en-tête HTTP. Je viens de vérifier sous Firefox, Internet Explorer, Opera et Chrome : même résultat. Pourtant ça me parait stupide pour au moins deux raisons :

- Une logique : c'est quand même la page qui est le mieux placée pour savoir comment elle est encodée. Peu importe ce que le serveur indique, si la page prend la peine de re-spécifier le header il y a beaucoup de chances pour que ce soit le bon.
- Une pratique : j'ai un serveur (Apache) qui spécifie par défaut (en l'absence de .htaccess) un charset UTF-8 quand il répond à une requête. Si j'accède à une page HTML encodée en Latin-1 qui précise dans son en-tête et via une balise <meta> qu'elle est encodée en Latin-1, mon navigateur va quand même considérer qu'elle est en UTF-8 et donc me l'afficher n'importe comment.

Est-ce que vous connaissez la raison qui justifie ce comportement ? Puisqu'il se retrouve dans tous les navigateurs que j'ai testés, je suppose qu'il est standard et qu'il y a une explication logique, mais pour l'instant ça me parait surtout pas très pratique.

Zephyr (./1) :
Est-ce que vous connaissez la raison qui justifie ce comportement ? Puisqu'il se retrouve dans tous les navigateurs que j'ai testés, je suppose qu'il est standard

ça a l'air d'être le comportement défini par la RFC HTTP/1.1 :
http://www.w3.org/Protocols/rfc2068/rfc2068.txt
Si tu vas à la section "7.2.1 Type", elle dit :

7.2.1 Type

When an entity-body is included with a message, the data type of that
body is determined via the header fields Content-Type and Content-
Encoding. These define a two-layer, ordered encoding model:

entity-body := Content-Encoding( Content-Type( data ) )

Content-Type specifies the media type of the underlying data.
Content-Encoding may be used to indicate any additional content
codings applied to the data, usually for the purpose of data
compression, that are a property of the requested resource. There is
no default encoding.

Any HTTP/1.1 message containing an entity-body SHOULD include a
Content-Type header field defining the media type of that body. If
and only if the media type is not given by a Content-Type field, the
recipient MAY attempt to guess the media type via inspection of its
content and/or the name extension(s) of the URL used to identify the
resource. If the media type remains unknown, the recipient SHOULD treat it as type "application/octet-stream".

Et la RFC HTML (je cite la RFC HTML 4.0 ; j'imagine que c'est resté pareil dans la RFC XHTML) dit :
http://www.w3.org/TR/REC-html40/charset.html#h-5.2.2

To sum up, conforming user agents must observe the following priorities when determining a document's character encoding (from highest priority to lowest):

1. An HTTP "charset" parameter in a "Content-Type" field.
2. A META declaration with "http-equiv" set to "Content-Type" and a value set for "charset".
3. The charset attribute set on an element that designates an external resource.
In addition to this list of priorities, the user agent may use heuristics and user settings.

Donc, il semble effectivement s'agir du comportement standard.
Pour ce qui est de la raison "logique", après...

Je suis absolument pas un expert HTML mais <?xml version="1.0" encoding="windows-1252"?> agit il avec le même niveau de priorité que la balise méta?

Et certains navigateurs se comportent différemment.

Mais effectivement, la spec dit que le serveur a toujours raison, peut-être aussi pour des raisons de performance, mais il est clair que c'est peu pratique malheureusement.

C'est - hélas ! - le header qui prime, oui.
[mode="HS"]J'en ai fait l'expérience malheureuse avec mon hébergeur qui lance un header charset: ISO-8859-1 pour TOUTES leurs pages, alors que je codais bien tranquilement en utf-8… Là, je pense qu'il y a quelque chose à revoir.[/mode]

./2 : ok, merci pour les liens, ça n'explique pas les raisons de ces choix mais au moins ça élimine mes espoirs de trouver un navigateur qui se comporte de façon intelligente

./5 : si tu codes en PHP, ce n'est pas vraiment un problème, tu peux envoyer ton propre header Content-Type (fonction "header()") pour remplacer celui que le serveur envoie par défaut

assez interessant comme remarque, et ca éclair quelques problèmes que j'ai eu à un moment !

Je sais, c'est ce que j'ai fait, mais je trouvais quand-même stupide de devoir passer mes pages en .php juste pour envoyer le header. Enfin bref, voilà, quoi

Ah oui c'est sûr que si ça aurait pu rester des .html sans ça, c'est carrément dommage (c'est moins pratique, ça coute bien plus cher en charge serveur, etc...), d'où le ./1

ça coute vraiment plus cher un fichier php qui contient que du html?

beaucoup plus cher non, plus cher oui puisqu'il faut quand même appeler le parseur php qui va se taper tout le fichier à la recherche d'un "<?php" inexistant pour finalement retourner le contenu de la page à l'identique

Zephyr (./1) :
Vous savez déjà que quand on accède à une page HTML avec un navigateur web, l'information sur l'encodage peut venir de deux endroits différents :
- De l'en-tête HTTP, avec l'instruction "Content-Type" (par exemple "Content-Type: text/html; charset=UTF-8
")
- De l'en-tête HTML, avec la balise "<meta>" (par exemple <meta http-equiv="Content-Type" content="application/xhtml+xml;charset=UTF-8" />)

Tu as oublié
- De l'en-tête XML, avec la balise "<?xml version="1.0" encoding="windows-1252"?>"

Zephyr (./6) :
si tu codes en PHP, ce n'est pas vraiment un problème, tu peux envoyer ton propre header Content-Type (fonction "header()") pour remplacer celui que le serveur envoie par défaut

sinon, selon ce que te permet la conf de ton serveur (et donc, selon ton hébergeur, je suppose), tu dois pouvoir configurer l'en-tête Content-type via un fichier .htaccess

Ça me semble compréhensible que ce soit l'encodage défini dans l'entête HTTP qui doit être utilisé.
Comment le navigateur peut faire pour lire la page et trouver le bon encodage si l'encodage qu'il utilise pour lire n'est pas bon ?

Si ton entête HTTP indique un truc du genre UTF-16, si le navigateur arrive à lire dans la page qu'il doit utiliser un autre encodage, c'est qu’à priori, il utilise déjà le bon... Et si l'encodage défini dans la page est bon, mais pas celui de l'entête, alors ce bon encodage risque de ne pas être trouvé.

Thepro (./14) :
Comment le navigateur peut faire pour lire la page et trouver le bon encodage si l'encodage qu'il utilise pour lire n'est pas bon ?

C'est pas faux, mais le navigateur pourrait se réajuster une fois qu'il tombe sur l'encodage de la page, qui a quand même peu de chances de spécifier une valeur mauvaise (si on précise l'encodage dans la page, c'est pas pour en mettre un mauvais).

Si ton entête HTTP indique un truc du genre UTF-16, si le navigateur arrive à lire dans la page qu'il doit utiliser un autre encodage, c'est qu’à priori, il utilise déjà le bon... Et si l'encodage défini dans la page est bon, mais pas celui de l'entête, alors ce bon encodage risque de ne pas être trouvé.

Heu, non ? Dans l'exemple que je citais au ./1, le navigateur qui utilise un encodage UTF-8 (indiqué par le header HTTP) arrivera sans problème à lire l'en-tête de la page HTML. En revanche il pourrait prendre en compte l'encodage Latin-1 spécifié par la page une fois qu'il tombe dessus, sans quoi il va afficher n'importe quoi en parcourant la balise <body> :/

Thepro (./14) :
Ça me semble compréhensible que ce soit l'encodage défini dans l'entête HTTP qui doit être utilisé.
Comment le navigateur peut faire pour lire la page et trouver le bon encodage si l'encodage qu'il utilise pour lire n'est pas bon ?

Quel intérêt de définir la balise meta, alors ?

tiens je croyais que la balise meta était utilisée par le serveur pour savoir quel content-type annoncer #àlamasse#

Flanker (./16) :

Thepro (./14) :
Ça me semble compréhensible que ce soit l'encodage défini dans l'entête HTTP qui doit être utilisé.
Comment le navigateur peut faire pour lire la page et trouver le bon encodage si l'encodage qu'il utilise pour lire n'est pas bon ?

Quel intérêt de définir la balise meta, alors ?

Bah, ça sert si tu ne définis pas d'encodage dans l'entête HTTP et si celui que tu utilises est plus ou moins compatible avec celui par défaut utilisé par le navigateur.
Si tu envoies une page en UTF-16 sans l'indiquer dans l'entête, je ne sais pas si elle va s'afficher correctement...

(d'ailleurs, je n'ai jamais bien compris l'intérêt de l'UTF-16 et de l'UTF-32... pour une fois qu'on avait l'occasion de faire une nouvelle norme propre, on nous en pond 3, histoire d'être sûr d'avoir toujours une source d'incompatibilité...)

le meta c utile qunad le charset est pas declare dans le content-type (cad souvent) et donc le browser (c a lui de rendre et de prober le charset) utilise le meta, ou se demerde pour le trouver

L'UTF-16 était censé être le Unicode (c'est pour ça que les premiers logiciels à gérer l'Unicode utilisaient ça), ensuite l'UTF-8 a été conçu pour être compatible ASCII et ensuite l'UTF-32 parce qu'ils se sont rendus compte que 16 bits ne suffisaient pas pour représenter tous les caractères chinois et donc l'UTF-16 n'est plus l'encodage à longueur constante que c'était censé être, l'UTF-32 le remplace pour cette utilisation. Bref, l'UTF-16 n'est plus qu'une relique historique, il faudrait utiliser partout l'UTF-8 en externe et éventuellement l'UTF-32 en interne, mais en pratique l'UTF-16 est très répandu pour des raisons historiques.

Flanker (./19) :
(d'ailleurs, je n'ai jamais bien compris l'intérêt de l'UTF-16 et de l'UTF-32... pour une fois qu'on avait l'occasion de faire une nouvelle norme propre, on nous en pond 3, histoire d'être sûr d'avoir toujours une source d'incompatibilité...)

L'intérêt de l'UTF-16, c'est qu'il est quand même plus facile à manipuler que l'UTF-8, dans 99% des cas tout sera sur des bloc de 16 bits. C'est pour ça que c'est généralement ce qui est employé en interne dans un programme, du moins pour Java et Qt, mais je suppose qu'ils ne sont pas les seuls.
Après pour les fichiers de données, il n'est heureusement presque jamais utilisé.

l'UTF-32 c'est pour les rare cas ou l'UTF-16 ne serait pas suffisant et garantir des bloc de taille fixe.

l'UTF-8 à l'avantage de rester compatible avec l'ASCII, c'est pour ça qu'il est le format recommandé pour les fichiers de données.

Uther (./22) :
c'est généralement ce qui est employé en interne dans un programme, du moins pour Java et Qt, mais je suppose qu'ils ne sont pas les seuls.

PHP 6, aussi, qui est 100% unicode

ouep, et ca ct enfin un bon move de PHP (qui fait donc comme Python)

moué, enfin, c'est pas encore fait... déjà, PHP 5.3 qui pointe le bout de son nez petit à petit...
... et après, seulement, PHP 6...

Et vu comment il y en a toujours qui se traînent du PHP 4 , PHP 6 est encore loin devant pour l'usage grand public.
Si seulement tout le monde faisait comme Fedora... (PHP 4 remplacé par PHP 5 depuis FC4.)

Kevin Kofler (./26) :
Et vu comment il y en a toujours qui se traînent du PHP 4

Kevin Kofler (./26) :
Si seulement tout le monde faisait comme Fedora... (PHP 4 remplacé par PHP 5 depuis FC4.)

On a déjà parlé de ça 36 fois ; Cf les autres posts (genre dans le topic html2pdf, me semble) ; assez de hors-sujet ici...

Kevin Kofler (./26) :
PHP 6 est encore loin devant pour l'usage grand public.

Moué, enfin, PHP6, faudrait déjà que PHP5.3 sorte, et après, que PHP6 avance un peu, puis qu'il sorte, avant de commencer à être adopté ^^

oue enfin; si les devs de php assuraient une certaine compatibilite entre les versions; y'aurait surement plus de personnes avec les dernieres updates etc.

Ca reste a prouver Java a beau avoir une excellente compatibilité, Je suis étonné du nombre de projets restent en version 1.4

[HS] ./29
Dans ma boîte, il y a encore beaucoup de code en Java 1.3, et une partie de mon boulot consiste à migrer tout ça (enfin non, pas tout, mais du moins les classes sur lesquelles je fais des évols) en 1.5 + nettoyage de code + refactoring quand les algos sont vraiment trop crades.
D’un autre côté, le code 1.3 marche très bien sur une JVM 1.5, donc pourquoi s’emmerder à migrer tout le code ?[/HS]