Leçon d’histoire : Qu’est-ce qu’un fichier .txt ? Pourquoi les vieux textes affichent des caractères étranges

Qu’est-ce qu’un fichier .txt ?

Ouvrez un .txt dans n’importe quel éditeur et vous ne voyez que des caractères : lettres, chiffres, ponctuation, espaces et retours à la ligne. C’est tout le format. Pas d’en-tête, pas de police, pas de gras ni d’italique, pas de taille de page, pas de trace de la langue du texte. Ce que le fichier contient vraiment, c’est une suite d’octets (des nombres de 0 à 255), et le programme qui l’ouvre doit décider quel caractère correspond à chaque nombre. L’extension « .txt » indique seulement à Windows quel programme proposer ; elle ne dit rien sur la façon de lire les octets. C’est pourquoi le texte brut est l’un des formats les plus portables jamais conçus, et l’un des plus faciles à mal lire.

Pourquoi mon fichier .txt affiche-t-il des caractères étranges ?

Parce que le programme qui lit le fichier utilise un encodage de caractères différent de celui du programme qui l’a écrit. Une même lettre peut être stockée sous des octets différents : é est l’octet unique E9 en Windows-1252, la page de codes que Microsoft décrit comme la page habituelle pour l’anglais et d’autres langues d’Europe occidentale, mais les deux octets C3 A9 en UTF-8. Ouvrez un fichier UTF-8 comme du Windows-1252 et chaque é devient é. L’apostrophe typographique ’ (E2 80 99 en UTF-8) devient ’. Un fichier UTF-8 qui commence par une marque d’ordre des octets (BOM, expliquée plus bas) débute par . Dans l’autre sens, si vous ouvrez un fichier Windows-1252 comme de l’UTF-8, l’octet E9 isolé n’est pas de l’UTF-8 valide et le programme affiche le caractère de remplacement �.

Les fichiers de l’époque DOS se trompent autrement. Sur l’IBM PC d’origine, un même octet pouvait être encore un autre caractère : dans la page de codes 437, le jeu de caractères de DOS, l’octet 82 est é et les cinq octets C9 CD CD CD BB dessinent le haut d’un cadre (╔═══╗). Windows les lit comme de la page de codes 1252 et affiche ‚ et ÉÍÍÍ», si bien que le mot café devient caf‚ et que le cadre de la bannière d’un README se change en lettres.

Aucun programme ne peut toujours trancher seul. En 2007, Raymond Chen, de Microsoft, a montré le dilemme du Bloc-notes avec un fichier de deux octets, D0 AE. Lu comme du Windows-1252, ce sont les caractères Ю ; lu comme de l’UTF-8, c’est la lettre cyrillique Ю ; lu comme de l’UTF-16 (deux octets par caractère), c’est une unique syllabe du hangul coréen, différente selon l’ordre des octets. Il soulignait que les quatre lectures sont plausibles. Sans étiquette dans le fichier, « étrange » est simplement l’allure d’une mauvaise supposition.

1963 : l’ASCII donne un numéro à 128 caractères

Pour que le texte brut devienne un fichier, il fallait des numéros de caractères sur lesquels les machines s’accordent. L’American Standards Association a créé en août 1960 un sous-comité pour les jeux de caractères codés et, le 17 juin 1963, elle a approuvé la norme X3.4-1963, l’American Standard Code for Information Interchange : l’ASCII. C’était un code sur 7 bits à 128 valeurs pour les caractères de contrôle, les chiffres, la ponctuation et l’alphabet anglais. L’édition de 1963 était sciemment incomplète, une bonne partie de la table restant à attribuer. Un avis de 1967 sur la révision approuvée le 7 juillet 1967, X3.4-1967, disait que la plupart des participants au projet ASCII y voyaient le premier véritable achèvement du code de base sur 7 bits.

Sept bits ne tiennent pas proprement dans un octet. L’un des premiers documents à dire quoi faire est la RFC 20, écrite par Vint Cerf en octobre 1969 pour l’ARPANET naissant, le réseau de recherche qui a précédé Internet. Elle proposait de l’« ASCII standard sur 7 bits intégré dans un octet de 8 bits dont le bit de poids fort est toujours 0 ». C’est ce huitième bit inutilisé qui sème ensuite la pagaille : dès qu’un octet peut contenir 256 valeurs, les 128 autres sont libres pour qui veut les attribuer.

CR, LF ou les deux : comment une ligne se termine

