Geschiedenisles: Wat is een .txt-bestand? Waarom oude tekstbestanden vreemde tekens tonen

Wat is een .txt-bestand?

Open een .txt-bestand in een willekeurige editor en je ziet alleen tekens: letters, cijfers, leestekens, spaties en regeleinden. Dat is het hele formaat. Er is geen koptekst, geen lettertype, geen vet of cursief, geen paginagrootte en geen vermelding van de taal van de tekst. Wat het bestand werkelijk bevat is een rij bytes, getallen van 0 tot 255, en het programma dat het opent moet bepalen voor welk teken elk getal staat. De extensie ‘.txt’ vertelt Windows alleen welk programma het moet aanbieden; over hoe de bytes gelezen moeten worden zegt ze niets. Daarom is platte tekst een van de meest overdraagbare formaten ooit en tegelijk een van de makkelijkst verkeerd te lezen.

Waarom toont mijn .txt-bestand vreemde tekens?

Omdat het programma dat het bestand leest een andere tekencodering gebruikt dan het programma dat het schreef. Dezelfde letter kan als verschillende bytes zijn opgeslagen: é is de enkele byte E9 in Windows-1252, de codepagina die Microsoft omschrijft als de gebruikelijke voor Engels en andere West-Europese talen, maar de twee bytes C3 A9 in UTF-8. Open je een UTF-8-bestand als Windows-1252, dan wordt elke é é. De typografische apostrof ’ (E2 80 99 in UTF-8) wordt ’. Een UTF-8-bestand dat begint met een byte order mark (BOM, hieronder uitgelegd) begint met . Andersom, als een Windows-1252-bestand als UTF-8 wordt geopend, is de losse byte E9 geen geldige UTF-8 en toont het programma het vervangingsteken �.

Bestanden uit het DOS-tijdperk gaan op een andere manier mis. Op de oorspronkelijke IBM PC kon dezelfde byte weer een ander teken zijn: in codepagina 437, de DOS-tekenset, is byte 82 een é en tekenen de vijf bytes C9 CD CD CD BB de bovenrand van een kader (╔═══╗). Windows leest ze als codepagina 1252 en toont ‚ en ÉÍÍÍ», zodat het woord café caf‚ wordt en het kader van een README-banner in letters verandert.

Geen enkel programma kan altijd zelf goed raden. In 2007 liet Microsofts Raymond Chen het dilemma van Kladblok zien met een bestand van twee bytes, D0 AE. Gelezen als Windows-1252 zijn dat de tekens Ю; gelezen als UTF-8 is het de Cyrillische letter Ю; gelezen als UTF-16 (twee bytes per teken) is het één Koreaanse hangul-lettergreep, een andere voor elke bytevolgorde. Hij wees erop dat alle vier de leesmanieren aannemelijk zijn. Zonder label in het bestand is ‘vreemd’ gewoon hoe een verkeerde gok eruitziet.

1963: ASCII geeft 128 tekens een nummer

Voordat platte tekst een bestand kon zijn, hadden tekens nummers nodig waarover verschillende machines het eens waren. De American Standards Association richtte in augustus 1960 een subcommissie voor gecodeerde tekensets op en keurde op 17 juni 1963 norm X3.4-1963 goed, de American Standard Code for Information Interchange: ASCII. Het was een 7-bitscode met 128 waarden voor besturingstekens, cijfers, leestekens en het Engelse alfabet. De uitgave van 1963 was bewust onvolledig, een groot deel van de tabel was nog niet toegewezen. Een bericht uit 1967 over de op 7 juli 1967 goedgekeurde herziening, X3.4-1967, zei dat de meeste betrokkenen bij het ASCII-project haar zagen als de eerste echte voltooiing van de basiscode van 7 bits.

Zeven bits passen niet netjes in een byte. Een van de eerste documenten die zegt wat je daarmee moet doen, is RFC 20, geschreven door Vint Cerf in oktober 1969 voor het vroege ARPANET, het onderzoeksnetwerk dat aan het internet voorafging. Het stelde ‘standaard 7-bits ASCII ingebed in een 8-bits byte waarvan het hoogste bit altijd 0 is’ voor. Dat ongebruikte achtste bit is waar de problemen later beginnen: zodra een byte 256 waarden kan bevatten, zijn de andere 128 vrij voor wie ze maar wil toewijzen.

CR, LF of beide: hoe een regel eindigt

