Historielektion: Hvad er en .txt-fil? Hvorfor gamle tekstfiler viser mærkelige tegn

Hvad er en .txt-fil?

Åbn en .txt-fil i en vilkårlig editor, og du ser kun tegn: bogstaver, tal, tegnsætning, mellemrum og linjeskift. Det er hele formatet. Der er ingen header, ingen skrifttype, ingen fed eller kursiv, ingen sidestørrelse og ingen oplysning om tekstens sprog. Det, filen i virkeligheden indeholder, er en række bytes, tal fra 0 til 255, og programmet, der åbner den, må afgøre, hvilket tegn hvert tal står for. Endelsen “.txt” fortæller kun Windows, hvilket program der skal tilbydes; den siger intet om, hvordan bytes skal læses. Derfor er ren tekst et af de mest portable formater nogensinde og samtidig et af dem, der er nemmest at læse forkert.

Hvorfor viser min .txt-fil mærkelige tegn?

Fordi programmet, der læser filen, bruger en anden tegnkodning end det program, der skrev den. Det samme bogstav kan gemmes som forskellige bytes: é er den enkelte byte E9 i Windows-1252, den codepage, Microsoft beskriver som den sædvanlige for engelsk og andre vesteuropæiske sprog, men de to bytes C3 A9 i UTF-8. Åbner du en UTF-8-fil som Windows-1252, bliver hvert é til é. Den typografiske apostrof ’ (E2 80 99 i UTF-8) bliver til ’. En UTF-8-fil, der begynder med et byte order mark (BOM, forklaret nedenfor), starter med . Den anden vej, når en Windows-1252-fil åbnes som UTF-8, er den enlige byte E9 ikke gyldig UTF-8, og programmet viser erstatningstegnet �.

Filer fra DOS-tiden går galt på en anden måde. På den oprindelige IBM PC kunne den samme byte være et helt andet tegn: i codepage 437, DOS’ tegnsæt, er byte 82 et é, og de fem bytes C9 CD CD CD BB tegner øverste kant af en boks (╔═══╗). Windows læser dem som codepage 1252 og viser ‚ og ÉÍÍÍ», så ordet café bliver til caf‚, og rammen om en README’s banner bliver til bogstaver.

Intet program kan altid gætte rigtigt alene. I 2007 viste Microsofts Raymond Chen Notesbloks dilemma med en fil på to bytes, D0 AE. Læst som Windows-1252 er det tegnene Ю; læst som UTF-8 er det det kyrilliske bogstav Ю; læst som UTF-16 (to bytes pr. tegn) er det en enkelt koreansk hangul-stavelse, en forskellig for hver byterækkefølge. Han påpegede, at alle fire læsninger er sandsynlige. Uden mærkat i filen er “mærkeligt” blot det, en forkert gætning ser ud som.

1963: ASCII giver 128 tegn et nummer

Før ren tekst kunne være en fil, havde tegn brug for numre, som forskellige maskiner var enige om. American Standards Association nedsatte i august 1960 et underudvalg for kodede tegnsæt og godkendte den 17. juni 1963 standarden X3.4-1963, American Standard Code for Information Interchange: ASCII. Det var en 7-bit-kode med 128 værdier til kontroltegn, tal, tegnsætning og det engelske alfabet. Udgaven fra 1963 var bevidst ufuldstændig, og store dele af tabellen var endnu ikke tildelt. En meddelelse fra 1967 om revisionen godkendt den 7. juli 1967, X3.4-1967, sagde, at de fleste i ASCII-projektet så den som den første egentlige fuldførelse af den grundlæggende 7-bit-kode.

Syv bit passer ikke pænt i en byte. Et af de tidligste dokumenter, der siger, hvad man skal gøre, er RFC 20, skrevet af Vint Cerf i oktober 1969 til det tidlige ARPANET, forskningsnettet der gik forud for internettet. Den foreslog “standard 7-bit ASCII indlejret i en 8-bit byte, hvis højeste bit altid er 0”. Det ubrugte ottende bit er der, hvor problemerne senere starter: Når en byte kan rumme 256 værdier, er de øvrige 128 frie for enhver at tildele.

CR, LF eller begge: hvordan en linje slutter

