ISO 8859-1

La norme ISO 8859-1, dont le nom complet est ISO/CEI 8859-1, et qui est souvent appelée Latin-1 ou Europe occidentale, forme la première partie de la norme internationale ISO/CEI 8859, qui est une norme de l'Organisation internationale de normalisation pour le codage des caractères en informatique.
Elle définit ce qu'elle appelle l'alphabet latin numéro 1, qui consiste en 191 caractères de l'alphabet latin, chacun d'entre eux étant codé par un octet (soit 8 bits). ISO 8859-1 reprend le codage des caractères imprimables d'US-ASCII.

Dans les pays occidentaux, cette norme est utilisée par de nombreux systèmes d’exploitation, dont UNIX, Windows ou AmigaOS. Elle a donné lieu à quelques extensions et adaptations, dont Windows-1252 et ISO 8859-15. La distinction entre ASCII, ISO 8859-1, ISO 8859-15, Windows-1252 et MacRoman est une source de confusion parmi les développeurs de programmes informatiques. Le Multinational Character Set créé par Digital Equipment Corporation pour le terminal informatique VT220 est considéré comme à la fois l'ancêtre de l'ISO 8859-1 et de l'Unicode^[1].

Principe

En première approximation, le jeu de caractères codés sur 8 bits de la norme ISO/CEI 8859-1 est une extension le jeu de caractères codés sur 7 bits de la norme américaine US-ASCII (qui est une des variantes de la norme de base ISO 646). Cependant ce codage normalisé au plan mondial par l’ISO et CEI n’assigne aucun caractère de contrôle ni aucun autre caractère dans les positions réservées des plages 0x00 à 0x1F et 0x7F à 0x9F.

Il ajoute de nombreux caractères latins manquant dans l’alphabet latin de base défini dans l’US-ASCII (ce qui a permis de déprécier ou rendre obsolètes de nombreuses variantes nationales de la norme ISO 646), ainsi que quelques autres signes de ponctuation ou symboles, ce qui lui permet de recouvrir les caractères nécessaires à l’écriture de nombreuses langues, pour nombre d’entre elles des langues d’Europe occidentale, avec parmi elles des langues nationales officielles comme l’albanais, l’allemand, l’anglais, le danois, l’espagnol, le finnois (sauf les lettres « š » et « Š »), le français (sauf les lettres « œ », « Œ », et « Ÿ »), l’islandais (sauf les signes de ponctuation „ et “), le gaélique irlandais, l’italien, le latin liturgique (sans les diacritiques du latin moderne), le luxembourgeois, le néerlandais, le norvégien, le portugais, le romanche, le suédois, et encore de nombreuses autres langues régionales ou minoritaires comme le basque, le bas-saxon, le breton, le catalan, le corse, le féringien, le gallo, le gaélique écossais, le galicien, l’occitan, le picard, le rromani moderne, le sarde, le vénitien, ou le wallon. Des langues d’autres régions du monde sont également couvertes comme l’afrikaans, l’indonésien, le malais, le swahili, le malgache, ou le wolof, ainsi que la plupart des créoles et pidgins qui se sont développés en grande partie sur les bases des langues précédentes, tels que le bichelamar, le capverdien, le créole haïtien, le filipino (souvent improprement appelé tagalog) ou le mauricien.

Cette norme est donc utilisée sur tous les continents, en Europe de l’Ouest, en Amérique, et dans une grande partie de l'Afrique ou de l’Océanie ainsi que certains pays d’Asie du Sud-Est.

