Man page - charsets(7)

Packages contains this manual

Available languages:

en fr es it ja ro zh_TW zh_CN de

Manual

charsets

NOM
DESCRIPTION
ASCII
ISO/IEC 8859
KOI8-R et KOI8-U
GB 2312
Big5
JIS X 0208
KS X 1001
ISO/IEC 2022 et ISO/IEC 4873
TIS-620
Unicode
VOIR AUSSI
TRADUCTION

NOM

charsets - Normes de jeux de caractĂšres et internationalisation

DESCRIPTION

Cette page de manuel prĂ©sente diffĂ©rentes normes de jeux de caractĂšres et la façon de les utiliser sous Linux avant qu’Unicode ne devienne ubiquitaire. Certains de ces renseignements sont encore utiles aux personnes travaillant avec des systĂšmes ou des documents anciens.

ASCII, GB 2312, ISO/IEC 8859, JIS, KOI8-R, KS et Unicode font partie des normes présentées.

Un accent particulier est mis sur les jeux de caractĂšres qui Ă©taient vĂ©ritablement utilisĂ©s dans les paramĂštres rĂ©gionaux, et non sur la myriade de jeux de caractĂšres provenant d’autres systĂšmes.

ASCII

L’ASCII (American Standard Code For Information Interchange) est le jeu de caractĂšres 7 bits original, prĂ©vu pour l’anglais (amĂ©ricain). Il est aussi connu sous le nom US-ASCII. Il est dĂ©crit actuellement dans la norme ISO/IEC 646:1991 IRV (International Reference Version).

DiffĂ©rentes variantes d’ASCII sont apparues, remplaçant le dollar par d’autres symboles monĂ©taires et la ponctuation par des caractĂšres accentuĂ©s pour couvrir l’allemand, le français, l’espagnol et d’autres langues en 7 bits. Elles sont toutes obsolĂštes, la glibc ne gĂšre que les paramĂštres rĂ©gionaux dont le jeu de caractĂšres est un sur-ensemble d’ASCII.

Comme Unicode, lors de l’utilisation d’UTF-8, est compatible avec ASCII, le texte en simple ASCII est toujours rendu correctement sur les systùmes modernes utilisant l’UTF-8.

ISO/IEC 8859

L’ISO/IEC 8859 est une sĂ©rie de 15 jeux de caractĂšres 8 bits contenant l’ASCII dans leur premiĂšre moitiĂ© (7 bits), des caractĂšres de contrĂŽle non imprimables entre les positions 128 et 159, et 96 symboles graphiques de largeur fixe aux emplacements 160 à 255.

De tous ces jeux, le plus important est l’ISO/IEC 8859-1 (« alphabet latin nÂș 1 », latin-1). Il Ă©tait massivement adoptĂ© et pris en charge par diffĂ©rents systĂšmes et est remplacĂ© au fur et Ă  mesure par Unicode. Les caractĂšres d’ISO/IEC 8859-1 sont aussi les premiers 256 caractĂšresd’Unicode.

La prise en charge en console des autres jeux de caractÚres ISO/IEC 8859 est disponible sous Linux, à travers des utilitaires comme setfont (8), qui modifient la correspondance des touches du clavier, la table graphique EGA et utilisent une projection personnalisée de la table de fonte du gestionnaire de console.

Voici une brÚve description des jeux de caractÚres 8859 :
ISO/IEC 8859-1 (Latin-1)

Le latin-1 couvre de nombreuses langues d’Europe, comme l’albanais, l’anglais, le basque, le danois, l’espagnol, le fĂ©roĂŻen, le galicien, le gallois, l’irlandais, l’islandais, l’italien, le norvĂ©gien, le portugais et le suĂ©dois. L’absences de ligatures « ÄČ » et « ij » du nĂ©erlandais et « Ɠ » du français, ainsi que l’absence des guillemets „allemands“ Ă©taient considĂ©rĂ©es tolĂ©rables.

ISO/IEC 8859-2 (Latin-2)

Le latin-2 prend en charge de nombreuses langues d’Europe centrale et de l’Est utilisant l’alphabet latin comme l’allemand, le bosniaque, le croate, le hongrois, le polonais, le slovaque, le slovĂšne et le tchĂšque. Remplacer les « ș » et « ț » roumains par Â«Â ĆŸÂ Â» et « ƣ » Ă©tait considĂ©rĂ© tolĂ©rable.

