Historiatunti: Mikä on .txt-tiedosto? Miksi vanhat tekstitiedostot näyttävät oudoilta merkeiltä

Mikä on .txt-tiedosto?

Avaa .txt-tiedosto millä tahansa editorilla, niin näet vain merkkejä: kirjaimia, numeroita, välimerkkejä, välilyöntejä ja rivinvaihtoja. Se on koko tiedostomuoto. Mukana ei ole otsaketta, fonttia, lihavointia tai kursivointia, sivukokoa eikä tietoa tekstin kielestä. Tiedosto sisältää todellisuudessa tavujonon, lukuja 0–255, ja sen avaavan ohjelman on päätettävä, mitä merkkiä kukin luku tarkoittaa. Pääte ”.txt” kertoo Windowsille vain, mitä ohjelmaa ehdotetaan; se ei kerro mitään siitä, miten tavut luetaan. Siksi pelkkä teksti on yksi koskaan tehdyistä siirrettävimmistä tiedostomuodoista ja samalla yksi helpoimmin väärin luettavista.

Miksi .txt-tiedostoni näyttää outoja merkkejä?

Koska tiedostoa lukeva ohjelma käyttää eri merkistökoodausta kuin sen kirjoittanut ohjelma. Sama kirjain voidaan tallentaa eri tavuina: é on yksittäinen tavu E9 Windows-1252:ssa, koodisivulla, jonka Microsoft kuvaa englannin ja muiden länsieurooppalaisten kielten tavanomaiseksi, mutta kaksi tavua C3 A9 UTF-8:ssa. Jos avaat UTF-8-tiedoston Windows-1252:na, jokainen é muuttuu muotoon é. Typografinen heittomerkki ’ (E2 80 99 UTF-8:ssa) muuttuu muotoon ’. UTF-8-tiedosto, joka alkaa tavujärjestysmerkillä (BOM, selitetty alla), alkaa merkeillä . Toiseen suuntaan, kun Windows-1252-tiedosto avataan UTF-8:na, yksinäinen tavu E9 ei ole kelvollista UTF-8:aa, ja ohjelma näyttää korvausmerkin �.

DOS-ajan tiedostot menevät pieleen toisella tavalla. Alkuperäisessä IBM PC:ssä sama tavu saattoi olla vielä jokin toinen merkki: koodisivulla 437, DOSin merkistössä, tavu 82 on é ja viisi tavua C9 CD CD CD BB piirtävät laatikon yläreunan (╔═══╗). Windows lukee ne koodisivuna 1252 ja näyttää ‚ ja ÉÍÍÍ», joten sana café näkyy muodossa caf‚ ja README-tiedoston bannerin kehys muuttuu kirjaimiksi.

Mikään ohjelma ei voi aina arvata oikein yksin. Vuonna 2007 Microsoftin Raymond Chen havainnollisti Muistion ongelmaa kaksitavuisella tiedostolla, D0 AE. Windows-1252:na luettuna se on merkit Ю; UTF-8:na luettuna kyrillinen kirjain Ю; UTF-16:na (kaksi tavua merkkiä kohti) luettuna yksi korealainen hangul-tavu, eri tavu kummallakin tavujärjestyksellä. Hän huomautti, että kaikki neljä tulkintaa ovat uskottavia. Ilman tiedostossa olevaa merkintää ”outo” on yksinkertaisesti väärän arvauksen ulkonäkö.

1963: ASCII antaa 128 merkille numeron

Jotta pelkkä teksti voisi olla tiedosto, merkeille tarvittiin numerot, joista eri koneet olivat yhtä mieltä. American Standards Association perusti elokuussa 1960 alakomitean koodatuille merkistöille ja hyväksyi 17. kesäkuuta 1963 standardin X3.4-1963, American Standard Code for Information Interchange: ASCII. Se oli 7-bittinen koodi, jossa oli 128 arvoa ohjausmerkeille, numeroille, välimerkeille ja englannin aakkosille. Vuoden 1963 versio oli tietoisesti keskeneräinen, ja suuri osa taulukosta oli vielä jakamatta. Vuoden 1967 tiedote 7. heinäkuuta 1967 hyväksytystä tarkistuksesta, X3.4-1967, totesi, että useimmat ASCII-hankkeessa mukana olleet pitivät sitä perustavan 7-bittisen koodin ensimmäisenä todellisena valmistumisena.