Cependant il ignore quelques caractères européens comme le symbole de l’euro € (qui n’existait pas encore lorsque ce jeu a été normalisé) ou certaines des lettres normalement nécessaires à certaines langues théoriquement couvertes (comme les lettres « œ », « Œ » et « Ÿ » en français, ou les lettres « š » et « Š » en finnois) : le jeu de caractères universel des normes ISO/CEI 10646 et Unicode (ou plus rarement le jeu de caractères codés ISO 8859-15) permet de pallier ces absences. Les lettres françaises œ et Œ n'ont pas été incluses dans ISO/CEI 8859-1 car les principaux représentants francophones dans le groupe de travail (GT) n’ont pas estimé cela nécessaire : l'un estimait qu'il s'agissait d'une simple ligature typographique (à tort, bien qu’il n’existe aucune possibilité de confusion avec les lettres non ligaturées dans l’orthographe française), et l’autre était employé par un grand fabricant d’imprimantes qui ne les avait pas inclus dans ses imprimantes^[2].

La plupart des 191 caractères codés dans la norme ISO/CEI 8859-1 sont représentés sous forme de glyphes (œil) dans le tableau suivant, à l’exception de trois d’entre eux (décrits après la table). Les titres des lignes et des colonnes indiquent les valeurs hexadécimales correspondant aux positions codées assignées à chaque caractère, par exemple, la valeur hexadécimale de la position codée assignée à la lettre « L » est 0x4C, soit 01001100 en binaire ou 76 en décimal.

Dans cette table :

• la position 0x20 en hexadécimal (32 en décimal) est assignée au caractère de l’« espace » (elle est souvent représentée par SP, de space en anglais),
• la position 0xA0 en hexadécimal (160 en décimal) est assignée au caractère de l'espace insécable (elle est souvent représentée par NBSP, de no-break space en anglais),
• la position 0xAD en hexadécimal (173 en décimal) est assignée au caractère de formatage indiquant la position d’une possible coupure de mot : il reste normalement invisible lorsqu’il est inséré au milieu d’un mot mais il n’apparaît comme un tiret de coupure de mot que si un saut de ligne est réalisé à cette position ; le tiret est alors accolé après le début du mot coupé et sur la même ligne (il est souvent représenté par SHY, de soft hyphen en anglais).
• Les positions 0x00 à 0x1F en hexadécimal (0 à 31 en décimal) et 0x7F à 0x9F en hexadécimal (127 à 159 en décimal) ne sont assignées à aucun caractère dans le codage normalisé ISO/CEI 8859-1 (leur utilisation éventuelle et leur interprétation dépend des applications).

ISO/CEI 8859-1 par rapport à ISO-8859-1

L’IANA en anglais : Internet Assigned Numbers Authority a validé, pour une utilisation sur Internet, le codage ISO-8859-1 (remarquez le tiret supplémentaire), un sur-ensemble de l'ISO/CEI 8859-1.

Ce jeu de caractères codés, ou page de codes, supplée le jeu de caractère codé ISO/CEI 8859-1 en assignant des caractères de contrôle aux positions hexadécimales des plages 0x00 à 0x1F, et 0x7F à 0x9F. On obtient de cette manière 256 caractères recouvrant toutes les positions possibles codées sur 8 bits.

L’IANA autorise l’utilisation des alias enregistrés suivants pour ISO-8859-1 (la casse mentionnée peut être changée librement car elle n’est pas significative) :

• ISO_8859-1:1987
• ISO_8859-1
• ISO-8859-1
• iso-ir-100
• csISOLatin1
• latin1
• l1
• IBM819
• CP819

Le nom Latin-1 est une appellation informelle non reconnue par les organismes de normalisation ISO, CEI ou IANA, mais utilisée par certains logiciels.

Le tableau suivant montre l’ISO-8859-1, avec les abréviations représentant les caractères de contrôle et les espaces.

Il existe d’autres parties de la norme ISO/CEI 8859 à laquelle correspond un jeu de caractères codé validé par l’IANA, par exemple l’ISO/CEI 8859-10 (alphabet latin n^o 6) ressemble fortement au jeu de caractères codés ISO-8859-10.

