Fájlformátum - File format

wav fájl: 2,1 megabájt.
ogg-fájl: 154 kilobájt.

A fájlformátum egy szabványos módja annak, hogy az információkat kódolják a számítógépes fájlban való tároláshoz . Meghatározza, hogyan használják a biteket az információk digitális adathordozón történő kódolására. A fájlformátumok lehetnek szabadalmazottak vagy ingyenesek, és lehetnek közzé nem tett vagy nyílt formátumúak .

Egyes formátumok vannak tervezve nagyon bizonyos típusú adatok: PNG fájlokat, például store bittérképes képek segítségével veszteségmentes tömörítés . Más fájlformátumokat azonban többféle típusú adat tárolására terveztek: az Ogg formátum különböző típusú multimédiák tárolójaként működhet, beleértve az audio és videó bármilyen kombinációját, szöveggel vagy anélkül (például felirattal ) és metaadatokat . A szöveges fájl tetszőleges karakterfolyamot tartalmazhat, beleértve a lehetséges vezérlőkaraktereket is , és különböző karakterkódolási sémák egyikében van kódolva . Egyes formátumok, mint a HTML , méretezhető vektorgrafikus , és a forráskódot a számítógép program olyan szöveges fájlok, meghatározott szintaxis , amelyek lehetővé teszik számukra, hogy használják az adott célra.

Specifikációk

A fájlformátumok gyakran rendelkeznek közzétett specifikációval, amely leírja a kódolási módszert, és lehetővé teszi a program által tervezett funkciók tesztelését. Nem minden formátum rendelkezik szabadon hozzáférhető specifikációs dokumentumokkal, részben azért, mert egyes fejlesztők a specifikációs dokumentumaikat üzleti titoknak tekintik , másrészt pedig azért, mert más fejlesztők soha nem készítenek hivatalos specifikációs dokumentumot, és hagyják, hogy a formátumot használó más, már létező programok által létrehozott precedens határozza meg a formátumot. ezek a meglévő programok használják.

Ha egy formátum fejlesztője nem tesz közzé ingyenes specifikációkat, akkor egy másik, az ilyen típusú fájlt használni kívánó fejlesztőnek vagy vissza kell fejlesztenie a fájlt, hogy megtudja, hogyan kell elolvasni, vagy díj ellenében és aláírásával meg kell szereznie a specifikációs dokumentumot a formátum fejlesztőitől. egy titoktartási megállapodást . Ez utóbbi megközelítés csak akkor lehetséges, ha létezik hivatalos specifikációs dokumentum. Mindkét stratégia jelentős időt, pénzt vagy mindkettőt igényel; ezért a nyilvánosan elérhető specifikációjú fájlformátumokat általában több program támogatja.

Szabadalmak

A fájlformátumok védelmére gyakrabban a szabadalmi törvényeket használják, nem pedig a szerzői jogokat . Bár a fájlformátumok szabadalmait közvetlenül nem engedélyezi az amerikai törvény, egyes formátumok szabadalmazott algoritmusokkal kódolják az adatokat . Például a GIF fájlformátumú tömörítés használata szabadalmaztatott algoritmus használatát igényli, és bár a szabadalom tulajdonosa eredetileg nem érvényesítette szabadalmát, később elkezdték szedni a jogdíjakat . Ennek eredményeként jelentősen csökkent a GIF -ek használata, és részben felelős az alternatív PNG -formátum kifejlesztéséért . A GIF szabadalom azonban az USA-ban 2003 közepén, világszerte 2004 közepén járt le.

A fájltípus azonosítása

A különböző operációs rendszerek hagyományosan különböző megközelítéseket alkalmaztak egy adott fájl formátumának meghatározására, minden megközelítésnek megvannak a maga előnyei és hátrányai. A legtöbb modern operációs rendszernek és egyedi alkalmazásnak az alábbi módszerek mindegyikét kell használnia az "idegen" fájlformátumok olvasásához, ha nem is teljesen velük.

Fájlnév kiterjesztés

