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.
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 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 Ò Ú Û Ù ı ˆ ˜ ¯ ˘ ˙ ˚ ¸ ˝ ˛ ˇ
- 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 sous quel format ?
Il faut distinguer 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 plage A0-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 !
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 (le hongrois distingue -ő- long et -ö- bref)
Constantin Brâncuși (sculpteur roumain)
Alexandru Șunǎ (étudiant roumain 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.
- 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 entre les écritures devanâgari et gujarâti, mais beaucoup moins pour les 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.
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.
Le code Shift-JIS a une autre structure, employant systématiquement deux octets.
La communauté d'origine des écritures chinoise, japonaise et coréenne a conduit à un regroupemet
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 GB18030 et Big5.
Outre les pages de Wikipedia, voyez encore une fois le site de Roman Czyborra.
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.
Une excellente référence sur ce point est fournie par le site SELFHTML.
-
Stucture 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...
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
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 prématurée
l'opération de traduction, de manière à saisir le texte transmis avant sa mise au net.
- 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 chaîne de caractères
en ISO-8859-1 qu'il affiche aussitôt ;
- réciproquement, il prend un texte en
ISO-8859-1, 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.
???
- 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",
Arrêtons-nous là !