ASCII kodede også fjernskriverens mekanik. Som Chen forklarer, flyttede vognretur (CR) skrivehovedet tilbage til kolonne 0 uden at fremføre papiret, og linjeskift (LF) fremførte papiret én linje uden at flytte hovedet, så en ny linje krævede begge dele. Udgaven af ASCII fra 1968, gengivet i RFC 20, lader LF betyde “ny linje”, men tilføjer, at brugen heraf “kræver aftale mellem afsender og modtager af data”. Den aftale kom aldrig helt. RFC 20 selv noterer, at de første ARPANET-steder var uenige: SRI brugte et punktum som linjeafslutning, mens UCLA brugte vognretur.

CP/M, MS-DOS og Windows beholdt begge tegn, CRLF (bytes 0D 0A). Unix nøjedes med ét LF (0A). Microsofts meddelelse fra 2018 om Notesbloks nye adfærd nævner de tre konventioner, det nu håndterer: Unix/Linux-linjeslutninger (LF), Macintosh-linjeslutninger (CR) og Windows-linjeslutninger (CRLF). Indtil da kunne Notesblok ifølge meddelelsen kun vise Windows-linjeslutninger korrekt, så en tekstfil lavet på Unix eller Linux så forvansket ud. Rettelsen nåede Windows 10 Insider-builds i maj 2018.

1981: de øvrige 128 værdier går hver til sit

IBM PC’en kom i 1981 med 8-bit-bytes og en 7-bit-standard. David Bradley, en af dens ingeniører, huskede senere, at pc’en “brugte ASCII-tegnsættet, en radikal ændring for et IBM-produkt” (IBMs tidligere produkter brugte EBCDIC), og at holdet, da der var 128 nye pladser at fylde, fyldte dem med fremmedsprogede bogstaver, blokgrafik samt matematiske og græske symboler. Han sagde, at han gerne beskrev tegnsættet som udviklet på “et tremandsmøde på fire timer”. Resultatet er codepage 437, som Microsoft kalder den sædvanlige OEM-codepage (DOS) til engelsk: dens øverste halvdel rummer accenttegn, linjetegn og symboler.

Derefter byggede Windows sine egne codepages. Microsofts dokumentation siger, at Windows-codepage 1252 oprindelig var baseret på et udkast fra American National Standards Institute (ANSI), som til sidst blev til ISO 8859-1, men den blev implementeret, før standarden var endelig, og er ikke helt den samme. Windows-codepages kaldes stadig almindeligvis “ANSI-codepages”, selv om de er Microsofts egne. Alle stemmer overens med ASCII for værdierne 0 til 127 og er uenige derover: byten E9 er é i codepage 1252, й i den kyrilliske codepage 1251 og ι i den græske 1253. Japansk og kinesisk brugte dobbeltbyte-codepages, hvor nogle bytes kun betyder noget sammen med den følgende byte. Microsoft bemærker, at ingen enkelt codepage dækker alt, hvad Unicode dækker.

1992: Unicode og en dækkeserviet på en diner i New Jersey

Unicode valgte den modsatte tilgang: ét nummer for hvert tegn, så man ikke længere skulle jonglere med codepages. I den første version, fra 1991 til 1995, var det en 16-bit-kodning; siden Unicode 2.0 i juli 1996 dækker det området U+0000 til U+10FFFF. Men et nummer er ikke en fil. At gemme 16-bit-værdier direkte i filer stødte sammen med datidens Unix-software, som byggede på ASCII-bytes som nulbyten og skråstregen, og i 1992 overvejede et X/Open-udvalg en Unix-venlig måde at gemme Unicode på.

Rob Pike, dengang hos Bell Labs, skrev i 2003, at UTF-8 “blev designet, for øjnene af mig, på en dækkeserviet på en diner i New Jersey en aften i september eller deromkring 1992”. Udvalgsmedlemmer havde bedt ham og Ken Thompson gennemgå deres forslag. De to tog ud at spise, Thompson udtænkte bitpakningen, og bagefter ringede de til udvalget. Pike siger, at Thompson skrev pakke- og udpakningskoden den nat, og at deres operativsystem, Plan 9, om fredagen kun kørte på det, der senere blev kaldt UTF-8. Mailarkiver, som hans kollega Russ Cox gravede frem, daterer forslaget til begyndelsen af september 1992.