A sok operációs rendszer, köztük a Windows , a macOS , a CP/M , a DOS , a VMS és a VM/CMS által használt egyik népszerű módszer a fájl formátumának meghatározása a neve vége, pontosabban az utolsó időszakot követő betűk alapján. Ez része a fájlnév az úgynevezett fájlnév kiterjesztése . Például a HTML dokumentumokat a .html (vagy .htm ) végű nevek, a GIF képeket pedig a .gif azonosítja . Az eredeti FAT fájlrendszerben a fájlnevek egy nyolc karakterből álló azonosítóra és egy három karakterből álló kiterjesztésre korlátozódtak, amelyet 8.3 fájlnévnek neveznek . Csak annyi hárombetűs kiterjesztés létezik, ezért gyakran bármelyik bővítmény több programhoz is kapcsolódik. Sok formátum továbbra is három karakteres kiterjesztést használ, annak ellenére, hogy a modern operációs rendszerek és alkalmazásprogramok már nem rendelkeznek ezzel a korlátozással. Mivel nincs szabványos bővítménylista, több formátum is használhatja ugyanazt a kiterjesztést, ami megzavarhatja mind az operációs rendszert, mind a felhasználókat.

Ennek a megközelítésnek az egyik tárgya az, hogy a rendszer egyszerűen becsapható úgy, hogy egy fájlt más formátumként kezel, egyszerűen átnevezve - egy HTML fájl például könnyen kezelhető egyszerű szövegként, ha átnevezi a fájlnév.html fájlról a fájlnévre. txt . Bár ez a stratégia hasznos volt a szakértő felhasználók számára, akik könnyen megértették és manipulálták ezeket az információkat, gyakran zavaró volt a kevésbé technikai felhasználók számára, akik véletlenül használhatatlanná tehetik (vagy "elveszíthetik") a fájlt, ha helytelenül átnevezték.

Ez arra késztette a Windows és a Mac OS legtöbb verzióját, hogy elrejtse a kiterjesztést a fájlok listázásakor. Ez megakadályozza, hogy a felhasználó véletlenül megváltoztassa a fájltípust, és lehetővé teszi a szakértő felhasználók számára, hogy kikapcsolják ezt a funkciót, és megjelenítsék a kiterjesztéseket.

A kiterjesztés elrejtése azonban két vagy több azonos fájlnév megjelenését eredményezheti ugyanabban a mappában. Például szükség lehet egy vállalati logóra .eps formátumban (közzétételhez) és .png formátumban (webhelyekhez). Ha a kiterjesztések láthatók, ezek egyedi fájlnevekként jelennek meg: " CompanyLogo.eps " és " CompanyLogo.png ". Másrészt, ha elrejti a kiterjesztéseket, mindkettő " CompanyLogo " néven jelenik meg , ami zavart okozhat.

A kiterjesztések elrejtése biztonsági kockázatot is jelenthet. Például egy rosszindulatú felhasználó létrehozhat egy futtatható programot ártatlan névvel, például " Holiday photo.jpg.exe ". Az " .exe " el lesz rejtve, és egy gyanútlan felhasználó látja a " Holiday photo.jpg " -t, amely JPEG képnek tűnik, és általában nem károsíthatja a gépet. Az operációs rendszer azonban továbbra is látja az " .exe " kiterjesztést, és futtatja a programot, amely aztán kárt okozhat a számítógépben. Ugyanez vonatkozik az egyetlen kiterjesztésű fájlokra is: mivel nem jelenik meg a felhasználó számára, a fájlra vonatkozó információk nem vezethetők le a fájl kifejezett kivizsgálása nélkül. A felhasználók további becsapása érdekében lehetőség van egy ikon tárolására a programon belül, ebben az esetben egyes operációs rendszerek ikonja a végrehajtható fájlhoz ( .exe ) felülbírálásra kerül egy, a JPEG képek ábrázolására általában használt ikonnal, így a program megjelenése mint egy kép. A kiterjesztéseket is hamisítani lehet: egyes Microsoft Word makróvírusok sablon formátumú Word fájlt hoznak létre, és .doc kiterjesztéssel mentik . Mivel a Word általában figyelmen kívül hagyja a kiterjesztéseket, és megvizsgálja a fájl formátumát, ezek sablonként nyílnak meg, végrehajtják és terjesztik a vírust. Ez gyakorlati problémát jelent azoknak a Windows rendszereknek, ahol a kiterjesztés elrejtése alapértelmezés szerint be van kapcsolva.

