Dans le HTML

[ Accueil ] [ l'Ecriture ] [ Le code ASCII ] [ Autres astuces ] [ Dans le HTML ] [ MIME ]

Les pieds dans la toile

Bien que pour HTTP, protocole apte à transmettre des flux d'octets sans considérer que ce sont forcément des caractères, bon nombre de problèmes sont à résoudre.

Le langage HTML (Hyper Text Markup Language), lui aussi, propose des méthodes particulières pour traiter les caractères non US-ASCII. Il règne d'ailleurs dans ce domaine la plus grande confusion.

Avec la version 3.2 du HTML, il n'y avait normalement pas d'autre possibilité que de passer par un transcodage du type "signes nommés". Depuis le version 4.0 de HTML, il est théoriquement possible de définir dans l'en-tête du document quel jeu de caractères est utilisé.

Comme HTML est probablement le lieu où les normes sont le moins respectées, il convient tout de même de rester prudent...

Les signes nommés

Le principe est simple :

• Un caractère d'échappement : Le &,
• un nom pour le caractère non US-ASCII
• un délimiteur de fin de codage : le ;

Un simple exemple, juste pour illustrer. Le é devrait se coder dans le source HTML : é

Vous trouverez beaucoup plus de détails sur les signes nommés ainsi que sur beaucoup d'autres points du HTML sur le très instructif site SELFHTML.

Il existe une table de signes nommés définie dans HTML 3.2 . HTML 4.0 définit des ajouts à cette table, bien que, théoriquement, une balise d'en-tête du type :

<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">

devrait à elle seule permettre l'emploi de tous les symboles définis par iso-8859-1 (version 4.0 uniquement).

Une manipulation amusante

FrontPage 2000, l'éditeur HTML de Microsoft (celui avec lequel ces pages sont faites), ne s'embarrasse pas de considérations complexes, annonce un charset=windows-1252 (volontairement modifié manuellement dans cette page en iso-8859-1) dans ses en-têtes et ne code aucun de ces symboles de façon particulière, même pas l'euro.
Il serait pertinent de penser que cette façon cavalière de procéder va créer des problèmes sur toute plateforme autre que Windows/Internet Explorer...
Dans la pratique, ça fonctionne sans le moindre problème avec Mozilla 1.1, aussi bien sous Windows que sous Linux, ça fonctionne aussi avec Konqueror 3.0.3 sous Linux. Il ne faut tout de même pas trop en demander, ça ne fonctionne pas pour l' euro avec Netscape 4.78 sous Linux, qui affiche à la place un ? .

D'autres éditeurs, comme DreamWeaver (de Macromedia) ou Golive (d' Adobe) sont plus orthodoxes et, non seulement annonceront un "charset=iso-8869-1", mais encore utiliseront les signes nommés pour les caractères non US.

L'exemple qui suit est "bricolé" directement dans le source HTML. La même ligne sera codée selon diverses façons :

é è ç ù à ê € (sans codage)

é è ç ù à ê €

é è ç ù à ê €

Normalement, il y a de grandes chances que vous voyez tout ça correctement. Maintenant, si vous utilisez Internet Explorer, allez dans "Affichage", puis "Codage" et changez le codage par défaut. Là, vous risquez de voir les limites de FrontPage qui n'utilise pas systématiquement les signes nommés, même si en théorie, HTML 4.0 devrait le permettre. Ceux qui n'utilisent pas IE doivent avoir quelque part une fonction équivalente, pour changer l'affichage par défaut.

Notez la curieuse façon de coder le symbole de l'euro par Golive 5 : € . C'est tout simplement sa valeur numérique, en hexadécimal, dans la normalisation unicode (16 bits)...

Que penser de tout ça ?

Il serait possible de pousser encore plus loin les investigations, et de supprimer dans l'en-tête de chaque page la définition du "charset" , ça ne changerait très probablement rien au résultat final.

Conclusions

Si vous n'avez pas encore attrapé le vertige, vous ne l'attraperez plus. Sinon, essayons de consolider un peu nos positions.

Les faits

• Les systèmes numériques ne savent traiter que des informations binaires, donc numériques.
• Les protocoles applicatifs, le plus souvent, ont besoin de transporter du texte.
• Le texte est destiné à être lu, donc écrit, et  n'est pas constitué d'une collection de valeurs numériques, mais d'une collection de symboles graphiques : Un alphabet
• Il n'y a pas qu'un seul alphabet au monde.
• Les protocoles applicatifs peuvent avoir aussi à échanger des données qui ne sont pas du texte (une image, du son, une vidéo...).

Les solutions

• Coder sur 7 bits un jeu de caractères minimal (US-ASCII), mais il n'y a pas que l'américain dans le monde, et 128 valeurs ne suffisent pas pour des langues riches en lettres accentuées.
• Coder sur 8 bits, mais ça ne suffit pas non plus pour toutes les langues possibles.
• Coder sur 16 bits, mais ça alourdit considérablement la taille des données. De plus, l'unité courante de transport est l'octet (8 bits), ça ne simplifie pas.

Le bricolage

Le "bricolage" le plus propre consiste à utiliser un jeu de caractères minimal et de coder les caractères supplémentaires par une combinaison identifiable des caractères de base. C'est cette solution qui est le plus souvent mise en oeuvre, et elle donne finalement les meilleurs résultats.

• Codage "quoted-printable" (e-mails, imprimantes...)
• Codage "Base64" (e-mails, fichiers pouvant contenir autre chose que du texte pur...)
• Signes nommés (HTML)