Seitsemän bittiä ei sovi siististi tavuun. Yksi varhaisimmista asiakirjoista, joka kertoo, mitä tehdä, on RFC 20, jonka Vint Cerf kirjoitti lokakuussa 1969 varhaiselle ARPANETille, internetiä edeltäneelle tutkimusverkolle. Siinä ehdotettiin ”standardia 7-bittistä ASCII:a upotettuna 8-bittiseen tavuun, jonka korkein bitti on aina 0”. Juuri tuosta käyttämättömästä kahdeksannesta bitistä ongelmat myöhemmin alkavat: kun tavuun mahtuu 256 arvoa, loput 128 ovat vapaasti kenen tahansa määriteltävissä.

CR, LF vai molemmat: miten rivi päättyy

ASCII koodasi myös kaukokirjoittimen mekaniikan. Kuten Chen selittää, vaununpalautus (CR) siirsi kirjoituspään takaisin sarakkeeseen 0 siirtämättä paperia, ja rivinsyöttö (LF) siirsi paperia yhden rivin siirtämättä päätä, joten uuden rivin aloittaminen vaati molemmat. ASCII:n vuoden 1968 versio, joka on kopioitu RFC 20:een, sallii LF:n tarkoittavan ”uutta riviä”, mutta lisää, että sen käyttö ”edellyttää sopimusta datan lähettäjän ja vastaanottajan välillä”. Tuo sopimus ei koskaan täysin syntynyt. RFC 20 itse toteaa, että ensimmäiset ARPANET-asemat olivat eri mieltä: SRI käytti rivinpäätteenä pistettä, kun taas UCLA käytti vaununpalautusta.

CP/M, MS-DOS ja Windows säilyttivät molemmat merkit, CRLF (tavut 0D 0A). Unix tyytyi yhteen LF-merkkiin (0A). Microsoftin vuoden 2018 tiedote Muistion uudesta toiminnasta luettelee kolme käytäntöä, joita se nyt käsittelee: Unix/Linux-rivinpäätteet (LF), Macintosh-rivinpäätteet (CR) ja Windows-rivinpäätteet (CRLF). Siihen asti, tiedotteessa kerrottiin, Muistio osasi näyttää oikein vain Windowsin rivinpäätteet, joten Unixilla tai Linuxilla tehty tekstitiedosto näytti sekavalta. Korjaus tuli Windows 10 Insider -versioihin toukokuussa 2018.

1981: loput 128 arvoa lähtevät omille teilleen

IBM PC tuli markkinoille 1981 8-bittisillä tavuilla ja 7-bittisellä standardilla. David Bradley, yksi sen insinööreistä, muisteli myöhemmin, että PC ”käytti ASCII-merkistöä, mikä oli radikaali muutos IBM:n tuotteelle” (IBM:n aiemmat tuotteet käyttivät EBCDIC:ia) ja että tiimi täytti 128 uutta paikkaa vieraiden kielten kirjaimilla, lohkografiikalla sekä matemaattisilla ja kreikkalaisilla symboleilla. Hän sanoi kuvailevansa mielellään merkistön kehitetyn ”kolmen hengen nelituntisessa kokouksessa”. Tuloksena oli koodisivu 437, jota Microsoft kutsuu englannin tavanomaiseksi OEM-koodisivuksi (DOS): sen yläpuoliskossa on aksenttikirjaimia, viivanpiirtomerkkejä ja symboleja.

