Historietime: Hva er en .txt-fil? Hvorfor gamle tekstfiler viser rare tegn

Hva er en .txt-fil?

Åpner du en .txt-fil i en hvilken som helst editor, ser du bare tegn: bokstaver, sifre, tegnsetting, mellomrom og linjeskift. Det er hele formatet. Det finnes ingen header, ingen skrifttype, ingen fet eller kursiv, ingen sidestørrelse og ingen opplysning om språket teksten er skrevet på. Det filen egentlig inneholder, er en rekke byte, tall fra 0 til 255, og programmet som åpner den må avgjøre hvilket tegn hvert tall står for. Endelsen «.txt» forteller bare Windows hvilket program det skal tilby; den sier ingenting om hvordan byteene skal leses. Derfor er ren tekst et av de mest portable formatene som noen gang er laget, og samtidig et av dem som er lettest å lese feil.

Hvorfor viser .txt-filen min rare tegn?

Fordi programmet som leser filen, bruker en annen tegnkoding enn programmet som skrev den. Den samme bokstaven kan lagres som ulike byte: é er den enkelte byten E9 i Windows-1252, kodesiden Microsoft beskriver som den vanlige for engelsk og andre vesteuropeiske språk, men de to byteene C3 A9 i UTF-8. Åpner du en UTF-8-fil som Windows-1252, blir hver é til é. Den typografiske apostrofen ’ (E2 80 99 i UTF-8) blir til ’. En UTF-8-fil som begynner med et byte order mark (BOM, forklart nedenfor), starter med . Motsatt vei, når en Windows-1252-fil åpnes som UTF-8, er den enslige byten E9 ikke gyldig UTF-8, og programmet viser erstatningstegnet �.

Filer fra DOS-tiden går galt på en annen måte. På den opprinnelige IBM PC-en kunne den samme byten være et helt annet tegn: i kodeside 437, DOS’ tegnsett, er byte 82 en é, og de fem byteene C9 CD CD CD BB tegner øverste kant av en boks (╔═══╗). Windows leser dem som kodeside 1252 og viser ‚ og ÉÍÍÍ», slik at ordet café blir til caf‚, og rammen rundt en README-banner blir til bokstaver.

Ingen program kan alltid gjette riktig på egen hånd. I 2007 viste Microsofts Raymond Chen Notisblokks dilemma med en fil på to byte, D0 AE. Lest som Windows-1252 er det tegnene Ю; lest som UTF-8 er det den kyrilliske bokstaven Ю; lest som UTF-16 (to byte per tegn) er det én koreansk hangul-stavelse, en ulik for hver byterekkefølge. Han pekte på at alle fire lesemåtene er sannsynlige. Uten merkelapp i filen er «rart» bare hvordan en gal gjetning ser ut.

1963: ASCII gir 128 tegn et nummer

Før ren tekst kunne bli en fil, trengte tegnene numre som ulike maskiner var enige om. American Standards Association nedsatte i august 1960 en underkomité for kodede tegnsett og godkjente 17. juni 1963 standarden X3.4-1963, American Standard Code for Information Interchange: ASCII. Det var en 7-bits kode med 128 verdier for kontrolltegn, sifre, tegnsetting og det engelske alfabetet. Utgaven fra 1963 var bevisst ufullstendig, og store deler av tabellen var ennå ikke tildelt. En melding fra 1967 om revisjonen godkjent 7. juli 1967, X3.4-1967, sa at de fleste i ASCII-prosjektet så på den som den første virkelige fullføringen av den grunnleggende 7-bits koden.

Sju bit passer ikke pent i en byte. Et av de tidligste dokumentene som sier hva man skal gjøre, er RFC 20, skrevet av Vint Cerf i oktober 1969 for det tidlige ARPANET, forskningsnettet som gikk forut for Internett. Den foreslo «standard 7-bits ASCII innebygd i en 8-bits byte der den høyeste biten alltid er 0». Den ubrukte åttende biten er der problemene senere begynner: Når en byte kan rumme 256 verdier, er de andre 128 frie for hvem som helst å tildele.

CR, LF eller begge: hvordan en linje slutter

