MIME (Extensions Polyvalentes pour le Courrier Internet)

Traduction approximative de la RFC 2047 en français.
Index Documentation Accueil
Network Working Group
Request for Comments: 2047
Rends obsolètes: 1521, 1522, 1590
Catégorie: Standards Track
K. Moore
University of Tennessee
Novembre 1996
MIME (Extensions Polyvalentes pour le Courrier Internet)
(EPCI) Troisième Partie :
Extensions pour les En-têtes de Message ayant du Texte de type NonASCII
(Multipurpose Internet Mail Extensions)
Statut de ce mémo
On spécifie par ce document un protocole Internet de niveau standard track pour la communauté Internet, ainsi
que les demandes de discussions et de suggestions d'améliorations. Si vous le souhaitez, vous pouvez vous
référer à l'actuelle édition de l 'Internet Official Protocol Standards" (STD 1) pour connaître l'état de
standardisation et le statut pour ce protocole. La distribution de ce mémo n'est pas limitée.
Abrégé
STD 11, RFC 822, définissent un protocole de représentation de message spécifiant très précisément les détails
qui concernent les en-têtes de message US-ASCII, et qui laissent le contenu du message, ou du corps du
message, en tant que texte brut ("flat-text") de type US-ASCII. L'actuel jeu de documents, collectivement
appelé le Multipurpose Internet Mail Extensions (extensions polyvalentes aux courriers Internet), ou MIME,
redéfini le format des messages pour permettre
(1) les corps de message texte dans un jeu de caractères autre que l'US-ASCII,
(2) un jeu extensible de différents formats pour les corps de message qui ne soient pas textuels,
(3) des corps de message composés de parties multiples, et
(4) des informations d'en-tête de type texte composés avec des jeux de caractères autre que l'US-ASCII.
Ces documents sont basés sur le travail effectué précédemment et qui est documenté par la RFC 934, le STD
11, et la RFC 1049, mais aussi les étends et les révises. Parce que la RFC 822 dit si peu en ce qui concerne le
corps des messages, ces documents "se positionnent à coté" de la RFC 822 (plutôt que de la réviser).
Ce document est le troisième document de la série. On y décrit les extensions à la RFC 822 permettant d'avoir
des données en texte non-US-ASCII dans les champs d'en-têtes du courrier Internet. Les autres documents de
cette série sont :
+ la RFC 2045, qui décrit les divers en-têtes utilisés pour décrire la structure des messages
MIME.
+ la RFC 2046, qui définit la structure générale du système permettant de typer ce qui est
supporte MIME, et défini une première série de type de media,
+ la RFC 2048, qui spécifie les diverses procédures d'enregistrement de l'IANA pour les
nouvelles capacités de MIME, et
+ la RFC 2049, qui décrit les critères pour être en conformité avec MIME et elle fournit
quelques exemples de format de message MIME, des remerciements, et la
bibliographie.
Ces documents sont des révisions des RFC 1521, 1522, et 1590, qui elles-mêmes était des révisions des RFC
1341 et 1342. Une annexe située dans la RFC 2049 décrit les différences et les changements par rapport aux
versions précédentes.
1. Introduction
La RFC 2045 décrit un mécanisme pour indiquer les parties de corps de texte qui sont codées sous divers jeux
de caractères, en plus des méthodes qui encodent ces parties de corps en tant que séquence de caractères USASCII imprimable. Ce mémo décrit des techniques similaires pour permettre l'encodage de texte non-ASCII
dans les diverses portions de l'en-tête RFC 822 [2] du message, et de manière à ce qu'il soit peu probable
d'embrouiller les logiciels déjà existants qui manipulent les messages.
Semblables aux techniques d'encodages décrites dans la rfc 2045, les techniques esquissées ici, ont été conçues
pour permettre l'utilisation de caractères non-ASCII dans les en-têtes de message de manière à ce qu'il soit peu
probable qu'elles soient gênées par les caprices de programmes déjà existant qui manipulent le courrier
Internet. En particulier, certains programmes faisant le relais de courrier sont connus pour(a) supprimer certains
champs d'en-tête de message alors qu'ils en gardent d'autre, (b) réarranger l'ordre des adresses dans les champs
To ou Cc, (c) réarranger l'ordre (vertical) des champs d'en-têtes, et/ou (d) "rassembler" les en-têtes des
messages à des emplacements différents de ceux situés dans le message d'origine. En plus, certains
programmes de lecture de courrier sont connus pour avoir des difficultés à faire une analyse grammaticale
correcte des messages d'en-têtes qui, bien que ce soit en accord avec la RFC 822, font usage de la mise entre
guillemets avec des antislash pour "cacher" des caractères spéciaux tel que ">", "," ou ":" , ou qui exploite les
caractéristiques utilisées peu fréquentent de cette spécification.
Bien qu'il soit malencontreux que ces programmes n'interprètent pas correctement les en-têtes RFC 822,
"casser" ces programmes causeraient de sévères problèmes de fonctionnement pour le système de courrier de
courrier Internet. Les extensions décrites dans ce mémo ne font pas confiance aux caractéristiques de la RFC
822 peu utilisées.
Au lieu de cela, certaines séquences de caractères ASCII imprimable "ordinaire" (connu en tant que "mot
encodé" (traduction de "encoded-words")) sont réservées pour l'usage de l'encodage des données. La syntaxe
des mots encodés est telle qu'il est peu vraisemblable qu'elles apparaissent "accidentellement" comme du texte
normal dans les champs d'en-têtes. En outre, les caractères utilisés dans les mots encodés sont restreints à ceux
qui n'ont pas de signification particulière dans le contexte où le mot encodé apparaît.
Généralement, un "encoded-word" est une séquence de caractères ASCII imprimable qui commence par
"=?",finit par "?=", et qui a donc ces deux "?" entre. On définit un jeu de caractère et une méthode d'encodage,
et cela comprends aussi les textes d'origines qui sont encodés avec des caractères ASCII graphiques, tout en
étant en accord avec les règles de la méthode d'encodage.
Un composeur de courrier qui met en application cette spécification donnera un sens au texte non-ASCII
entrant par les champs d'en-têtes, mais aussi devra traduire ces champs (ou les portions appropriées de ces
champs) dans des mots encodés avant de les insérer dans l'en-tête de message.
Un lecteur de courrier qui implémente cette norme devra reconnaître les mots encodés quand ils apparaissent
dans certaines portions de l'en-tête du message. Au lieu, d'afficher les mots encodés "à l'identique", il
retranscrira et affichera le texte d'origine dans le jeu de caractère désigné.
REMARQUES
Ce mémo s'appuie fortement sur la notation et les termes définis dans les RFC 822 et RFC 2045. En particulier,
la syntaxe pour la ABNF utilisée dans ce mémo est définie dans la RFC 822, dont beaucoup de symbole de la
RFC 822 de terminaison ou de non-terminaison, sont utilisés dans la grammaire des extensions d'en-tête
définies ici. Parmi les symboles définis dans la RFC 822, et ceux référencés dans ce mémo, on a : 'addr-spec',
'atom', 'CHAR', 'comment', 'CTLs', 'ctext', 'linear-white-space', 'phrase', 'quoted-pair'. 'quoted-string', 'SPACE',
et 'word'. Une implémentation de cette extension de protocole qui soit une réussite implique que l'on ait été
attentif aux définitions RFC 822 de ces termes.
Quand le terme "ASCII" apparaît dans ce mémo, on fait référence au "7-Bit American Standard Code for
Information Interchange", ANSI X3.4-1986. Le nom de jeu de caractère MIME pour ce jeu de caractère est
"US-ASCII". Quand on ne se réfère pas spécialement au nom du jeu de caractère MIME, ce document utilise le
terme "ASCII", à la fois pour la brièveté et pour être en cohérence avec la RFC 822. Cependant, les
implémenteurs doivent faire attention à ce que le nom de jeu de caractère doit être orthographié "US-ASCII"
dans le message MIME et dans les en-têtes des parties de corps.
Ce mémo définit un protocole pour la représentation de texte non-ASCII dans les champs d'en-tête. On NE
DOIT PAS définir de façon précise de traduction entre les "8-bit headers" (en-tête 8-bit) et les en-têtes
véritablement ASCII, ni même supposer qu'une telle traduction soit possible.
2. Syntaxe des mots encodés
Un 'mot encodé' ('encoded-word') est défini par la grammaire ABNF suivante. On utilise la notation de la RFC
822, exception faite que les caractères d'espace blanc NE DOIVENT PAS apparaître entres les composantes
d'un 'mot encodé'.
mot encodé = "=?" charset "?" encoding "?" encoded-text "?="
charset = token ; voir section 3
encoding = token ; voir section 4
token = 1*<tous CHAR excepté SPACE, les CTLs, et especials>
especials = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / " <"> / "/" / "[" / "]" / "?" / "." / "="
encoded-text = 1*< Tous caractères ASCII imprimable autre que "?" ou SPACE>
; (mais voir "utilisation de mots encodés dans les
; en-têtes", section 5)
Les noms "d'encodage" ('encoding') et de "jeux de caractère" ('charset') sont indépendants à la case. Ainsi le
nom de jeu de caractère "ISO-8859-1" est équivalent à "iso-8859-1", et l'encodage "Q" peut être écrit soit "Q"
ou "q".
Un "mot encodé" (encoded-word) ne peut avoir une longueur de plus de 75 caractères, en y incluant le 'charset',
et l''encoding', l''encodeed-text' et les délimiteurs. Si on désire encoder plus de texte qu'il n'en rentrerait dans un
"mot encodé" de 75 caractères, de multiples "mots encodés" (séparés par CRLF SPACE) peuvent être utilisés.
Alors qu'il n'y a pas de limite à des champs d'en-tête multi-ligne, chaque ligne de champs d'en-tête qui contient
un ou plusieurs 'mots -encodé' est limité à 76 caractères.
Les restrictions de taille sont prises à la fois pour faciliter l'interoperabilité au travers des passerelles de courrier
inter-réseaux, et pour imposer une limite sur le nombre de recherche "vers l'avant" (traduction de lookahead)
qu'un analyseur d'en-tête doit faire (à la cherche un délimiteur de fin ?=) avant que l'on puisse décider si un
marqueur (token) est un 'encoded word' ou quelque chose d'autre.
IMPORTANT: Les 'mots encodés' sont conçus pour être reconnu comme des 'atomes' par les analyseurs de
RFC 822. En conséquence, les caractères d'espace blanc non encodé("unencoded") (tel que ESPACE et HTAB)
sont INTERDITS à l'intérieur d'un mot 'encoded-word'. Par exemple la séquence de caractère
=?iso-8859-1?q?this is some text?=
devra être analysé grammaticalement comme étant quatre 'atome's plutôt qu'un atome (par un analyseur
grammatical rfc822), ou comme un 'mot encodé' (par un analyseur qui comprends les 'mots encodés' ('encodedword')). La bonne manière d'encoder la chaîne "this is some text" est d'encoder aussi les caractères SPACE,
comme par. ex.,
=?iso-8859-1?q?this=20is=20some=20text?=
Les caractères qui peuvent apparaître dans le 'texte encodé' sont limités par les règles de la section 5.
3. Jeux de caractères
Le morceau 'charset' du mot encodé ('encoded-word') précise le jeu de caractère associé au texte non-encodé.
Un 'charset' peut être n'importe quel nom de jeu caractère autorisé pour le paramètre MIME "charset" d'une
partie de corps de type "text/plain", ou peut être tous les noms de jeu de caractères enregistrés par l'IANA qui
peuvent être utilisé avec un content-type MIME text/plain.
Certains jeux de caractère utilisent des techniques de code-switching (changement de codage) pour s'aiguiller
vers le "Mode ASCII" ou vers d'autres modes. Si un texte non encodé dans un 'mot encodé' contient une
séquence qui a par effet que l'interpréteur de jeu de caractère s'oriente vers un mode autre que vers un mode
ASCII, il DOIT y avoir des codes de contrôles supplémentaires de façon à ce que le mode ASCII soit de
nouveau sélectionné à la fin de l''encoded-word'. (Cette règle s'applique séparément à chacun des mots encodés,
y compris aux mots encodés qui sont adjacent à l'intérieur d'un seul champ d'en-tête).
Quand il y a la possibilité d'utiliser plus d'un jeu de caractère pour représenter le texte dans un mot encodé, et
en l'absence d'accord privé entre l'expéditeur et les destinataires d'un message, on recommande que les jeux
ISO-8859-* soient utilisés de préférence à d'autres jeux de caractères.
4. Encodages
Initialement, les valeurs légales de "encoding" sont "Q" et "B". Ces encodages sont décrit au-dessous. On
recommande d'utiliser l'encodage "Q" quand la plupart des caractères a être encodés font partie du jeu de
caractères ASCII. Sinon, l'encodage 'B' devra être utilisé. Néanmoins, un lecteur de courrier qui prétends
reconnaître les mots encodés DOIT être capable d'accepter l'un de ces encodages pour tous les jeux de
caractères qu'il supporte.
Seul un sous-jeu de caractères ASCII imprimable peut être utilisé dans l' 'encoded-text'. Les caractères tab et
Space ne sont pas autorisé, de façon à ce que le début et la fin d'un mot encodé soient évident. Le caractère "?"
est utilisé à l'intérieur d'un 'mot-encodé' pour séparer les diverses portions de 'mot-encodé' l'une de l'autre, et
ainsi ne peut apparaître dans la portion d''encoded-text'. Dans certains contextes, d'autres caractères aussi sont
aussi illégaux. Par exemple, un mot encodé dans une 'phrase' précédant une adresse dans le champ d'en-tête
From ne doit pas contenir les choses dites "speciales" définies dans la RFC 822. Enfin, d'autres caractères sont
interdits dans certains contexte, afin d'assurer la fiabilité pour les messages qui passent au travers de passerelles
inter réseaux de courrier.
L'encodage "B" satisfait de façon automatique à ces exigences. L'encodage "Q" permet qu'une large étendue de
caractères imprimables soit utilisé dans des emplacements non critiques dans les champs d'en-têtes (par ex.
subject), alors que beaucoup moins de caractères valides peuvent être utilisés pour les autres emplacements.
4.1. L'encodage "B"
L'encodage "B" est identique à l'encodage "BASE64" défini par la RFC 2045.
4.2. L'encodage "Q"
L'encodage "Q" est similaire à l'encodage de content-transfer-encoding "Quoted-Printable" défini dans la RFC
2045. Il est conçu pour donner la possibilité d'avoir un texte contenant la plupart des caractères ASCII qui soit
déchiffrable sur un terminal sans décodage.
(1) Toute valeur 8-bit doit être représenté par un "=" suivi par deux chiffres hexadécimaux.
Par exemple, si le jeu de caractère en cours est ISO-8859-1, le caractère "=" devrait
ainsi être encodé en "=3D", et un espace par "=20" (Les majuscules devront être
utilisées pour les chiffres hexadécimaux compris de "A" à "F".)
(2) La valeur 8-bit hexadécimale 20 (par ex., ISO-8859-1 SPACE) peut être représenté par
"_" ( underscore, ASCII 95.). (Ce caractère peut ne pas passer au travers de certaines
passerelles de courrier inter-réseaux, mais son utilisation augmente grandement la
lisibilité des données encodées "Q" pour des lecteurs de courrier qui ne supportent pas
cet encodage.). Remarquez que le "_" représente toujours l'hexadécimal 20, même si le
caractère SPACE occupe une position de code différant dans le jeu de caractère utilisé.
(3) Les valeurs 8-bit qui correspondent au caractère ASCII imprimable autre que "=", "?",
et "_" (underscore), PEUVENT être représenté par ces caractères (mais il faut voir
section 5 pour les restrictions.). En particulier, SPACE et TAB NE DOIVENT PAS être
représenté par eux-mêmes à l'intérieur des mots encodés.
5. Utilisation des mots encodés dans les en-têtes de message
Un 'mot encodé' peut apparaître dans un en-tête de message ou dans un en-tête de partie de corps en respectant
les règles suivantes :
(1) Un 'mot encodé' peut remplacer une balise 'text' (comme défini par la RFC 822) dans tous les champs
d'en-tête Subject ou Commentaire, dans tous les champs d'en-tête d'extension de message, ou dans tous
les champs de partie de corps MIME pour qui le corps du champ est défini en tant que '*text'. Un 'mot
encodé' peut aussi apparaître dans toutes les en-têtes de parties de corps ou de messages ("X-") définis
par un utilisateur.
Le texte ASCII ordinaire et les 'mots encodés' peuvent apparaître ensemble dans le même champ d'entête. Toutefois, un 'mot encodé' qui apparaît dans un champ d'en-tête défini comme '*text' DOIT être
séparé de tout 'mot-encodé' adjacent ou 'text' par des 'espaces-blanc-linéaire'('linear-white-space').
(2) Un 'mot encodé' peut apparaître à l'intérieur d'un commentaire ('comment') qui délimité par "(" et ")",
c.a.d., partout où un 'ctext' est autorisé. Plus précisément, la définition ABNF de la RFC 822 pour
'comment' est modifié par ce qui suit:
comment = "(" *(ctext / quoted-pair / comment / encoded-word) ")"
Un 'mot encodé' codé en "Q" qui apparaît dans un 'comment' NE DOIT PAS contenir de caractères "(",
")" ou " tout 'mot encodé' qui apparaît dans un 'comment' DOIT être séparé de tout 'mot encodé' ou 'ctext'
adjacent par un 'linear-white-space'.
Il est important de noter que 'comment' soit seulement reconnu à l'intérieur des corps de champs
"structured". Dans les champs, dont les corps sont définis en tant que '*text', "(" et ")" sont traités en tant
que caractère ordinaire plutôt qu'en tant que délimiteurs de commentaires, et la règle (1) de cette section
s'applique (voir la RFC 822, sections 3.1.2 et 3.1.3).
(3) En tant que substitution d'une entité 'word' à l'intérieur d'une 'phrase', par exemple, une qui précède une
adresse dans un champ From, To, ou Cc. La définition ABNF pour 'phrase' de la RFC 822 devient ainsi :
phrase = 1*( encoded-word / word )
Dans ce cas, les jeux de caractères qui peuvent être utilisé dans un 'mot encodé par encodage "Q" encodé
est restreint à : <lettre majuscules et minuscule, "!","*","+", "-", "/", "=", et "_" (tiret bas, ASCII 95)>.
Un 'mot encodé', qui apparaît à l'intérieur d'une 'phrase' DOIT être séparé de tout 'word', 'text' ou 'special'
adjacents par un 'linear-white-space'.
Ce sont les SEULS emplacements où un 'mot encodé' peut apparaître. Plus précisément :
+ Un 'mot encodé' NE DOIT PAS apparaître dans une partie d''addr-spec'.
+ Un 'mot encodé' NE DOIT PAS apparaître dans une 'quoted-string'.
+ Un 'mot encodé' NE DOIT PAS être utilisé dans un champ d'en-tête Received.
+ Un 'mot encodé' NE DOIT PAS être utilisé dans un paramètre de champ d'en-tête
MIME Content-Disposition et Content-Type, ou dans un corps de champ d'en-tête
structuré excepté à l'intérieur d'un 'comment' ou d'une 'phrase'
Le 'encoded-text' dans un 'mot encodé' doit de part lui-même être limité (sic..: traduction de "self-contained");
Cela implique que le morceau d' 'encoded-text' d'un 'mot encodé' en "B" sera d'une longueur égale à un multiple
de 4 caractères. Pour un "mot encodé' en "Q", tout caractère "=" qui apparaît dans le morceau d' 'encoded-text'
devra être suivi par deux caractères hexadécimaux.
Chaque 'mot encodé' DOIT coder un nombre entier d'octets. L''encoded-text' de chaque 'mot encodé' doit être
formé correctement selon les normes d'encodage ; Le 'encoded-text' ne peut se continuer dans le prochain 'mot
encodé' ; (Par exemple,"=?charset?Q?=?==?charset?Q?AB?=" est illégal, parce que les deux chiffres
hexadécimaux "AB" doivent suivre le "=" du même 'mot encodé'.).
Chaque 'mot encodé' DOIT représenter un nombre entier de caractère. Un caractère multi-octets ne doit pas être
coupé en deux dans des 'mots encodés' qui soient adjacents.
Seules des données imprimables et les caractères d'espace blanc peuvent être encodé en utilisant ce système.
Toutefois, puisque ces systèmes d'encodages permettent l'encodage de valeurs arbitraires d'octet, les lecteurs de
courrier qui implémentent ce décodage devrait s'assurer que l'affichage des données décodées sur le terminal du
destinataire ne provoquera pas des effets de bords non voulus.
L'utilisation de ces méthodes pour encoder des données non textuelles (par exemple, des images, ou des sons)
n'est pas définie avec ce mémo. L'utilisation de 'mots encodés' pour représenter les chaînes de caractère
purement ASCII est autorisé, mais pas encouragé. Pour de rare cas, il peut être nécessaire d'encoder le texte
ordinaire qui ressemble à des 'mots encodés'.
6. Support des 'encoded-word' par les lecteurs de courrier
6.1. Reconnaissance des 'mots encodés' dans les en-têtes de message
Un lecteur de courrier doit analyser le message et les en-têtes de partie de corps d'après les règles de la RFC
822 pour reconnaître de façon correcte les "mots encodés".
Les 'mots encodés' doivent être identifiés comme suit :
(1) Tout champ d'en-tête de partie de corps ou de message définis en tant que '*text' ou tout
autres champs d'en-tête définis par l'utilisateur, doit être analysé comme suit : en
commençant au début du corps de champs et en suivant immédiatement chaque
occurrence de 'linear-white-space' (Space), chaque séquence de plus de 75 caractères
imprimables (ne contenant pas de 'limear-white-space') devra être examinée pour voir si
c'est un 'mot encodé' en fonction des règles de syntaxe de la section 2. Toute autre
séquence de caractères imprimable devra être traitée comme du texte ASCII ordinaire.
(2) tous champs d'en-tête non définis en tant que '*text' doit être analysé d'après les règles
syntaxiques de ce champ d'en-tête. Cependant, tout 'word' qui apparaît à l'intérieur d'une
'phrase' doit être traité comme un 'mot encodé' si c'est en concordance avec les règles
syntaxiques de la section 2. Sinon, on devra les traiter en tant que 'word' ordinaire.
(3) A l'intérieur d'un 'comment', toutes séquences de plus de 75 caractères imprimables (ne
contenant pas de 'linear-white-space'), qui satisfont aux règles syntaxiques de la section
2, devront être traitées en tant que 'encoded-word'. Sinon, on devra les traiter en tant que
texte normal de commentaire.
(4) Il N'est Pas nécessaire qu'un champ d'en-tête MIME-Version soit présent pour que les
'mots encodés' soient interprétés en accord de cette norme. Une raison pour cela, est
qu'il n'est pas prévu que le lecteur de courrier analyse entièrement la syntaxe de l'en-tête
de message avant d'afficher les lignes qui pourraient contenir des 'mots encodés'.
6.2. Affichages des 'mots encodés'
Tous 'mots encodés' ainsi reconnus sont décodés, et, si c'est possible, le texte non encodé qui en résulte est
affiché dans le jeu de caractère d'origine.
NOTE: le Décodage et l'affichage des mots encodés s'effectuent *après* qu'un corps de champ structuré soit
analysé entre ces marqueurs (token). Il est donc possible de cacher les caractères 'spéciaux' ('special') dans des
mots encodés qui, quand ils sont affichés, ne seront pas distingué des caractères 'spéciaux' du texte qui les
entoures. Pour cette raison et bien d'autres, il N'est généralement PAS possible de traduire un en-tête de
message contenant les 'mots encodés' en une forme non encodé que l'on puisse ensuite analyser en un lecteur de
courrier RFC 822.
Quand on affiche un champ d'en-têtes particulier qui contiens de multiple 'mots encodés', tous 'linear-whitespace' qui séparent une paire de mots encodés adjacents, est ignoré (ceci permet l'utilisation de multiple 'mots
encodés' afin de représenter de longues chaînes de texte non encodé ou sont situés les espaces, sans avoir à
séparer les 'mots encodés').
Dans le cas où d'autre encodage serait définis dans le futur, et que le lecteur de courrier ne supporte pas
l'encodage utilisé, on peut (a) afficher le 'mot encodé' sous forme de texte ordinaire, ou (b) le remplacer par un
message approprié indiquant que le texte ne peut être décodé.
Si le lecteur de courrier ne supporte pas le jeu de caractère utilisé, on peut (a) afficher le 'mot encodé' comme
du texte ordinaire(par exemple, comme il apparaît dans l'en-tête), (b) faire un "gros effort" pour l'afficher
comme si les caractères était disponible, ou (c) le substituer par un message approprié indiquant que le texte
décodé pourra ne pas être affiché.
Si le jeu de caractère qui est utilisé employé des techniques de commutation de code (code-switching
techniques), l'affichage du texte encodé commence implicitement en "mode ASCII". En plus, le lecteur de
courrier doit s'assurer après le "mot encodé" ait été affiché que le périphérique de sortie soit de nouveau en
"mode ASCII".
6.3. Lecteur de courrier manipulant des 'mots encodés mal formés'
Il est possible qu'un 'mot encodé' bien qu'en accord avec la syntaxe définie en section 2, soit mal formé si on se
référe aux règles qui régissent l'encodage utilisé. Par exemple :
(1) Un 'mot encodé' qui contient des caractères qui ne sont pas autorisés pour un encodage
spécifique (par exemple, un "-" pour un encodage "B", ou un SPACE ou un HTAB pour
l'encodage "B" ou l'encodage "Q"), n'a pas une forme correcte.
(2) Tous 'mots encodés' qui codent un nombre non entier de caractères ou d'octets ne
génèrent pas de forme correcte.
On ne doit pas s'attendre à ce qu'un lecteur de courrier affiche le texte associé à un 'mot encodé' qui a une
forme incorrecte. Toutefois, un lecteur de courrier NE DOIT PAS empêcher l'affichage ou la manipulation d'un
message parce qu'un 'mot encodé' est mal formé.
7. Conformité
Un programme de composition de courrier prétendant être conforme à cet spécification DOIT s'assurer que
toute chaîne de caractères ASCII imprimable (hormis les espaces blanc) à l'intérieur d'un '*text' ou d'un 'ctext'
qui commence par "=?" et qui finit par '?=' est un 'mot encodé' valide. ("commence"' signifie : Au début du
corps de champ, suivant immédiatement le 'linear-white-space', ou suivant immédiatement un '(' pour un 'mot
encodé' à l'intérieur d'un '*ctrext'; "fini" signifie : à la fin du corps de champ ; précédant immédiatement 'linearwhite-space', ou immédiatement précèdent un ')' pour un 'encoded-word' à l'intérieur '*ctext'). De plus, tous
'word' à l'intérieur d'une 'phrase' qui commence par "=?" et qui fini par "?=3" doit être un 'mot encodé' valide.
Un programme de lecteur de courrier prétendant être conforme à cette norme doit être capable de distinguer les
'mots encodés' des 'text', 'ctext', ou des 'word', en fonction des règles de la section 6, chaque fois qu'ils
apparaissent dans les emplacements approprié dans les en-têtes de messages. Il doit supporter à la fois
l'encodage "B" et "Q" pour tous jeux de caractères qu'il admet. Le programme doit être capable d'afficher les
textes non-encodé si le jeu de caractères est "US-ASCII". Pour les jeux de caractères ISO-8859-*, le
programme de lecture de courrier doit au moins être capable d'afficher les caractères qui font partie aussi du jeu
ASCII.
8. Exemples
Ce qui suit sont des exemples d'en-têtes de messages comprenant des 'mots encodés' :
From: =?US-ASCII?Q?Keith_Moore?= <[email protected]>
To: =?ISO-8859-1?Q?Keld_J=F8rn_Simonsen?= <[email protected]>
CC: =?ISO-8859-1?Q?Andr=E9?= Pirard <[email protected]>
Subject: =?ISO-8859-1?B?SWYgeW91IGNhbiByZWFkIHRoaXMgeW8=?=
=?ISO-8859-2?B?dSB1bmRlcnN0YW5kIHRoZSBleGFtcGxlLg==?=
Remarque: Dans le premier 'mots encodé' du champ Subject situé au-dessus, le dernier "=" à la fin de l'
'encoded-text' est nécessaire parce que chacun des 'mots encodés' doit se terminer de part luimême (le caractère "=" termine un groupe de 4 caractères base64 représentant 2 octets. Un octet
supplémentaire aurait pu être encodé dans le premier 'mot encodé' (de manière à ce que le mot
encodé contienne un multiple de 3 octets encodé), si ce n'est le fait que le second 'mot encodé'
utilise un 'charset' diffèrent de celui du premier.
From: =?ISO-8859-1?Q?Olle_J=E4rnefors?= <[email protected]>
To: [email protected], [email protected]
Subject: Time for ISO 10646?
To: Dave Crocker <[email protected]>
Cc: [email protected], [email protected]
From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[email protected]>
Subject: Re: RFC-HDR care and feeding
From: Nathaniel Borenstein <[email protected]>
(=?iso-8859-8?b?7eXs+SDv4SDp7Oj08A==?=)
To: Greg Vaudreuil <[email protected]>, Ned Freed
<[email protected]>, Keith Moore <[email protected]>
Subject: Test of new header generator
MIME-Version: 1.0
Content-type: text/plain; charset=ISO-8859-1
Les exemples suivants illustrent la manière dont un texte contenant les 'mots encodés' apparaissent dans un
corps de champ structuré. Les règles sont légèrement différente pour les champs définis en tant que '*text' parce
que '(' et ')' ne sont pas reconnues en tant que délimitateurs de 'comment' (commentaire). [Section 5, paragraphe
(1)].
Pour chacun des exemples suivant, si on a mis les mêmes séquences dans la zone '*text', la forme "affiché
comme" N'est PAS traité comme un mot encodé, mais comme étant identique à la "forme encodée". Ceci étant
dû au fait que chacun des mots encodées dans les exemples suivants est adjacent à un des caractères "(" ou ")".
forme encodée
affiché comme
--------------------------------------------------------(=?ISO-8859-1?Q?a?=)
(a)
(=?ISO-8859-1?Q?a?= b)
(a b)
A l'intérieur d'un 'comment', les espaces blancs DOIVENT apparaître entre le
'mot encodé' et en entourant le texte. [Section 5, paragraphe (2)]. Cependant,
l'espace blanc n'est pas nécessaire entre le "(" initial qui commence le 'comment',
et le 'mot encodé'.
(=?ISO-8859-1?Q?a?= =?ISO-8859-1?Q?b?=)
(ab)
L'espace blanc n'est pas affiché s'il est entre des 'mots encodés'.
(=?ISO-8859-1?Q?a?= =?ISO-8859-1?Q?b?=)
(ab)
Même de multiples ESPACES entre des 'mots encodés' sont ignorés si c'est pour
être affiché.
(=?ISO-8859-1?Q?a?=
=?ISO-8859-1?Q?b?=)
(ab)
Toute quantité d'espace linéaire blanc entre des 'mots encodés', même si cela
comprends un CRLF suivi par un ou plusieurs ESPACE, est ignoré si c'est pour
l'afficher.
(=?ISO-8859-1?Q?a_b?=)
(a b)
Au lieu d'essayer de faire afficher un ESPACE à l'intérieur une portion de texte
d'encodage, l'ESPACE DOIT être encodé en tant que partie du 'mot encodés'.
(=?ISO-8859-1?Q?a?= =?ISO-8859-2?Q?_b?=) (a b)
Au lieu d'essayer de faire afficher un ESPACE entre deux chaînes de texte
d'encodage, l'ESPACE PEUT (MAY) être encodé en tant que morceau d'un des
'mot encodé'.
9. Références
[RFC 822]
Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822,
UDEL, Août 1982.
[RFC 2049] Borenstein, N., and N. Freed, "Multipurpose Internet Mail Extensions (MIME) Part Five:
Conformance Criteria and Examples", RFC 2049, Novembre 1996.
[RFC 2045] Borenstein, N., and N. Freed, "Multipurpose Internet Mail Extensions (MIME) Part One: Format
of Internet Message Bodies", RFC 2045, Novembre 1996.
[RFC 2046] Borenstein N., and N. Freed, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media
Types", RFC 2046, Novembre 1996.
[RFC 2048] Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four:
Registration Procedures", RFC 2048, Novembre 1996.
10. Considérations sécuritaires
Les problèmes de sécurité ne sont pas traités dans ce mémo.
11. Remerciements
L'auteur veut remercier Nathaniel Borenstein, Issac Chan, Lutz Donnerhacke, Paul Eggert, Ned Freed, Andreas
M. Kirchwitz, Olle Jarnefors, Mike Rosin, Yutaka Sato, Bart Schaefer, et Kazuhiko Yamamoto, pour leur avis
utiles, leurs commentaires perspicaces, et leurs questions éclairée en réaction aux versions précédentes de cette
norme.
12. Adresse de l'auteur
Keith Moore
University of Tennessee
107 Ayres Hall
Knoxville TN 37996-1301
EMail: [email protected]
Annexe - changement depuis la RFC 1522 (sans aucun ordonnancement particulier)
+ déclaration formelle que la Version-MIME n'est pas nécessaire pour utiliser les 'encoded-word'
+ ajout explicite de remarque pour les SPACEs et TABs disant qu'ils ne sont pas autorisé à l'intérieur
d'encoded-word', expliquant qu'un 'encoded-word' doit paraître identique aux 'atom' pour un analyseur
grammatical RFC 822. Parseur.value pour être précis).
+ ajout d'exemples fournit par Olle Jarnefors (merci !) qui illustre comment les mots encodés avec des
espaces blancs linéaires sont affichés.
+ Liste explicite des termes définis dans la rfc822 et référencés dans ce mémo.
+ réparation de transcription typographique qui avait provoqué la disparition d'une ou deux lignes et de deux
caractères pour le texte qui en résulté, cela étant du à des "bizarreries nroff".
+ clarification disant que les mots encodés sont autorisé dans les champs '*text' à la fois dans les en-têtes
RFC822 et dans les en-têtes de parties de corps MIME, et NON en tant que valeurs de paramètres.
+ clarification des conditions pour revenir à l'ASCII à l'intérieur portion encodé d'un 'encoded-word', pour
n'importe quel jeu de caractères qui utilise des séquence de codes de commutation.
+ ajout d'une remarque pour les 'encoded-word qui sont limité par "(" et ")" à l'intérieur d'un commentaire et
non à l'intérieur d'un *text (comme c'est bizarre !).
+ arrangement de l'exemple Andre Pirard pour se débarrasser du "_" traînant après le =E9 (plus besoin post1342).
+ éclaircissement : un 'encoded-word' peut apparaître immédiatement après le premier "(" ou immédiatement
avant le dernier ")" délimiteur de commentaire, pas seulement adjacent à "(" et ")" *within* *ctext (que l'on
pourrait traduire à l'intérieur d'un *ctext).
+ ajout d'un note qui explique qu'un 'encoded-word' "B" aura toujours un multiple de 4 caractères dans la
portion 'encoded-text'.
+ ajout d'une remarque pour le "=" dans les exemples
+ remarque en ce qui concerne le traitement des 'encoded-word' qui s'effectuent par une analyse *after*
(après), et les implications que cela a.
+ affirmation formelle disant que l'on ne peut s'attendre de traduction entre la 1522 et la vanilla 822 ou plus
communément appelé "en-têtes 8-bit".
+ affirmation formelle disant que les 'encoded-word' ne sont pas valables à l'intérieur de 'chaîne entre
guillemets' (quoted-string) .
Fin de traduction.