ASCII codeerde ook de mechaniek van de telex. Zoals Chen uitlegt, bracht de regelterugloop (CR) de printkop terug naar kolom 0 zonder het papier te verplaatsen, en de regelinvoer (LF) schoof het papier één regel op zonder de kop te bewegen, dus voor een nieuwe regel waren beide nodig. De uitgave van ASCII uit 1968, weergegeven in RFC 20, laat LF ‘nieuwe regel’ betekenen, maar voegt toe dat het gebruik daarvan ‘overeenstemming tussen zender en ontvanger van gegevens vereist’. Die overeenstemming kwam er nooit helemaal. RFC 20 zelf vermeldt dat de eerste ARPANET-locaties het oneens waren: SRI gebruikte een punt als regeleinde, UCLA de regelterugloop.

CP/M, MS-DOS en Windows behielden beide tekens, CRLF (de bytes 0D 0A). Unix volstond met één LF (0A). Microsofts aankondiging van 2018 over het nieuwe gedrag van Kladblok noemt de drie conventies die het nu aankan: Unix/Linux-regeleinden (LF), Macintosh-regeleinden (CR) en Windows-regeleinden (CRLF). Tot dan toe, zo stond erin, kon Kladblok alleen Windows-regeleinden goed weergeven, zodat een tekstbestand dat op Unix of Linux was gemaakt door elkaar gegooid leek. De oplossing kwam in mei 2018 in de Insider-builds van Windows 10.

1981: de andere 128 waarden gaan hun eigen weg

De IBM PC verscheen in 1981 met bytes van 8 bits en een standaard van 7 bits. David Bradley, een van de ingenieurs, herinnerde zich later dat de pc ‘de ASCII-tekenset gebruikte, een radicale verandering voor een IBM-product’ (eerdere IBM-producten gebruikten EBCDIC) en dat het team de 128 nieuwe plekken vulde met vreemdetalige letters, blokgrafiek en wiskundige en Griekse symbolen. Hij zei dat hij de tekenset graag omschreef als ontwikkeld in ‘een bijeenkomst van drie mensen van vier uur’. Het resultaat is codepagina 437, die Microsoft de gebruikelijke OEM-codepagina (DOS) voor Engels noemt: de bovenste helft bevat letters met accenten, lijntekens en symbolen.

Daarna bouwde Windows eigen codepagina’s. Volgens de documentatie van Microsoft was Windows-codepagina 1252 oorspronkelijk gebaseerd op een ontwerp van het American National Standards Institute (ANSI) dat uiteindelijk ISO 8859-1 werd, maar werd ze ingevoerd voordat de norm definitief was en is ze niet precies hetzelfde. Windows-codepagina’s heten nog steeds gewoonlijk ‘ANSI-codepagina’s’, hoewel ze van Microsoft zelf zijn. Ze komen allemaal overeen met ASCII voor de waarden 0 tot 127 en verschillen daarboven: de byte E9 is é in codepagina 1252, й in de Cyrillische codepagina 1251 en ι in de Griekse 1253. Japans en Chinees gebruikten dubbelbyte-codepagina’s, waarin sommige bytes pas iets betekenen samen met de byte die volgt. Microsoft merkt op dat geen enkele codepagina alles dekt wat Unicode dekt.

1992: Unicode en een placemat in een diner in New Jersey

Unicode koos de tegenovergestelde aanpak: één nummer voor elk teken, geen goochelen meer met codepagina’s. In de eerste versie, van 1991 tot 1995, was het een 16-bitscodering; sinds Unicode 2.0 in juli 1996 beslaat het het bereik U+0000 tot U+10FFFF. Maar een nummer is geen bestand. 16-bitswaarden rechtstreeks in bestanden opslaan botste met de Unix-software van die tijd, die steunde op ASCII-bytes zoals de nulbyte en de schuine streep, en in 1992 overwoog een X/Open-commissie een Unix-vriendelijke manier om Unicode op te slaan.

Rob Pike, toen bij Bell Labs, schreef in 2003 dat UTF-8 ‘werd ontworpen, voor mijn ogen, op een placemat in een diner in New Jersey op een avond in september of zo 1992’. Commissieleden hadden hem en Ken Thompson gevraagd hun voorstel te beoordelen. De twee gingen eten, Thompson bedacht de bitverpakking, en daarna belden ze de commissie. Pike zegt dat Thompson die nacht de pak- en uitpakcode schreef en dat hun besturingssysteem Plan 9 vrijdag al alleen draaide op wat later UTF-8 zou heten. Mailarchieven die zijn collega Russ Cox opgroef, dateren het voorstel begin september 1992.