ASCII kodet også mekanikken i fjernskriveren. Som Chen forklarer, flyttet vognretur (CR) skrivehodet tilbake til kolonne 0 uten å mate papiret, og linjeskift (LF) matet papiret én linje uten å flytte hodet, så en ny linje krevde begge deler. Utgaven av ASCII fra 1968, gjengitt i RFC 20, lar LF bety «ny linje», men legger til at bruken «krever avtale mellom avsender og mottaker av data». Den avtalen kom aldri helt. RFC 20 selv noterer at de første ARPANET-stedene var uenige: SRI brukte et punktum som linjeavslutning, mens UCLA brukte vognretur.

CP/M, MS-DOS og Windows beholdt begge tegnene, CRLF (byteene 0D 0A). Unix nøyde seg med ett enkelt LF (0A). Microsofts melding fra 2018 om Notisblokks nye oppførsel nevner de tre konvensjonene det nå håndterer: Unix/Linux-linjeslutt (LF), Macintosh-linjeslutt (CR) og Windows-linjeslutt (CRLF). Frem til da, het det, kunne Notisblokk bare vise Windows-linjeslutt riktig, så en tekstfil laget på Unix eller Linux så rotete ut. Rettelsen nådde Windows 10 Insider-bygg i mai 2018.

1981: de andre 128 verdiene går hver sin vei

IBM PC kom i 1981 med 8-bits byte og en 7-bits standard. David Bradley, en av ingeniørene, husket senere at PC-en «brukte ASCII-tegnsettet, en radikal endring for et IBM-produkt» (IBMs tidligere produkter brukte EBCDIC), og at teamet, med 128 nye plasser å fylle, fylte dem med fremmedspråklige bokstaver, blokkgrafikk og matematiske og greske symboler. Han sa at han likte å beskrive tegnsettet som utviklet på «et tremannsmøte på fire timer». Resultatet er kodeside 437, som Microsoft kaller den vanlige OEM-kodesiden (DOS) for engelsk: den øvre halvdelen inneholder bokstaver med aksent, linjetegn og symboler.

Deretter bygde Windows sine egne kodesider. Microsofts dokumentasjon sier at Windows-kodeside 1252 opprinnelig var basert på et utkast fra American National Standards Institute (ANSI) som til slutt ble ISO 8859-1, men den ble implementert før standarden var endelig og er ikke helt lik. Windows-kodesider kalles fortsatt ofte «ANSI-kodesider», selv om de er Microsofts egne. Alle stemmer med ASCII for verdiene 0 til 127 og er uenige over det: byten E9 er é i kodeside 1252, й i den kyrilliske kodesiden 1251 og ι i den greske 1253. Japansk og kinesisk brukte dobbeltbyte-kodesider, der noen byte bare betyr noe sammen med byten som følger. Microsoft bemerker at ingen enkelt kodeside dekker alt Unicode dekker.

1992: Unicode og en kuvertbrikke på en diner i New Jersey

Unicode valgte motsatt tilnærming: ett nummer for hvert tegn, så man slapp å sjonglere kodesider. I den første versjonen, fra 1991 til 1995, var det en 16-bits koding; siden Unicode 2.0 i juli 1996 dekker det området U+0000 til U+10FFFF. Men et nummer er ikke en fil. Å lagre 16-bits verdier direkte i filer kolliderte med datidens Unix-programvare, som baserte seg på ASCII-byte som nullbyten og skråstreken, og i 1992 vurderte en X/Open-komité en Unix-vennlig måte å lagre Unicode på.

Rob Pike, den gang hos Bell Labs, skrev i 2003 at UTF-8 «ble utformet, rett foran øynene på meg, på en kuvertbrikke på en diner i New Jersey en kveld i september eller så i 1992». Komitémedlemmer hadde bedt ham og Ken Thompson om å gå gjennom forslaget deres. De to dro ut for å spise, Thompson fant ut av bitpakkingen, og etterpå ringte de komiteen. Pike sier at Thompson skrev pakke- og utpakkingskoden den natten, og at operativsystemet deres, Plan 9, innen fredag bare kjørte på det som skulle bli kalt UTF-8. E-postarkiver som kollegaen Russ Cox gravde frem, daterer forslaget til tidlig i september 1992.

