Historielektion: Vad är en .txt-fil? Varför gamla textfiler visar konstiga tecken

Vad är en .txt-fil?

Öppna en .txt-fil i vilken redigerare som helst så ser du bara tecken: bokstäver, siffror, skiljetecken, mellanslag och radbrytningar. Det är hela formatet. Det finns ingen rubrik, inget typsnitt, ingen fetstil eller kursiv, ingen sidstorlek och inga uppgifter om textens språk. Det filen egentligen innehåller är en rad byte, tal från 0 till 255, och programmet som öppnar den måste avgöra vilket tecken varje tal står för. Ändelsen ”.txt” talar bara om för Windows vilket program som ska erbjudas; den säger ingenting om hur byten ska läsas. Därför är ren text ett av de mest portabla format som någonsin skapats och samtidigt ett av de lättaste att läsa fel.

Varför visar min .txt-fil konstiga tecken?

För att programmet som läser filen använder en annan teckenkodning än programmet som skrev den. Samma bokstav kan lagras som olika byte: é är den enda byten E9 i Windows-1252, den kodsida som Microsoft beskriver som den vanliga för engelska och andra västeuropeiska språk, men de två byten C3 A9 i UTF-8. Öppnar du en UTF-8-fil som Windows-1252 blir varje é till é. Den typografiska apostrofen ’ (E2 80 99 i UTF-8) blir till ’. En UTF-8-fil som börjar med ett byte order mark (BOM, förklaras nedan) inleds med . Åt andra hållet, när en Windows-1252-fil öppnas som UTF-8, är den ensamma byten E9 inte giltig UTF-8, och programmet visar ersättningstecknet �.

Filer från DOS-tiden går fel på ett annat sätt. På den ursprungliga IBM PC kunde samma byte vara ännu ett annat tecken: i kodsida 437, DOS teckenuppsättning, är byte 82 ett é, och de fem byten C9 CD CD CD BB ritar överkanten av en ruta (╔═══╗). Windows läser dem som kodsida 1252 och visar ‚ och ÉÍÍÍ», så ordet café blir caf‚ och ramen runt en README-banner förvandlas till bokstäver.

Inget program kan alltid gissa rätt på egen hand. År 2007 visade Microsofts Raymond Chen Anteckningars dilemma med en fil på två byte, D0 AE. Läst som Windows-1252 är det tecknen Ю; läst som UTF-8 är det den kyrilliska bokstaven Ю; läst som UTF-16 (två byte per tecken) är det en enda koreansk hangul-stavelse, en olika för varje byteordning. Han påpekade att alla fyra tolkningarna är rimliga. Utan etikett i filen är ”konstigt” helt enkelt hur en felaktig gissning ser ut.

1963: ASCII ger 128 tecken ett nummer

Innan ren text kunde bli en fil behövde tecknen nummer som olika maskiner var överens om. American Standards Association inrättade i augusti 1960 en underkommitté för kodade teckenuppsättningar och godkände den 17 juni 1963 standarden X3.4-1963, American Standard Code for Information Interchange: ASCII. Det var en 7-bitarskod med 128 värden för styrtecken, siffror, skiljetecken och det engelska alfabetet. Utgåvan från 1963 var medvetet ofullständig, med stora delar av tabellen ännu inte tilldelade. Ett meddelande från 1967 om revisionen som godkändes den 7 juli 1967, X3.4-1967, sade att de flesta i ASCII-projektet såg den som den första verkliga fullbordan av den grundläggande 7-bitarskoden.

Sju bitar passar inte snyggt i en byte. Ett av de tidigaste dokumenten som säger vad man ska göra är RFC 20, skriven av Vint Cerf i oktober 1969 för det tidiga ARPANET, forskningsnätet som föregick internet. Den föreslog ”standard 7-bitars ASCII inbäddad i en 8-bitars byte vars högsta bit alltid är 0”. Den oanvända åttonde biten är där problemen senare börjar: När en byte kan rymma 256 värden är de övriga 128 fria för vem som helst att tilldela.

CR, LF eller båda: hur en rad slutar

