Résumé

  • Le RFC 1557, paru en décembre 1993, décrit un corps de message en ISO-2022-KR : départ en ASCII, désignation de KSC 5601 par ESC $ ) C, passage aux caractères coréens par SO, retour à ASCII par SI.
  • Dans les champs d’en-tête, le coréen prend la forme EUC-KR, puis un mot encodé B ou Q selon le RFC 1522. La réussite du décodeur du corps ne présume rien de celle du décodeur du sujet.

Le sujet n’empruntait pas la même file

Un message annonce un rendez-vous en coréen. Le sujet reste lisible dans la boîte de réception ; une fois le courriel ouvert, l’heure du rendez-vous disparaît derrière des signes incohérents. Le défaut n’a pas forcément eu lieu pendant le transport. Il peut se trouver dans l’opération que le lecteur effectue après la livraison. Le sujet et le corps réclament deux modes d’emploi.

La séparation est ancienne. Le RFC 822 place des champs structurés au-dessus du corps du message. Dans ces champs, ponctuation, adresses et retours à la ligne ont des fonctions précises. Un relais peut replier une ligne ou réordonner des destinataires. En septembre 1993, le RFC 1522 répondait à ce milieu délicat par des « mots encodés » fabriqués avec des caractères ASCII imprimables. Ils protègent un texte non ASCII sans demander aux anciens logiciels d’en-tête de comprendre immédiatement ses octets.

Trois mois plus tard, U. Choi, K. Chon et H. Park expliquèrent dans le RFC 1557 comment transporter du coréen dans les deux parties d’un message en texte brut. Selon les auteurs, la méthode avait été fixée en 1991 et était largement employée sur les réseaux IP coréens. Leur document consigne une pratique et sa syntaxe ; il ne donne aucun comptage d’installations.

Dans le corps, tout commence en ASCII. La séquence ESC $ ) C désigne le jeu KSC 5601. SO fait ensuite lire les octets par paires comme des caractères de ce jeu, qui comprend hangul et hanja ; SI ramène le flux à ASCII. Le libellé MIME du corps est ISO-2022-KR. Ici, la mémoire du décodeur compte autant que l’octet présent : sans savoir quel déplacement vient d’être annoncé, une paire de signes peut être interprétée sur la mauvaise voie.

Le texte explicatif du RFC situe la désignation au début d’une ligne contenant du coréen. Sa grammaire formelle permet qu’une désignation précède plusieurs lignes pertinentes, et les auteurs donnent expressément priorité à cette grammaire en cas de désaccord. Pour lire une pièce conservée, mieux vaut donc suivre l’emplacement réel de ESC $ ) C, de SO et de SI plutôt que plaquer sur elle une règle de répétition venue d’un autre encodage.

Ce corps emploie sept bits. Le RFC indique qu’il n’a pas besoin, à ce titre, d’un en-tête Content-Transfer-Encoding. Les auteurs signalent aussi que les logiciels coréens de leur époque ne savaient pas superposer Base64 ou Quoted-Printable à un corps déjà codé ainsi. C’est un portrait des outils de 1993. Il explique la solution choisie sans transformer une limite de logiciel en loi intemporelle.

Au-dessus du corps, le traitement change. Le coréen d’un champ d’en-tête est représenté en EUC-KR, puis enveloppé dans un mot encodé B ou Q. Le RFC 1522 définit la forme =?charset?encoding?encoded-text?=. L’extérieur ressemble à de l’ASCII ordinaire pour les relais anciens ; l’intérieur donne au lecteur averti les indications nécessaires pour reconstruire les caractères. Le corps annonce ISO-2022-KR, l’en-tête annonce EUC-KR. Confier le sujet au décodeur du corps reviendrait à présenter le bon voyageur avec le mauvais passeport.

Une seule lettre apparaît à l’écran, mais deux accords techniques l’ont rendue lisible. C’est précisément l’intérêt historique du RFC 1557 : il montre combien une frontière de logiciel peut traverser une phrase sans que son lecteur s’en aperçoive, jusqu’au jour où un seul des deux guichets ferme.