Chacune des parties de la norme ISO/CEI 8859 définit un jeu de caractères codés sur 8 bits de la même manière : elle assigne les caractères graphiques codés sur 7 bits de la norme ISO 646 (dans sa version américaine ASCII la plus courante) aux positions codées dans la plage hexadécimale 0x20 à 0x7E, ainsi que 96 caractères supplémentaires aux positions codées dans la plage hexadécimale de 0xA0 à 0xFF, pour un total de 191 caractères codés.

L’IANA définit les jeux de caractères codés « ISO-8859-x » selon la partie correspondante de la norme ISO/CEI 8859, en assignant en plus tous les caractères de contrôle « C0 » de la norme ISO 646 aux positions de la plage hexadécimale 0x00 à 0x1F et à la position hexadécimale 0x7F, ainsi que des caractères de contrôle « C1 » supplémentaires aux positions de la plage hexadécimale de 0x7F à 0x9F, offrant ainsi un ensemble de 256 caractères codés.

Le jeu de caractères codés ISO-8859-1 est le seul, parmi tous ces ensembles de jeu de caractères codés, dont la codification sur 8 bits soit équivalente aux 256 premiers caractères codés du jeu universel de caractères, défini dans les normes ISO/CEI 10646 et Unicode.

Jeux de caractères codés apparentés

Windows-1252

Dans la page de codes n^o 1252 définie et utilisée dans Microsoft Windows, quelques caractères ont été assignés aux positions codées dans la plage hexadécimale 0x80 à 0x9F. Cette extension remplace ou annule tous les caractères de contrôle C1 qui sont assignés à ces positions dans le jeu de caractères codés ISO-8859-1 et réservés dans la norme ISO/CEI 8859-1.

Cette page de codes est enregistrée dans la base de données des jeux de caractères codés de l’IANA, pour son usage dans les logiciels et sur Internet, sous le nom Windows-1252.

ISOLatin1Encoding

PostScript prédéfinit une variante de ISO/CEI 8859-1, appelée improprement ISOLatin1Encoding^[3], dans laquelle le caractère codé en position 140 (0x8C en hexadécimal) est l’apostrophe gauche ( ‘ ), au lieu de l’accent grave ( ` ).

Cet encodage n’assigne aucun caractère de contrôle C0 ou C1 dans les positions 0x00 à 0x1F et 0x7F à 0x8F. Cependant, il définit certains caractères supplémentaires dans les positions inutilisées entre 0x90 et 0x9F (mais d’une façon différente de la variante Windows-1252) :

• à la position 0x90, la lettre minuscule i sans point ( ı ) ;
• aux positions 0x91 à 0x98, l’accent grave ( ` ), l’accent aigu ( ´ ), l’accent circonflexe ( ˆ ), le tilde en chef ( ˜ ), le macron ( ¯ ), la brève inversée ( ˘ ), le point en chef ( ˙ ) et le tréma ou signe de diérèse ( ¨ ) ;
• aux positions 0x9B et 0x9C, le rond en chef ( ˚ ) et la cédille ( ¸ ) ;
• aux positions 0x9D à 0x9F, le double accent aigu ( ˝ ), l’ogonek ( ˛ ) et le caron ( ˇ ).

Tous les diacritiques y sont codés avec leur chasse dans les polices PostScript Type 1 ou Type 3 (leur combinaison ou positionnement relatif avec une lettre de base étant à la charge du logiciel de composition du document PostScript), cependant les polices TrueType ou OpenType encodées avec Unicode (et utilisables dans certains interprètes PostScript) réutilisent souvent les mêmes glyphes pour définir les diacritiques combinants sans chasse.

ISO 8859-15