Belső metaadatok

A fájlformátum azonosításának második módja a fájlban tárolt formátumra vonatkozó információk felhasználása , akár az erre a célra szánt információk, akár bináris karakterláncok, amelyek bizonyos formátumú fájlokban mindig bizonyos helyeken találhatók. Mivel a legegyszerűbb megtalálni őket az elején, így a területet általában úgynevezett fájl fejlécében ha ez nagyobb, mint néhány byte , vagy bűvös szám , ha ez csak néhány bájt hosszú.

Fájlfej

A metaadatok tartalmazott egy fájl fejlécében általában tároljuk elején a fájlt, de jelen lehet más területeken is, köztük gyakran a végén, attól függően, hogy a fájl formátum vagy az adatok típusát tartalmazza. A karakter alapú (szöveges) fájlok általában karakter alapú fejlécekkel rendelkeznek, míg a bináris formátumok általában bináris fejlécekkel rendelkeznek, bár ez nem szabály. A szöveg alapú fájlfejlécek általában több helyet foglalnak el, de mivel ember által olvashatók, könnyen megvizsgálhatók egyszerű szoftverek, például szövegszerkesztő vagy hexadecimális szerkesztő használatával.

A fájlformátum azonosításán túl a fájlfejlécek metaadatokat is tartalmazhatnak a fájlról és tartalmáról. Például a legtöbb képfájl információkat tárol a képformátumról, a méretről, a felbontásról és a színtérről , és adott esetben szerzői információkat is tartalmaz, például, hogy ki készítette a képet, mikor és hol készült, milyen fényképezőgép -modellt és fényképészeti beállításokat használtak ( Exif ), és hamar. Az ilyen metaadatokat a szoftver használhatja a fájl olvasására vagy értelmezésére a betöltési folyamat során és azt követően.

A fájlfejléceket az operációs rendszer használhatja arra, hogy gyorsan információkat gyűjtsön egy fájlról anélkül, hogy mindezt betöltené a memóriába, de ez több számítógép erőforrását használja fel, mint közvetlenül a könyvtárinformációkból való olvasás . Például, ha egy grafikus fájlkezelőnek ki kell jelenítenie egy mappa tartalmát, sok fájl fejlécét el kell olvasnia, mielőtt megjelenítené a megfelelő ikonokat, de ezek a tárolóeszköz különböző helyein találhatók, így hosszabb ideig tart a hozzáférés . Ha egy mappa sok fájlt tartalmaz, bonyolult metaadatokkal, például miniatűr adatokkal, akkor sok időbe telhet, mielőtt megjeleníthetők.

Ha egy fejléc binárisan kódolt , és maga a fejléc bonyolult értelmezést igényel ahhoz, hogy felismerhető legyen, különösen a metaadatok tartalmának védelme érdekében, fennáll annak a veszélye, hogy a fájlformátum rosszul értelmezhető. Lehet, hogy a forrásnál is rosszul írták. Ez sérült metaadatokat eredményezhet, amelyek rendkívül rossz esetekben akár olvashatatlanná is tehetik a fájlt.

A fájlfejlécek összetettebb példái a burkoló (vagy tároló) fájlformátumok.

Varázslatos szám

