De part son origine anglo-saxonne, Internet n'était pas prévu pour gérer les caractères accentués du français (RFC 196 du 20 juillet 1971, puis RFCs 821-822 du 13 août 1982). Seuls les 64 caractères US-ASCI étaient utilisables. Le codage des caractères US-ASCI se fait sur 7 bits (SMTP), alors que le codage des caractères accentués, plus nombreux nécessitent au moins 8 bits (ESMTP).
L'infrastructure d'Internet est très lourde et il est assez long d'en changer les différents constituants pour les rendre compatibles avec les signes diacritiques du français et autres langues. En attendant la mise à jour en 8 bits de toutes les passerelles (ordinateur par lesquelles les données transitent), il fallut trouver une solution pour faire transiter les messages accentués, mais aussi les programmes, les images, les sons
Plusieurs solutions furent trouvées, comme l'emploi du codage des fichiers, codage ne contenant que des caractères US-ASCI, UUencode (plutôt pour les NewsGroups, mais employés par certains mailers) / Quoted-Printable ou Base 64.
Ces deux derniers formats appartiennent à un dispositif plus large, le standard MIME (Multipurpose Internet Mail Extensions) apparu le 6 novembre 1992 (RFC 1341). Ce format est en constante évolution ce qui peut provoquer le désarroi des nouveaux utilisateurs.
Tous les messages qui ne sont pas au format pur US-ASCI doivent obligatoirement comporter un en-tête MIME. Ce n'est pas une loi au sens juridique du terme, mais une nécessité pour que les différents usagers puissent communiquer sans dégradation de leurs messages.
Dans quelques mois (années), l'ensemble des passerelles de la planète sera mis à jour en 8 bits (ESMTP) et les accents pourront circuler aussi facilement que les messages en anglais.
Cliquer ici pour obtenir le tableau sur une page isolée.
Jeu de caractères |
Mime |
Codage |
Passerelle 7 bits |
Logiciel de lecture Mime |
Qualité de réception |
US-ASCI (7 bits) |
Inutile |
Non |
Pas de problème |
Inutile |
Parfaite mais aucun accent. Ne convient pas au français. |
Iso-8859-1 |
Obligatoire |
Quoted Printable |
Pas de problème dans 98% des cas |
Oui |
Parfaite avec accents. |
Non (ce qui est une erreur) |
Les accents sont remplacés par des =E9 Le message est moins lisible, mais il est possible de faire un chercher remplacer pour récupérer les bons caractères. |
||||
Base64 |
Pas de problème |
Oui |
Parfaite |
||
Non |
Message illisible |
||||
Aucun (8 bits) |
Le message traverse uniquement des passerelles 8 bits (ESMTP) |
Oui |
Message parfait, c'est le meilleur format si tout est 8 bits. |
||
Certaines passerelles convertissent automatiquement le message en Quoted Printable ou Base64. |
Oui |
Exactement comme pour les autres messages en QP ou base64. |
|||
Les caractères accentués sont convertis en n'importe quoi.. |
Inutile, le message est corrompu |
Les accents sont remplacés par des caractères quelconques, ce qui rend le message peu lisible. |
|||
Iso-8859-1 avec caractères enrichis (en couleur ) |
Obligatoire |
Quoted Printable + Base 64 |
Pas de problème |
Oui, mais aussi support RTF |
Accents OK, mais la taille du message est doublée par un attachement en base 64 contenant le texte RTF. Si reader pas RTF, attachement illisible en fin de message. |
Quoted Printable + HTML |
Pas de problème |
Oui, mais aussi support HTML (rare) |
Accents OK, mais le message est doublé par un attachement en HTML. Si reader pas HTML, attachement peu lisible en fin de message. |
||
HTML seul |
Pas de problème |
Oui mais pur HTML (très rare) |
Illisible sans logiciel spécifique (Netscape...). Format interdit ! |
Ces codages sont destinés à transformer les messages contenant des caractères accentués de façon à ce qu'ils ne contiennent plus que des caractères compatibles avec le jeu de caractères US-ASCI.
Pour produire des messages plus attrayants, les RFCs ont évolué pour utiliser la couleur.
Les caractères accentués sont remplacés par des signes = suivis du code hexa du caractère (=E9 pour "é"...).
Ce format nécessite un en-tête Mime en émission :
Mime-Version: 1.0 Content-Type: Text/Plain; Charset="iso-8859-1" Content-Transfert-Encoding: Quoted-Printableet un logiciel compatible en réception.
C'est le meilleur format pour les fichiers accentués, tant que toutes les passerelles de la planète ne sont pas encore adaptées au 8 bits.
Ce format est rarement utilisé seul. Il est généralement associé à un message en Text/Plain. La partie codée en Base64 contient généralement les caractères enrichis des messages au format RTF.
Mime-Version: 1.0 Content-Type: Applicationt/ms-tnef Content-Transfert-Encoding: Base64Les caractères accentués ne sont pas convertis et sont envoyés tels quels. Ce format est sans doute l'avenir, mais tant que toutes les passerelles ne le comprennent pas, son emploi est risqué. Il vaut mieux le réserver aux messages ne quittant pas un pays francophone (et encore).
En-tête du type:
Mime-Version: 1.0 Content-Type: Text/Plain; Charset="iso-8859-1" Content-Transfert-Encoding: 8bitEn cas de rencontre avec une passerelle 7 bits, 4 possibilités:
1) le message est converti en Quoted-Printable (cas le plus fréquent). Pas de problème si l'en-tête est mis à jour par une ligne:
X-MIME-Autoconverted from 8 bit to quoted-printable.2) le message est converti en base 64. Pas de problème si l'en-tête est mis à jour par une ligne
X-MIME-Autoconverted from 8 bit to base64
3) Les accents du message sont transformés par des caractères faisant partie du jeu de caractère 8 bits.
Le message et ses caractires accenties ressemble i ceci (des i à la place des lettres accentuées)
ou bien:
Le message et ses caractÄres accentÆes ressemble ceci (n'importe quoi à la place des lettres accentuées). Ceci se produit quand le jeu de caractères par défaut n'est pas le même sur les deux machines iso-8859-1 / 8859-2...
Si les lettres accentuées disparaissent totalement, c'est que vous utilisez une police incapable d'afficher les accents
Le message et ses caractres accentus ressemble ceci (rien à la place des lettres accentuées).
Rare pour le courrier électronique. C'est un format à éviter car peu de lecteurs peuvent l'employer. C'est par contre un format courant sur les NewsGroups.
Il s'agit de textes auxquels on a rajouter des attributs de couleur...
Le message transite sous deux formes. Une forme en texte brut, et une autre en texte coloré. Les messages sont donc au moins deux fois plus gros lorsque l'option est activée; C'est la raison pour laquelle ce format est interdit dans les listes de diffusion.
Il existe deux possibilités pour transmettre les enrichissements:
1) le codage dans un attachement en base64. Relativement standard. Si le reader n'est pas compatible, à la suite du fichier apparaît un fouillis de caractères illisibles. kj'lkjsrk%fsdfùmlkqsmdlk MLSflksegf ùe^%ùù%ùsmdf
2) le codage HTML, le même que celui des pages WEB (ou presque...). Si le lecteur n'est pas compatible, un attachement est généré, ou pire, le texte est mélangé à des balises HTML, le rendant difficile à lire.
<p><pre><font color="#FF0000"><p>Les différents formats de mail :</p></p></b></i></font><font size="4">
Attention. Ce format envoie souvent des fichiers images avec le message. En effet, si votre message au format HTML comporte un fond d'écran ou un logo, il sera expédier en même temps que le message, ce qui le gonflera de plus de 10ko. Cette pratique est rigoureusement interdite sur les listes de diffusion (en privé, vous faîtes ce que vous voulez, mais demandez-vous si votre destinataire a vraiment envie de multiplier par 5 sa facture téléphonique pour recevoir vos images...).
Ce procédé très utilisé quand tout le monde avait la même résolution d'écran est maintenant déconseillé pour l'expédition des messages. En effet, il est désagréable de n'avoir que le quart de son écran occupée par le message. Par contre, en lecture, vous devez activer le wraping (renvoi à la ligne) automatique pour que le texte ne sorte pas de l'affichage.
Si vous décidez malgré tout de wraper votre texte, faites-le à 70 caractères, pour permettre les citations avec mise en retrait sans obliger la personne qui vous répond à d'abord supprimer les sauts de lignes et ensuite de les rajouter au nouveau format.
Dans tous les cas, il est déconseiller de wrapper les messages codés en QP (risque de corruption du codage) et interdit de le faire en Base 64 (le message risque de devenir indécodable).
Pour simplifier, on considérera que les messages devront être accentués, et que par conséquent devront comporter un en-tête Mime légal comprenant une ligne décrivant la police de caractère nécessaire au français (ISO-8859-1) et un codage Quoted Printable (ou 8 bits) sans enrichissements.
Outils / Options / Onglet Internet E-Mail (le nom peut varier)
Cocher la case Mime
Choisir le jeu de caractère Iso-8859-1.
Les options suivantes ne sont pas disponibles dans toutes les versions.
Ne pas cocher la case 8 bits sauf pour des messages à des destinataires dont vous êtes sûrs qu'ils reçoivent correctement les messages 8 bits.
Ne pas cocher UUENCODE
Éviter de Wraper les textes en ne cochant pas la case.
Pour Exchange, dans Messages / Options WorldMail, choisir le modèle par défaut EMAIL, surtout pas les autres qui contiennent des images !
Pour Outlook, dans Messages / Choisir le modèle, choisir le modèle par défaut EMAIL, surtout pas les autres qui contiennent des images !
Outils / Options / Onglet Envoyer
COCHER Texte Brut SURTOUT PAS HTML / Paramètres: Mime. Coder le texte en utilisant (Quoted Printable (ou aucun si vous êtes sûr que votre destinataire recevra correctement le 8 bits).
Ne pas activer le papier à lettres, les messages deviendraient beaucoup plus gros, n'oubliez pas que si aux USA, on ne paye pas le téléphone à la durée pour les communications locales, en France, c'est payant et que multiplier par 5 ou 10 la taille des messages n'est pas très sympa pour les destinataires.
Tools / Options / Advanced Settings: Mime Character set : ISO-8859-1
Ne pas activer en principe Allow 8 bits MIME message encoding, sauf si vous êtes sûr que votre destinataire le recevra correctement.
Tools / Options / Message editor settings: Use MIME features: On
Tools / Options / Sending Mail: décochez Word Wrap
Tools / Options / Sending Mail: cochez May Use Quoted Printable.
Tools / Options / Attachements: Encoding method: cochez Mime.
Options / Préférences de courrier et de nouvelles / Rédaction: Standard MIME (Quoted Printable) sauf si vous êtes sûr que votre destinataire peut recevoir le 8 bits).
Options / Encodage du document: Occidental (Latin1). C'est l'ISO 8859-1.
Pour limiter la charge des serveurs de messagerie, la TOTALITÉ DES LISTES INTERDISENT LES ATTACHEMENTS.
C'est à dire que vous ne devez pas envoyer un fichier directement à la liste, mais seulement à ceux qui vous l'ont demandé. Vérifiez toujours la liste des destinataires avant d'envoyer un message. Pensez qu'un fichier de 100Ko, expédié aux 300 membres d'une liste, génère un trafic de 30 Mo. Si les membres de la liste sont connectés en 28800, cela correspond à près de 4 heures de connexion et à un revenu supplémentaire de 80 francs pour France Télécom. Plus grave, le serveur de messagerie gérant la liste sera embouteillé et les messages seront tous retardés.
Récemment, sur une liste du serveur de Rennes, un fichier de 10Mo a été envoyé à une liste comprenant près d'un millier d'utilisateur. Ce sont donc 10 Go qui ont saturé le réseau. Pensez au nombre d'utilisateurs dont le courrier a été totalement bloqué pendant des heures. Un administrateur de réseau a du faire 600 km pour dépanner sa messagerie bloquée. Le coût de cette bévue a certainement été monstrueux.
Mais beaucoup d'utilisateurs envoient, sans s'en rendre compte, des attachements sur les listes. Deux raison à cette erreur: la volonté d'envoyer des messages enrichis (RTF), et l'envoi de documents sous la forme de pages WEB.
Vous devez donc envoyer uniquement des messages en text seul (TEXT / BRUT).
Le format RTF (texte enrichi) double le volume des messages. Quand vous écrivez à une liste, vous devez donc désactiver le RTF. Vous perdrez la possibilité de vous exprimer en couleur, mais reconnaissez que la quasi-totalité des messages n'y perdra pas. Lorsque vous recevrez votre facture de téléphone, vous serez sans doute heureux de savoir qu'elle pourrait être deux fois plus importante ;-)
Vous reconnaîtrez facilement un fichier enregistré au format RTF, car il comporte un attachement en base64 ou en HTML. Si votre reader est compatible avec ce format, vous verrez des caractères colorés.
De plus en plus de logiciels permettent d'envoyer les messages sous la forme de Pages WEB. Cette initiative de Netscape a été reprise par Microsoft. Elle restait relativement rarement utilisée, mais depuis la sortie d'Outlook Express de Microsoft, c'est une véritable avalanche de fichiers images attachés qui déferlent dans les messages.
Il est donc extrêmement important de bien veiller à ne pas utiliser un papier peint (Outlook Express) ou un modèle contenant des images de fond d'écran (Exchange ou Outlook 97).
Chaque mailing list a sa propre étiquette. Vous devrez donc la consulter pour éviter de choquer les colistiers. Elle peut se consulter sur le site HTTP de l'organisme qui propose la liste
Pour quitter une liste, il y a plusieurs possibilités.
Vous devez généralement envoyer une commande au robot qui gère la liste. ATTENTION, vous ne devez jamais envoyer cette commande sur la liste elle-même. Les adresses de la liste et du robot sont généralement indiquées sur votre confirmation d'abonnement.
Cette commande est du genre Signoff nom_de_la_liste ou Unsubscribe nom_de_la_liste. Ce message adressé au robot doit ne comporter que cette ligne. Dans certains cas, il vous faudra aussi rajouter votre adresse E-Mail, celle avec laquelle vous recevez votre courrier. Pour que la commande soit acceptée par le serveur, il faut que la commande soit envoyée à partir de la même adresse que la commande qui a servi à vous abonner.
Certains organismes proposent un abonnement, et désabonnement à partir d'un site WEB. Dans ce cas, vous aurez un message de confirmation à renvoyer sans le modifier.
Par exemple, pour scsi@ldt.proto.education.gouv.fr, allez sur http://www.francopholistes.com/scsi@ldt.proto.education.gouv.fr/ et cliquez sur désinscrire dans le formulaire.
ATTENTION ! Sur beaucoup de listes, une infraction à ses règles peut se traduire par une flamme. Vous risquez alors de recevoir une multitude de messages de protestation, et , beaucoup plus gênant, des dizaines, voire des centaines de copies de votre message qui devraient vous bloquer pendant quelques heures.
Le modérateur de la liste, après un avertissement vous exclura également de la liste. Si vous aviez commis une erreur, la moindre des politesse est de vous en excuser, se tromper est humain disaient les latins, mais ce n'est pas une excuse pour être sans-gêne.
1969 Arpanet, l'ancêtre d'Internet était un réseau d'ordinateurs militaires aux États-Unis reliés par un maillage destiné à éviter les risques de coupure de transmission en cas d'attaque d'un élément de la structure.
1972 Le réseau militaire comprends alors 37 nuds couvrant le territoire des États-Unis.
1974 le réseau militaire adopte un standard de communication inter-réseau TCP-IP développé par les universités américaines.
1977 Les militaires inquiets du développement du réseau universitaire et craignant des fuites, décident de se désolidariser. Les universités se sont alors retrouvées seuls usagères du réseau qui peu à peu pris le sobriquet d'Internet.
Dès 1984 Internet s'enrichit de grandes bases de données en ligne, celles de la NASA ou de la NSF. À la fin de la décennie, près de quatre millions d'utilisateurs universitaires et scientifiques pouvaient dialoguer, EN ANGLAIS.
En effet, Internet n'est pas encore très convivial, il est en mode texte, et pour "aller" d'un point à l'autre, il faut taper les adresses des sites que l'on veut contacter, pas de clics sur des liens hypertextes et autres astuces qui facilitent aujourd'hui nos navigations.
1991 Les chercheurs du CERN inventent le langage HTML, langage permettant à l'aide de liens de naviguer de site en site sans être obligé de saisir l'adresse des différents sites. La toile (le WEB) devient un peu plus accessible. Ce n'est cependant que deux ans plus tard (en 1993), que le logiciel Mosaic premier navigateur WEB rendra la navigation aussi simple que celle que nous connaissons aujourd'hui.
1994 Maintenant que la navigation est conviviale, AOL, le "Minitel" américain, décide d'offrir un accès Internet à son million d'abonnés. Immédiatement, 600000 nouveaux utilisateurs débarquent sur le Net. Je pense que c'est de cette époque que date le mépris des AOLiners. En effet, les professionnels virent d'un assez mauvais oeil le débarquement d'utilisateurs néophytes. Cependant, le grand mouvement de démocratisation du Net était amorcé.
Très rapidement, des sociétés proposèrent de relier les particuliers et les entreprises, ces ISP (Internet Service Providers / Fournisseurs d'accès Internet) se créèrent dans le monde entier, y compris dans des pays non anglophones.
Parmi les nouveaux utilisateurs non-anglophones certains souhaitaient s'exprimer dans leurs langues naturelles. Malheureusement, nombre d'entre elles, sont truffées de signes diacritiques que les initiateurs américains d'Arpanet / Internet n'avaient pas envisager. Ainsi, tous les échanges se faisaient avec un jeu de caractères réduits, les 64 caractères US-ASCI.
Il existe un dispositif de régulation, l'InterNIC, qui dispose de la gestion des adresses Internet. Cet organisme gère les TLDs (Top Level Domains) qui comprennent les .COM .NET et .ORG. Les .FR sont gérés par une "antenne" française. Ce monopole est remis en questions par diverses sociétés, dont l'AlterNIC.
Personne ne "dirige" Internet (pour l'instant ?). Il existe cependant la diffusion de textes de références, les RFCs (Requests for Comments). Ce sont ces RFCs qui définissent les formats de mails, les protocoles et tout ce qui est nécessaire à la standardisation des échanges. La plus ancienne concernant le courrier date du 20 juillet 1971 (RFC 196). La plus célèbre est la 822 du 13 août 1982. Elle est obsolète, mais a servi de référence pour l'établissement du standard du courrier en langue anglaise. Cette norme n'accepte strictement que les caractères US-ASCI.
Les RFCs concernant format Mime sont les : 1344 du 11/6/92 - 1426 du 10/2/93 - 1428 du 10/2/93 - 1437 du 1/4/93 - 1496 du 26/8/93 - 1521 du 23/9/93 - 1522 du 23/9/93 - 1523 du 23/9/93 - 1556 du 23/12/93 - 1563 du 10/1/94 - 1641 du 13/7/94 - 1652 du 18/7/94 - 1740 du 22/12/94 (MacMIME) Mime pour les Macs - 1741 du 22/12/94 - 1767 du 2/3/95 - 1820 du 22/8/95 - 1830 du 16/8/95 - 1844 du 24/8/95 - 1847 du 3/10/95, messages encryptés - 1848 du 3/10/95 - 1872 du 26/12/95, Mime Multipart - 1896 du 19-2-96 Texte enrichi - 1927 du 1/4/96 - 2015 du 14/10/96 Sécurité avec PGP (Pretty Good Privacy (cryptage)) - 2017 du 14/10/96 URLs dans messages - 2045 du 2/12/96 - 2046 du 2/12/96 - 2047 du 2/12/96 En-têtes pour caractères non ASCII - 2048 du 28/1/97 - 2049 du 2/12/96 - 2110 du 12/3/97, intégration de documents HTML - 2112 du 12/3/97.
Document préparé par Bernard-Yves COCHAIN / Studio_byc@4u.net
16 novembre 1997