UTF-8 gemmer hvert tegn i en til fire bytes. De 128 ASCII-tegn beholder deres enkeltbyte-værdi, og ingen byte i andre tegn ligner ASCII, så en ren ASCII-fil er allerede gyldig UTF-8. Alt andet fylder to til fire bytes, med indledende bit, der fortæller læseren, hvor lang sekvensen er: é bliver C3 A9. François Yergeaus RFC 3629 (november 2003) gjorde det til en internetstandard, og Unicode-FAQ’en kalder det “den foretrukne form for Unicode-tekstfiler”.

BOM’en, og hvorfor Notesblok måtte gætte

UTF-16 gemmer tegn i 16-bit-enheder, så læseren skal også kende byterækkefølgen. Unicodes svar er et tegn, U+FEFF, helt i starten af filen som signatur: byte order mark. I UTF-8 optræder det som bytes EF BB BF, og Unicode-FAQ’en er klar: Der har det intet med byterækkefølge at gøre, det markerer kun filen som UTF-8. FAQ’en tilføjer, at nogle programmer ikke forventer det (første linje i et Unix-shellscript, som begynder med #!, er et eksempel), og at en protokol som “Microsofts konventioner for .txt-filer” kan kræve det. En .txt-fil kan altså begynde med en BOM eller ej, og når den ikke gør, må programmet gætte.

Chens indlæg fra 2007 om “Notesbloks problem med filkodning” forklarer, hvorfor gætteri aldrig ender godt. Filer med BOM er lette. Uden BOM var de fleste tekstfiler i naturen 8-bit ANSI, nogle UTF-8- og UTF-16-filer havde heller ingen BOM, og hver regel, han prøvede, favoriserede én gruppe og ødelagde en anden. Hans eksempel: Kommandoen cmd /u /c dir >results.txt skriver en UTF-16-fil uden BOM.

Microsoft ændrede Notesblok i to trin. I 2018 lærte det Unix- og Mac-linjeslutninger. Derefter, i Windows 10 Insider-build 18298 den 10. december 2018, tilføjede Microsoft muligheden for at gemme UTF-8 uden BOM, gjorde det til standard for nye filer og satte kodningen i statuslinjen med begrundelsen, at UTF-8 uden BOM er bagudkompatibel med ASCII og fungerer bedre med nettet, “hvor UTF-8 er blevet standardkodningen”. Ændringen nåede alle med Windows 10 version 1903, majopdateringen 2019. Før da brugte en ny Notesblok-fil ANSI som standard.

2007 og efter: UTF-8 overtager nettet

Google rapporterede, at Unicode i december 2007 for første gang blev den hyppigste kodning på de websider, det indekserede, og overhalede både ASCII og vesteuropæiske kodninger inden for ti dage. W3Techs rapporterer nu UTF-8 på 99,1 % af de websteder, hvis kodning det kan identificere (november 2026). Det er en statistik om websteder. Tekstfiler på gamle diske var aldrig en del af skiftet, og ingen gik tilbage og omkodede dem.

Hvorfor .txt-filer fra gamle diske stadig ser ulæselige ud i 2026

Nutidens software forudsætter UTF-8, men en masse tekst blev skrevet før: DOS-README’er, tidlige Windows-noter, eksport fra programmer, der ikke længere kører, og mails eller logfiler gemt som tekst. De ligger i codepagen på den pc, der lavede dem, afhængigt af dens sprog og Windows-version, og de bærer intet mærkat. Læg linjeslutninger fra et andet system til og en sjælden UTF-16-fil uden BOM, og den samme .txt-endelse skjuler flere indbyrdes urelaterede formater. Mange af dem er legacy-filer, hvor ingen kan spørge det oprindelige program.

Legacy File Converter opfører ren tekst (.txt) blandt dokumenterne på siden Understøttede filtyper og konverterer dem på din egen Windows-pc til moderne formater som DOCX, PDF, Markdown eller HTML; intet bliver uploadet. Sammenlign bagefter bogstaver med accent, citationstegn og symboler med originalen, og behold originalfilen. For andre formater, der under overfladen mest er tekst, se Historielektion: Hvad er en .csv-fil?, hvor en manglende BOM får Excel til at snuble, og Historielektion: Hvad er en .rtf-fil?.