L'ISO 8859-15, notamment introduite pour prendre en charge le caractère € de l'euro, gère également mieux le français car les caractères ¤, ¦, ¨, ´, ¸, ¼, ½ et ¾ ont été remplacés par €, Š, š, Ž, ž, Œ, œ et Ÿ. En français, l'ISO 8859-1 reste cependant nettement plus utilisée, avec OE et oe au lieu de Œ et œ, alors que le Ÿ n'est utilisé que par quelques noms propres. Le standard Unicode est généralement utilisé lorsqu'il est nécessaire de dépasser les limites de ISO 8859-1, notamment, symboles mathématiques, phonétiques et caractères non-latins.

MacRoman

Les ordinateurs Apple Macintosh les plus anciens utilisent un codage nommé MacRoman, qui diffère de l'ISO 8859-1 de par les 32 premiers et 127 derniers caractères, mais inclut tout de même tous les caractères présents dans l'ISO 8859-1, à l'exception du tiret invisible. En revanche, le MacRoman inclut de nombreux caractères qui ne sont pas dans l'ISO 8859-1. Le glyphe Euro a remplacé le symbole monétaire générique précédent.

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 ambigüe 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 <meta http-equiv="content-Type" content="text/html; charset=iso-8859-1" /> 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 <?xml version="1.0" encoding="iso-8859-1"?> 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 à tort) 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).

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 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).

Notes et références

Voir aussi

Liens externes

• (en) Version finale du standard ISO/IEC 8859-1:1998 [PDF]
• (en) Différences entre les caractères ANSI, ISO-8859-1 et MacRoman
• (en) The Letter Database
• La série de normes ISO 8859

Articles connexes

• Windows-1252
• MacRoman
• ISO 8859-15
• ISO 8859 ; blocs de caractères Unicode contenant des caractères codés dans au moins une de ses 16 parties :
  • pour ISO 8859-1 :
    • Latin de base
    • Supplément latin-1
  • pour les autres parties :
    • Latin étendu - A
    • Latin étendu - B
    • Diacritiques combinants
    • Grec et copte
    • Cyrillique
    • Hébreu
    • Arabe
    • Thaï
    • Symboles monétaires

v · Unicode
Jeux de caractères	UCS (ISO/CEI 10646) · ISO 646, ASCII · ISO 8859-1 · WGL4 · UniHan
Équivalences normalisées	NFC (précomposée) · NFD (décomposée) · NFKC (compatibilité) · NFKD (compatibilité)
Propriétés et algorithmes	ISO 15924 · Casse · Ordonnancement UCA · Texte bidirectionnel · BOM
Codage	UTF-7 · UTF-8 · CESU-8 · UTF-EBCDIC · BOCU-1 · SCSU · UTF-16 · UTF-32
Autres transformations	Punycode · GB 18030
Applications d’échanges de données	Courriel et Unicode · Unicode et HTML

v · Unicode			ISO/CEI 10646, Table des caractères Unicode, UTF-8, UTF-16, UTF-32, UTF-EBCDIC, CESU-8, BOCU-1
Autres	ISO/CEI 2022, Big5, ISCII, GB 18030, GBK, Shift-JIS, Codage des caractères chinois

Codés sur 8 bits

ISO/CEI 8859	ISO/CEI 8859-1 (latin-1), ISO/CEI 8859-3 (latin-3), ISO/CEI 8859-15 (latin-9)
Pages de code Windows	Windows-1252 (latin-1), Windows-1258 (vietnamien)
Pages de code MacOS	MacRoman
Pages de code DOS	CP437 (latin-US), CP850 (latin-1), CP852 (latin-2)
Pages de code diverses	DEC-MCS, KOI8-R (russe), KOI8-U (ukrainien), StandardEncoding (PostScript)
Non basés sur ISO 646	VISCII, EBCDIC, EBCDIC 297, EBCDIC 8859

Autres

Codés sur 7 bits	ASCII, ISO 646
Moins de 7 bits	Code morse, Code wabun, Code Baudot, RADIX-50, Sixbit

Articles connexes Codage des caractères, Clavier d’ordinateur, Police numérique, Glyphe, Portail:Écriture

• Portail de l’informatique
• Portail de l’écriture