PDF-tiedostot tarkenteella ja ilman

[iTry]

Poistin kansiollisesta pdf-tiedostoja yksinkertaisella Automator-ohjelmalla tiedoston nimen tarkenteen (".pdf"), koska halusin käyttää nimiä joissain sovelluksissa sellaisenaan. Suurin osa näistä tiedostoista näkyy Finderissa edelleen pdf-ikoneina ja avautuu ohjelmissa normaalisti. Osa näkyy tyyppinä "dokumentti" (tyhjä ikoni), mutta avautuu silti pdf:nä. Osa tiedostoista näyttää tarkenteen poiston jälkeen tyyppiä "suoritettava ohjelma" ja avaa klikattaessa Päätteen, joka yrittää suorittaa niitä. Lisäämällä tarkenne takaisin tiedoston nimeen se palautuu normaaliksi.

Haluaisin ymmärtää, millä logiikalla ja miksi osa tiedostoista käyttäytyy tarkenteen poistamisen jälkeen eri tavalla ja osa ei. Kaikki tiedostot on tehty tulostamalla MS-Word -dokumentti pdf:ksi. Käyttöjärjestelmän kertomissa tiedoissa ei näy eroja tiedostojen välillä eli periaatteessa ainoan eron pitäisi olla niiden sisällössä.

[Lampela]

Voi olla että kokemukseni ei enää päde, mutta MS-Word on aina ollut omituinen täällä Mac puolella. Kun Mac dokumentit ovat periteisesti käyttäneet resurssihaarukkaa joka kertoo millä ohjelmalla dokumentti on tehty ja mikä on dokumentin muoto, ei dokumentin päätteellä ole ollut sellaista merkitystä kuin pc puolella. Tämä resurssihaarukka-ajattelu ei ole ollut koskaan Mikrosoftin vahvimpia puolia. Ei taida olla enää minkään järjestelmän vahvimpia puolia kuten ei standardointi yleensäkään tietotekniikassa.

Onneksi on edes html jota sitäkään eivät kaikki noudata vaan tekevät mitä omituisimpia omia viritelmiä jotka ovat pääasiassa haitakkeita ja potentiaalisia viruksien levittäijiä kuten java.

[jkoodari]

Mitä Finderin Get Info näyttää sellaisen tiedoston kohdalla jossa on PDF-ikoni ja se aukeaa normaalisti, mutta PDF-pääte puuttuu?

ruutu2014-08-19_06-35-43_pm.png

[homenamsi]

Poistin kansiollisesta pdf-tiedostoja yksinkertaisella Automator-ohjelmalla tiedoston nimen tarkenteen (".pdf"), koska halusin käyttää nimiä joissain sovelluksissa sellaisenaan. Suurin osa näistä tiedostoista näkyy Finderissa edelleen pdf-ikoneina ja avautuu ohjelmissa normaalisti. Osa näkyy tyyppinä "dokumentti" (tyhjä ikoni), mutta avautuu silti pdf:nä. Osa tiedostoista näyttää tarkenteen poiston jälkeen tyyppiä "suoritettava ohjelma" ja avaa klikattaessa Päätteen, joka yrittää suorittaa niitä. Lisäämällä tarkenne takaisin tiedoston nimeen se palautuu normaaliksi.

Haluaisin ymmärtää, millä logiikalla ja miksi osa tiedostoista käyttäytyy tarkenteen poistamisen jälkeen eri tavalla ja osa ei. Kaikki tiedostot on tehty tulostamalla MS-Word -dokumentti pdf:ksi. Käyttöjärjestelmän kertomissa tiedoissa ei näy eroja tiedostojen välillä eli periaatteessa ainoan eron pitäisi olla niiden sisällössä.

Logiikasta en nykyisellään tiedä, koska tuo Applen alkuperäisen Macintoshin käyttöjärjestelmän (Finder 1.1...MacOS 9.2.1) vaatimia creator/type - tietoja ei käsittääkseni enää MacOS X:ssä ole enää yleisesti käytetty vaikka tiedostojärjestelmä (HFS+) sitä todennäköisesti edelleen tukee.

Unixissahan on vain tämä tiedoston nimeen liittyvä sopimus, jota sitten on plagioitu siellä sun täällä.

Kaksi teoriaa/arvausta:
1. Ne jotka tietävät olevansa PDF:ää ovat HFS+ -taltiolla, ne jotka eivät taas exFAT- tai FAT16/32-taltiolla.
2. 1. Ne jotka tietävät olevansa PDF:ää on avattu jollain PDF-katseluohjelmalla (Esikatselu, muitakin on) , ne jotka eivät, niitä ei ole avattu (liittyy tavallaan tuohon edelliseen eli HFS+ - olettamaan)

Todellinen tieto logiikasta kiinnostaisi kyllä minuakin..

[jkoodari]

