Note sur les fichiers de caractères

Cours PLURITAL n°1 du 02/10/2007 revu le 5/11/2011

Jean-François Perrot

  1. Texte pur et texte mis en forme
    1. Le texte et sa mise en forme
    2. Différents types de fichiers
    3. Codage des caractères
    4. Codage de la mise en forme

  2. Le texte (ASCII) comme format d'échange
    1. Emballage pour le voyage
    2. Pourquoi préférer le texte (ASCII) ?
    3. Codage binaire vers texte (ASCII)
    4. Coder la mise en forme en ASCII

  3. L'exemple de RTF

  4. L'exemple de HTML

  5. Conclusion

  1. Texte pur et texte mis en forme

    1. Le texte et sa mise en forme

      Un texte se présente toujours de manière concrète sur une feuille de papier - ou sur un écran -
      écrit avec une certaine police de caractères, dans un certain corps, etc, donc dans une certaine typographie (voir cours n°2),
      une certaine mise en pages, voire un illustration, bref dans une certaine mise en forme.

      Mais nous savons faire abstraction de cette mise en forme pour obtenir le texte "abstrait", ou "proprement dit" (les informaticiens disent "texte pur").
      Par exemple, le texte de La Princesse de Clèves...
      Si nous travaillons avec un logiciel de traitement de textes comme Microsoft Word, ou OpenOffice, cette abstraction est effectuée par la commande
      Enregistrer sous... en format Texte seulement (ou Texte seulement avec sauts de ligne).

    2. Différents types de fichiers

      Du point de vue de la machine, les fichiers contenant du texte mis en forme sont d'un type différent de ceux qui contiennent du texte pur.

      Dans la pratique courante, les fichiers "avec mise en forme" sont confiés à Microsoft Word - ou à OpenOffice -
      et ils portent l'extension ".doc" - ou ".odt" -
      tandis que les fichiers de texte pur peuvent être traités indifféremment par toute une classe de logiciels (éditeurs de texte),
      et portent en général l'extension ".txt".

      Dans le système de conventions MIME dont nous parlerons au cours n°3, les premiers portent l'étiquette "Content-Type: application/msword;" - ou "Content-Type: application/octet-stream;"-
      et les seconds l'étiquette "Content-Type: text/plain;".

    3. Codage des caractères

      Un fichier-texte ("en texte pur") est donc un fichier dont le contenu (séquence d'octets) a vocation à être interprété simplement comme comme une séquence de caractères (le degré zéro du texte).

      • Si on se limite aux caractères ASCII, un fichier-texte est un fichier dont tous les octets sont des octets ASCII (dont le 8ème bit est 0).
        Il s'agit donc d'une caractéristique intrinsèque du fichier, aisément vérifiable par n'importe quel logciel de traitement.
        Pendant longtemps, les seuls fichiers-textes en circulation ont été de ce genre (textes de programmes -en C, en JavaScript, etc.-,
        ou fichers de documentation), entièrement en anglais ou dans d'autre langues à l'orthographe plus ou moins massacrée.

      • Si on veut s'affranchir de cette limitation, alors il faut trouver un moyen pour indiquer comment les caractères sont représentés
        (dans le jargon technique : le codage des caractères, en anglais character encoding)...
        En général, cette indication figure dans l'en-tête du fichier, elle-même rédigée entièrement en ASCII,
        suivant des modalités qui varient selon le type du fichier.
        Pour un fichier XML, l'en-tête en question pourra être
            <?xml version="1.0" encoding="iso-8859-1"?>
        mais dans un fichier HTML on trouvera par exemple
            <html>
              <head>
               <meta content="text/html; charset=iso-8859-1" http-equiv="content-type">
               ....
              </head>
        Dans le système MIME, cette information complète l'étiquette "Content-Type: text/plain;" avec la mention "charset=iso-8859-1;".

        En l'absence d'une indication de ce genre, le logiciel chargé du traitement pourra
        • soit appliquer un codage par défaut - et peut-être se tromper, ou tout simplement refuser de lire
        • soit interroger l'utilisateur sur le choix du codage (illustration)

    4. Codage de la mise en forme

      Un fichier ".doc" ne peut être traité que par le logiciel Microsoft Word, il est donc inutilisable sur une machine où Word n'est pas installé.
      Plus précisément, dans un tel fichier, le contenu "texte pur" (lisible) est mélangé avec les indications de mise en forme (illisibles),
      comme on le voit si on essaie de lire un tel fichier avec un éditeur de texte standard.

      Pour faciliter l'interopération, on a mis au point divers procédés pour coder les indications de mise en forme par des marques écrites dans le texte,
      ces marques étant elles-mêmes réalisées comme des fragments de texte supplémentaires.
      La machine est en effet malhabile à interpréter des symboles spéciaux comme les marques typographiques,
      en revanche elle sait très bien donner un sens spécial à certaines chaînes de caractères : voyez les balises des Markup Languages.

      On aboutit ainsi à des fichiers-textes dont une partie code la mise en forme du reste.
      Exemple typique : pour obtenir une mise en forme comme

      "Mettre ceci en italiques et ceci en gras !"

      on écrira en texte pur
      "Mettre ceci <i>en italiques</i> et ceci <b>en gras</b> !" (HTML)
      ou
      "Mettre ceci {\i en italiques} et ceci {\b en gras} !" (RTF)
      ou encore
      "Mettre ceci \emph{en italiques} et ceci \textbf{en gras} !" (LaTeX).

      Soulignons que la notion de codage qui apparaît ici pour la mise en forme est totalement distincte de
      celle de codage des caractères (character encoding) mentionnée au paragraphe précédent.
      L'idée de coder l'information, et de la permanence de l'information à travers les codages-décodages, est omniprésente en informatique.
      Pour donner un sens précis au mot codage, il faut donc prendre garde au contexte où il est employé !
      Nous allons voir plus loin une troisième sorte de codage...

      Nous examinerons brièvement ici les deux systèmes RTF et HTML.
      Signalons au passage que l'évolution commencée chez Microsoft avec RTF aboutit aujourd'hui au format ".docx" où le document "avec mise en forme"
      est réalisé comme un ensemble de fichiers-textes (en l'occurrence, des fichiers XML)

  2. Le texte (ASCII) comme format d'échange

    1. Emballage pour le voyage

      Il faut soigneusement distinguer deux situations pour un fichier :
      • installé bien au chaud sur le disque d'un ordinateur
      • en voyage sur le réseau

      En principe, un fichier pris sur le disque peut être envoyé sur le réseau sans autre forme de procès :
      après tout, il ne s'agit jamais que d'une séquence d'octets...
      De même un flot d'octets arrivant du réseau vient s'inscrire sur le disque et devient un fichier.

      En pratique les choses sont un peu différentes, non pas tant à cause des contraintes propres au réseau qu'en raison des différences entre les machines.
      Il s'ensuit qu'un fichier voyage souvent sous une la forme d'un texte ASCII
      - ce qui nécessite qu'il soit codé avant l'envoi et décodé à la réception.

    2. Pourquoi préférer le texte (ASCII) ?

      Les différentes machines interprètent l'information binaire chacune à sa manière.
      Bornons-nous à évoquer ici la question des processeurs gros-boutiens et petit-boutiens
      (en anglais big-endian/little-endian) : cette distinction, empruntée aux Voyages de Gulliver,
      vise l'ordre dans lequel les octets sont interprétés (par exemple, pour y lire un nombre).
      Pour une définition, voir l'article de Wikipédia, et pour la terminologie un débat sur la liste Debian.

      Il en résulte qu'un fichier binaire aura sur des machines différentes des interprétations différentes,
      ce qui nuit gravement à la communication.
      C'est pourquoi on emploie souvent les caractères ASCII comme étape intermédiaire d'interprétation :
      un fichier qui est réputé contenir uniquement des caractères ASCII est en principe interprété
      de la même manière par toutes les machines actuelles.
      Par exemple, c'est cette identité de traitement qui rend possible le courrier électronique :
      en principe, il doit être entièrement rédigé en ASCII,
      et on observe couramment que les caractères non-ASCII sont mal transmis ! Affaire à suivre au cours 3...
      Pour mieux comprendre la nécessité d'échanger de l'information sous forme textuelle et non sous forme binaire,
      ainsi que les modalités de ces échanges, voyez la série d'articles de Wikipedia (en anglais)
      • Binary to text encoding, où il est dit notamment :

        Many computer programs came to rely on this distinction between seven-bit text
        and eight-bit binary data, and would not function properly
        if non-ASCII characters appeared in data that was expected to include only ASCII text.
        For example, the value of the eighth bit might not be preserved,
        or the program might interpret a byte value above 127 as a flag telling it to perform some function.

      • Text file, et
      • Plain text, où on voit apparaître diverses nuances qui montrent bien que la question n'est pas simple !
      • MIME, système de conventions omniprésentes sur le réseau, dont nous reparlerons au cours 3.

    3. Codage binaire vers texte (ASCII)

      Les procédé utilisés pour convertir une séquence d'octets quelconques en une séquence ASCII sont nombreux et variés.
      Citons l'historique uuencode, et  sa variante BinHex.
      Nous examinerons au cours n°3 les codages utilisés aujourd'hui dans les échanges de courrier électronique :
      • Quoted-Printable bien adapté à des contenus ayant une forte proportion d'octets ASCII
      • Base64 utilisé notamment pour transmettre des images

      Répétons que la notion de codage qui apparaît ici est totalement distincte de celle de codage des caractères (character encoding)
      et de celle de codage de la mise en forme.

    4. Coder la mise en forme en ASCII

      Les fichiers-textes contenant du texte mis en forme (RTF, HTML, LaTeX, etc) voyagent eux aussi.
      La question de leur "emballage" se pose pour eux comme pour les autres !

      Observation :
      Les éléments codant la mise en forme (balises HTML, indications RTF ou LaTeX) sont écrits exclusivement en ASCII.

      Pour le texte proprement dit, deux attitudes, l'ancienne et la moderne :

      1. L'ancienne consiste à tout traduire en ASCII, suivant un procédé qui dépend du type de fichier.
        C'est le cas de RTF, du HTML d'autrefois, et de LaTeX employé sans recourir à des extensions comme XeTeX.
        • En RTF, les caractères non ASCII sont désignés par leur numéro Unicode en décimal, précédé de "\u",
          par exemple é = \u233 ,  à = \u224, etc.

        • En HTML à l'ancienne mode, les lettres accentuées étaient codées par une collection d'entités du genre
          é = &eacute;,   à = &agrave;, etc. (liste complète)

        • En LaTeX, les diacritiques sont indiqués par une commande commençant par '\', par exemple é = \'e ,  à = \`a, etc.

        On se ramène ainsi à un fichier en ASCII pur, qui peut voyager partout sans encombre.
        Le logiciel qui l'exploite à son arrivée est censé savoir opérer le décodage et retrouver les carctères d'origine.

      2. La moderne consiste à
        1. déclarer le codage des caractères employé, suivant une modalité qui dépend du type de fichier (XML, HTML ou autre),
          mais qui à coup sûr n'utilise que de l'ASCII.
        2. une fois cette déclaration faite, on peut écrire du texte avec le codage en question.

        • En HTML moderne, la déclaration du codage se fait dans l'en-tête <head> par une balise ainsi conçue :
          <meta content="text/html; charset=le-codage-employé" http-equiv="content-type">
          dont nous expliquerons la composition au cours n°3.
          Le caractère alambiqué de cette déclaration, et le fait qu'elle ne soit pas obligatoire,
          montre bien qu'il s'agit d'un perfectionnement récent, non d'un dispositif prévu dès l'origine.

        • En XML, au contraire, la déclaration fait partie intégrante de l'en-tête
          <?xml version='1.0', encoding = le-codage-employé ?>
          et si elle est omise le codage par défaut est Unicode utf-8, pas ASCII !

        • En LaTeX il convient de déclarer l'emploi de l'extension XeLaTeX, seule capable de traiter autre chose que l'ASCII,
          et ensuite le codage des caractères demandé, par exemple :
          %!TEX TS-program = xelatex
          %!TEX encoding = UTF-8 Unicode

      Exercice : inspectez (une partie de) la collection de fichiers disponibles sur votre ordinateur, et distinguez les anciens des modernes...
      Le présent fichier de cours, par exemple, où se range-t-il ?

  3. L'exemple de RTF


    Le format RTF (Rich Text Format) donne la possibilité d'échanger du texte mis en forme
    (avec des caractères gras, italiques, des choix de justification, des choix de polices, etc.)
    entre des logiciels d'édition normalement incompatibles. Ce format a été créé par Microsoft.
    Parmi les logiciels d'usage courant, Microsoft Word et OpenOffice savent lire et écrire en format RTF.
    Voyez les articles de Wikipédia à son sujet : en français, et (plus détaillé) en anglais.

    Pour comprendre de quoi il retourne, faites l'expérience suivante :
    1. téléchargez le petit fichier Ex.rtf (extrait de l'article de Wikipédia),
    2. inspectez-le avec hexdump (ou avec un éditeur de "texte pur" comme NotePad sous Windows),
      pour constater qu'il ne contient que de l'ASCII
    3. et ouvrez-le enfin avec Word (n'oubliez pas de lui donner l'extension ".rtf").
    Vous pourrez aisément fabriquer des fichiers RTF avec Word
    en utilisant le format Texte mis en forme (RTF) de la commande  Enregistrez sous... (menu Fichier).
    Essayez de retrouver le texte dans la masse d'informations que contient un tel fichier,
    et observez comment les caractères non-ASCII sont représentés.

    Exercice :  voici une image fidèle d'un fichier Word

    fichier Word


    Ce fichier a été sauvegardé en RTF, sous le nom ExRTF.rtf.
    Le fichier ExRTFb.rtf a été obtenu en supprimant dans ce fichier un grand nombre d'informations jugées superflues.
    1. Téléchargez-les tous les deux et vérifiez que Word vous restitue l'apparence illustrée ci-dessus pour l'un
      et une apparence un peu différente pour l'autre. Attention à bien les nommer avec l'extension ".rtf" !
    2. Quelles informations faut-il restituer à ExRTFb.rtf pour que le titre soit de nouveau centré ?
    3. Comment retrouver la différence de polices dans la ligne 3 ?
    Pour en savoir davantage...

  4. L'exemple de HTML

    5. Nous aurons l'occasion de revenir sur HTML (Hypertext Markup Language).
    Pour l'instant, nous en noterons deux aspects :
    1. Le codage des lettres accentuées : ces lettres sortent du répertoire ASCII, il faut donc les coder.
      Le procédé traditionnel est de les représenter par des "entités" (c'est le terme consacré dans la grammaire de HTML)
      qui sont de la forme "&", suivi d'une chaîne de caractères explicative à consonance anglaise, suivi de ";".
      Exemples :
      • "é" (e accent aigu) ==> &eacute;
      • "À" (a accent grave majuscule) ==> &Agrave;
      • "ô" (o accent circonflexe) ==> &ocirc;
      • "ç" (c cédille) ==> &ccedil;

    2. L'interprétation de certaines constructions syntaxiques pour engendrer une mise en pages.
      Contentons-nous d'observer avec un navigateur quelconque le code source (ou la page source)
      d'une page Web. Voici par exemple le début de la table du code ASCII :

      <table style="width: 100%; text-align: left;" border="2" cellpadding="2" cellspacing="2">
      <tbody><tr>
      <td>
      <table>
       <tbody>
       <tr>
       <th style="vertical-align: top;">D&acute;c</th>
       <th style="vertical-align: top;"> Hex</th>
       <th style="vertical-align: top;">Car</th>
       </tr>
       <tr>
       <td style="vertical-align: top;">00</td>
       <td style="vertical-align: top;">00</td>
       <td style="vertical-align: top;">NUL</td>
       </tr>

      On voit que l'effet de mise en table est produit par l'interprétation que le navigateur donne de la structure
      <table>... <tr><td> ... </td> ...</tr> ... </table>
      qui est elle-même entièrement rédigée en ASCII (et transmis comme tel sur le réseau).

  5. Conclusion

    À titre de comparaison, pour voir à quoi ressemble un fichier qui n'est pas un fichier-texte,
    regardez avec hexdump le petit fichier-image flip.gif ...

    Les exemples RTF et HTML font apparaître l'ambiguïté du rôle des caractères ASCII :
    Comme nous le verrons dans la suite, dans le premier rôle les caractères ASCII seront remplacés par les caractères Unicode,
    tandis qu'ils resteront immuables dans leur rôle de métacaractères.
    Ce qui fait que la notion de "fichier-texte" est en train d'évoluer :
    de "fichier en ASCII pur" on en vient à "fichier de caractères Unicode",
    ce qui est par exemple le point de vue adopté par Java dès  l'origine de ce langage.

    Toutefois, comme nous le verrons, il ne suffit pas de dire "Unicode" pour spécifier une norme opérationnelle,
    il faut encore dire coment Unicode est représenté en machine.
    Sur ce point, l'événement majeur est l'adoption par XML du codage Unicode utf-8 comme "codage par défaut",
    si bien qu'un fichier XML est, sauf mention contraire, un fichier de caractères en utf-8.
    Et comme HTML est vu à présent, sous sa forme XHTML, comme un dialecte de XML,
    cette évolution favorable s'étend à tout Internet.

    Les logiciels modernes savent traiter utf-8 aussi bien qu'ASCII, les machines sont bien assez puissantes
    l'espace-mémoire suffisamment vaste et les réseaux assez rapides pour absorber quelques octets supplémentaires.
    La généralisation de cet usage est donc affaire de changement d'habitudes de la part des utilisateurs.
    Il s'agit de mieux utiliser les ressources dont nous disposons.
    Le but de ce cours est de vous y aider.