UTF-8 slaat elk teken op in één tot vier bytes. De 128 ASCII-tekens behouden hun waarde van één byte, en geen enkele byte van een ander teken lijkt op ASCII, dus een zuiver ASCII-bestand is al geldige UTF-8. Al het andere neemt twee tot vier bytes in beslag, met voorloopbits die de lezer vertellen hoe lang de reeks is: é wordt C3 A9. RFC 3629 van François Yergeau (november 2003) maakte er een internetstandaard van, en de Unicode-FAQ noemt het ‘de voorkeursvorm voor Unicode-tekstbestanden’.

De BOM, en waarom Kladblok moest raden

UTF-16 slaat tekens op in eenheden van 16 bits, dus de lezer moet ook de bytevolgorde kennen. Het antwoord van Unicode is een teken, U+FEFF, helemaal aan het begin van het bestand als handtekening: de byte order mark. In UTF-8 verschijnt het als de bytes EF BB BF, en de Unicode-FAQ is duidelijk: daar heeft het niets met bytevolgorde te maken, het markeert het bestand alleen als UTF-8. De FAQ voegt toe dat sommige programma’s het niet verwachten (de eerste regel van een Unix-shellscript, die met #! begint, is een voorbeeld) en dat een protocol als de ‘Microsoft-conventies voor .txt-bestanden’ het kan eisen. Een .txt-bestand kan dus met een BOM beginnen of niet, en zonder BOM moet het programma raden.

Chens bericht uit 2007 over ‘het coderingsprobleem van Kladblok-bestanden’ legt uit waarom raden nooit goed afloopt. Bestanden met BOM zijn makkelijk. Zonder BOM waren de meeste tekstbestanden in het wild 8-bits ANSI, hadden sommige UTF-8- en UTF-16-bestanden ook geen BOM, en elke regel die hij probeerde bevoordeelde de ene groep en brak een andere. Zijn voorbeeld: het commando cmd /u /c dir >results.txt schrijft een UTF-16-bestand zonder BOM.

Microsoft veranderde Kladblok in twee stappen. In 2018 leerde het Unix- en Mac-regeleinden. Daarna voegde Microsoft in Windows 10 Insider-build 18298 op 10 december 2018 de optie toe om UTF-8 zonder BOM op te slaan, maakte dat de standaard voor nieuwe bestanden en zette de codering in de statusbalk, met als toelichting dat UTF-8 zonder BOM achterwaarts compatibel is met ASCII en beter werkt met het web, ‘waar UTF-8 de standaardcodering is geworden’. De wijziging bereikte iedereen met Windows 10 versie 1903, de May 2019 Update. Daarvoor gebruikte een nieuw Kladblok-bestand standaard ANSI.

2007 en daarna: UTF-8 neemt het web over

Google meldde dat Unicode in december 2007 voor het eerst de meest voorkomende codering werd op de webpagina’s die het indexeerde, en binnen tien dagen zowel ASCII als de West-Europese coderingen inhaalde. W3Techs meldt nu UTF-8 op 99,1% van de websites waarvan het de codering kan vaststellen (november 2026). Dat is een statistiek over websites. Tekstbestanden op oude schijven maakten nooit deel uit van die verschuiving, en niemand ging terug om ze opnieuw te coderen.

Waarom .txt-bestanden van oude schijven in 2026 nog steeds onleesbaar lijken

Software van nu gaat uit van UTF-8, maar veel tekst is eerder geschreven: DOS-README’s, vroege Windows-notities, exports uit programma’s die niet meer draaien, en e-mail of logbestanden die als tekst zijn opgeslagen. Ze staan in de codepagina van de pc die ze maakte, afhankelijk van de taal en de Windows-versie, en dragen geen label. Voeg regeleinden van een ander systeem toe en af en toe een UTF-16-bestand zonder BOM, en dezelfde extensie .txt verbergt meerdere niet-verwante formaten. Veel daarvan zijn legacy-bestanden waarvan niemand het oorspronkelijke programma nog kan raadplegen.

Legacy File Converter vermeldt platte tekst (.txt) bij de documenten op de pagina Ondersteunde bestandstypen en zet ze op je eigen Windows-pc om naar moderne formaten als DOCX, PDF, Markdown of HTML; er wordt niets geüpload. Vergelijk daarna letters met accenten, aanhalingstekens en symbolen met het origineel en bewaar het originele bestand. Voor andere formaten die onder de motorkap vooral tekst zijn, zie de Geschiedenisles: Wat is een .csv-bestand?, waar een ontbrekende BOM Excel laat struikelen, en de Geschiedenisles: Wat is een .rtf-bestand?.