Mes impressions sur le web, les standards et autres…

Les soucis de l’encodage

Cela faisait déja plusieurs jours voire semaines que je butais sur un problème. Impossible d’envoyer mes pages encodées en UTF-8, cela faisait purement et simplement planter mon navigateur (Firebird, faut le faire quand même). Reprenant mes tests ce matin pour essayer de comprendre, j’ai constaté plusieurs choses au fur et à mesure :

  1. Le fil RSS, pourtant encodé lui aussi en UTF-8 et à l’aide du même mécanisme (script), s’affichait très bien dans Firebird.
  2. Les pages s’affichaient très bien dans Mozilla, Opera 7.22 et IE 6.0 lorsque encodées en UTF-8.
  3. Et pour finir, je constatais que les pages de tests, indépendantes en terme de design du reste du site, s’affichaient très bien quelque soit le navigateur (Firebird compris donc).

À ce niveau là, je me disais que le problème venait des données même de la page et non pas des en-têtes HTTP envoyés par exemple. Et puis vient la lueur de lucidité, je retourne voir ma feuille de style principale pour finalement constater ceci : 

div#menus li.menu > a:after { content: "\00A0»"; }

Et le problème venait évidemment de là. J’insérais un caractère non encodé en UTF-8 (la feuille de style n’étant pas elle-même encodées en UTF-8) et cela a suffi pour faire planter Firebird. Il m’a suffi de remplacer le caractère » par son code ISO 10646 \00BB pour que tout refonctionne, ouf :)

Que se serait-il passé si j’utilisais non pas Firebird mais Mozilla et que mes pages étaient encodées en UTF-8 depuis le début ? Mes pages auraient été inaccessibles aux visiteurs utilisant Firebird, et ceux ci n’auraient pas pu me prévenir même s’ils en prenaient le temps puisqu’ils n’auraient pu obtenir mon adresse email. Au mieux, j’aurais été prévenu par des amis utilisant Firebird ou par des personnes parvenues ici par l’adresse du site donnée dans ma signature sur les newsgroups.

Cet exemple démontre que, malgré l’application stricte des normes en vigueur, il est nécessaire de tester ses pages sous différents navigateurs car il suffit de peu pour les rendre involontairement inaccessibles à une partie des visiteurs.

Vos réactions, opinions, insultes…

Rétroliens

Faire un rétrolien sur ce billet : [trackback]

Commentaires

1. De jmd

En fait, les en-têtes server renvoyés pour la page de style ne déclarent pas d'encodage, puisque pas d'attribute charset dans le Content-Type, pas de :
Content-type: text/css, charset="XXX"
Et sur une feuille de style, pas de META pour fixer la valeur dans le contenu.

En l'absence de valeur explicite, on est un peu dans le flou, réutiliser l'encodage du document principal, considérer que la règle par défaut du HTTP s'applique et que c'est du ISO-8859-1 ?
Il est tout à fait possible que Mozilla et Firebird ait fait deux choix différents sur ce point, d'où un comportement différent même si derrière le moteur d'affichage est le même.

A défaut, le champ link stylesheet aurait pu préciser cet encodage.
Une utilisation astucieuse de .htaccess permet aussi de préciser un encodage à renvoyer par le serveur fichier par fichier, pour ne pas avoir besoin de le fixer globalement en modifiant Content-Type pour toutes les feuilles de style.
Ca s'applique aussi aux pages HTML dès lors que l'on souhaite fixer leur encodage par les champs serveurs et plus par un META.

Mais si on en reste aux feuille de style, la situation est suffisament compliquée et l'interprétation du coté du navigateur aléatoire, pour préferrer effectivement utiliser des entitées pour tout ce qui n'est pas US-ASCII pur, de façon à se libérer de toute erreur d'encodage.

2. De Bobe

Je viens de faire le test. Et pour Mozilla comme pour Firebird, lorsque j'appelle par exemple l'URL :http://webnaute.net/Styles/Basic, c'est le jeu de caractère windows-1252 qui est utilisé (système windows, détection automatique de l'encodage activé).

Je suis d'accord avec toi qu'il vaut mieux s'en tenir aux caractères us-ascii et c'est généralement naturellement le cas car la plupart du temps, l'utilisation des feuilles de style est relativement basique, mais dés qu'on utilise les sélecteurs :before et :after en conjonction avec la propriété content, le problème peut se poser.
On dispose comme tu l'as énoncé de plusieurs possibilités pour indiquer l'encodage d'une feuille de style, autant en profiter :)

Sinon, on peut aussi la règle-at @charset mais j'ai constaté des problèmes au niveau du rendu avec opera lorsque j'avais fait le test.

3. De Bobe

Bon, pour finir, j’ai choisi l’option de plus haut niveau.

J’ai ajouté la ligne AddCharset ISO-8859-15 .css dans mon fichier .htaccess.
Cette solution est préférable car il est probable que certains navigateurs ne tiennent pas compte de l’attribut charset et je ne veux pas prendre de risque.

Par contre, j’ai un gros souci avec la fonction utf8_encode() de PHP. Apparamment, elle n’encode pas tous les caractères. J’ai dù effectuer des str_replace() par derrière pour obtenir le bon encodage pour notamment les guillemets français, les e dans l’o (œ Œ) et le caractère €.
Si quelqu’un a déja été confronté ce problème… (version de php du serveur est 4.3.4)

4. De Bobe

Ah, je pense que ça vient du fait que la fonction utf8_encode() encode en utf-8 à partir d’une chaine en iso-8859-1 (ça explique pourquoi € œ et Œ sont pas encodés mais pas pour le guillemet français). Même problème avec l’extension iconv :/

Je fais comment du coup pour encoder proprement mes chaines de caractères sans que certains caractères soient boudés ?

5. De S. F. • Site

Une bêtise peut-être, mais css permet de définir le charset via la directive @charset "utf-8" (par exemple). Reste à voir si celle-ci est bien gérée par les différents navigateurs…

L’ajout de commentaires sur ce billet n’est pas/plus autorisé.