A gyakran a Unixhoz és származékaihoz kapcsolódó fájltípus -metaadatok beépítésének egyik módja az , ha csak egy "varázslatos számot" tárol magában a fájlban. Eredetileg ezt a kifejezést a fájlok kezdetén a 2 bájtos azonosítók meghatározott készletére használták, de mivel bármely bináris szekvencia számnak tekinthető, a fájlformátum bármely olyan jellemzője, amely egyedileg megkülönbözteti, felhasználható az azonosításra. GIF képek, például mindig kezdődik ASCII ábrázolását sem GIF87a vagy GIF89a függően a standard általuk követett. Sok fájltípust, különösen a sima szöveges fájlokat, nehezebb felismerni ezzel a módszerrel. A HTML -fájlok például kezdődhetnek a <html> karakterlánccal (amely nem különbözteti meg a kis- és nagybetűket), vagy egy megfelelő dokumentumtípus -meghatározással, amely <! DOCTYPE HTML> -vel kezdődik , vagy XHTML esetén az XML -azonosítóval, amely <-vel kezdődik ? xml . A fájlok HTML -megjegyzésekkel, véletlenszerű szöveggel vagy több üres sorral is kezdődhetnek, de továbbra is használható HTML -fájlok lehetnek.

A mágikus számok megközelítése jobb garanciát nyújt a formátum helyes azonosítására, és gyakran pontosabb információkat is meghatározhat a fájlról. Mivel az ésszerűen megbízható "mágikus szám" tesztek meglehetősen bonyolultak lehetnek, és minden fájlt hatékonyan kell tesztelni a mágikus adatbázis minden lehetőségével szemben, ez a megközelítés viszonylag nem hatékony, különösen a nagy fájllisták megjelenítéséhez (ezzel szemben a fájlnév és a metaadatok alapú módszereknek csak egy adatot kell ellenőrizniük, és egy rendezett indexhez kell igazítaniuk). Ezenkívül az adatokat magából a fájlból kell kiolvasni, növelve a késleltetést a könyvtárban tárolt metaadatokkal szemben. Ahol a fájltípusok ilyen módon nem ismerhetők fel, a rendszernek vissza kell térnie a metaadatokhoz. Ez azonban a legjobb módja annak, hogy egy program ellenőrizze, hogy a fájl, amelyet feldolgozásra utasítottak, megfelelő formátumú: míg a fájl neve vagy metaadatai a tartalomtól függetlenül módosulhatnak, de nem sikerül egy jól megtervezett varázsszám teszt elég biztos jele annak, hogy a fájl sérült vagy rossz típusú. Másrészt az érvényes varázsszám nem garantálja, hogy a fájl nem sérült, vagy nem megfelelő típusú.

A szkriptfájlokban az úgynevezett shebang sorok a mágikus számok különleges esetei. Itt a mágikus szám ember által olvasható szöveg, amely azonosítja a parancsparamétert és a parancsértelmezőnek továbbítandó lehetőségeket.

Egy másik mágikus számokat használó operációs rendszer az AmigaOS , ahol a mágikus számokat "varázsüteményeknek" hívták, és szabványos rendszerként alkalmazták a végrehajtható fájlok felismerésére a Hunk futtatható fájlformátumban, és lehetővé tették, hogy az egyes programok, eszközök és segédprogramok automatikusan kezeljék mentett adatfájljaikat , vagy bármilyen más fájltípust az adatok mentésekor és betöltésekor. Ezt a rendszert továbbfejlesztették az Amiga szabványos Datatype felismerő rendszerével. Egy másik módszer volt a FourCC módszer, amely Macintosh OSType -ből származik , később Interchange File Format (IFF) és származékai által adaptált .

Külső metaadatok

A fájl formátumának utolsó tárolási módja az, hogy a formátumra vonatkozó információkat kifejezetten a fájlrendszerben tárolja, nem pedig a fájlon belül.

Ez a megközelítés elkülöníti a metaadatokat mind a főadattól, mind a névtől, de kevésbé hordozható, mint a fájlnévkiterjesztések vagy a "mágikus számok", mivel a formátumot fájlrendszerből fájlrendszerré kell alakítani. Bár ez bizonyos mértékig igaz a fájlnévkiterjesztésekre is-például az MS-DOS három karakterkorlátjával való kompatibilitás érdekében-, a legtöbb tárolási forma nagyjából egyenértékű definícióval rendelkezik a fájl adataira és nevére, de előfordulhat, hogy az ábrázolásuk eltérő vagy nincs további metaadatokról.

