ISO 8859-1 - Définition

Solutions aux limitations du jeu de caractères

La meilleure solution est alors d’utiliser un jeu de caractères codés dit « universel », capable de coder un répertoire très étendu de caractères compatible avec tous les alphabets, notamment celui défini dans les normes ISO/CEI 10646 et Unicode. Un tel jeu universel nécessitera que de très nombreux caractères soient codés individuellement sur plusieurs octets.

Cependant, même avec ce seul jeu de caractères universel ISO/CEI/Unicode, il existe différentes représentations binaires dont l’interprétation peut être très différente si la représentation effective est mal déterminée, un problème qui peut aussi conduire à des interprétations incorrectes mais qui peut se résoudre en intégrant là encore une méta-donnée sur cette représentation, notamment une marque d’ordonnancement (byte order mark en anglais, souvent abrégé BOM) représentée par le caractère codé U+FEFF, placé en tête du document uniquement dans le but de déterminer la représentation binaire utilisée, mais qui ne représente alors lui-même aucun caractère codé significatif dans le document.

Pour ces raisons, le jeu de caractères codés ISO-8859-1 et son sous-ensemble US-ASCII codé sur 7 bits restent encore très répandus lorsque les textes à coder ne nécessitent qu'un alphabet simple. Cependant, seul le second (US-ASCII) est totalement compatible (dans son codage comme dans son interprétation) avec la représentation binaire UTF-8 normalisée pour le jeu de caractères universel ISO/CEI/Unicode.

Le jeu universel des normes ISO/CEI/Unicode n’est pas le seul (même si c’est aujourd’hui celui qui est le plus répandu et le mieux supporté partout dans le monde sur de très nombreux logiciels, car il demandé aujourd'hui pour tous les nouveaux protocoles de l’Internet approuvés par l'IETF, et approuvé par la plupart des organismes de normalisation nationaux ou privés) : d’autres jeux universels ont été normalisés notamment en Asie orientale (tel que GB18030 en Chine, qui est également totalement compatible avec US-ASCII mais qui a l’avantage de n’avoir qu’une seule représentation binaire et ne nécessite donc aucune inclusion d’un caractère BOM).

Limitations

La principale limitation de ce jeu de caractères codés sur un octet est la nécessité d'utiliser plusieurs jeux de caractères codés pour couvrir plusieurs alphabets.

Certains documents sont typés à l'aide de méta-données externes et non dans le document lui-même ; dans ce cas un jeu de caractères codés et un seul est associé à chaque document. Par exemple dans les protocoles de transport de données HTTP ou MIME, c’est l’entête Content-Type: qui indique le jeu de caractères utilisés dans le document transporté. Et dans ce cas on mentionnera explicitement l’entête Content-Type: ISO 8859-1 afin de permettre au destinataire d’interpréter le contenu du document transporté, y compris via un transcodage préalable vers le jeu de caractères codés qu’il reconnait ou peut afficher.

Si cette méta-donnée n’est pas précisée, le document stocké ou transporté n’a pas lui même de jeu de caractères codés clairement défini et il devrait être traité et transporté uniquement de façon opaque, ce qui n’était pas toujours le cas (par exemple dans les protocoles de transports de courrier électronique comme SMTP, même si le protocole ESMTP a été créé comme une extension qui intègre le protocole de transport MIME et est aujourd’hui largement utilisé pour éviter toute altération du contenu binaire de tels documents).

Cependant, même si le protocole de transport ou de stockage du document permet de préserve le codage du document, l’interprétation et l’affichage du document reste ambigue en absence de cette méta-données. C’est pourquoi certains types de documents permettent de mentionner explicitement le jeu de caractères avec lesquels ils sont codés directement dans leur contenu. Cette information sera fiable à la seule condition que le document ne subisse aucun transcodage et soit traité de façon opaque (ce qui sera le cas dans un système de fichiers stockant les documents sous forme de fichiers binaires), et que cette indication intégrée au document soit elle-même correcte.

Par exemple dans un document HTML, la balise permet de mentionner que le document a été créé en utilisant le jeu de caractères codés ISO-8859-1. Dans un document XML, la déclaration présente au début du document permet de préciser de la même façon que le jeu de caractères codés utilisé pour créer le document est bien ISO-8859-1.

Malheureusement, même si le protocole de transport mentionne le jeu de caractères utilisé, cette méta-donnée essentielle peut être perdue par le destinataire lors de son stockage, et il ne reste alors plus que le document opaque. D’autre part, même le créateur du document peut aussi créer une copie du document en omettant aussi de copier ses métadonnées et transmettre ce fichier en omettant de préciser le codage ou en le stockant dans un système de fichiers (y compris un serveur internet) dont les documents sont, par défaut, supposés être codés dans un autre jeu de caractères, soit parce que le système de stockage ou le serveur est mal réglé, soit encore parce que ce système ne permet pas de stocker cette information. Le document sera donc délivré à son destinataire avec une méta-donnée erronée qui ne correspond pas au codage utilisé lors de la création du document. Le système de stockage ou le serveur devrait être capable de déterminer automatiquement le jeu de caractères utilisé à partir du type de document et de son balisage interne mentionnant explicitement le jeu de caractères utilisé, au lieu de fournir une information erronée au destinataire (mais de nombreux serveurs omettent de le faire, car ils supposent que celui qui a stocké le document a aussi renseigné correctement la métadonnée à délivrer avec le document.

À défaut de la méta-donnée provenant du protocole de transport ou de stockage du document, et d’une déclaration explicite intégrée au document, c’est le logiciel utilisé par le destinataire du document qui tentera éventuellement de déterminer le jeu de caractères codés utilisé, en analysant sont contenu. S’il ne le fait pas, le logiciel pourra supposer (éventuellement à tord) que le document utilise un jeu de caractères codés par défaut, propre à ce logiciel ou à ses réglages applicable par défaut à tous les documents qui n’intègrent pas la méta-donnée et tous ceux qui leur sont transmis sans méta-donnée associée.

Malheureusement dans ce cas, le jeu de caractères codés utilisé par défaut par le logiciel du destinataire peut être différent de celui utilisé dans le logiciel utilisé par le créateur du document initial (par exemple sur un autre système ou avec un logiciel différent). L’interprétation du document sera incohérente, et pourra produire ce que les Japonais appellent du « mojibake », qui résulte de l’utilisation du document dans un contexte différent, ou du mélange de données provenant de documents multiples, initialement créés dans des jeux de caractères codés différents mais incorrectement supposés comme identiques.

Le problème est alors l’impossibilité de mélanger dans un même document des alphabets qui ne sont pas définis dans le même jeu de caractères codés (par exemple les alphabets français et hébreu).