Iso-8859-1, iso-8859-15, utf-8, lequel choisir ?

, par  Hamid , popularité : 4%

Que doit-on comprendre ?
L’iso-8859-15 est la "nouvelle version" de l’iso-8859-1. On peut le voir comme ça vu qu’il n’y a pas vraiment de perte (les caractères enlevés ne servaient pas vraiment) mais il s’agit dans les fait d’un nouveau jeu de caractère et pas d’une mise à jour de l’ancien (on a changé de nom, on ne s’est pas contenté de changer quelques caractères et de faire une v2 de l’ancien -1).

Nombreux sont ceux qui continuent d’utiliser l’iso-8859-1, les raisons sont très variées :
 parce que les gens ne connaissent pas ou ne pensent pas au -15 ;
 parce qu’il existe encore des logiciels qui connaissent le -1 mais pas le -15 (compatibilité) ;
 parce que ces gens n’utilisent de toute façon pas les nouveaux caractères (en HTML si c’est juste pour l’euro une entité suffit) ;
 parce que le -1 c’est le codage par défaut sur de nombreux protocoles et pas simplicité on utilise les codages par défaut ;
 parce les personnes n’ont pas fait attention au problème tout simplement ;
 Etc.

Pourquoi même en iso-8859-1, on arrive à afficher le symbole de l’euro ?
 Parce que Windows n’utilise pas vraiment de l’ISO-8859-1, mais un truc à lui (souvent nommé cp1252). Ce truc à lui c’est du -1 avec quelques variantes, dont le caractère euro (mais pas positionné au même endroit que dans le -15). Les navigateurs ont intégré ce biais et savent que souvent quand la personne dit ISO-8859-1, elle veut dire "dans le truc Windows qui dit être de l’ISO-8859-1". Ils reconnaissent donc ces caractères "spéciaux" (qui globalement ne servent de toute façon presque pas normalement) et les affichent comme le veut Windows et pas comme le veut la norme (ou alors passent carrément le rendu en cp1252, suivant les navigateurs).

Pourquoi ne pas tous passer à l’UTF8 ?
L’utf-8 a une bonne réputation (enfin, il se généralise de plus en plus), et l’on dirait qu’il prend de l’importance. Serait-donc "la solution" ? Peut-être, mais ça pose aussi des problèmes pratiques :
- en PHP (par exemple) le résultat d’un bête strlen() sera faussé et pour avoir un résultat cohérent il faudra utiliser le module string qui n’est pas fréquemment présent. Dans bien d’autres langages le problème est le même ;
 en Mysql (toujours par exemple), l’UTF8 n’est pas officiellement supporté avant la version 4.1 qui vient de sortir et qui n’est pas chez les hébergeurs, pour gérer avec les anciennes versions, il faut bidouiller les contraintes de taille ;
 quand on envoie ou on reçoit des données, il faut faire attention que le logiciel ou le serveur en face connaisse la problématique des codages caractères et comprend bien qu’on lui envoie de l’utf8 (ou alors faire une conversion), en ISO-8859-1, on n’a pas ce problème vu que c’est le codage "par défaut" de quasi tous les protocoles réseaux.

Un fichier est obligatoirement dans un "codage", même en ISO-8859-1 : ça signifie que si on fait de l’utf8, il faudra mettre des accents utf8, si on fait de l’ISO-8859-1, il faudra mettre un accent ISO-8859-1. La plupart des éditeurs de code savent passer en Utf8 nativement, ça devrait être transparent de ce côté-là.

Encore une fois, quel encodage choisir ?
 UTF-8 si vous n’avez aucune contrainte technique ;
 ISO-8859-1 sinon et si vous pouvez coder le symbole euro sous forme d’entité ;
 ISO-8859-15 sinon car le support est globalement moins là que pour l’ISO-8859-1 et ce qu’il apporte est très faible.

Nombreux développeurs continuent d’utiliser l’iso-8859-1, pour les raisons suivantes :
 parce que ces développeurs n’utilisent de toute façon pas les nouveaux caractères ;
 parce certains développeurs n’ont pas fait attention au problème ;
 surtout parce que beaucoup de développeurs ne connaissent pas ou ne pensent pas au-15.

L’UTF-8 est vraiment la solution !
On peut tout coder de manière transparente avec UTF-8. Il faut juste que les applications suivent.
Il reste un problème incontournable, quel que soit le système d’encodage :
Avec UTF-8 chaque caractère est codé sur un nombre variable de caractères. De 1 à 4.
Il y a de la place pour tout le monte, mais la question est de savoir qui passe en premier ? Car les langues dont les caractères sont codés sur 3 ou 4 octets verront augmenté l’espèce disque de leur document.

Alors disons le tout de suite. Les mieux placés sont les Américains. Et puis pour des raisons de compatibilité aussi, on a préféré garder le code ASCII en tête, comme ça il passe toujours.

Mais les Asiatiques sont mal placés (3 ou 4 octets) ? Evidement, on ne peut de toute façon pas les coder sur un seul octet.
En revanche, ils utilisent des systèmes de codages optimisés pour eux (J.. Lq chose pour les japonais) qui leur permettent de coder leur langue sur deux octets à coup sûr. Ils peuvent aussi placer toutes les autres langues, mais ce sont les autres qui occupent les emplacements coûteux en octets.

C’est un peu comme la carte du monde. Chaque pays se représente au centre.

Alors les Japonais n’aimeront jamais l’UTF-8 ?
Je parie que si UTF-8 a le succès que l’on peut espérer, les japonais se simplifieront la vie en y passant aussi. Car les échanges internationaux augmentent. En revanche le prix de la mémoire de stockage et du processeur baissent encore.
Leur système à 2 octets ne sera plus qu’une petite économie dérisoire.

En fait, si l’UTF-8 ne code les caractères américains que sur un octet, c’est pour garder une compatibilité avec le système ASCII actuel. Du coup, les agents utilisateurs ne supportant pas l’Unicode affichent les documents avec un minimum de casse, à condition qu’on se limite à certains caractères...


Sources :
 forum.alsacreations.com
 openweb.eu.org/articles/jeux_caracteres