Ne feledje, hogy a zip vagy archív fájlok megoldják a metaadatok kezelésének problémáját. Egy segédprogram egy új fájlban (például .zip kiterjesztésű zip fájlban ) több fájlt, valamint az egyes fájlok metaadatait, valamint a mappákat/könyvtárakat gyűjti össze . Az új fájl tömörített és esetleg titkosított is, de most egyetlen fájlként továbbítható az operációs rendszereken az FTP rendszerek által, vagy csatolható e -mailhez. A célállomáson egy kompatibilis segédprogramnak kell kicsomagolnia, hogy hasznos legyen, de az átvitel problémái így megoldódnak.

Mac OS típuskódok

A Mac OS " Hierarchikus fájlrendszer tárolja kódjait alkotója és típusú részeként a könyvtár bejegyzést minden fájlt. Ezeket a kódokat OSTypes -nek nevezzük. Ezek a kódok tetszőleges 4 bájtos szekvenciák lehetnek, de gyakran úgy választották ki, hogy az ASCII-reprezentáció értelmes karakterek sorozatát alkotta, például az alkalmazás nevének rövidítését vagy a fejlesztő kezdőbetűit. Például egy HyperCard „stack” fájl egy alkotója a WILD (az Hypercard korábbi neve, „wildcard”), és a típus a STAK . A BBEdit szövegszerkesztő létrehozói kódja R*chhivatkozik eredeti programozójára, Rich Siegelre . A típuskód a fájl formátumát adja meg, míg a készítői kód azt az alapértelmezett programot adja meg, amellyel megnyitja, ha a felhasználó duplán rákattint. Például a felhasználónak több szövegfájlja lehet , amelyek mindegyike TEXT típusú kóddal rendelkezik , de amelyek mindegyike más programban nyílik meg, mivel különböző alkotói kódok vannak. Ezt a funkciót úgy tervezték, hogy például az ember által olvasható egyszerű szöveges fájlokat egy általános célú szövegszerkesztőben lehessen megnyitni, míg a programozási vagy HTML kódú fájlokat egy speciális szerkesztőben vagy IDE-ben . Ez a szolgáltatás azonban gyakran okozott zavart a felhasználókban, mivel az, hogy melyik program indul el a fájlok dupla kattintásakor, gyakran kiszámíthatatlan volt. A RISC OS hasonló rendszert használ, amely egy 12 bites számból áll, amely a leírások táblázatában kereshető-pl. A hexadecimális szám FF5"alias" a PoScript-hez , ami PostScript- fájlt jelent.

Mac OS X egységes típusazonosítók (UTI -k)

Az egységes típusazonosító (Uniform Type Identifier, UTI) egy módszer, amelyet a macOS -ban használnak az egyedek "gépelt" osztályainak, például fájlformátumok egyedi azonosítására. Az Apple fejlesztette ki az OSType (típus és készítő kódok) helyettesítésére.

Az UTI egy Core Foundation karakterlánc , amely fordított DNS- karakterláncot használ . Egyes gyakori és szabványos típusok nyilvános tartományt használnak (pl. Public.png a hordozható hálózati grafikus képhez), míg más tartományok használhatók harmadik féltől származó típusokhoz (pl. Com.adobe.pdf a hordozható dokumentumformátumhoz ). Az UTI -k egy hierarchikus struktúrán belül definiálhatók, amely megfelelési hierarchia néven ismert. Így a public.png megfelel a public.image szupertípusának , amely maga is megfelel a public.data szupertípusának . Az UTI több hierarchiában is létezhet, ami nagy rugalmasságot biztosít.