Sitten Windows rakensi omat koodisivunsa. Microsoftin ohjeiden mukaan Windowsin koodisivu 1252 perustui alun perin American National Standards Instituten (ANSI) luonnokseen, josta lopulta tuli ISO 8859-1, mutta se toteutettiin ennen kuin standardi oli valmis, eikä se ole täsmälleen sama. Windowsin koodisivuja kutsutaan yhä yleisesti ”ANSI-koodisivuiksi”, vaikka ne ovat Microsoftin omia. Kaikki ovat ASCII:n kanssa samaa mieltä arvoilla 0–127 ja eri mieltä sen yläpuolella: tavu E9 on é koodisivulla 1252, й kyrillisellä koodisivulla 1251 ja ι kreikkalaisella 1253. Japanin ja kiinan kielille käytettiin kaksitavuisia koodisivuja, joissa jotkin tavut merkitsevät jotain vain seuraavan tavun kanssa. Microsoft huomauttaa, ettei mikään yksittäinen koodisivu kata kaikkea, minkä Unicode kattaa.

1992: Unicode ja paperialunen New Jerseyn ravintolassa

Unicode valitsi päinvastaisen lähestymistavan: yksi numero jokaiselle merkille, ei enää koodisivujen välillä pomppimista. Ensimmäisessä versiossa, vuosina 1991–1995, se oli 16-bittinen koodaus; Unicode 2.0:sta heinäkuusta 1996 lähtien se kattaa alueen U+0000–U+10FFFF. Mutta numero ei ole tiedosto. 16-bittisten arvojen tallentaminen suoraan tiedostoihin törmäsi aikakauden Unix-ohjelmistoihin, jotka nojasivat ASCII-tavuihin kuten nollatavuun ja kauttaviivaan, ja vuonna 1992 X/Openin komitea harkitsi Unixille sopivaa tapaa tallentaa Unicodea.

Rob Pike, silloin Bell Labsissa, kirjoitti vuonna 2003, että UTF-8 ”suunniteltiin silmieni edessä paperialuselle New Jerseyn ravintolassa eräänä iltana syyskuussa tai siihen aikaan 1992”. Komitean jäsenet olivat pyytäneet häntä ja Ken Thompsonia tarkistamaan ehdotuksensa. He lähtivät illalliselle, Thompson keksi bittien pakkaustavan, ja sen jälkeen he soittivat komitealle. Pike kertoo Thompsonin kirjoittaneen pakkaus- ja purkukoodin saman yön aikana ja että perjantaihin mennessä heidän käyttöjärjestelmänsä Plan 9 toimi pelkästään sillä, mitä alettaisiin kutsua UTF-8:ksi. Hänen kollegansa Russ Coxin kaivamat sähköpostiarkistot ajoittavat ehdotuksen syyskuun 1992 alkuun.

UTF-8 tallentaa jokaisen merkin yhdestä neljään tavuun. 128 ASCII-merkkiä säilyttävät yhden tavun arvonsa, eikä minkään muun merkin tavu muistuta ASCII:a, joten pelkkä ASCII-tiedosto on jo kelvollista UTF-8:aa. Kaikki muu vie kaksi–neljä tavua, ja alkubitit kertovat lukijalle jakson pituuden: é muuttuu muotoon C3 A9. François Yergeaun RFC 3629 (marraskuu 2003) teki siitä internet-standardin, ja Unicoden UKK kutsuu sitä ”Unicode-tekstitiedostojen suositelluksi muodoksi”.

BOM, ja miksi Muistion piti arvata