ISO/IEC 8859-3 (Latin-3)

Le latin-3 Ă©tait conçu pour couvrir l’espĂ©ranto, le gallois, le maltais et le turc, mais ISO/IEC 8859-9 l’a ensuite supplantĂ© pour le turc.

ISO/IEC 8859-4 (Latin-4)

Le latin-4 a introduit des lettres pour les langues de l’Europe du Nord comme l’estonien, le letton et le lituanien, mais il a Ă©tĂ© supplantĂ© par ISO/IEC 8859-10 et ISO/IEC 8859-13.

ISO/IEC 8859-5

Alphabet cyrillique prenant en charge le bulgare, le biĂ©lorusse, le macĂ©donien, le russe, le serbe et (presque complĂštement) l’ukrainien. Il n’a jamais Ă©tĂ© beaucoup utilisĂ©, consultez les remarques concernant KOI8-R et KOI-U ci-dessous.

ISO/IEC 8859-6

Avait Ă©tĂ© créé pour l’arabe. La table ISO/IEC 8859-6 est une fonte de largeur fixe de formes de lettre distinctes, mais un affichage correct doit combiner les lettres en utilisant leurs formes initiale, centrale et finale.

ISO/IEC 8859-7

Avait été créé pour le grec moderne en 1987 et mis à jour en 2003.

ISO/IEC 8859-8

Prend en charge l’hĂ©breu moderne sans diacritiques (signes de ponctuation). Les diacritiques et l’hĂ©breu biblique dans son ensemble Ă©taient en dehors de la portĂ©e de ce jeu de caractĂšres.

ISO/IEC 8859-9 (Latin-5)

Il s’agit d’une variante du latin-1 qui remplace les lettres islandaises rarement utilisĂ©es par des lettres turques.

ISO/IEC 8859-10 (Latin-6)

Le latin-6 ajoutait les lettres inuit (Groënland) et same (lapon) qui manquaient au latin-4 pour couvrir toute la zone nordique.

ISO/IEC 8859-11

Prend en charge l’alphabet thaï et est presque identique à la norme TIS-620.

ISO/IEC 8859-12

Ce jeu de caractùres n’existe pas.

ISO/IEC 8859-13 (Latin-7)

Prend en charge les langues des pays baltes, en particulier les caractĂšres lituaniens absents du latin-4.

ISO/IEC 8859-14 (Latin-8)

Jeu de caractĂšres celtique, couvrant le breton, le cornique, le gaĂ©lique, le gallois, l’irlandais ancien et le mannois.

ISO/IEC 8859-15 (Latin-9)

Le latin-9 est similaire au latin-1 largement utilisé mais remplace les symboles les moins communs par le symbole euro et les lettres françaises et finlandaises qui manquaient au latin-1.

ISO/IEC 8859-16 (Latin-10)

Ce jeu de caractùres couvre de nombreuses langues d’Europe du Sud-Est et, ce qui est plus important, prend mieux en charge le roumain que le latin-2.

KOI8-R et KOI8-U

Le KOI8-R est un jeu de caractĂšres non ISO trĂšs rĂ©pandu en Russie avant Unicode. La premiĂšre moitiĂ© correspond Ă  l’ASCII, la seconde est un jeu de caractĂšres cyrilliques un peu mieux conçu que l’ISO/IEC 8859-5. Le KOI8-U, basĂ© sur le KOI8-R, a une meilleure prise en charge de l’ukrainien. Aucun de ces jeux n’est compatible avec l’ISO/IEC 2022, contrairement aux normes ISO/IEC ISO-8859.

La prise en charge du KOI8-R en console est disponible sous Linux, Ă  l’aide d’utilitaires en mode utilisateur qui modifient la correspondance des touches du clavier, la table graphique EGA et utilisent une projection personnalisĂ©e de la table de fonte du gestionnaire de console.

GB 2312

GB 2312 est le principal jeu de caractĂšres normalisĂ© en Chine, utilisĂ© pour exprimer le chinois simplifiĂ©. Comme avec le JIS X 0208, les caractĂšres sont projetĂ©s dans une matrice 94x94 sur deux octets pour construire l’EUC-CN. Celui-ci est l’encodage le plus important sous Linux et inclut l’ASCII et le GB 2312. Remarquez que l’EUC-CN est souvent appelĂ© GB, GB 2312 ou CN-GB.