A fájlformátumokon kívül az UTI -k más entitásokhoz is használhatók, amelyek létezhetnek a macOS -ban, beleértve:

  • Pasteboard adatok
  • Mappák (könyvtárak)
  • Fordítható típusok (a Fordításkezelő kezeli)
  • Kötegek
  • Keretrendszerek
  • Adatfolyam
  • Álnevek és szimbólumok

OS/2 kiterjesztett attribútumok

A HPFS , FAT12 és FAT16 (de nem FAT32) fájlrendszerek lehetővé teszik a "kiterjesztett attribútumok" tárolását fájlokkal. Ezek tetszőleges hármashalmazt tartalmaznak névvel, az érték kódolt típusával és egy értékkel, ahol a nevek egyediek, és az értékek akár 64 KB hosszúak is lehetnek. Vannak szabványosított jelentések bizonyos típusokhoz és nevekhez ( OS/2 alatt ). Az egyik ilyen, hogy a ".TYPE" kiterjesztett attribútum a fájltípus meghatározására szolgál. Értéke tartalmazza a fájlhoz tartozó egy vagy több fájltípus listáját, amelyek mindegyike karakterlánc, például "Sima szöveg" vagy "HTML dokumentum". Így egy fájlnak több típusa lehet.

Az NTFS fájlrendszer lehetővé teszi az OS/2 kiterjesztett attribútumok tárolását is, mint az egyik fájlvillát , de ez a szolgáltatás csak az OS/2 alrendszer támogatására szolgál (XP -ben nem), így a Win32 alrendszer átláthatatlanként kezeli ezeket az információkat blokkolja az adatokat, és nem használja fel. Ehelyett más fájlvillákra támaszkodik, hogy Win32-specifikus formátumban tárolja a metainformációt. Az OS/2 kiterjesztett attribútumokat a Win32 programok továbbra is olvashatják és írhatják, de az adatokat az alkalmazásoknak teljesen elemezniük kell.

POSIX kiterjesztett attribútumok

Unix és Unix-szerű rendszereken az ext2 , ext3 , ReiserFS 3. verzió, XFS , JFS , FFS és HFS+ fájlrendszerek lehetővé teszik a kiterjesztett attribútumok fájlokkal való tárolását. Ezek magukban foglalják a "name = value" karakterláncok tetszőleges listáját, ahol a nevek egyediek, és az értékek a hozzájuk kapcsolódó neveken keresztül érhetők el.

PRONOM egyedi azonosítók (PUID)

A PRONOM Persistent Unique Identifier (PUID) a fájlformátumok állandó, egyedi és egyértelmű azonosítóinak kiterjeszthető sémája, amelyet a The National Archives of the UK fejlesztett ki a PRONOM műszaki nyilvántartási szolgáltatás részeként . A PUID egységes erőforrás -azonosítóként fejezhető ki az info: pronom/ namespace segítségével. Bár a PUID rendszer még nem széles körben használatos az Egyesült Királyság kormányán és néhány digitális megőrzési programon kívül, nagyobb részletességet biztosít, mint a legtöbb alternatív rendszer.

MIME típusok

A MIME -típusokat széles körben használják számos internethez kapcsolódó alkalmazásban, és egyre inkább máshol is, bár ritkán használják a lemez típusú információkat. Ez tartalmaz egy egységes rendszer azonosítók (által irányított IANA ) álló típus és altípusát , elválasztva egy perjel -A például text / html vagy image / gif . Eredetileg a forrástól és a cél operációs rendszertől függetlenül azonosítani kívánták, hogy milyen típusú fájlt csatoltak egy e-mailhez . A MIME típusok azonosítják a BeOS , AmigaOS 4.0 és MorphOS fájlokat , valamint egyedi alkalmazás -aláírásokat tárolnak az alkalmazások indításához. AmigaOS és MorphOS rendszerekben a Mime típusú rendszer párhuzamosan működik az Amiga specifikus adattípus rendszerrel.

A MIME típusokkal azonban vannak problémák; több szervezet és személy saját MIME -típusokat hozott létre anélkül, hogy megfelelően regisztrálta volna őket az IANA -nál, ami bizonyos esetekben kényelmetlenné teszi ennek a szabványnak a használatát.