L’ASCII a aussi codé la mécanique du téléscripteur. Comme l’explique Chen, le retour chariot (CR) ramenait la tête d’impression à la colonne 0 sans faire avancer le papier, et le saut de ligne (LF) faisait avancer le papier d’une ligne sans bouger la tête : commencer une nouvelle ligne demandait donc les deux. L’édition de 1968 de l’ASCII, reproduite dans la RFC 20, permet à LF de signifier « Nouvelle ligne », mais ajoute que l’utiliser « exige un accord entre l’émetteur et le destinataire des données ». Cet accord n’est jamais vraiment venu. La RFC 20 elle-même note que les premiers sites de l’ARPANET divergeaient : SRI utilisait un point comme caractère de fin de ligne, tandis que l’UCLA utilisait le retour chariot.

CP/M, MS-DOS et Windows ont gardé les deux caractères, CRLF (les octets 0D 0A). Unix s’est contenté d’un seul LF (0A). L’annonce de Microsoft de 2018 sur le nouveau comportement du Bloc-notes énumère les trois conventions qu’il gère désormais : fins de ligne Unix/Linux (LF), Macintosh (CR) et Windows (CRLF). Jusque-là, disait-elle, le Bloc-notes ne savait afficher correctement que les fins de ligne Windows, si bien qu’un fichier texte créé sous Unix ou Linux paraissait brouillé. La correction est arrivée dans les versions Insider de Windows 10 en mai 2018.

1981 : les 128 autres valeurs partent chacune de leur côté

L’IBM PC est arrivé en 1981 avec des octets de 8 bits et une norme sur 7 bits. David Bradley, l’un de ses ingénieurs, s’est souvenu plus tard que le PC « utilisait le jeu de caractères ASCII, un changement radical pour un produit IBM » (les produits IBM antérieurs utilisaient l’EBCDIC) et que, avec 128 nouvelles places à remplir, l’équipe les avait garnies de lettres de langues étrangères, de graphiques en blocs et de symboles mathématiques et grecs. Il disait aimer décrire ce jeu de caractères comme développé lors d’« une réunion de trois personnes de quatre heures ». Le résultat est la page de codes 437, que Microsoft appelle la page OEM (DOS) habituelle pour l’anglais : sa moitié haute contient des lettres accentuées, des caractères de tracé de lignes et des symboles.

Windows a ensuite créé ses propres pages de codes. La documentation de Microsoft explique que la page de codes 1252 de Windows reposait à l’origine sur un projet de l’American National Standards Institute (ANSI) devenu finalement l’ISO 8859-1, mais qu’elle a été mise en œuvre avant que la norme soit définitive et n’est pas exactement identique. On appelle encore couramment les pages de codes de Windows des « pages de codes ANSI », bien qu’elles soient propres à Microsoft. Toutes s’accordent avec l’ASCII pour les valeurs 0 à 127 et divergent au-delà : l’octet E9 est é en page 1252, й dans la page cyrillique 1251 et ι dans la page grecque 1253. Le japonais et le chinois utilisaient des pages de codes à deux octets, où certains octets n’ont de sens qu’avec l’octet qui suit. Microsoft note qu’aucune page de codes ne couvre tout ce que couvre Unicode.

1992 : Unicode, et un set de table dans un diner du New Jersey

Unicode a pris l’approche inverse : un numéro pour chaque caractère, et fini le jonglage entre pages de codes. Dans sa première version, de 1991 à 1995, c’était un encodage sur 16 bits ; depuis Unicode 2.0, en juillet 1996, il couvre la plage U+0000 à U+10FFFF. Mais un numéro n’est pas un fichier. Stocker directement des valeurs de 16 bits dans des fichiers heurtait les logiciels Unix de l’époque, qui s’appuyaient sur des octets ASCII comme l’octet nul et la barre oblique, et en 1992 un comité de X/Open étudiait une façon de stocker Unicode compatible avec Unix.

Rob Pike, alors aux Bell Labs, a écrit en 2003 que l’UTF-8 « a été conçu, sous mes yeux, sur un set de table dans un diner du New Jersey un soir de septembre 1992 environ ». Des membres du comité avaient demandé à lui et à Ken Thompson d’examiner leur proposition. Les deux sont allés dîner, Thompson a imaginé l’empaquetage des bits, puis ils ont téléphoné au comité. Pike raconte que Thompson a écrit le code d’empaquetage et de dépaquetage dans la nuit, et que le vendredi leur système d’exploitation, Plan 9, ne fonctionnait plus qu’avec ce qu’on appellerait l’UTF-8. Des archives de courriels retrouvées par son collègue Russ Cox datent la proposition du début de septembre 1992.

