Les problèmes fréquents
Lorsque l'on traîne un peu sur des forums de conception web, on voit très souvent revenir les mêmes questions concernant les « caractères qui s'affichent mal ». Beaucoup de webmasters écrivent leur page et lors de la publication, tous leurs accents sont remplacés par des objets étranges (point d'interrogation, « î », ou autre...).
Bien souvent, les solutions proposées consistent à effectuer 2 ou 3 manipulations dans l'éditeur du webmaster, ou encore à lui faire modifier son code HTML.
Si comme moi vous en avez assez de ces solutions trop directives, que vous souhaitez comprendre réellement d'où vient votre problème et comment le résoudre, alors suivez-moi dans l'exploration des profondeurs du monde des jeux de caractères.
Ce qui ne va pas
Vous êtes en train d'écrire une page web, jusque là vous suivez. Mais comprenez-vous réellement cette chose si naturelle que vous faites tous les jours ? Commençons par résumer vos tâche :
- vous lancez la création d'une nouvelle page dans votre éditeur ;
- vous ajoutez vos balises HTML et votre contenu ;
- vous enregistrez votre fichier ;
- vous publiez votre contenu.
Aïe, et ça ne fonctionne pas, vos accents ont toujours disparu. Et bien contrairement à ce que vous pensez, l'erreur vient en fait de la partie qui vous semble pourtant la plus simple : enregistrer votre fichier.
Cette tâche que vous effectuez depuis des années ne devrait pas être si compliquée, il ne s'agit finalement que d'un peu de texte à sauvegarder sur votre disque dur.
Et voilà, vous faites vous aussi l'erreur la plus monumentale et la plus vieille de l'informatique. Et oui, du texte, ça n'existe pas en informatique.
Revenons aux fondements
La machine que vous utilisez en ce moment n'a aucune notion de texte. Tout ce qu'elle peut comprendre, ce sont les octets. Que cette machine soit un Mac, un PC, sous Windows, Linux, Mac OS X ou autre, cela ne change en rien le fait qu'elle ne sait traiter que des octets.
Cette fameuse tâche d'enregistrer votre fichier ne revient donc pas à sauvegarder un peu de texte sur votre disque dur mais un peu d'octets.
Ah vous voyez où se trouve la difficulté ? Tout à coup, on ne parle plus de la même chose. Le texte, bah c'est du texte, des caractères dont des lettres, des chiffres, de la ponctuation... Les octets, ce sont des nombres. Et plus précisément des nombres dont la valeur peut aller de 0 à 255. Alors il est passé où votre texte ?
Champolion !
Ce grand explorateur arrive à votre rescousse. Vous avez du texte à enregistrer ? Vous ne pouvez enregistrer que des octets ?
Pas de problème, j'ai la solution : la Pierre de Rosette !
Bah oui, quand vous avez 2 langages différents, d'un côté des caractères, de l'autre des nombres, le plus simple est d'utiliser une table de concordance pour traduire de l'un vers l'autre et inversement.
Messieurs, mesdames, veuillez sans plus attendre accueillir sous un tonnerre d'applaudissements la Pierre de Rosette iso-8859-1 et la Pierre de Rosette iso-8859-15 !
Voilà ce qu'est un jeu de caractères. Il s'agit d'une table permettant de faire la traduction d'un caractères vers des octets et inversement.
La pilule rouge
Maintenant vous savez.
À chaque fois que du texte s'affiche sur votre écran, c'est qu'une table de conversion a été utilisée pour obtenir les caractères à partir des octets. À chaque fois que vous enregistrez du texte sur un support informatique, c'est qu'une table de conversion a été utilisée pour obtenir les octets à partir des caractères.
Autant vous dire que si vous n'utilisez pas la même table pour enregistrer et pour afficher, c'est là que les problèmes surviennent. Et c'est pour ça qu'il est fondamental de préciser avec chaque fichier texte la table avec laquelle il a été enregistré.
Sur le web, c'est comment ?
Lorsque vous écrivez une page web, il faut préciser le jeu de caractères de votre page, soit dans les options HTTP envoyés par votre serveur, soit dans votre fichier HTML avec une balise <meta>.
Il vous faudra toujours préciser le jeu de caractères avec lequel vous avez enregistré le fichier dans votre logiciel, et c'est là que les choses peuvent se complexifier.
La notion que vous venez de comprendre sur les jeux de caractères, 80% des dévelopeurs ne la connaissent pas. Et il y a de grandes chances que les auteurs de votre logiciel soit dans cette majorité. Votre logiciel ne permet donc pas de spécifier le jeu de caractères utilisé à l'enregistrement de votre fichier.
Si c'est votre cas, 2 solutions :
- vous êtes sur Windows, et il y a de grandes chances que le jeu de caractères utilisé soit celui par défaut de Windows, c'est à dire windows-1252 très souvent confondu avec iso-8859-1 pour leur similitude ;
- vous n'êtes pas sur Windows et vous ne pouvez pas prévoir réellement le jeu de caractères utilisé, une seule solution alors : changer d'éditeur.
Pour aller plus loin
Les exemples de jeux de caractères que j'ai pris sont simples, car ils associent un caractère avec un octet. Cela les limite forcément à 255 caractères enregistrables (en théorie, en pratique certaines valeurs sont réservées). En utilisant de tels jeux de caractères, vous devrez donc vous limiter au seuls caractères situés dans la table, les autres ne seront pas enregistrables directement dans le fichier (on pourra passer par le système des entités en HTML mais c'est un autre sujet).
D'autres jeux de caractères comme UTF-8 peuvent définir beaucoup plus de caractères en associant un caractère à un nombre variable d'octets, entre 1 et 4. UTF-8 permet par exemple d'enregistrer dans son document tous les caractères définit par le standard Unicode qui liste tous les caractères de cette planète.
Ces jeux de caractères sont plus lourds en taille puisque certaines caractères peuvent faire plus de 1 octet, mais sont forcément plus puissants puisque vous n'aurez plus à passer par le système des entités.
Pour continuer à vivre une vie normale :-)
Vous connaissez enfin la plus vieille et la plus complexe des problématiques du web et de la communication informatique. Je vous conseille de vous documenter sur les différents jeux de caractères (ou charsets en anglais) utilisés aujourd'hui. Et vous devriez alors être à même de comprendre tous les problèmes de jeux de caractères qui pourraient se présenter, et même éventuellement les résoudre ! Quelle merveille !
Et voilà, vous êtes maintenant des pros des jeux de caractères. On dit merci à qui ?
1 De S.F. -
À garder sous le coude, ça me paraît un tantinet plus accessible au néophyte que mon article. J'aime particulièrement l'image de la pierre de rosette !
2 De ghola -
Merci Vincent !
Rappeller que le texte ça ne va pas de soi est l'angle parfait sous lequel il fallait prendre la question, bravo.
Pour ceux qui veulent aller plus loin, je me permets de soumettre ce lien vers un article indispensable de Joel on Software :
http://www.joelonsoftware.com/articles/Unicode.html - The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)
En français : http://french.joelonsoftware.com/Articles/Unicode.html - Le minimum absolu que tout développeur doit absolument, positivement savoir sur Unicode et les jeux de caractères (aucune excuse !)
3 De Florian -
Une explication bien compréhensible. Mais ce que tu dit n'est pas excat. Tu as fait un racourci, et je ne sais pas si c'est volontaire ou pas. Tu as mélangé les jeux de caratères (charset) et les encodages (encoding).
Le jeu de caractères est un ensemble de caractères à représenter. Par exemple: tous les caractères de l'alphabet utilisé en francais, plus quelques signes (copyright, euro, dièse...). Ou alors, l'alphabet russe (et ici aussi quelques signes annexes en plus). Ou encore, tous les idéogrammes chinois. Voir même : tous les caractères connus (le "fameu" jeu de caractère unicode). Mais un jeu de caractère, ça n'est rien de plus que ça: une liste des caratères qu'on souhaite représenter. Un jeu de caractère ne définit pas d'association entre les caractères et les octets.
Pour pouvoir effectivement utiliser un jeu de caractères, il faut ce que les anglais appellent un "encoding", et qui trouve diverses traductions en français, comme "encodage", ou "page de code".
Si on veux reprende l'exemple de champolion, c'est plutôt ça, la pierre de rosette. L'encodage effectue la traduction entre le jeu de caractère et les octets, en associant un nombre à chaque caractère du jeu .
On confond très souvent jeu de caractère et encodage, car dans de nombreux cas, il n'existe qu'un seul encodage pour un jeu de caractère donné, et ils portent malheureusement le meme nom. Ainsi, iso-8859-15 désigne à la fois le jeu de caractères permetant d'écrire les langues d'europes occidentale ET l'encodage utilisé pour traduire ces caractères en octets.
Pourquoi faire la nuance? Tout simplement parce que certains jeux de caractères ont plusieurs encodages possibles. Plusieurs façons de numéroter les mêmes caractères. Ce qu'il est donc important de préciser dans ses pages HTML, et quand on enregistre un fichier texte, c'est l'encodage. Parce que choisir un jeu de caractère seulement, ça dit quels caractères on peu utiliser, mais ca ne dit pas comment les enregistrer. Par contre, choisir un encodage détermine automatiquement quel jeu de caractères on utilise, puisque par définition, un encodage est une manière de numérotter les caractères d'un jeu particulier.
4 De Batmat -
@Florian
Par exemple ? Charset : Unicode Encodings :utf-8, utf-16, etc ?
5 De Batmat -
Vincent, rien à voir avec le billet en cours, mais tu voudrais pas changer le texte du template en dessous de la zone de saisie : .
Tu as dû activer le formatage Wiki, mais tu ne le dis pas. Tu peux reprendre stu veux l'explication que j'utilise, je l'avais récupéré chez Laurent (Jouanneau).
Ah oui, puis des accesskey p et s par exemple sur "prévisualiser" et "envoyer", ça serait super cool :)
6 De Florian -
@ batman:
Oui c'est ca, unicode est un charset, et utf-8, utf-16, etc, sont des encoding. Merci d'avoir rajoute un exmple a mon explication, j'avais oublie.
Une petite remarque en plus, tant qu'on parle d'unicode. Comme ce charset contient tous les caracteres possibles, on peut considerer les autres charsets sont des sous ensembles d'unicode.
Il arrive donc que dans certain systemes, en encodage concu pour unicode (utf-16 par exemple) soit utilise alors qu'on ne s'interesse pas a unicode en entier, mais seulement une sous partie. Je suis par exemple en train de bosser sur un logiciel pour telephone portable au Japon, ou toutes les chaines de caracteres sont en UTF-16 (puisque c'est comme ca que marche java), mais seule la sous partie de unicode correspondant au charset Shift-JIS est affichable, car la police disponible dans le telephone ne contient pas les representations graphiques pour le reste d'unicode.
PS: desole pour le manque d'accents, y en a pas sur le clavier que j'utilise. par contre je peux ecrire comme ca: 日本語の文字 (visible uniquement si vous avez navigateur gerant correctement l encoding utf-8 ET une police couvrant les caracteres japonais)
7 De Normand Lamoureux -
Autre petite précision. HTML 4 ne réfère qu'à qu'un seul jeu de caractères: ISO-10646; et ce jeu correspond, caractère à caractère, à Unicode.
C'est dans la spécification HTML 4.
8 De jeux mobile -
tres bien réalisé, merci pour les infos sur les différents jeux de caractères
9 De François Brutsch -
Euh, oui, très intéressant: on comprend mieux d'où vient le problème! Mais concrètement comment faire dans le détail pour résoudre un problème. P.ex. sur mon blog (UTF-8) j'ai constaté (http://swissroll.info/?2005/07/14/316-comration) que l'envoi d'un billet avec photo par mail depuis un téléphone portable (via Flickr) pose un problème (lettre accentuées remplacées par le losange noir avec point d'interrogation) alors que sur Flickr c'est bon. Paradoxalement, je me souviens l'avoir aussi fait sur un autre blog, lui ISO 8859-1, et là aussi les caractères accentués étaient mal traduits. Y a-t-il une autre solution que l'écriture sans accent et la correction manuelle?
10 De Vincent -
Le seul moyen de résoudre ce problème va être de savoir avec quel encodage est envoyé ce fameux mail. Pour cela, il n'y a pas d'autres solutions que de chercher...
Une fois cet encodage connu, il faudra se demander si les outils utilisés (DotClear, Flickr et le logiciel de mail) font bien des conversions de jeux de caractères et pas de simples modifications de l'encodage déclaré sans aucune modification dans les données.
11 De publicité -
bah il l'a dit, c'est de l'UTF-8, donc avec thunderbird par ex, c'est bon :) Voila ! @++
12 De Classics -
Très intéressant, merci. Je vais essayer d'appliquer tout ça à mon site qui en a grandement besoin... http://www.dynamictic.com
13 De Sonnerie -
Bon article complet. Le "plain text", sans accent ni caractère régional, reste tout de même le plus universel il me semble :)
14 De Classics -
Je ne comprenais pas pourquoi j'avais des problèmes de cet ordre sur mon site. Grâce à toi, c'est réparé. Merci !
15 De Mary -
Ah ben j'ai du boulot (voir mon site).
16 De bjb -
[perso]Merci pour le rétrolien ;-)[/perso] Pour info, votre page n'affiche pas correctement des flux utilisant unicode (voir mon rétrolien).... je pense que c'est un blème de dotclear :(
17 De Vincent -
Il me semble que c'est un bug connu de DotClear. C'est apparemment corrigé dans la prochaine version 2 :)
18 De Caroline -
Au fait, elle sort quand la prochaine version ? (je n'ose pas poser la question sur le forum de dotclear)...
Caroline
19 De Vincent -
Je ne sais pas. Elle sortira quand elle aura un niveau de stabilité suffisant pour les développeurs, en attendant, il reste toujours Dotclear 1 :)
20 De Wintermute -
Ben moi, meme en sachant cela, je n'arrive pas à faire en sorte que les caractères soient correctement interprétés entre un mac OSX 10.4, et un linux mandriva 2006 : - en ssh, depuis le mac jusqu'au serveur linux, les noms des dossiers, les textes des fichiers voient leur caractères accentués transformés en points d'interrogation. - sous eclipse, toujours depuis le mac, sur le linux, même problème avec les fichiers de code, sauf que là on a des caractères ésotériques à la place des points d'interrogation.
Pourtant, le mac est reconnu pour etre par défaut en UTF8, tandis que le serveur linux a lui son /etc/sysconfig/i18n configuré avec LANG="fr_FR@UTF-8"
Alors je ne sais quoi penser... Si quelqu'un peut me venir en aide j'en serais reconnaissant.
21 De Sitges pulsations -
TRès bon article. Merci pour cette explication super simple. Tout est plus clair maintenant.
22 De Ziolrooski -
Très bon article mais pourquoi n'y a t-il pas un tableau avec tous les caractères spéciaux et l'équivalent en html à côté ? Ou au moins les plus utilisés (é, è, ê...)
23 De Batmat -
@Ziolroosky : Parce qu'ils sont inutiles, obsolètes. Si tu spécifies l'encodage de ton fichier, tu peux utiliser tous les accents que tu veux directement.
24 De Kablumy -
@Batmat : Très bonne réponse.
25 De Riton -
hé oui il faut jongler avec les fonctions urlencode, urldecode, utf8 encode et decode , htmlentities etc ... en php pour s 'en sortir ;)
26 De David -
Un conseil purement html: n'oubliez pas d'utiliser htmlentities lorsque vous récuperez des enregistrements d'une table sql comportants des accents, sinon les moteurs de recherche auront peut-être du mal à interpréter les accents (Dans le code html il faut: écrire et pas écrire).
27 De Batmat -
@David. Non. Seuls les moteurs de recherche merdiques auront ce pb. Utiliser les entités html appartient au passé. Ça rend particulièrement illisible le code html. Je n'ai jamais eu le moindre pb à être référencé en utilisant des accents. Tous les moteurs dignent de ce nom parsent de toute façon l'en-tête de la page, récupèrent/chargent le charset utilisé et analysent la page avec le jeu de caractère en question.
Donc, non. Je me répète. Les entités html sont obsolètes et inutilement compliqués à écrire ET à relire. (Je ne parle pas de la fonction htmlentities en php qui permet certes de ne pas avoir à s'en souvenir, mais qui contraint qd même à n'avoir que des pages php et donc jamais pur html).