Big5

Big5 Ă©tait un jeu de caractĂšres populaire Ă  TaĂŻwan pour exprimer le chinois traditionnel (Big5 est Ă  la fois un jeu de caractĂšres et un encodage). C’est un sur-ensemble de l’ASCII. Les caractĂšres non ASCII sont exprimĂ©s sur deux octets. Les octets 0xA1-0xFE sont utilisĂ©s en prĂ©ambule pour les caractĂšres de deux octets. Le Big5 et son extension Ă©taient largement utilisĂ©s Ă  TaĂŻwan et Hong Kong. Il n’est pas compatible ISO/IEC 2022.

JIS X 0208

JIS X 0208 est un jeu de caractĂšres normalisĂ© au Japon. Bien qu’il y ait plusieurs jeux de caractĂšres normalisĂ©s au Japon, (comme JIS X 0201, JIS X 0212 et JIS X 0213), celui-ci est le plus important. Les caractĂšres sont projetĂ©s dans une matrice 94x94 de deux octets, dont chaque octet est dans l’intervalle 0x21-0x7E. Remarquez que JIS X 0208 est un jeu de caractĂšres, pas un encodage. Cela signifie que JIS X 0208 lui-mĂȘme n’est pas utilisĂ© pour exprimer des donnĂ©es de texte. Il est utilisĂ© comme composant pour construire un encodage comme EUC-JP, Shift_JIS et ISO/IEC 2022-JP. EUC-JP est le plus important encodage sous Linux et inclut l’ASCII et le JIS X 0208. Dans l’EUC-JP, les caractĂšres du JIS X 0208 sont exprimĂ©s sur deux octets, chacun Ă©tant le code JIS X 0208 plus 0x80.

KS X 1001

KS X 1001 est un jeu de caractĂšres normalisĂ© en CorĂ©e. Comme dans le JIS X 0208, les caractĂšres sont projetĂ©s dans une matrice 94x94 sur deux octets. KS X 1001 est utilisĂ©, comme le JIS X 0208, comme composant pour construire un encodage comme le EUC-KR, Johab, et ISO/IEC 2022-KR. EUC-KR est l’encodage le plus important sous Linux et inclut l’ASCII et le KS X 1001. KS C 5601 est un ancien nom pour le KS X 1001.

ISO/IEC 2022 et ISO/IEC 4873

Les normes ISO/IEC 2022 et ISO/IEC 4873 décrivent un modÚle de contrÎle des fontes basé sur le fonctionnement du VT100. Ce modÚle est (partiellement) pris en charge par le noyau Linux et xterm (1). Plusieurs encodages de caractÚres basés sur ISO/IEC 2022 ont été définis, en particulier pour le japonais.

Il existe 4 jeux de caractĂšres graphiques, nommĂ©s G0, G1, G2 et G3, l’un d’entre eux est utilisĂ© comme jeu de caractĂšres en cours pour les codes avec le bit de poids fort Ă  0 (par dĂ©faut G0), et un autre est utilisĂ© pour les codes avec le bit de poids fort Ă  1 (initialement G1). Chaque ensemble dispose de 94 ou 96 caractĂšres, et est constituĂ© de caractĂšres sur 7 bits. Ce modĂšle utilise soit les codes 040-0177 (041-0176), soit les codes 0240-0377 (0241-0376). G0 a toujours une taille de 94 caractĂšres et utilise les codes 041-0176.

Le basculement entre les jeux de caractĂšres est effectuĂ© Ă  travers les suites ˆN (SO ou LS1), ˆO (SI ou LS0), ESC n (LS2), ESC o (LS3), ESC N (SS2), ESC O (SS3), ESC  (LS1R), ESC } (LS2R), ESC | (LS3R). La fonction LS n rĂ©clame le jeu G n pour les codes dont le bit de poids fort est Ă  zĂ©ro. La fonction S n demande le jeu G n pour les codes dont le bit de poids fort est Ă  un. La fonction SS n rĂ©clame le jeu G n ( n =2 ou 3) pour le caractĂšre suivant uniquement (quelle que soit la valeur du bit de poids fort).