UTF-8 lagrer hvert tegn i én til fire byte. De 128 ASCII-tegnene beholder enkeltbyte-verdien sin, og ingen byte i andre tegn ligner ASCII, så en ren ASCII-fil er allerede gyldig UTF-8. Alt annet tar to til fire byte, med innledende bit som forteller leseren hvor lang sekvensen er: é blir C3 A9. François Yergeaus RFC 3629 (november 2003) gjorde det til en Internett-standard, og Unicode-FAQ-en kaller det «den foretrukne formen for Unicode-tekstfiler».

BOM-en, og hvorfor Notisblokk måtte gjette

UTF-16 lagrer tegn i 16-bits enheter, så leseren må også kjenne byterekkefølgen. Unicodes svar er et tegn, U+FEFF, helt først i filen som signatur: byte order mark. I UTF-8 vises det som byteene EF BB BF, og Unicode-FAQ-en er tydelig: Der har det ikke noe med byterekkefølge å gjøre, det merker bare filen som UTF-8. FAQ-en legger til at noen programmer ikke forventer det (første linje i et Unix-skallskript, som begynner med #!, er et eksempel), og at en protokoll som «Microsofts konvensjoner for .txt-filer» kan kreve det. En .txt-fil kan altså begynne med en BOM eller ikke, og når den ikke gjør det, må programmet gjette.

Chens innlegg fra 2007 om «Notisblokks problem med filkoding» forklarer hvorfor gjetting aldri ender godt. Filer med BOM er enkle. Uten BOM var de fleste tekstfiler i naturen 8-bits ANSI, noen UTF-8- og UTF-16-filer hadde heller ingen BOM, og hver regel han prøvde, favoriserte én gruppe og ødela en annen. Eksempelet hans: Kommandoen cmd /u /c dir >results.txt skriver en UTF-16-fil uten BOM.

Microsoft endret Notisblokk i to trinn. I 2018 lærte det Unix- og Mac-linjeslutt. Deretter, i Windows 10 Insider-bygg 18298 den 10. desember 2018, la Microsoft til muligheten for å lagre UTF-8 uten BOM, gjorde det til standard for nye filer og satte kodingen i statuslinjen, med begrunnelsen at UTF-8 uten BOM er bakoverkompatibelt med ASCII og fungerer bedre med nettet, «der UTF-8 har blitt standardkodingen». Endringen nådde alle med Windows 10 versjon 1903, mai 2019-oppdateringen. Før det brukte en ny Notisblokk-fil ANSI som standard.

2007 og senere: UTF-8 tar over nettet

Google rapporterte at Unicode i desember 2007 for første gang ble den vanligste kodingen på nettsidene det indekserte, og forbi både ASCII og vesteuropeiske kodinger med ti dagers mellomrom. W3Techs rapporterer nå UTF-8 på 99,1 % av nettstedene der kodingen kan identifiseres (november 2026). Det er en statistikk om nettsteder. Tekstfiler på gamle disker var aldri en del av skiftet, og ingen gikk tilbake og kodet dem om.

Hvorfor .txt-filer fra gamle disker fortsatt ser uleselige ut i 2026

Dagens programvare forutsetter UTF-8, men mye tekst ble skrevet før: DOS-README-filer, tidlige Windows-notater, eksporter fra programmer som ikke lenger kjører, og e-post eller logger lagret som tekst. De ligger i kodesiden til PC-en som lagde dem, avhengig av språk og Windows-versjon, og de har ingen merkelapp. Legg til linjeslutt fra et annet system og en og annen UTF-16-fil uten BOM, så skjuler den samme .txt-endelsen flere urelaterte formater. Mange av dem er legacy-filer der ingen kan spørre det opprinnelige programmet.

Legacy File Converter fører opp ren tekst (.txt) blant dokumentene på siden Støttede filtyper og konverterer dem på din egen Windows-PC til moderne formater som DOCX, PDF, Markdown eller HTML; ingenting lastes opp. Sammenlign etterpå bokstaver med aksent, anførselstegn og symboler med originalen, og ta vare på originalfilen. For andre formater som under overflaten mest er tekst, se Historietime: Hva er en .csv-fil?, der en manglende BOM får Excel til å snuble, og Historietime: Hva er en .rtf-fil?.