Fájlformátum -azonosítók (FFID -k)

A fájlformátum -azonosítók egy másik, nem széles körben használt módszer a fájlformátumok eredetük és fájlkategóriájuk szerinti azonosítására. A Description Explorer szoftvercsomaghoz készült. Az űrlap több számjegyéből áll NNNNNNNNN-XX-YYYYYYY. Az első rész a szervezet eredetét/karbantartóját jelzi (ez a szám a vállalati/szabványügyi szervezet adatbázisában szereplő értéket jelöli), a következő 2 számjegy a fájl típusát hexadecimális kategóriába sorolja . Az utolsó rész a fájl szokásos fájlnévkiterjesztéséből vagy a fájl nemzetközi szabványszámából áll, balra nullákkal párnázva. Például a PNG fájl specifikáció a FFID a 000000001-31-0015948hol 31jelzi egy képfájlt, 0015948a szabvány számát, és 000000001jelzi, hogy a Nemzetközi Szabványügyi Szervezet (ISO).

Fájltartalom -alapú formátum -azonosítás

Egy másik, de kevésbé népszerű módszer a fájlformátum azonosítására, ha megvizsgálja a fájlok tartalmát a megkülönböztethető minták között a fájltípusok között. A fájl tartalma bájtsorozat, és egy bájt 256 egyedi permutációval rendelkezik (0–255). Így a bájtminták előfordulásának számlálása, amelyet gyakran bájtfrekvencia -eloszlásnak neveznek, megkülönböztethető mintákat ad a fájltípusok azonosításához. Sok tartalom-alapú fájltípus-azonosító séma létezik, amelyek bájtfrekvencia-elosztást használnak a fájltípus reprezentatív modelljeinek felépítéséhez, és bármilyen statisztikai és adatbányászati ​​technikát alkalmaznak a fájltípusok azonosítására

A fájl szerkezete

A fájlok adatszerkesztésének többféle módja van. A leggyakoribbakat az alábbiakban ismertetjük.

Strukturálatlan formátumok (nyers memórialerakók)

A korábbi fájlformátumok nyers adatformátumokat használtak, amelyek abból álltak, hogy egy vagy több struktúra memóriaképét közvetlenül a fájlba dobták.

Ennek számos hátránya van. Kivéve, ha a memóriaképek a jövőbeli bővítmények számára is fenntartottak helyet, az ilyen típusú strukturált fájlok kiterjesztése és javítása nagyon nehéz. Ezenkívül fájlokat hoz létre, amelyek specifikusak lehetnek egy platformra vagy programozási nyelvre (például a Pascal karakterláncot tartalmazó szerkezetet nem ismerik fel ilyenként a C -ben ). Másrészt az ilyen típusú fájlok olvasására és írására szolgáló eszközök kifejlesztése nagyon egyszerű.

A strukturálatlan formátumok korlátai más típusú fájlformátumok kifejlesztéséhez vezettek, amelyek könnyen kiterjeszthetők és ugyanakkor visszafelé kompatibilisek lehetnek.

Darab alapú formátumok

Ebben a fajta fájlstruktúrában minden adat be van ágyazva egy olyan tárolóba, amely valamilyen módon azonosítja az adatokat. A tároló hatóköre azonosítható valamilyen kezdő- és végjelzővel, valahol kifejezett hosszmezővel, vagy a fájlformátum definíciójának rögzített követelményeivel.

Az 1970 -es években sok program használt ilyen általános formátumokat. Például az olyan szövegszerkesztők, mint a troff , a Script és a Scribe , valamint az adatbázis-exportáló fájlok, például a CSV . Electronic Arts és Commodore - Az Amiga 1985 -ben is használt ilyen típusú fájlformátumot, az IFF (Interchange File Format) fájlformátummal együtt.

A tartályt néha " darabnak " nevezik , bár a "darab" azt is jelentheti, hogy minden darab kicsi, és/vagy a darabok nem tartalmaznak más darabokat; sok formátum nem írja elő ezeket a követelményeket.

