Tiedostotyypeistä

   tietotekniikka

Kauan, kauan sitten galaksissa hyvin, hyvin kaukana… Eiku tällä planeetalla, mutta henkilökohtaisten tietokoneiden aamuhämärässä Microsoft päätti käyttää Unixien (johon idea oli lainattu ties mistä) tapaa ilmaista tiedoston tyyppi päätteen avulla. Aluksi kaikki toimi hyvin, kaksoisosoittamalla doc-tiedostoa, se aukesi MS Worksiin, txt-tiedosto Muistioon jne. Unixithan olivat ammattilaisten koneita, joten he tiesivät, minkä tyyppinen kukin tiedosto on – sitä paitsi Unixeissahan varsinkin tuolloin lähes kaikki olivat tekstitiedostoja ja Emacs ruletti (ja itseaiheutettu lobotomia raivosi) – joten aina päätettä ei edes viitsitty laittaa. MS DOS -koneet sitä vastoin oli suunnattu enemmän tai vähemmän tavallisille käyttäjille, joten tavaksi tuli, että jokaiseen tiedostoon lisättiin pääte.

Apple tuumaili niin ikään asiaa ja huomasi, että oikeastaan kyse on kahdesta asiasta:

  • minkä ohjelman luoma tiedosto on (tiedoston omistaja) ja
  • mikä on sen tyyppi (miten tiedoston sisältö on koodattu).

Näille Apple antoi nimet creator code ja file type, jälkimmäistä kutsutaan joskus ei-Apple -kirjallisuudessa nimellä Mac type. Samasta syystä kuin Microsoft oli päätynyt muistia ja kovalevytilaa säästävään 8+3 -nimikäytäntöön, Apple päätti, että nämä tunnisteet ovat enintään nelimerkkisiä.

Mutta mihin tallentaa nuo kaksi tunnistetta? Päätteen avullahan saattoi ilmaista vain toisen. Keinoksi Apple valitsi tiedostohaaran (fork), joka on tiedoston sisällä oleva lohko, jota voi käsitellä toisista lohkoista erillään. Siinä missä MS DOS -käyttöjärjestelmän tiedostojärjestelmässä FAT:ssa tiedostoissa oli oikeastaan vain yksi tiedostohaara, heti Applen ensimmäisessä tiedostojärjestelmässä MFS:ssä tiedostolla saattoi olla useita, yleensä kaksi: resource fork ja data fork. Ensin mainittuun tallennettiin tiedoston metadata ml. nuo creator code ja file type.

Kaikki toimi hienosti, esim. koneella saattoi olla kaksi mp3-äänitiedostoa (tyyppi ”MP3”), joista toisen omistaja on Itunes (omistaja ”hook”) ja toisen Winamp (”NSWa”). Tällöin ekaa tiedostoa kaksoisklikatessa käynnistyi Itunes ja jälkimmäistä klikatessa Winamp. Tämä temppu ei muuten onnistu MS Windowseissa tänäkään päivänä ilman valintaa kohdevalikosta. Tämä ratkaisu oli itse asiassa niin hyvä, että mäkkien käyttäjät vuosien saatossa tottuivat siihen siinä määrin, että satunnaisesti joutuessaan voiman pimeälle puolelle ihmettelivät, miksi tiedostoa kaksoisosoittamalla käynnistyi joskus aivan väärä sovellus.

Sivuhuomautuksena kerrottakoon, että Microsoft otti MS Windows NT:n myötä käyttöön useamman haaran, mutta vasta MS Windows Vistassa niille ilmestyi enemmän tukea. Valitettavasti niiden käyttö on jäänyt vähiin, mikä johtunee siitä, että koko asia on monelle ohjelmistokehittäjille aivan outo. Eikä MS ei muuten olisi MS, ellei olisi keksinyt haaroille aivan uutta nimeä, Alternate Data Streams ADS.

Aluksi sekä tiedostopäätteet että Applen tiedostohaarat toimivat, koska sovellukset käyttivät enimmäkseen omia tiedostotyyppejään. Sitten asiat alkoivat muuttua, tuli käyttöön yleisiä tiedostotyyppejä, joita saattoi käsitellä useilla ohjelmilla: jpeg, html jne. Käyttöjärjestelmälle nämä aiheuttivat ongelmia. Avatako käyttäjän kaksoisklikkaama jpeg-kuva jossain kuvankäsittelyohjelmassa vai vain jossain katseluohjelmassa vai verkkosivuselaimessa? Avatako html-tiedosto selaimessa, tekstimuokkaimessa vai jossain verkkosivumuokkaimessa? Microsoft päätti pitää kiinni tiedostopäätteestä eli ei oikeastaan tehnyt asialle mitään. Periaate ”kaikki tai ei mitään” pysyi: jos vaihtoi jpeg-tiedostojen oletusohjelman MS IE:stä Adoben Photoshoppiin, jokainen kaksoisosoitus merkitsi tuskastuttavan pitkää Photarin käynnistymistä, jos se ei ollut valmiiksi käynnissä. Ei hyvä.

 