L’UTF-8 stocke chaque caractère sur un à quatre octets. Les 128 caractères ASCII gardent leur valeur sur un seul octet, et aucun octet d’un autre caractère ne ressemble à de l’ASCII : un fichier ASCII pur est donc déjà de l’UTF-8 valide. Tout le reste prend de deux à quatre octets, avec des bits de tête qui indiquent au lecteur la longueur de la séquence : é devient C3 A9. La RFC 3629 de François Yergeau (novembre 2003) en a fait une norme de l’Internet, et la FAQ d’Unicode l’appelle « la forme préférée pour les fichiers texte Unicode ».

Le BOM, et pourquoi le Bloc-notes devait deviner

L’UTF-16 stocke les caractères en unités de 16 bits : le lecteur doit donc aussi connaître l’ordre des octets. La réponse d’Unicode est un caractère, U+FEFF, placé tout au début du fichier comme signature : la marque d’ordre des octets. En UTF-8, elle apparaît sous la forme des octets EF BB BF, et la FAQ d’Unicode est explicite : là, elle n’a rien à voir avec l’ordre des octets, elle indique seulement que le fichier est en UTF-8. Elle ajoute que certains programmes ne l’attendent pas (la première ligne d’un script shell Unix, qui commence par #!, en est un exemple) et qu’un protocole comme les « conventions Microsoft pour les fichiers .txt » peut l’exiger. Un .txt peut donc commencer par un BOM ou non, et quand il n’y en a pas, le programme doit deviner.

Le billet de Chen de 2007 sur « le problème d’encodage des fichiers du Bloc-notes » explique pourquoi deviner finit toujours mal. Les fichiers avec BOM sont faciles. Sans BOM, la plupart des fichiers texte dans la nature étaient de l’ANSI sur 8 bits, certains fichiers UTF-8 et UTF-16 n’avaient pas de BOM non plus, et chaque règle qu’il essayait favorisait un groupe et en cassait un autre. Son exemple : la commande cmd /u /c dir >results.txt écrit un fichier UTF-16 sans BOM.

Microsoft a modifié le Bloc-notes en deux temps. En 2018, il a appris les fins de ligne Unix et Mac. Puis, dans la version Insider 18298 de Windows 10, le 10 décembre 2018, Microsoft a ajouté l’option d’enregistrer en UTF-8 sans BOM, en a fait le choix par défaut pour les nouveaux fichiers et a placé l’encodage dans la barre d’état, expliquant que l’UTF-8 sans BOM est rétrocompatible avec l’ASCII et fonctionne mieux avec le Web, « où l’UTF-8 est devenu l’encodage par défaut ». Le changement est arrivé pour tout le monde avec Windows 10 version 1903, la mise à jour de mai 2019. Avant, un nouveau fichier du Bloc-notes était enregistré en ANSI par défaut.

2007 et après : l’UTF-8 conquiert le Web

Google a indiqué qu’en décembre 2007 Unicode était devenu pour la première fois l’encodage le plus fréquent sur les pages Web qu’il indexait, dépassant l’ASCII et les encodages d’Europe occidentale à dix jours d’intervalle. W3Techs relève aujourd’hui l’UTF-8 sur 99,1 % des sites Web dont il peut identifier l’encodage (novembre 2026). C’est une statistique sur les sites Web. Les fichiers texte qui dorment sur de vieux disques n’ont jamais fait partie de ce basculement, et personne n’est revenu les réencoder.

Pourquoi les .txt de vieux disques sont encore illisibles en 2026

Les logiciels d’aujourd’hui supposent de l’UTF-8, mais beaucoup de textes ont été écrits avant : README DOS, premières notes sous Windows, exports de programmes qui ne tournent plus, courriels ou journaux enregistrés en texte. Ils sont dans la page de codes du PC qui les a produits, selon sa langue et sa version de Windows, et ne portent aucune étiquette. Ajoutez des fins de ligne venues d’un autre système et le fichier UTF-16 sans BOM de temps en temps : la même extension .txt cache plusieurs formats sans rapport. Beaucoup sont des fichiers legacy dont personne ne peut interroger le programme d’origine.

Legacy File Converter range le texte brut (.txt) parmi les documents de sa page Types de fichiers pris en charge et les convertit sur votre propre PC Windows vers des formats modernes comme DOCX, PDF, Markdown ou HTML ; rien n’est envoyé. Ensuite, comparez les lettres accentuées, les guillemets et les symboles avec l’original, et gardez le fichier d’origine. Pour d’autres formats qui sont surtout du texte en dessous, voir la Leçon d’histoire : Qu’est-ce qu’un fichier .csv ?, où l’absence de BOM fait trébucher Excel, et la Leçon d’histoire : Qu’est-ce qu’un fichier .rtf ?.