Az adott "csomagot" azonosító információkat sokféleképpen lehet nevezni, gyakran olyan kifejezésekkel, mint a "mező neve", "azonosító", "címke" vagy "címke". Az azonosítók gyakran ember által olvashatóak, és osztályozzák az adatok egyes részeit: például "vezetéknév", "cím", "téglalap", "betűnév" stb. Ezek nem azonosak az azonosítókkal adatbáziskulcs vagy sorozatszám (bár egy azonosító jól azonosíthatja a hozzá tartozó adatokat ilyen kulcsként).

Az ilyen típusú fájlstruktúrával az olyan eszközök, amelyek nem ismernek bizonyos darab azonosítókat, egyszerűen kihagyják azokat, amelyeket nem értenek. A kihagyott adatok tényleges jelentésétől függően ez hasznos lehet, vagy nem (a CSS kifejezetten meghatározza az ilyen viselkedést).

Ezt a koncepciót újra és újra használta a RIFF (a Microsoft-IBM megfelelője az IFF-nek), a PNG, a JPEG-tároló, a DER ( Distinguished Encoding Rules ) kódolt folyamok és fájlok (amelyeket eredetileg a CCITT X.409: 1984-ben írtak le, és ezért az IFF-nél korábbiak) ) és a strukturált adatcsere formátum (SDXF) .

Valójában minden adatformátumnak valahogyan azonosítania kell alkotóelemeinek jelentőségét, és a beágyazott határjelzők ennek nyilvánvaló módja:

  • A MIME fejlécek ezt minden logikai sor elején kettősponttal elválasztott címkével teszik. A MIME fejlécek nem tartalmazhatnak más MIME fejléceket, bár egyes fejlécek adattartalma alrészeket tartalmaz, amelyek más konvenciókkal kinyerhetők.
  • A CSV és hasonló fájlok ezt gyakran fejlécrekordok segítségével teszik mezők neveivel, és vesszőkkel a mező határainak megjelölésére. A MIME -hez hasonlóan a CSV nem rendelkezik több szinttel rendelkező struktúrákkal.
  • Az XML-t és hozzátartozóit lazán egyfajta darab-alapú formátumnak tekinthetjük, mivel az adatelemeket a darabjel-azonosítókkal rokon jelöléssel azonosítják. Ennek azonban formai előnyei vannak, mint például a sémák és az érvényesítés , valamint az, hogy képes összetettebb struktúrákat, például fákat , DAG -kat és diagramokat ábrázolni . Ha az XML -t "darabos" formátumnak tekintik, akkor az SGML és elődje, az IBM GML az ilyen formátumok legkorábbi példái közé tartoznak.
  • A JSON hasonlít az XML-hez sémák, kereszthivatkozások vagy az ismétlődő mezőnevek jelentésének meghatározása nélkül, és gyakran kényelmes a programozók számára.
  • A YAML hasonló a JSON-hoz, de a behúzást használva szétválasztja az adatdarabokat, és célja, hogy jobban olvasható legyen, mint a JSON vagy az XML.
  • A protokollpufferek viszont hasonlóak a JSON-hoz, nevezetesen az adatok határjelzőit mezőszámokkal helyettesítve, amelyeket valamilyen külső mechanizmus leképez a nevekre.

Címtár-alapú formátumok

Ez egy másik kiterjeszthető formátum, amely nagyon hasonlít egy fájlrendszerre (az OLE dokumentumok tényleges fájlrendszerek), ahol a fájl „könyvtárbejegyzésekből” áll, amelyek tartalmazzák az adatok helyét a fájlban, valamint az aláírásokat (és bizonyos esetek típusa). Az ilyen típusú fájlstruktúrákra jó példák a lemezképek , az OLE dokumentumok TIFF , a könyvtárak . Az ODT és a DOCX, mivel PKZIP -alapúak, darabolva vannak, és könyvtárat is tartalmaznak.

Lásd még

Hivatkozások

Külső linkek