Codages et jeux de caractères

[Florent Guillaume <efge@xxxxxxxxxxxxxx>]

> Non, pour ce que j'en comprends, ISO-8859-x et ISO-Latin-x ne recouvre
> pas la même réalité. Pour preuve, l'éditeur HTML que j'utilise pour la
> FAQ me propose la conversion de et vers ISO-Latin-1, d'une part, et de
> et vers ISO-8859-1, d'autre part. ISO-8859-1 établit la correspondance
> entre codes 8 bits (ASCII ?) et caractères, alors qu'ISO-Latin-1
> transcrit toutes les lettres sortant du 7 bits sous forme d'entités
> (&...;). On peut donc considérer, je pense, qu'ISO-Latin est une
> version sécurisée d'ISO-8859-1, qui permet de transmettre le texte de
> façon à peu près sure, même si le destinataire ne comprends pas
> l'ISO-8859-1.

C'est une incompréhension de la part du logiciel. Je persiste, et comme
expliqué par Philippe Jallon dans un autre message, ISO 8859-1 et
ISO Latin 1 c'est la même chose, une norme qui fait correspondre à un
octet de 8 bits un glyphe/caractère (ici la distinction n'est pas
vraiment pertinente).

Les entités (é) sont une invention de SGML et donc de HTML, qui
n'ont pas de vraiment rapport avec le codage de transport sous-jacent.
Appeller "ISO-Latin-1" un transcodage vers des entités HTML est vraiment de
l'abus de language de la part du logiciel (et ça ne rend service à
personne, la preuve :-)).


> Oui et non. Certes, le courrier est transmis en ASCII 7 bits (enfin, je
> crois). ISO 8859-1 est actuellement la norme la plus efficace (sic)
> pour transmettre du 8 bits de cette manière. Tout nos problèmes, si je
> comprends bien, viennent du fait qu'on utilise des tuyaux de 7 bits
> pour transmettre du 8 bits. Quand ça marche, ça va. Quand ça ne marche
> pas, on obtient le résultat du dernier postage de la charte ;-(

Ça fait longtemps que les tuyaux 7 bits ont pratiquement disparu.  Le
problème ne vient plus du transfert de caractères sur 8 bits dans des
tuyaux ne laissant passer du 7 bits, car au besoin les passerelles de
mail (MTA, Mail Transfer Agent) savent encoder les 8 bits en
quoted-printable pour que ça passe.  (C'est le champ
Content-Transfer-Encoding: des entêtes qui est pertinent ici).

Le problème est que quand on reçoit un mail avec des caractères 8 bits,
il faut savoir quel charset (codage, c'est à dire correspondance octet
-> glyphe/caractère) a été utilisé pour pouvoir afficher ce qu'il
faut. Par défaut, eh bien il n'y a pas de défaut. Un mail avec des
caractères 8 bits _doit_ être labellé pour que l'on sache quel est le
codage utilisé. Par exemple, le plus courant ici :
	Content-Type: ...; charset="iso-8859-1"

Le problème est qu'encore pas mal de programmes de mail labellent
(labèlent ? de tout façon labeller est un anglicisme) les messages avec
"iso-8859-1" alors même qu'ils envoient des choses qui n'y correspondent
pas.

Exemple typique, ton mac, qui a envoyé le message auquel je réponds
avec les entêtes :
	Mime-Version: 1.0
	Content-Type: text/enriched; charset="iso-8859-1"
	Content-Transfer-Encoding: 8bit

Mais ton exemple qui suit a voulu faire passer un y tréma majuscule, qui
existe dans le codage natif mac mais n'existe pas en ISO 8859-1 (je sais
bien que le but des envois était de montrer les différences de codage
que tu vois, supposons que tu aies voulu simplement envoyer un message
avec un y téma majuscule). Le programme envoyant le mail aurait dû ou
bien l'envoyer dans un charset="codage-mac" adéquat, ou bien l'envoyer
en ISO 8859-1 correct, donc sans l'octet 0x8d qui correspond au y tréma
majuscule du codage mac mais ne correspond à rien dans le codage
ISO 8859-1 (le programme aurait du translitérer soit en Y soit en Y¨ ou
ce qui lui plait le mieux).

Donc moi j'ai lu un message contenant un octet inconnu dans le codage
ISO 8859-1 :
> RÔTIS DE BOEUF AU KIR, À L'A\215 D'ÂGE MÛR, & CÆTERA.
                              ^^^^
Pour les autres exemples en pseudo "iso-latin-1" et "iso-8859-1" alors
là c'est la catastrophe, tous les diacritiques sont complètement
chamboulés. Mais c'était prévisible, il est difficile de parler de
différents codages alors même que le message que l'on rédige est censé
être dans un codage défini.


> >En revanche pour HTML, le codage par défaut est bien ISO 8859-1.
>
> Euh, non, ISO-Latin-1, justement (voir plus haut). Et ce n'est plus
> vrai en HTML 4.

Pour le web, il daut distinguer deux choses : le protocole de transport
des caractères du document, qui est HTTP, et la structure du document
qui est le langage HTML.

Pour HTTP, le codage par défaut est ISO 8859-1 = ISO Latin 1.
C'est-à-dire que les octets du document, sans indication explicite (par
exemple <META CONTENT="text/html;charset=UTF-8" HTTP-EQUIV="Content-Type">)
le codage (charset) utilisé est implicitement ISO 8859-1.

La norme HTTP/1.1 dit :
  When no explicit charset parameter is provided by the sender, media
  subtypes of the "text" type are defined to have a default charset value
  of "ISO-8859-1" when received via HTTP. Data in character sets other
  than "ISO-8859-1" or its subsets MUST be labeled with an appropriate
  charset value.

La norme HTML, qui décrit le document, peut utiliser des
caractères/glyphes codés sur plus de 8 bits, HTML 4.0 utilise ISO 10646
(=Unicode pour nos besoins). Mais pour que plus de 8 bits soient
utilisables, il faut que le charset du document précise que le codage
utilisé est non plus une correspondance 8bits -> caractère comme l'est
ISO 8859-1 mais un correspondance plusieurs-octets -> caractère comme
l'est UTF-8 ou UTF-16 par exemples (deux codages de Unicode).

Comme les 256 premiers caractères de Unicode correspondent position pour
position à ceux de ISO 8859-1, en l'absence de codage on retombe sur nos
pieds et l'on peut dire que par défaut, un document HTML est en ISO
8859-1.


J'espère avoir éclairci tout ça.


-- 
Florent Guillaume <efge@xxxxxxxxxxxxxx>