Tiedostoon voi liittää tiedon millä ohjelmalla se avataan ja silloin tiedoston pääte ei ole merkitsevä, kunhan aukeava ohjelma osaa tulkita tiedoston muodon sen sisällöstä.

[vemssi]

OS X ei käytä resurssihaarukan creator/type -tietoja, vaan sen on korvannut UTI (Uniform Type Identifier), jonka perusteella tiedoston tyyppi tunnistetaan. UTI noudattelee esim. Javasta tuttua käänteistä DNS-rakennetta; esim. PDF:lle se on com.adobe.pdf ja PNG-kuvalle public.png. UTI voi muodostaa hierarkioita, joten esim. public.png kuuluu ylempään public.image -luokkaan, joka puolestaan kuuluu yleiseen public.data -luokkaan.

Jos tiedoston metadatasta puuttuu UTI, niin Finder ei tunnista tiedostoa. Miksi Word ei UTI:a ole jokaiseen PDF:ään lisännyt, on... No, niin.

Unix tunnistaa tiedostot ns. magic fingerprintillä, eli lukemalla tiedoston alusta muutaman tavun dataa ja vertaamalla sitä tunnettujen tiedostoformaattien vastaaviin tavuihin. Myös OS X osaa tämän tempun (kokeile Terminaalissa komentoa 'file tiedoston_nimi'), mutta Finder ei.

[homenamsi]

UTIsta nyt viisastuneena - kiitos vemssin - paljon lisäkysymyksiä lisää viisastuakseni:

Onko tuo UTI tiedostojärjestelmäriippumaton, ts. mahtuuko - ja onko sillä paikkansa - ko. metadata Mac-käyttäjille oudompien tiedostojärjestelmien tiedostotunnisteisiin (FAT16, NTFS, EXTn,... tms.)? exFAT lienee automaattisesti OK.

Kenen tuo UTI on (määrittelemä)?

Jos otsikon metadatan sisältö on sovellusohjelman vastuulla niin voisi kuvitella olevan jokin apuohjelma, jolla voi verrata UTI-tietoa ja tiedostonimeä.

Eikö MacOS X nyt sitten käytä lainkaan tiedostonimeä päättelemään, millä ohjelmalla avata tiedostoa?

Ja lopulta, kai uusimmillakin MacOS X:llä formatoitu HFS+ -partitio tukee edelleen aiempia MacOS:n tiedosto-otsakkeiden luontikäytäntöjä (creator/type) ja X osaa tulkita niitä (MacOS 8/9)?

[Lampela]

OS X ei käytä resurssihaarukan creator/type -tietoja, vaan sen on korvannut UTI (Uniform Type Identifier), jonka perusteella tiedoston tyyppi tunnistetaan. UTI noudattelee esim. Javasta tuttua käänteistä DNS-rakennetta; esim. PDF:lle se on com.adobe.pdf ja PNG-kuvalle public.png. UTI voi muodostaa hierarkioita, joten esim. public.png kuuluu ylempään public.image -luokkaan, joka puolestaan kuuluu yleiseen public.data -luokkaan.

Jos tiedoston metadatasta puuttuu UTI, niin Finder ei tunnista tiedostoa. Miksi Word ei UTI:a ole jokaiseen PDF:ään lisännyt, on... No, niin.

Unix tunnistaa tiedostot ns. magic fingerprintillä, eli lukemalla tiedoston alusta muutaman tavun dataa ja vertaamalla sitä tunnettujen tiedostoformaattien vastaaviin tavuihin. Myös OS X osaa tämän tempun (kokeile Terminaalissa komentoa 'file tiedoston_nimi'), mutta Finder ei.

Kiitos tiedosta. Meinasin juuri lähteä hakemaan tietoa, mutta tämä riitti minulle. Surullista on että standardia ei ole päässyt syntymään.

[vemssi]

Onko tuo UTI tiedostojärjestelmäriippumaton, ts. mahtuuko - ja onko sillä paikkansa - ko. metadata Mac-käyttäjille oudompien tiedostojärjestelmien tiedostotunnisteisiin (FAT16, NTFS, EXTn,... tms.)? exFAT lienee automaattisesti OK.

UTI on periaatteessa tiedostojärjestelmäriippumaton, samoin kuin mikä tahansa muukin tiedoston tunnistamisjärjestelmä missä tahansa käyttöjärjestelmässä. Tiedoston tunnistaminenhan on loppujen lopuksi käyttöjärjestelmän tehtävä, ei tiedostojärjestelmän, joka vain säilöö tiedoston.

Tiedostotarkenne (aka .pdf) on osa tiedoston nimeä. Toisissa käyttöjärjestelmissä sillä on merkitystä, toisissa ei. Metadata taas on "tietoa tiedosta", toisin sanoen tietoa levylle tallenetusta tiedostosta, joka ei kuitenkaan ole itse sitä tiedostossa olevaa dataa. Yleisin metadata on tiedoston tallennus-/muokkaus-/avausaikaleima. Näin ollen likipitäen jokainen tiedostojärjestelmä ymmärtää ja käyttää metadataa, myös se aataminaikainen FAT16. "Surkein" tiedostojärjestelmä suhteessa metadataan lienee CP/M File System ja pahaksi onneksi se on juuri se aikanaan "tuttu ja turvallinen käyttäjänäkymä", jonka FAT omaksui.