ASCII kodade också teleskrivarens mekanik. Som Chen förklarar flyttade vagnretur (CR) skrivhuvudet tillbaka till kolumn 0 utan att mata fram papperet, och radmatning (LF) matade fram papperet en rad utan att flytta huvudet, så en ny rad krävde båda. Utgåvan av ASCII från 1968, återgiven i RFC 20, låter LF betyda ”ny rad”, men tillägger att användningen ”kräver överenskommelse mellan avsändare och mottagare av data”. Den överenskommelsen kom aldrig riktigt. RFC 20 själv noterar att de första ARPANET-platserna var oeniga: SRI använde en punkt som radslut, medan UCLA använde vagnretur.

CP/M, MS-DOS och Windows behöll båda tecknen, CRLF (byten 0D 0A). Unix nöjde sig med ett enda LF (0A). Microsofts meddelande från 2018 om Anteckningars nya beteende räknar upp de tre konventioner det nu hanterar: Unix/Linux-radslut (LF), Macintosh-radslut (CR) och Windows-radslut (CRLF). Fram till dess, stod det, kunde Anteckningar bara visa Windows-radslut korrekt, så en textfil gjord på Unix eller Linux såg rörig ut. Rättelsen nådde Windows 10 Insider-byggen i maj 2018.

1981: de övriga 128 värdena går sina egna vägar

IBM PC kom 1981 med 8-bitars byte och en 7-bitars standard. David Bradley, en av dess ingenjörer, mindes senare att pc:n ”använde ASCII-teckenuppsättningen, en radikal förändring för en IBM-produkt” (IBM:s tidigare produkter använde EBCDIC) och att teamet, med 128 nya platser att fylla, fyllde dem med utländska bokstäver, blockgrafik samt matematiska och grekiska symboler. Han sade att han gärna beskrev teckenuppsättningen som utvecklad på ”ett tremansmöte på fyra timmar”. Resultatet är kodsida 437, som Microsoft kallar den vanliga OEM-kodsidan (DOS) för engelska: dess övre halva innehåller bokstäver med accent, linjeritande tecken och symboler.

Därefter byggde Windows egna kodsidor. Microsofts dokumentation säger att Windows-kodsida 1252 ursprungligen baserades på ett utkast från American National Standards Institute (ANSI) som till slut blev ISO 8859-1, men den implementerades innan standarden var slutgiltig och är inte exakt densamma. Windows-kodsidor kallas fortfarande ofta ”ANSI-kodsidor”, fast de är Microsofts egna. Alla stämmer överens med ASCII för värdena 0 till 127 och går isär över det: byten E9 är é i kodsida 1252, й i den kyrilliska kodsidan 1251 och ι i den grekiska 1253. Japanska och kinesiska använde dubbelbyte-kodsidor där vissa byte bara betyder något tillsammans med byten som följer. Microsoft noterar att ingen enskild kodsida täcker allt som Unicode täcker.

1992: Unicode och ett bordstablett på en diner i New Jersey

Unicode valde motsatt ansats: ett nummer för varje tecken, så att man slapp jonglera med kodsidor. I den första versionen, från 1991 till 1995, var det en 16-bitarskodning; sedan Unicode 2.0 i juli 1996 omfattar det intervallet U+0000 till U+10FFFF. Men ett nummer är inte en fil. Att lagra 16-bitarsvärden direkt i filer krockade med tidens Unix-programvara, som förlitade sig på ASCII-byte som nollbyten och snedstrecket, och 1992 övervägde en X/Open-kommitté ett Unix-vänligt sätt att lagra Unicode.

Rob Pike, då på Bell Labs, skrev 2003 att UTF-8 ”utformades, inför mina ögon, på ett bordstablett på en diner i New Jersey en kväll i september eller så 1992”. Kommittéledamöter hade bett honom och Ken Thompson att granska deras förslag. De två gick ut och åt, Thompson kom på bitpackningen, och efteråt ringde de kommittén. Pike säger att Thompson skrev pack- och uppackningskoden samma natt, och att deras operativsystem, Plan 9, på fredagen bara körde på det som skulle kallas UTF-8. E-postarkiv som kollegan Russ Cox grävde fram daterar förslaget till början av september 1992.