Un jeu de 94 caractĂšres est dĂ©signĂ© comme jeu G n par une suite ESC ( xx (pour G0), ESC ) xx (pour G1), ESC * xx (pour G2), ESC + xx (pour G3), oĂč xx est un symbole ou une paire de symboles de la norme ISO/IEC 2375 International Register of Coded Character Sets. Par exemple, ESC ( @ sĂ©lectionne le jeu de caractĂšre ISO/IEC 646 en tant que G0, ESC ( A sĂ©lectionne le jeu normalisĂ© au Royaume-Uni (avec la livre sterling Ă  la place du diĂšse), ESC ( B sĂ©lectionne l’ASCII, ESC ( M sĂ©lectionne un jeu de caractĂšres africain, ESC ( ! A sĂ©lectionne les caractĂšres cubains, etc.

Un jeu de 96 caractĂšres est dĂ©signĂ© comme jeu G n par une suite ESC - xx (pour G1), ESC . xx (pour G2) ou ESC / xx (pour G3). Par exemple, ESC - G sĂ©lectionne l’alphabet hĂ©breu comme G1.

Un jeu de caractĂšres multioctets est dĂ©signĂ© comme jeu G n par une suite ESC $ xx ou ESC $ ( xx (pour G0), ESC $ ) xx (pour G1), ESC $ * xx (pour G2), ESC $ + xx (pour G3). Par exemple, ESC $ ( C sĂ©lectionne les caractĂšres corĂ©ens pour le jeu G0. Le jeu de caractĂšres japonais sĂ©lectionnĂ© par ESC $ B dispose d’une version plus rĂ©cente sĂ©lectionnĂ©e par ESC & @ ESC $ B.

L’ISO/IEC 4873 rĂ©clame une utilisation prĂ©cise des jeux de caractĂšres, dans laquelle G0 est fixĂ© (toujours l’ASCII), ainsi seuls G1, G2 et G3 peuvent ĂȘtre invoquĂ©s pour les codes avec un bit de poids fort à 1. En particulier, ˆN et ˆO ne sont plus utilisĂ©s, ESC ( xx peut seulement ĂȘtre utilisĂ© avec xx=B, et ESC ) xx, ESC * xx, ESC + xx sont Ă©quivalents Ă  ESC - xx, ESC . xx, ESC / xx, respectivement.

TIS-620

Le TIS-620 est un jeu de caractĂšre normalisĂ© en ThaĂŻlande, et est un sur-ensemble de l’ASCII. De la mĂȘme façon que la sĂ©rie des ISO/IEC 8859, les caractĂšres thaĂŻs sont projetĂ©s dans l’intervalle 0xA1-0xFE.

Unicode

L’Unicode (ISO/IEC 10646) est une norme destinĂ©e Ă  reprĂ©senter sans ambiguĂŻtĂ© tous les signes Ă©crits de toutes les langues humaines connues. La structure de l’Unicode offre 21 bits pour chaque caractĂšre. Comme les ordinateurs n’ont pas d’entiers avec 21 bits, Unicode est habituellement codĂ© en interne sur 32 bits, ou par des sĂ©ries d’entiers 16 bits (UTF-16) (ne nĂ©cessitant deux entiers 16 bits que pour des caractĂšres rares) ou par une sĂ©rie d’octets 8 bits (UTF-8).

Linux reprĂ©sente l’Unicode en utilisant le format de transfert sur 8 bits (UTF-8). L’UTF-8 est un encodage Ă  longueur variable. Il utilise un octet pour coder 7 bits, 2 octets pour 11 bits, 3 octets pour 16 bits, 4 octets pour 21 bits, 5 octets pour 26 bits, 6 octets pour 31 bits.

ReprĂ©sentons par 0, 1 ou x des bits Ă  0, 1 ou quelconque. Un octet 0xxxxxxx correspond Ă  l’Unicode 00000000 0xxxxxxx qui indique le mĂȘme symbole que l’ASCII 0xxxxxxx. Ainsi, ASCII n’est pas modifiĂ© par UTF-8, et les gens utilisant uniquement l’ASCII ne remarqueront aucun changement : ni dans l’encodage, ni dans les tailles de fichiers.

Un octet 110xxxxx reprĂ©sente le dĂ©but d’un code sur 2 octets, et 110xxxxx 10yyyyyy est assemblĂ© en 00000xxx xxyyyyyy. Un octet 1110xxxx correspond au dĂ©but d’un code sur 3 octets, et 1110xxxx 10yyyyyy 10zzzzzz sont assemblĂ©s en xxxxyyyy yyzzzzzz. Quand l’UTF-8 est utilisĂ© pour encoder les 31 bits de l’ISO/IEC 10646 cette progression continue jusqu’à des codes sur 6 octets.

Pour la plupart des textes en ISO/IEC 8859, cela signifie que les caractĂšres en dehors de l’ASCII sont dĂ©sormais encodĂ©s sur deux octets. Cela tend Ă  allonger la taille des fichiers textes ordinaires de un Ă  deux pourcents. Pour le russe ou le grec, la taille des fichiers textes ordinaires est gĂ©nĂ©ralement doublĂ©e, car la plupart des caractĂšres sont en dehors de l’ASCII. Pour les utilisateurs japonais, cela signifie que les codes sur 16 bits couramment employĂ©s prendront dĂ©sormais 3 octets. Des conversions algorithmiques sont possibles depuis certains jeux de caractĂšres (en particulier ISO/IEC 8859-1) vers l’Unicode, mais une conversion gĂ©nĂ©rique nĂ©cessite l’utilisation de tables de conversion pouvant ĂȘtre assez larges pour des codes sur 16 bits.

Remarquez que l’UTF-8 se synchronise automatiquement : 10xxxxxx est la fin d’un code, et tout autre octet est un dĂ©but de code. Notez Ă©galement que les octets ASCII dans un flux UTF-8 ne peuvent que reprĂ©senter les caractĂšres ASCII correspondants. En particulier il n’y a pas d’octet NULL (« \0 ») ou « / » faisant partie d’un code plus grand.

Comme l’ASCII, et, en particulier, l’octet NULL et « / », ne sont modifiĂ©s, le noyau ne remarque pas que l’UTF-8 est utilisĂ©. Il n’a pas Ă  se prĂ©occuper de la signification des octets qu’il manipule.

La gestion des flux de donnĂ©es Unicode est gĂ©nĂ©ralement effectuĂ©e Ă  travers des tables de « sous-fontes » correspondant Ă  un sous-ensemble des caractĂšres Unicode. En interne, le noyau utilise l’Unicode pour dĂ©crire les sous-fontes chargĂ©es en mĂ©moire vidĂ©o. Cela signifie que pour une console Linux en mode UTF-8, un jeu de caractĂšres avec 512 symboles diffĂ©rents peut ĂȘtre utilisĂ©. Ce n’est pas assez pour le japonais, le chinois ou le corĂ©en, mais c’est gĂ©nĂ©ralement suffisant pour toutes les autres utilisations.

VOIR AUSSI

iconv (1), ascii (7), iso_8859-1 (7), unicode (7), utf-8 (7)

TRADUCTION

La traduction française de cette page de manuel a été créée par Christophe Blaess <https://www.blaess.fr/christophe/>, Stéphan Rafin <stephan.rafin@laposte.net>, Thierry Vignaud <tvignaud@mandriva.com>, François Micaux, Alain Portal <aportal@univ-montp2.fr>, Jean-Philippe Guérard <fevrier@tigreraye.org>, Jean-Luc Coulon (f5ibh) <jean-luc.coulon@wanadoo.fr>, Julien Cristau <jcristau@debian.org>, Thomas Huriaux <thomas.huriaux@gmail.com>, Nicolas François <nicolas.francois@centraliens.net>, Florentin Duneau <fduneau@gmail.com>, Simon Paillard <simon.paillard@resel.enst-bretagne.fr>, Denis Barbier <barbier@debian.org>, David Prévot <david@tilapin.org> et Grégoire Scano <gregoire.scano@malloc.fr>

Cette traduction est une documentation libre ; veuillez vous reporter à la GNU General Public License version 3 concernant les conditions de copie et de distribution. Il n’y a aucune RESPONSABILITÉ LÉGALE.

Si vous découvrez un bogue dans la traduction de cette page de manuel, veuillez envoyer un message à debian-l10n-french@lists.debian.org .