UTF-16 tallentaa merkit 16-bittisinä yksikköinä, joten lukijan on tunnettava myös tavujärjestys. Unicoden vastaus on merkki U+FEFF, joka sijoitetaan aivan tiedoston alkuun allekirjoitukseksi: tavujärjestysmerkki. UTF-8:ssa se näkyy tavuina EF BB BF, ja Unicoden UKK on yksiselitteinen: siellä sillä ei ole mitään tekemistä tavujärjestyksen kanssa, se vain merkitsee tiedoston UTF-8:ksi. UKK lisää, että jotkin ohjelmat eivät odota sitä (Unixin komentotulkkikomentojonon ensimmäinen rivi, joka alkaa merkeillä #!, on esimerkki) ja että jokin protokolla, kuten ”Microsoftin käytännöt .txt-tiedostoille”, voi vaatia sitä. .txt-tiedosto voi siis alkaa BOM:illa tai ei, ja kun ei, ohjelman on arvattava.

Chenin vuoden 2007 kirjoitus ”Muistion tiedostokoodausongelmasta” selittää, miksi arvaaminen ei koskaan pääty hyvin. BOM:illa varustetut tiedostot ovat helppoja. Ilman BOM:ia useimmat luonnossa esiintyvät tekstitiedostot olivat 8-bittistä ANSI:a, jotkin UTF-8- ja UTF-16-tiedostot olivat myös ilman BOM:ia, ja jokainen hänen kokeilemansa sääntö suosi yhtä ryhmää ja rikkoi toisen. Hänen esimerkkinsä: komento cmd /u /c dir >results.txt kirjoittaa UTF-16-tiedoston ilman BOM:ia.

Microsoft muutti Muistiota kahdessa vaiheessa. Vuonna 2018 se oppi Unixin ja Macin rivinpäätteet. Sitten Windows 10 Insider -versiossa 18298 10. joulukuuta 2018 Microsoft lisäsi mahdollisuuden tallentaa UTF-8 ilman BOM:ia, teki siitä uusien tiedostojen oletuksen ja toi koodauksen tilariville, perustellen, että UTF-8 ilman BOM:ia on taaksepäin yhteensopiva ASCII:n kanssa ja toimii paremmin verkossa, ”jossa UTF-8:sta on tullut oletuskoodaus”. Muutos tavoitti kaikki Windows 10 -versiossa 1903, toukokuun 2019 päivityksessä. Sitä ennen uusi Muistio-tiedosto oli oletuksena ANSI.

2007 ja sen jälkeen: UTF-8 valtaa verkon

Google kertoi, että joulukuussa 2007 Unicode ohitti ensimmäistä kertaa sen indeksoimilla verkkosivuilla yleisimmän koodauksen, ohittaen sekä ASCII:n että länsieurooppalaiset koodaukset kymmenen päivän sisällä toisistaan. W3Techs raportoi nyt UTF-8:n 99,1 prosentilla verkkosivustoista, joiden koodauksen se pystyy tunnistamaan (marraskuu 2026). Se on tilasto verkkosivustoista. Vanhoilla levyillä lojuvat tekstitiedostot eivät koskaan olleet osa tätä muutosta, eikä kukaan palannut koodaamaan niitä uudelleen.

Miksi vanhojen levyjen .txt-tiedostot näyttävät yhä lukukelvottomilta vuonna 2026

Nykyohjelmat olettavat UTF-8:n, mutta paljon tekstiä kirjoitettiin ennen sitä: DOS-README-tiedostoja, varhaisia Windows-muistiinpanoja, enää toimimattomien ohjelmien vientitiedostoja sekä tekstinä tallennettuja sähköposteja tai lokeja. Ne ovat tiedoston tehneen PC:n koodisivulla, joka riippui sen kielestä ja Windows-versiosta, eivätkä ne sisällä mitään merkintää. Lisää toisen järjestelmän rivinpäätteet ja silloin tällöin UTF-16-tiedosto ilman BOM:ia, niin sama .txt-pääte kätkee useita toisistaan riippumattomia tiedostomuotoja. Monet niistä ovat legacy-tiedostoja, joiden alkuperäisohjelmalta ei voi enää kysyä mitään.

Legacy File Converter luettelee pelkän tekstin (.txt) asiakirjojen joukossa Tuetut tiedostotyypit -sivullaan ja muuntaa ne omalla Windows-tietokoneellasi nykyaikaisiin muotoihin, kuten DOCX, PDF, Markdown tai HTML; mitään ei lähetetä minnekään. Vertaa muunnoksen jälkeen aksenttikirjaimia, lainausmerkkejä ja symboleja alkuperäiseen ja säilytä alkuperäinen tiedosto. Muista muodoista, jotka ovat pohjimmiltaan pelkkää tekstiä, katso Historiatunti: Mikä on .csv-tiedosto?, jossa puuttuva BOM saa Excelin kompastelemaan, sekä Historiatunti: Mikä on .rtf-tiedosto?.