Applen ongelmaksi tuli, että tiedostot kävivät yhä useammin mäkkien ulkopuolella – ftp- ja webbipalvelimilla, MS Windowseissa – jotka hukkasivat resource forkin eli metadatan. Tällöin käyttöjärjestelmä ei tiennyt, mihin sovellukseen tiedosto täytyi lähettää avattavaksi. Mac OS X:n myötä Apple antoi periksi ja otti käyttöön päätteet creator coden ja file typen rinnalle. Tällöin tiedosto, josta nämä puuttuivat (esim. verkosta ladattu jpeg-kuva), aukaistiin käyttöjärjestelmään kirjatussa oletusohjelmassa – siis samaan tapaan kuin MS toimi tiedostopäätteiden kanssa. Jos käyttäjä halusi poikkeuksen, että jokin tietty tälläinen kuva aukeaisi jossakin toisessa ohjelmassa, hän saattoi lisätä tiedoston tiedot -ikkunan kautta tämän tiedon. Pellin alla käyttäjä siis loi tiedostolle resource forkin ja kirjoitti siihen tarvittavan tiedon. Näin olisi voitu jatkaa vuosia, mutta Apple päätti jossain vaiheessa (Lumileopardin eli Mac OS X 10.6 myötä?) muuttaa tarvittavan API:n yksityiseksi, joten ohjelmat eivät enää voi luoda omia tiedostojaan, joissa olisi resource fork.

Tilalle Apple tarjosi Tiikerin eli Mac OS X 10.4:n myötä käyttöön otettua Uniform Type Identifier UTI -nimistä rakennetta. UTI:n idea perustuu oikeastaan URI:in eli tässä tapauksessa tiedoston tyypin määrittävään merkkijonoon, joka on muodoltaan käänteinen DNS-nimi (esim. public.jpeg tai com.adobe.pdf). Toisin kuin MIME-määritteet UTI:t voivat moniperiytyä, jolloin tiedostot voidaan tarvittaessa avata usealla ohjelmalla, esim. videotiedosto voidaan avata ohjelmassa, joka toistaa pelkän ääniraidan. Nyt vain kävi niin, että UTI:lla ei tehnyt mitään Tiikerissä (vanha creator code -järjestelmä ryyditettynä tiedostopäätteillä toimi), joten ohjelmistokehittäjät ja ennen kaikkea jotkut kehitystyökalujen valmistajat eivät kiinnittäneet siihen huomiota.

Teknisessä mielessä UTI:t ovat ihan toimiva ratkaisu, mutta Applen ja kehitystyökalujen valmistajien välisen tietokatkoksen takia pari seuraavaa käyttöjärjestelmän versiota kärsi ongelmista, kun käyttöjärjestelmä ei enää ymmärtänyt creator codeja eivätkä kolmansien osapuolien sovellukset ymmärtäneet UTI-tunnuksia. Tätä nykyä ongelmaa ei enää ole.

Merkille pantavaa on, että Mäkkien käyttäjille näkyvä osuus ei ole muuttunut. Edelleen tiedoston tietoja tarkasteltaessa voi valita oletussovelluksen, johon tiedosto avataan sitä kaksoisklikattaessa. Valittavissa olevien sovellusten määrä on ehkä kasvanut.

UTI:t ovat muuten yksi syy, miksi Apple on välillä halunnut, että ohjelmat asennetaan asennusohjelman avulla: asennusohjelma lisää ohjelman omien tiedostotyyppien UTI:t käyttöjärjestelmän ylläpitämään UTI-tietokantaan. Tämä tietokanta määrittää, mitä sovelluksia tarjotaan minkäkin tiedoston yhteydessä (MS Windowsissa vastaava tieto tallennetaan nk. rekisteriin). Vaihtoehtoisesti ohjelma ensi kertaa käynnistyessään tekee tämän.

Entäs Microsoftin ADS? MS:n tiedostohallintasovellus Windows Explorer ei osaa niitä, joten suurin osa käyttäjistä tai edes ohjelmistokehittäjistä ei tiedä niiden olemassaolosta. Yleisin ja melkein ainut käyttö on nykyään, että tiedostoja webistä ladattaessa webbiselaimet kirjoittavat tiedostohaaraan merkinnän, että tiedosto on ladattu internetistä. Tämän perusteella Windows Explorer varoittaa sitten käyttäjää tiedostoa avattaessa. Kun käyttäjä hyväksyy avaamisen, merkintä ja yleensä koko tiedostohaara poistetaan.

Tiedostohaarat ovat tavallaan hukattu mahdollisuus tallentaa tiedostojen yhteyteen ennen kaikkea metatietoja yhtenäisellä tavalla. Apple joutui luopumaan niistä, kun tiedonsiirtosovellukset eivät niitä tukeneet. MS ei kai puolestaan oikein keksinyt niille käyttöä eikä näin ollen ole mainostanut niitä ohjelmistokehittäjille.

avainsanat |
Ei kommentteja

Vastaa

Sähköpostiosoitettasi ei julkaista. Pakolliset kentät on merkitty *

This site uses Akismet to reduce spam. Learn how your comment data is processed.