Resurssihaarukat, UTI:t sun muut "metadatat" ovat nekin metadataa ja sellaiselle metadatalle löytyy vaihtelevammin tukea eri tiedostojärjestelmistä, mutta melko laajasti kuitenkin. Esim. Linuxista tutut ext2-, ext3- ja ext4-tiedostojärjestelmät kutsuvat sitä nimellä Extended Attributes, Mac OS puolestaan resurssihaarukaksi, NTFS taas nimellä Alternate Data Streams ja HFS+ nimellä Attribute Data Records. Mahdollisesti paras metadatatuki on BeFS-tiedostojärjestelmässä, jossa metadataa voidaan käsitellä kuten relaatiotietokantaa indeksointeineen ja kyselyineen.

Kenen tuo UTI on (määrittelemä)?

Applen ja se tuli kuvaan Mac OS X 10.4:ssä. Sen toteutus on käyttöjärjestelmän CoreFoundation-kirjastossa. käyttöjärjestelmän tarjoamat UTI:t voi katsoa täältä. Lisäksi ohjelmistojen kehittäjät voivat esitellä omia UTI:aan käyttöjärjestelmän ylläpitämään listaan, jolloin käyttöjärjestelmä sitten tunnistaa nämä uudetkin tyypit.

Eikö MacOS X nyt sitten käytä lainkaan tiedostonimeä päättelemään, millä ohjelmalla avata tiedostoa?

Jos UTI:a ei löydy, niin sitten jollain sumealla logiikalla yhdistelemällä tiedoston tarkennetta, tiedoston magic numberia ja kuun asentoa.

Ja lopulta, kai uusimmillakin MacOS X:llä formatoitu HFS+ -partitio tukee edelleen aiempia MacOS:n tiedosto-otsakkeiden luontikäytäntöjä (creator/type) ja X osaa tulkita niitä (MacOS 8/9)?

Ilman muuta, mutta jos luet sitä tiedostojärjestelmää Mac OS X 10.0 - Mac OS X 10.3 -käyttöjärjestelmällä, niin niillä ei ole mitään merkitystä vaikka se tieto siellä tiedostojärjestelmässä onkin.

[jkoodari]

Miten UTI-tiedon näkee?

[homenamsi]

Kiitokset erinomaisista vastauksista uteluihini. Seuraava jäi vielä askarruttamaan mieltä:

homenamsi kirjoitti:
Ja lopulta, kai uusimmillakin MacOS X:llä formatoitu HFS+ -partitio tukee edelleen aiempia MacOS:n tiedosto-otsakkeiden luontikäytäntöjä (creator/type) ja X osaa tulkita niitä (MacOS 8/9)?

Ilman muuta, mutta jos luet sitä tiedostojärjestelmää Mac OS X 10.0 - Mac OS X 10.3 -käyttöjärjestelmällä, niin niillä ei ole mitään merkitystä vaikka se tieto siellä tiedostojärjestelmässä onkin.

Mahtoiko kuitenkin Rosetta tai Classic--ympäristö osata käyttää noita? Mielestäni käytin jonkin verran ongelmitta ristiin rastiin natiivissa ysikäyttiksessä, MacOS X/Rosettalla ja X/Classicissa AppleWorksin ja MS Officen tiedostoja verkkojakojen ja Zip-levyjen kautta.

Voihan toki olla, että tunnistus perustui johonkin muuhun magiaan mutta en muista ongelmiinkaan törmänneeni.

[vemssi]

Miten UTI-tiedon näkee?

Esim. Terminaalissa komennolla:

Koodi: Valitse kaikki

mdls /path/to/yourfile | grep kMDItemContentType

[vemssi]

homenamsi kirjoitti:
Ja lopulta, kai uusimmillakin MacOS X:llä formatoitu HFS+ -partitio tukee edelleen aiempia MacOS:n tiedosto-otsakkeiden luontikäytäntöjä (creator/type) ja X osaa tulkita niitä (MacOS 8/9)?

Ilman muuta, mutta jos luet sitä tiedostojärjestelmää Mac OS X 10.0 - Mac OS X 10.3 -käyttöjärjestelmällä, niin niillä ei ole mitään merkitystä vaikka se tieto siellä tiedostojärjestelmässä onkin.

Mahtoiko kuitenkin Rosetta tai Classic--ympäristö osata käyttää noita?

Tähän en osaa vastata, mutta loogisesti ajateltuna niiden kyllä täytyi osata, sillä muutenhan MacOS-ohjelmat eivät olisi toimineet oikein.