Des jeux de caractères plutôt que des caractères individuels
Nous attendrons Unicode pour donner un sens technique précis au mot "caractère".Pour l'instant (en ce début du cours n° 3) le caractère est pour nous une abstraction
reliant deux réalités concrètes : les octets (cours n°1) et les polices (cours n°2)
- Côté lecture (du fichier vers
l'écran ou vers l'imprimante) :
- les octets (concrets) sont d'abord interprétés pour donner des caractères (abstraits),
- et les caractères sont affichés
selon une certaine police (en l'absence de police,
pas d'affichage !).
Soulignons que dans cette affaire le caractère n'existe que transitoirement,
comme intermédiaire de calcul entre les deux entités concrètes et durables que sont
les octets sur le disque et la forme dessinée sur l'écran. -
Côté écriture (de l'utilisateur vers le fichier) :
- on écrit toujours un caractère (même en
calligraphie !). Quel caractère ?
Ce caractère est choisi dans un système de caractères répertorié.
Ce choix s'exerce par une désignation symbolique, il n'implique pas la présence réelle d'objets concrets.
Comment communiquer son choix à l'ordinateur ?- Par clavier (l'écho visuel est commode mais non nécessaire)
- Par désignation graphique (palette - ce qui suppose la présence d'une police)
- Par interaction (méthodes pour les caractères chinois)
- Par nomination (n° unicode ou autre)
- Ce choix est converti en octets,
qui vont d'abord dans le buffer de l'éditeur employé,
ensuite (lors de l'opération de sauvegarde Save) et le plus souvent avec un autre codage,
dans le fichier sur le disque.
- on écrit toujours un caractère (même en
calligraphie !). Quel caractère ?
- Comment s'opèrent l'interprétation
octets --> caractère et la conversion
caractère --> octets ?
Le jeu de caractères est précisément ce qui définit cette traduction.
Alors qu'Unicode nous permettra de n'envisager qu'un seul jeu (universel) de caractères,
chaque codage sur 8 bits au contraire définit un jeu de caractères différent,
ce qui est source d'une kyrielle d'ennuis.
Exemple :- Les octets dans le fichier
- Choix d'un jeu de caractères pour interpréter ces octets (avec l'éditeur TextWrangler)
- Le résultat : ya erreur !
- Les octets dans le fichier
Idée générale des codages sur 8 bits
-
Principe :
Exploiter à fond la correspondance octet <--> caractère.
Elle est tellement commode ! Les langages de programmation manipulent aisément les octets,
donc ils manipulent du même coup les caractères !
Difficile de renoncer à cette facilité...
En outre, depuis que le bit de parité a perdu son emploi, le code ASCII laisse 128 octets disponibles.
C'est bien assez pour satisfaire (presque) tous les besoins !
Oui, mais en spécifiant bien qu'on ne satisfait qu'un client à la fois...
Il est d'ailleurs intéressant de noter que l'idée d'utiliser des codes peu fréquents pour offrir un peu de variation
était déjà apparue dans le cadre du codage à 7 bits : dea variantes nationales (française, allemande, danoise..)
ont été normalisées dans les différents pays concernés (NF Z 62-010 en France, DIN 66003 en Allemagne)
et regroupées dans le norme ISO-646. On peut voir cette norme comme l'ancêtre de l'ISO-10646
qui est l'exact parallèle d'Unicode dans le cadre de l'International Standards Organization.
Voyez sur ce point la page (déjà ancienne) de Roman Czyborra.
-
Prolifération multidimensionnelle :
- dans le temps (évolution d'un même système, p. ex. de DOS à Windows),
- dans l'espace (à travers le monde : de l'Europe à l'Asie)
- et suivant les constructeurs (Apple & Macintosh, Microsoft & PC, les différents Linux).
Illustration : où se trouve le réglage du jeu de caractères dans différents logiciels qui traitent des textes ?
Voyez la longue liste des choix que votre logiciel vous propose...
- Safari (navigateur) : Présentation
-> Encodage du texte
- Firefox (navigateur) : Affichage
-> Encodage des caractères
- Netscape Composer (éditeur HTML)
: View -> Character Encoding
- Textedit (éditeur en mode texte)
: le choix apparaît au moment de l'enregistrement
Fichier -> Enregistrer sous..., et la liste qui apparaît peut être étendue
- TextWrangler (éditeur de
programmes), idem, File -> Save As
et le choix du codage fait partie des Options (où apparaît aussi celui des sauts de ligne !)
ce choix étant réglable dans les Preferences (Text Encodings)
- etc.
- Safari (navigateur) : Présentation
-> Encodage du texte
-
Exemples
- La table des premiers PC (avant Windows) : CP437
l'écran alphanumérique ne permettait pas de faire des dessins, pour pallier cette insuffisance la table CP437 contenait un maximum de caractères "graphiques", tout en restant compatible avec l'ASCII.
La figure ci-dessous vient du site de Roman Czyborra.
- La table Windows 1252 de
Microsoft, dont les caractères graphiques ont disparu en raison de
l'adoption des écrans bitmap.
Une partie de cette table a été normalisée comme ISO-8859-1, alias Latin-1, et joue encore un rôle pivot - voir plus loin.
La table ci-dessous est recopiée de Wikipédia (français). Les cases jaunes sont celles qui diffèrent de Latin-1.
Windows-1252 (CP1252)
x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF 0x NUL SOH STX ETX EOT ENQ ACK BEL BS HT LF VT FF CR SO SI 1x DLE DC1 DC2 DC3 DC4 NAK SYN ETB CAN EM SUB ESC FS GS RS US 2x SP ! " # $ % & ' ( ) * + , - . / 3x 0 1 2 3 4 5 6 7 8 9 : ; < = > ? 4x @ A B C D E F G H I J K L M N O 5x P Q R S T U V W X Y Z [ \ ] ^ _ 6x ` a b c d e f g h i j k l m n o 7x p q r s t u v w x y z { | } ~ DEL 8x €
‚ ƒ „ … † ‡ ˆ ‰ Š ‹ Œ
Ž
9x
‘ ’ “ ” • – — ˜ ™ š › œ
ž Ÿ Ax NBSP ¡ ¢ £ ¤ ¥ ¦ § ¨ © ª « ¬
® ¯ Bx ° ± ² ³ ´ µ ¶ · ¸ ¹ º » ¼ ½ ¾ ¿ Cx À Á Â Ã Ä Å Æ Ç È É Ê Ë Ì Í Î Ï Dx Ð Ñ Ò Ó Ô Õ Ö × Ø Ù Ú Û Ü Ý Þ ß Ex à á â ã ä å æ ç è é ê ë ì í î ï Fx ð ñ ò ó ô õ ö ÷ ø ù ú û ü ý þ ÿ
- La table MacRoman d'Apple,
symbole de
l'incompatibilité entre PC et Mac.
La table ci-dessous est recopiée de Wikipédia (français). Les cases jaunes sont celles qui diffèrent de Latin-1.
MacRoman
x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF 0x TAB LF CR 1x 2x SP ! " # $ % & ' ( ) * + , - . / 3x 0 1 2 3 4 5 6 7 8 9 : ; < = > ? 4x @ A B C D E F G H I J K L M N O 5x P Q R S T U V W X Y Z [ \ ] ^ _ 6x ` a b c d e f g h i j k l m n o 7x p q r s t u v w x y z { | } ~ 8x Ä Å Ç É Ñ Ö Ü á à â ä ã å ç é è 9x ê ë í ì î ï ñ ó ò ô ö õ ú ù û ü Ax † ° ¢ £ § • ¶ ß ® © ™ ´ ¨ ≠ Æ Ø Bx ∞ ± ≤ ≥ ¥ µ ∂ ∑ ∏ π ∫ ª º Ω æ ø Cx ¿ ¡ ¬ √ ƒ ≈ ∆ « » … NBSP À Ã Õ Œ œ Dx – — “ ” ‘ ’ ÷ ◊ ÿ Ÿ ⁄ € ‹ › fi fl Ex ‡ · ‚ „ ‰ Â Ê Á Ë È Í Î Ï Ì Ó Ô Fx Ò Ú Û Ù ı ˆ ˜ ¯ ˘ ˙ ˚ ¸ ˝ ˛ ˇ
Voici, à titre d'exemple, ce que donne la ligne :
Ça, c'était mon frère René (à gauche, près de la fenêtre) et ça c'était ma sœur Iñès.
- enregistrée en Windows-1252 et lue en MacRoman
- enregistrée en MacRoman et lue
en Windows-1252
- enregistrée en Windows-1252 et lue en MacRoman
- La table des premiers PC (avant Windows) : CP437
La série de codes ISO-8859
-
Lire la documentation
La famille de codes normalisée sous le nom d'ISO-8859 est bien documentée. Je ne reproduirai donc pas ici sa liste exhaustive.
Je vous recommande le site de Roman Czyborra pour ses savoureux commentaires.
Le site Alis vous donnera les mêmes tables. Mais il faut savoir les lire...
Distinguons les codepages, qui associent un caractère (pas nécessairement imprimable)
à chacun des 256 octets (voir les exemples précédents), et les tables issues de la norme ISO-8859 :
- cette norme ne régit que les 96 octets de la plage
A0-FF, en considérant que
- la plage 20-7E est consacrée aux caractères ASCII
imprimables
(i.e. autres que les caractères de contrôle et le n° 127 : DEL)
- la plages initiale 0-1F est occupée par les caractères de contrôle traditionnels
- la plage intermédiaire 7F-8F contient différents
caractères ad libitum.
ISO/CEI 8859-1
x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF 0x inutilisés 1x 2x
! " # $ % & ' ( ) * + , - . / 3x 0 1 2 3 4 5 6 7 8 9 : ; < = > ? 4x @ A B C D E F G H I J K L M N O 5x P Q R S T U V W X Y Z [ \ ] ^ _ 6x ` a b c d e f g h i j k l m n o 7x p q r s t u v w x y z { | } ~
8x inutilisés 9x Ax
¡ ¢ £ ¤ ¥ ¦ § ¨ © ª « ¬
® ¯ Bx ° ± ² ³ ´ µ ¶ · ¸ ¹ º » ¼ ½ ¾ ¿ Cx À Á Â Ã Ä Å Æ Ç È É Ê Ë Ì Í Î Ï Dx Ð Ñ Ò Ó Ô Õ Ö × Ø Ù Ú Û Ü Ý Þ ß Ex à á â ã ä å æ ç è é ê ë ì í î ï Fx ð ñ ò ó ô õ ö ÷ ø ù ú û ü ý þ ÿ
Il s'ensuit que la documentation relative aux jeux de caractères normalisés ne fournit que les caractères de la plageA0-FF,
les autres étant soit standard (ASCII) soit non réglementés.
Voici par exemple comment la table ISO-8859-1 est présentée chez Roman Czyborra :
Voir Wikipedia pour un traitement complet de la série.
Pour une présentation comparative très élaborée des principales tables,
adressez-vous à http://www.miakinen.net/vrac/charsets/.
- cette norme ne régit que les 96 octets de la plage
A0-FF, en considérant que
-
Le rôle particulier d'ISO-8859-1, alias Latin 1
Ce jeu de caractères a pris le succession de l'ASCII comme option par défaut dans la première génération d'Internet.
Les serveurs Apache, par exemple, contiennent une directive imposant ISO-8859-1 comme defaultcharset.
Il faut désactiver cette directive, car elle a une autorité supérieure aux indications fournies dans les pages Web elles-mêmes,
et par conséquent elle limite fortement l'ouverture à l'international !
À titre anecdotique, voici un extrait du fichier de configuration standard d'Apache 2.2.3 :
# Specify a default charset for all pages sent out. This is
# always a good idea and opens the door for future internationalisation
# of your web site, should you ever want it. Specifying it as
# a default does little harm; as the standard dictates that a page
# is in iso-8859-1 (latin1) unless specified otherwise i.e. you
# are merely stating the obvious. There are also some security
# reasons in browsers, related to javascript and URL parsing
# which encourage you to always set a default char set.
#AddDefaultCharset ISO-8859-1
# JMD 2003/09/15 Change to off, since it overrides the META tags
AddDefaultCharset Off
En outre, il a été repris tel quel dans le deuxième bloc d'Unicode (sous le nom de Supplement-Latin-1),
et au sein d'Unicode il est caractérisé comme formé des caractères dont le n° Unicode tient dans un octet
(i.e. ne dépasse pas 255).
Ayez donc sa table à portée de la main, car si une page s'affiche mal, la première hypothèse à essayer est que
- soit la page est en Latin-1 et l'interprète ne le
sait pas,
- soit la page n'est pas en Latin-1, mais elle ne l'a
pas dit, et l'interprète croit qu'elle est en Latin-1.
et Wikipedia (allemand) pour une discussion du rôle dominant du codage Latin-1.
- soit la page est en Latin-1 et l'interprète ne le
sait pas,
-
Latins autres
voici un échantillon des extensions nécessaires pour orthographier correctement les noms de nos concitoyens :
- Avec ISO-8859-1 :
Franz-Josef Strauß (homme politique bavarois : avec -ß et non -ss)
AP Møller-Mærsk (armateur danois, avec -ø-, pas -o-, et -æ-, pas -ae-,
même si en italiques -æ- ressemble beaucup à -œ- : regardez bien -æ-, -œ-)
Hans Christian Ørsted (avec Ø-, pas Œ-, encore moins Oe-)
Luís de Camões (l'auteur des Lusiades,
dont l'orthographe ancienne pose des problèmes techniques...)
Le roi Håkon de Norvège se rend en visite à Århus (on écrivait autrefois Haakon, Aarhus)
- Avec ISO-8859-2 :
Antonín Dvořák (en tchèque, les accents notent la longueur des voyelles,
et le -ř- désigne une consonne spécifique)
Karel Čapek (l'inventeur du mot "robot" : avec Č-, pas C-)
Lech Wałęsa (de Solidarność : avec -ł- , pas -l-, et -ę- nasalisé, pas -e- )
Czesław Miłosz (prix Nobel de littérature : idem)
Tadeusz Kościuszko (révolutionnaire polonais : -śc- et non -sc-)
Jaroslav Hašek (le père du "bon soldat Chveïk" = Dobrý voják Švejk)
Jan Černý (un collègue slovaque)
Sandor Petőfi (poète - le hongrois distingue -ő- long et -ö- bref)
Constantin Brâncuși (sculpteur roumain)
Alexandru Șunǎ (étudiant roumain autrefois en thèse au LIP6)
Nicolae Tonița (peintre roumain)
Ștefan cel Mare și Sfânt (Étienne III le grand, prince de Moldavie)
- Avec ISO-8859-3 ou 9 :
Asuman Doğaç (une collègue turque : Doğaç et pas Dogac)
Nazım Hikmet (le turc distingue soigneusement -i- avec point et -ı- sans point)
- Mais pour écrire correctement
Marc Bœgner (éminent protestant français : avec -œ- et non -oe-)
il faut ISO-8859-15 ! En effet, le "e dans l'o" ne figure pas dans ISO-8859-1,
pour des raisons mal élucidées.
En revanche, on donnera satisfaction àEugène Ysaÿe (musicien belge : avec le tréma sur -y-)
avec ISO-8859-1, car cette table possède le "y tréma" !
- Avec ISO-8859-1 :
-
Le grec et le cyrillique
- ISO-8859-5
pour le cyrillique (commentaires chez
Alis)
- ISO-8859-7
pour le grec (monotonique : l'écriture du grec moderne, pas celle du
grec ancien).
Elle a pour rivales différentes normes promulguées par le comité de normalisation du gouvernement soviétique
(GOST, acronyme de Государственный стандарт СССР), connues sous le nom générique de KOI8
(pour Код Обмена Информацией, 8 бит).
Ces codes sont fondés sur un procédé original, consistant à ranger les lettres cyrilliques dans un ordre
qui permet de translittérer en ASCII par simple suppression du bit de poids fort.
Voyez l'article de Wikipedia (plus détaillé en anglais) sur la version russe KOI8-R,
et le détail de l'histoire raconté par Roman Czyborra.
En Grèce, au contraire, la norme ISO-8859-5 est très utilisée. C'est normal puisqu'elle suit celle qui a été élaborée
par l'Organisation hellénique de normalisation ELOT (Ελληνικός Οργανισμός Τυποποίησης).
L'ordre dans lequel elle énumère les caractères se retrouve inchangé (y compris les lacunes) en Unicode
dans le bloc Greek & Coptic : à suivre au cours n° 4. - ISO-8859-5
pour le cyrillique (commentaires chez
Alis)
-
L'arabe et l'hébreu
- ISO-8859-6 pour l'arabe (formes isolées des lettres, sans les lettres supplémentaires du persan et de l'ourdou)
- ISO-8859-8
pour l'hébreu (les consonnes seulement, sans les marques de voyelles).
Les cinq formes finales particulières sont intégrées dans la norme comme des lettres à part entière.
Il en va tout autrement pour l'arabe, où chaque lettre peut prendre quatre formes différentes
et où les règles de liaison sont contraignantes.
Nous y reviendrons quand nous analyserons comment Unicode spécifie ces règles.
Systèmes extrême-orientaux
Nous avons vu, avec le cas du cyrillique, l'apparition de systèmes échappant à la tentative d'unification de l'ISO,sous l'impulsion de gouvernements soucieux de garder le contrôle de leur territoire...
-
Les systèmes indiens.
Les écritures indiennes sont des alphasyllabaires ou abugida. Elles dérivent toutes d'une même origine, la brahmi,
et elles conservent largement une structure commune. Cette constatation a fait naître l'idée d'un codage
tel qu'une seule information assurerait automatiquement la translittération d'un système à l'autre.
Cette possibilité est manifeste, par exemple, entre les écritures devanâgari et gujarâti, mais beaucoup moins pour d'autres,
de sorte que cette belle idée est en vérité illusoire.
Elle est à la base du code ISCII (Indian Script Code for Information Interchange), où les 128 octets non-ASCII
codent un jeu de caractères "abstrait", plus un caractère spécial qui permet de savoir quelle est la forme à utiliser
(devanâgari, gujarâti, bengali, gurmukhi, etc) jusqu'à nouvel ordre.
Ce système, soutenu par le gouvernement indien, est aujourd'hui dans une large mesure supplanté par Unicode.
Nous verrons avec Unicode des délicats problèmes que pose la typographie dans ces écritures.
La communauté tamoule, qui s'est lancée dans un grand projet d'édition électronique de sa littérature classique,
s'est munie pour ce faire de son propre système TSCII (Tamil Script Code for Information Interchange).
Ici aussi, Unicode se répand.
-
Les caractères chinois et leurs dérivés.
Ici, on sort radicalement de la portée des tables à 8 bits. On entre aussi dans un domaine où les rivalités
culturelles et politiques ont fortement marqué le paysage.
Naturellement, il n'est plus question de donner les tables de décodage ! On se bornera donc aux principes
et à quelques exemples.
- La première idée fut d'utiliser au maximum les
codages sur 8 et sur 16
bits, avec une information spécifique
(dite escape sequence) pour marquer le passage d'un régime à l'autre. Cette technique, très prisée
des Japonais, est normalisée par ISO-2022.
Exemple en ISO-2022-JP : Le texte mixte japonais-anglais (sorry ! les lettres accentuées ne sont pas admises...)
"田中さんは Mr Tanaka 学生です is a student 。"
est représenté par les 63 octets
1B 24 42 45 44 43 66 24 35 24 73 24 4F 1B 28 42 20 4D 72 20 54 61 6E 61 6B 61 20 1B 24 42 33 58
ESC $ B田中さんはESC ( B M r T a n a k a ESC $ B学
40 38 24 47 24 39 1B 28 42 20 69 73 20 61 20 73 74 75 64 65 6E 74 20 1B 24 42 21 23 1B 28 42
生で すESC ( B i s a s t u d e n tESC $ B。ESC ( B
On voit que les caractères japonais (kanjis et kanas) sont représentés sur 2 octets qui sont eux-mêmes des octets ASCII
(1er bit nul). L'éditeur hexadécimal interprète d'ailleurs le fichier sans hésitation comme :
.$BEDCf$5$s$O.(B Mr Tanaka .$B3X@8$G$9.(B is a student .$B!#.(B
où le caractère non interprété est1B=ESC.
On passe de l'interprétation ASCII à l'interprétation japonaise par l'"échappement" (escape sequence)"ESC $ B"
et on revient à l'interprétation ASCII par"ESC ( B".
Enfin, au commencement du processus l'interprète est en mode ASCII, et il y revient à la fin.
- Le code Shift-JIS,
également très populaire au Japon, a une autre structure, employant
systématiquement deux octets.
Exemple : le même texte est représenté cette fois par 45 octets :
93 63 92 86 82 B3 82 F1 82 CD 20 4D 72 20 54 61 6E 61 6B 61 20 8A 77
田中さんはM r T a n a k a学
90B6 82 C5 82 B7 20 69 73 20 61 20 73 74 75 64 65 6E 74 20 81 42
生で すi s a s t u d e n t。
On voit que les caractères japonais sont représentés sur 2 octets dont le premier n'est jamais un octet ASCII
(le second peut en être un : nous en avons deux cas ici), de sorte qu'il n'y a aucune ambiguïté dans le décodage.
On note que les deux passages en ASCII se retrouvent à l'identique dans les deux fichiers (évidemment !).
Voyez ici une illustration amusante de cette mécanique.
-
La communauté d'origine des écritures chinoise, japonaise (kanjis) et
coréenne a
conduit à un regroupement
connu sous l'acronyme CJK. Le problème de fond posé par cette communauté (Han Unification)
sera abordé dans le cadre d'Unicode.
Nous nous bornerons ici à noter que la rivalité entre la Chine populaire et Taïwan se manifeste par
deux codages incompatibles : la famille GB en République populaire et Big5 à Taïwan, Hong Kong
et autres lieux fidèles aux caractères traditionnels (non simplifiés).
La famille GB comprend GB2312, GBK et GB18030 [GB＝国家标准Guojia Biaozhunstandard national].
Outre les pages de Wikipedia, voyez encore une fois le site de Roman Czyborra.
Exemple : le Quotidien du Peuple 人民网 en ligne est
- en UTF-8 dans ses versions française
, anglaise (en fait c'est de l'ASCII), arabe, espagnole et russe ;
- en EUC-JP dans sa version japonaise (EUC = Extended Unix Coding)
- en GB2312 dans sa version d'origine
- mais en GBK dans sa version tibétaine
ce qui rend cette dernière illisible sur une machine où les polices tibétaines ne connaissent pas ce codage.
- en UTF-8 dans ses versions française
, anglaise (en fait c'est de l'ASCII), arabe, espagnole et russe ;
- La première idée fut d'utiliser au maximum les
codages sur 8 et sur 16
bits, avec une information spécifique
Le cas du courrier électronique
Exemple intéressant où les codages sur 8 bits règnent en maîtres et où leur rôle est facilement observable.Cette section fait suite à la Note sur les fichiers-texte du cours n° 1.
-
Clients & serveurs de mail
Les trois protocoles SMTP, POP et IMAP.
Voir l'excellent site pédagogique de Christian Caleca, en premier lieu les bases.
À noter toutefois que les expériences qu'il propose, utilisant le protocole telnet,
sont impraticables aujourd'hui, aucun serveur n'étant plus accessible en mode non sécurisé.
-
L'exigence ASCII et la convention MIME
Pour des raisons dont la validité est moindre aujourd'hui qu'à l'origine (dans les années '70),
la règle veut que les textes échangés par ces protocoles soient en ASCII (7 bits).
En outre, le texte doit être subdivisé en lignes d'au plus 76 caractères, terminées par CRLF.
La nécessité de transporter des contenus autres que du texte ASCII an conduit à élaborer
un ensemble de conventions appelé MIME (pour Multipurpose Internet Mail Extension),
qui s'applique aujourd'hui à toutes les communications sur Internet, notamment aux pages Web.
Outre Wikipédia, une excellente référence sur ce point est fournie par le site SELFHTML.
-
Structure des messages
Ces textes sont en deux parties : les en-têtes (headers) et le contenu.
- Les en-têtes sont engendrés automatiquement par le
logiciel de courrier (plus ou moins paramétrable).
Ils comportent (entre autres)
- l'expéditeur (champ From:),
- le destinataire (champ To:),
- l'objet du message (champ Subject:)
Donc pas de lettres accentuées dans une adresse (valeur des champs expéditeur et destinataire),
ni dans l'objet du message... Voir à ce sujet le paragraphe Mots encodés.
On observe couramment des erreurs de transmission dues à des négligences en la matière.
- l'expéditeur (champ From:),
- Le contenu en revanche peut être écrit avec un
codage des caractères quelconques
(qui dépend du bon vouloir de votre logiciel de courrier).
Mais comme la transmission est censée se faire en ASCII, pour pouvoir être acheminé
il devra être traduit en ASCII au départ et traduit en sens inverse à l'arrivée.
Cette traduction peut varier d'un logiciel émetteur à l'autre, elle doit donc être annoncée dans les en-têtes.
- La manière d'annoncer le procédé de traduction et
le codage cible relève de la convention MIME.
Elle fait l'objet de deux en-têtes particuliers :
Content-Type: et Content-Transfer-Encoding:
Le premier indique la nature du texte, il a en général comme valeur "text/plain" ou "text/html",
suivi (pas toujours) de la mention du codage des caractères utilisé, p. ex. "charset=iso-8859-1".
On trouvera donc souvent "Content-Type: text/plain; charset=iso-8859-1".
L'indication supplémentaire "format=flowed" qu'on verra dans les exemples ci-après
signale que les sauts de ligne qui ont été ajoutés pour transmettre le contenu
peuvent être supprimés à la réception pour ne garder que le sauts de paragraphe
"logiques" et ainsi adapter la longueur des lignes à la taille de la fenêtree de lecture.
Le second donne le procédé de traduction, les principaux sont
- Content-Transfer-Encoding: quoted-printable
- Content-Transfer-Encoding: base64
- Content-Transfer-Encoding: 8bit
- et aussi Content-Transfer-Encoding: 7bit
Notons au passage que l'action normale du logiciel de courrier, à la réception d'un message,
est de faire disparaître les informations qui n'ont servi qu'à la transmission.
Les observations que nous allons faire ne sont donc possibles qu'en interrompant de manière artificielle
l'opération de traduction, de manière à saisir le texte transmis avant sa mise au net.
Certains logiciels donnent accès au code-source du message, en ASCII (p.ex. Thunderbird).
- Les en-têtes sont engendrés automatiquement par le
logiciel de courrier (plus ou moins paramétrable).
-
Les principaux procédés de traduction d'octets en ASCII.
Ces procédés s'appliquent à des octets quelconques, ils peuvent donc coder aussi bien des photos que
de la musique ou des textes. Mais ils sont plus ou moins bien adaptés suivant la nature du document à tranmettre,
qui peut varier comme on le verra ci-après..
- Content-Transfer-Encoding: quoted-printable
Le procédé s'applique octet par octet.
Les octets correspondant à des caractères ASCII imprimables sont laissés tels quels,
les autres sont codés par 3 caractères : "=" suivi des deux chiffres hexadécimaux de l'octet.
Il s'ensuit que le signe "=" devra être codé pour être transmis
- d'où l'apparition de "=3D" puisque 0x3D est le code de "=" en Windows.
Le résultat reste lisible si les caractères ASCII sont suffisamment nombreux parmi les octets traduits.
Exemple :
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=ISO-8859-1;
format=flowed
Bonjour =E0 tous,
Voici le fichier r=E9capitulatif.
V=E9rifiez si besoin les descriptions, si erreur manifeste,
ou s'il en manquait (je n'esp=E8re pas, voir plus bas !).
Voyez Wikipedia (en anglais) pour plus de précisions.
- Content-Transfer-Encoding: base64
Le procédé s'appplique à une chaîne d'octets à traduire.
Cette chaîne est d'abord découpée en blocs de 6 bits, dont chacun peut est interprété comme
un indice dans la chaîne de longueur 2^6 = 64
"ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/"
Chaque bloc de 6 bits est codé par la lettre qui se trouve à l'indice en question.
Exemple : Soit à coder la chaîne "Man" = 4D 61 6E = 0100 1101 0110 0001 0110 1110
Cette chaîne de 24 bits est découpée en 4 blocs de 6 bits : 010011 010110 000101 101110
interprétés comme 4 entiers 19, 22, 5 et 46, qui repèrent dans la chaîne susdite (en commençant à 0)
les lettres T, W, F et u : la traduction de en base64 est donc "TWFu".
Comme on le voit le résultat est passablement illisible : comment savoir que
/9j/4AAQSkZJRgABAgEASABIAAD/7QIIUGhvdG9zaG9wIDMuMAA4QklNA+kAAAAAAHgCAQAA
AEgASAAAAAADLgJA//f/9gNBAkm0AgV7A98AAAAAAWgBaAAAAAAP5gtAAAAAAAAAAAAAAAAB
AQEAAAABJw8AAQABAAAAAAAAAAAAAAAAAAggGgBkIQhHAAEAREsCAP//IQGM+iM6NRiLIKUk
AQAAAAAAAHY4QklNA+0AAAAAABAASAAAAAEAAgBIAAAAAQACOEJJTQQNAAAAAAAEAAAAeDhC
SU0D8wAAAAAACAAAAAAAAAAAOEJJTQQKAAAAAAABAAA4QklNJxAAAAAAAAoAAQAAAAAAAAAC
OEJJTQP1AAAAAABIAC9mZgABAGxmZgAGAAAAAAABAC9mZgABAKGZmgAGAAAAAAABADIAAAAB
est le début d'une photo, alors que
TWFuIGlzIGRpc3Rpbmd1aXNoZWQsIG5vdCBvbmx5IGJ5IGhpcyByZWFzb24sIGJ1dCBieSB0
aGlzIHNpbmd1bGFyIHBhc3Npb24gZnJvbSBvdGhlciBhbmltYWxzLCB3aGljaCBpcyBhIGx1
c3Qgb2YgdGhlIG1pbmQsIHRoYXQgYnkgYSBwZXJzZXZlcmFuY2Ugb2YgZGVsaWdodCBpbiB0
aGUgY29udGludWVkIGFuZCBpbmRlZmF0aWdhYmxlIGdlbmVyYXRpb24gb2Yga25vd2xlZGdl
LCBleGNlZWRzIHRoZSBzaG9ydCB2ZWhlbWVuY2Ugb2YgYW55IGNhcm5hbCBwbGVhc3VyZS4=
se traduit en bon anglais (ref. Wikipedia) :
Man is distinguished, not only by his reason, but by this singular passion from other animals,
which is a lust of the mind, that by a perseverance of delight in the continued and indefatigable
generation of knowledge, exceeds the short vehemence of any carnal pleasure.
Voici un outil qui va vous permettre d'expérimenter :
- il prend une chaîne codée en base64 (essayez
tout ou partie des exemples ci-dessus),
il la décode et il interprète la chaîne de bits obtenue- comme une suite d'octets
- comme une chaîne de caractères en ISO-8859-1
- comme une chaîne de caractères en UTF-8
- réciproquement, il prend un texte donné comme une suite d'octets, ou en
ISO-8859-1, ou en UTF-8,
il le code en base64 et il affiche le résultat.
- il prend une chaîne codée en base64 (essayez
tout ou partie des exemples ci-dessus),
- Content-Transfer-Encoding:
8bit
Dans ce système, les octets sont transmis tels quels. Il est de plus en plus utilisé, même si sa légalité
reste controversée puisqu'elle va contre la règle.
Bien évidemment, il faut que l'émetteur et le récepteur soient d'accord sur le codage de l'information.
Par défaut ce sera naturellement Latin-1, mais il vaut mieux le préciser !
J'observe à son sujet un comportement énigmatique, typique des situations bizarres liées aux problèmes
de codage. Bien qu'elle soit spécifique à ma configuration (MacOS X), l'anecdote mérite d'être contée.
La voici.
En empêchant mon mailer de terminer sa tâche, j'obtiens des fichiers comme celui-ci :
Content-Type: text/plain; format=flowed
Content-Transfer-Encoding: 8bit
La deuxiËme Èdition des JournÈes sur líIngÈnierie DirigÈe par les
ModËles se propose de rÈunir ‡ nouveau les chercheurs intÈressÈs par les
multiples facettes des mÈta-modËles, modËles et de leurs utilisations.
Ces journÈes seront mises ‡ profit pour dÈbattre des thÈories et
pratiques actuelles de líingÈnierie dirigÈe par les modËles et de ses
applications et participeront ‡ la structuration de cette communautÈ
Èmergente. Les chercheurs francophones peuvent et doivent largement
contribuer ‡ ce vaste mouvement, notamment en Ètablissant des ponts
interdisciplinaires pour profiter au mieux des avancÈes technologiques
Vous avez dit bizarre ?
La clé de l'énigme se trouve dans la comparaison des tables Windows-1252 (pas Latin-1 !) et MacRoman.
L'octet E9 (resp. E8, E0, 92) qui code "é" (resp. "è", "à", l'apostrophe "’") en Windows
code "È" (resp. "Ë", "‡", "í") en MacRoman.
Conclusion : mon mailer (en l'occurrence Eudora v. 6) commence par interpréter les octets qu'il reçoit
dans son codage "natif" MacRoman, avant de recoder le tout en Windows (vu comme un Latin-1 étendu...)
pour l'affichage.
Bon, voilà un mystère éclairci. Mais que dites-vous de ceci :
Content-Type: text/plain
Content-Transfer-Encoding: 8bit
Ce rapport d‚habilitation à diriger des recherches traite de la
problématique de la coordination dans les systèmes multi-agents. La
coordination est un problème majeur dans ce domaine en raison de
l‚autonomie intrinsèque des agents et à leurs caractéristiques
fondamentales, notamment la concurrence. L‚approche de résolution adoptée
dans ce travail est purement cognitive et a été abordée en profondeur
selon trois axes de recherche fédérateurs.
???
- Content-Transfer-Encoding:
7bit
Dans ce cas également les octets du message sont transmis tels quels, sous l'hypothèse que ce sont tous des octets ASCII,
auquel cas leur intégrité est garantie.
En particulier, les messages écrits en ISO-2022-JP sont justiciables de ce traitement.
Exemple : le message dont voici le texte-source
From: Jean-Francois Perrot <jeanfrancoisperrotster@gmail.com>
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
To: jfp <Jean-Francois.Perrot@lip6.fr>
Subject: Essai
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit
Cher ami,
voici ce que j'apprends dans mon initiation au japonais :
"$BEDCf$5$s$O(B Mr Tanaka $B3X@8$G$9(B is a student $B!#(B"
Ce n'est qu'un commencement...
A` biento^t,
-JF.
est affiché comme
- Il y a encore d'autres procédés de traduction,
comme Content-Transfer-Encoding: x-uuencode...
- Content-Transfer-Encoding: quoted-printable
-
L'affaire des pièces jointes.
La situation s'aggrave si on veut transmettre des pièces jointes (photos, fichiers pdf, etc) en plus du texte.
Il s'agit clairement de contenus hétérogènes, ce pourquoi la convention MIME prévoit les déclarations suivantes :
- "Content-Type: multipart/alternative"
ou "Content-Type: multipart/mixed",
qui annonce clairement que le contenu sera en plusieurs parties, séparées par une ligne
tirée au hasard pour avoir une probabilité infinitésimale de faire partie du message initial.
Cette déclaration doit être complétée par la donnée de cette ligne, par exemple :
boundary="============_-1155134824==_============"
- Pour préciser si la pièce jointe peut être affichée
avec le texte d'envoi ou au contraire doit être sauvegardée à part,
on ajoute :
Content-Disposition: inline ou Content-Disposition: attachment
suivi dans le deux cas du nom du fichier : filename="machin.xxx"
Exemples :
Content-Type: multipart/mixed; boundary="=====================_1032958208==_"
--=====================_1032958208==_
Content-Type: text/plain; charset="us-ascii"
Cher(e)s Collegues,
je vous envoie le planning definitf et le calendrier
pour 2002-2003.
--=====================_1032958208==_
Content-Type: application/msword; name="calend1.doc";
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="calend1.doc"
0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAKgAAAAAAAAAA
Content-Type: multipart/mixed; boundary="------------010304010805010603040903"
This is a multi-part message in MIME format.
--------------010304010805010603040903
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Voici la photo promise
--------------010304010805010603040903
Content-Type: image/jpeg; name="laPhoto.jpg"
Content-Transfer-Encoding: base64
Content-Disposition: inline; filename="laPhoto.jpg"
/9j/4AAQSkZJRgABAgEASABIAAD/7QIIUGhvdG9zaG9wIDMuMAA4QklNA+kAAAAAAHgCAQAA
AEgASAAAAAADLgJA//f/9gNBAkm0AgV7A98AAAAAAWgBaAAAAAAP5gtAAAAAAAAAAAAAAAAB
AQEAAAABJw8AAQABAAAAAAAAAAAAAAAAAAggGgBkIQhHAAEAREsCAP//IQGM+iM6NRiLIKUk
AQAAAAAAAHY4QklNA+0AAAAAABAASAAAAAEAAgBIAAAAAQACOEJJTQQNAAAAAAAEAAAAeDhC
SU0D8wAAAAAACAAAAAAAAAAAOEJJTQQKAAAAAAABAAA4QklNJxAAAAAAAAoAAQAAAAAAAAAC
OEJJTQP1AAAAAABIAC9mZgABAGxmZgAGAAAAAAABAC9mZgABAKGZmgAGAAAAAAABADIAAAAB
Content-Type: multipart/mixed; boundary="============_-1155134824==_============"
--============_-1155134824==_============
Content-Type: text/plain; charset="iso-8859-1" ; format="flowed"
Content-Transfer-Encoding: 8bit
Je t'envoie la fiche d'Èvaluation ‡ remplir, merci de me la retourner.
‡ bientot,
--============_-1155134824==_============
Content-Type: application/msword; name="Fiche_d'eval.03.doc"
Content-Disposition: attachment; filename="Fiche_d'eval.03.doc"
Content-Transfer-Encoding: x-uuencode
begin 644 Fiche_d'.doc
MT,\1X*&Q&N$`````````````````````/@`#`/[_"0`&```````````````&
M````+0``````````$```OP(```$```#^____`````"X````P````,0```#(`
- "Content-Type: multipart/alternative"
ou "Content-Type: multipart/mixed",
-
Mots encodés
Il s'agit d'un procédé permettant d'envoyer autre chose que de l'ASCII dans les en-têtes.
Le libellé de l'en-tête est alors codés en ASCII par le mailer de l'expéditeur, et envoyés dans une enveloppe ad hoc
que le client du destinataire saura ouvrir pour en décoder le contenu et le révéler à l'utilisateur final.
La forme générale de cette enveloppe est :
=?CodeCar?X?............?=
- où
CodeCardésigne le système de codage des caractères utilisé (UTF-8,ISO-8859-1,windows-1252, etc) - et
Xindique la manière dont les octets ont été codés en ASCII :Bpour Base64 ;Qpour Quoted-printable, etc
Ce procédé est à l'œuvre chaque fois que votre mailer vous donne à lire une en-tête qui contient des caractères non-ASCII.
Allez voir !
-
Noms de personnes tirés d'un carnet d'adresses.
De plus en plus souvent, les logiciels de courrier envoient, avec l'adresse de l'expéditeur, son nom "en clair",
le tout remplissant le champ "From:" parmi les en-têtes.
Sous sa forme la plus simple, cela donne quelquechose comme :
From: Antoine DuNabla <adn@mondomicile.chezmoi.org>
To: joseph@marie.com
La même information facultative peut aussi apparaître dans les champs "To:" et "Cc:":
From: Antoine DuNabla <adn@mondomicile.chezmoi.org>
To: Joseph-Adrien Mouret <joseph@marie.com>
Cc: Antoinette DiGiorgio <adg@chezelle.fr>, <alt22@ailleurs.com>
La forme exacte de ces libellés dépend du mailer qui les engendre :
- Apple Mail produit la forme ci-dessus,
- tandis que Outlook Express
de
Microsoft préfère mettre des guillemets autour des chaînes :
From: "Antoine DuNabla" <adn@mondomicile.chezmoi.org>
To: "Joseph-Adrien Mouret" <joseph@marie.com>
Cc: "Antoinette DiGiorgio" <adg@chezelle.fr>, <alt22@ailleurs.com> - mais on peut aussi avoir les deux...
Or ce dernier n'a aucune raison d'être écrit entièrement en ASCII !
Par exemple, mon mailer envoie des en-têtes comme
From: =?UTF-8?B?SmVhbi1GcmFuwo1jb2lzIFBlcnJvdA==?= <Jean-Francois.Perrot@lip6.fr>
Reply-To: Jean-Francois.Perrot@lip6.fr
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
et je reçois du Japon des messages comme
From: "=?ISO-2022-JP?B?GyRCSkZfN0xAN3sbKEI=?=" <xx.yyyy@hoymail.com>
ou comme
From: =?UTF-8?B?5aSn5rGf5L2Q55+l5a2Q?= <yzt-uvw@asahi-net.or.jp>
Champ "
Cette fois, c'est vous qui tapez (par inadvertance ?) un caractère non-ASCII dans le champ "Sujet" de votre message,Subject:"
et votre mailer va automatiquement convertir tout le sujet en ASCII, en fonction du codage des caractères en vigueur
chez vous et selon le procédé de transfert qu'il juge bon d'employer.
Par exemple :Subject: =?ISO-8859-1?Q?Fwd=3A_reunion=5Fdelegu=E9s=5FSCIA?=
Ou cette variante d'un exemple précédent :From: "=?ISO-2022-JP?B?SmVhbi1GcmFuP2NvaXMgUGVycm90?=" <jeanfrancoisperrotster@gmail.com>
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
To: jfp <Jean-Francois.Perrot@lip6.fr>
Subject: =?ISO-2022-JP?B?GyRCJDMkcyRLJEEkTxsoQg==?=
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit
Cher ami,
voici ce que j'apprends dans mon initiation au japonais :"$BEDCf$5$s$O(B Mr Tanaka $B3X@8$G$9(B is a student $B!#(B"Ce n'est qu'un commencement...
A` biento^t,
-JF.
qui s'affiche comme
Mais pourquoi diable ce point d'interrogation dans le champ "From:" :Jean-Fran?cois.Perrot???
- où
Arrêtons-nous là !