UTF-8 lagrar varje tecken i ett till fyra byte. De 128 ASCII-tecknen behåller sitt enbytevärde, och ingen byte i andra tecken liknar ASCII, så en ren ASCII-fil är redan giltig UTF-8. Allt annat tar två till fyra byte, med inledande bitar som talar om för läsaren hur lång sekvensen är: é blir C3 A9. François Yergeaus RFC 3629 (november 2003) gjorde det till en internetstandard, och Unicode-FAQ:n kallar det ”den föredragna formen för Unicode-textfiler”.

BOM, och varför Anteckningar måste gissa

UTF-16 lagrar tecken i 16-bitarsenheter, så läsaren måste också känna till byteordningen. Unicodes svar är ett tecken, U+FEFF, allra först i filen som signatur: byte order mark. I UTF-8 visas det som byten EF BB BF, och Unicode-FAQ:n är tydlig: Där har det inget med byteordning att göra, det markerar bara filen som UTF-8. FAQ:n tillägger att vissa program inte förväntar sig det (första raden i ett Unix-skalskript, som börjar med #!, är ett exempel) och att ett protokoll som ”Microsofts konventioner för .txt-filer” kan kräva det. En .txt-fil kan alltså börja med en BOM eller inte, och när den inte gör det måste programmet gissa.

Chens inlägg från 2007 om ”Anteckningars problem med filkodning” förklarar varför gissning aldrig slutar bra. Filer med BOM är enkla. Utan BOM var de flesta textfiler i det vilda 8-bitars ANSI, vissa UTF-8- och UTF-16-filer saknade också BOM, och varje regel han provade gynnade en grupp och slog sönder en annan. Hans exempel: Kommandot cmd /u /c dir >results.txt skriver en UTF-16-fil utan BOM.

Microsoft ändrade Anteckningar i två steg. 2018 lärde det sig Unix- och Mac-radslut. Därefter, i Windows 10 Insider-bygge 18298 den 10 december 2018, lade Microsoft till möjligheten att spara UTF-8 utan BOM, gjorde det till standard för nya filer och satte kodningen i statusfältet, med motiveringen att UTF-8 utan BOM är bakåtkompatibelt med ASCII och fungerar bättre med webben, ”där UTF-8 har blivit standardkodningen”. Ändringen nådde alla med Windows 10 version 1903, majuppdateringen 2019. Före dess använde en ny Anteckningar-fil ANSI som standard.

2007 och senare: UTF-8 tar över webben

Google rapporterade att Unicode i december 2007 för första gången blev den vanligaste kodningen på de webbsidor det indexerade, och gick om både ASCII och västeuropeiska kodningar med tio dagars mellanrum. W3Techs rapporterar nu UTF-8 på 99,1 % av de webbplatser vars kodning det kan identifiera (november 2026). Det är en statistik om webbplatser. Textfiler på gamla diskar var aldrig en del av skiftet, och ingen gick tillbaka och kodade om dem.

Varför .txt-filer från gamla diskar fortfarande ser oläsliga ut 2026

Dagens programvara förutsätter UTF-8, men mycket text skrevs tidigare: DOS-README-filer, tidiga Windows-anteckningar, exporter från program som inte längre körs, och e-post eller loggar sparade som text. De ligger i kodsidan på den pc som skapade dem, beroende på dess språk och Windows-version, och bär ingen etikett. Lägg till radslut från ett annat system och då och då en UTF-16-fil utan BOM, så döljer samma .txt-ändelse flera orelaterade format. Många av dem är legacy-filer där ingen kan fråga det ursprungliga programmet.

Legacy File Converter listar ren text (.txt) bland dokumenten på sidan Filtyper som stöds och konverterar dem på din egen Windows-pc till moderna format som DOCX, PDF, Markdown eller HTML; ingenting laddas upp. Jämför efteråt bokstäver med accent, citationstecken och symboler med originalet, och behåll originalfilen. För andra format som under ytan mest är text, se Historielektion: Vad är en .csv-fil?, där en saknad BOM får Excel att snubbla, och Historielektion: Vad är en .rtf-fil?.