Geckozone

Hi All,

J'ai écris une page HTML en UTF-8 (mixant des caractères latins et arabes). J'ai une balise <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">. Tout ce qu'il faut pour afficher une page en utf-8. Mais quand j'ouvre la page dans un navigateur, elle s'affiche comme si elle était en ascii, et il faut que je choisisse le codage explicitement dans le menu, pour que la page s'affiche normalement (aussi bien avec IE que FireFox)

Ors, je ne veux pas que les visiteur(se)s aient à selectionné l'encodage pour lire la page (cela suppose déjà certaines connaissances, et je veut que mes pages soient accessibles à tous/toutes)

Pourquoi le navigateur ignore t-il le charset déclaré dans http-equiv, et ne reconnais pas non-plus que le fichier est en utf-8 (ce qui devrait être facilement reconnu) ?

Je me suis dit que c'est peut-être le serveur qui renvoie un charset 8859-1 dans l'entête http... (valeur par défaut) mais quand même ça n'explique pas pourquoi le navigateur ignore le http-equiv de la balise meta.

Comment est reconnu http-equiv au juste ? A t-il la priorité sur le charset indiqué dans l'entête http ?

Comment s'assurer qu'une page codée en utf-8, soit bien reconnue comme telle par le navigateur qui la reçoit ?

Quelqu'un(e) a une idée ?

Merci beaucoup

A+

p.s. je ne préfère pas utilisé l'encodage 8859-6, car il n'est pas assez répandu. Je lui préfère donc l'utf-8. And however, le même problème de reconnaissance d'encodage se poserait quand même, s'il s'avère que les pages web sont systèmatiquement considérées comme encodées 8859-1, en toute ignorance de directives qui semblent alors inutiles.

La solution passe par le fichier .htaccess.

Il faut ajouter la directive AddDefaultCharset, avec soit l'argument utf-8, sout l'argument off.

L'argument « Off » indique au serveur de se renseigner sur la page pour renvoyé le bon charset dans l'entête http. C'est donc la solution, la plus souple, la plus universel, et la plus logique.

AddDefaultCharset peut aussi prendre un nom d'encodage en arument « ex. AddDefaultCharset utf-8 ». Cette solution est interessante si toutes les pages du site sont encodées de la même manière. Attention: dans ce cas, le serveur ignore la valeur charset donné dans la balise meta http-equiv du fichier html.

La valeur avec laquelle est configuré AddDefaultChartset sur les serveur Apache, est « On ». Cette option commande au serveur de renvoyer un charset par défaut, qui est presque toujours iso-8859-1. Cela convient dans la plupart des cas, mais reserve de mauvaises surprises (pas trés commode, car le/la visiteur/se doit choisir le charset dans le menu affichage) quand on utilise des caractères non-occidentaux.

Par défaut, les serveur Apache sont configuré avec « AddDefaultCharset On »... mais en toute logique, la configuration par défaut devrait plutôt être « AddDefaultCharset Off », car c'est la seule qui garantie que le charset de l'entête http, et celui de la page html, sont en cohérence.

hibou57 a écrit :Pourquoi le navigateur ignore t-il le charset déclaré dans http-equiv, et ne reconnais pas non-plus que le fichier est en utf-8 (ce qui devrait être facilement reconnu) ?

Comme son nom ne l'indique pas, il ne s'agit pas d'un équivalent, du moins pas en terme de priorité.

hibou57 a écrit :Je me suis dit que c'est peut-être le serveur qui renvoie un charset 8859-1 dans l'entête http... (valeur par défaut)

C'est fort probable.

hibou57 a écrit :mais quand même ça n'explique pas pourquoi le navigateur ignore le http-equiv de la balise meta.

Eh si !

hibou57 a écrit :Comment est reconnu http-equiv au juste ? A t-il la priorité sur le charset indiqué dans l'entête http ?

Comme tu peux le constater, c'est exactement l'inverse

Priorité dans l'ordre :

1. Entêtes HTTP
2. Prologue XML
3. Balises http-equiv

(*)
Pas de chance, ton http-equiv arrive en dernière position et ne sera utilisé que si les entêtes HTTP et le prologue XML ne définissent pas d'encodage (et attention au XML, je ne sais pas exactement comment ça marche, mais si l'encodage n'est pas indiqué dans le prologue c'est de l'utf-8... je ne sais pas si le navigateur irait jusqu'à chercher le meta )

Donc, effectivement, l'entête meta http-equiv est inutile, sauf en cas d'enregistrement en local. Elle sera absente de XHTML 2.0.

Conclusion : attention à vos entêtes HTTP !!!

* cf la spec HTML chapitre 5.2.2 Spécifier l'encodage de caractères

merci beaucoup pour ces précisions, j'ai revu mon fichier htacess suite à cette lecture