Formát souboru - File format

soubor wav: 2,1 megabajtů.
ogg soubor: 154 kilobajtů.

Formát souboru je standardní způsob, jak tyto informace je kódována pro uskladnění v počítačovém souboru . Určuje, jak se bity používají ke kódování informací na digitálním paměťovém médiu. Formáty souborů mohou být buď proprietární, nebo bezplatné a mohou být buď nepublikované, nebo otevřené.

Některé formáty souborů jsou navrženy pro velmi konkrétní typy dat: Soubory PNG například ukládají bitmapové obrázky pomocí bezeztrátové komprese dat . Jiné formáty souborů jsou však určeny pro ukládání několika různých typů dat: formát Ogg může fungovat jako kontejner pro různé typy multimédií, včetně jakékoli kombinace zvuku a videa , s textem nebo bez textu (například titulky ) a metadat . Textový soubor může obsahovat libovolný proud postav, včetně možných postav kontroly , a je zakódováno v jednom z různých schémat kódování znaků . Některé formáty souborů, jako jsou HTML , Scalable Vector Graphics , a zdrojový kód z počítačového softwaru jsou textové soubory s definovanými syntaxí , které jim umožní využít pro specifické účely.

Specifikace

Formáty souborů mají často publikovanou specifikaci popisující metodu kódování a umožňující testování funkcí zamýšlených programem. Ne všechny formáty mají volně dostupné dokumenty specifikací, částečně proto, že někteří vývojáři považují své dokumenty specifikací za obchodní tajemství , a částečně proto, že jiní vývojáři nikdy nevytvářejí formální dokument specifikací, takže precedens nastavený jinými již existujícími programy, které formát používají, definuje formát pomocí tyto stávající programy to používají.

Pokud vývojář formátu nezveřejní bezplatné specifikace, jiný vývojář, který chce tento typ souboru využít, musí soubor buď zpětně analyzovat, aby zjistil, jak jej přečíst, nebo za poplatek a podpisem získat dokumentaci od vývojářů formátu. dohoda nezveřejnění . Druhý přístup je možný pouze tehdy, když existuje formální dokument specifikace. Obě strategie vyžadují značný čas, peníze nebo obojí; formáty souborů s veřejně dostupnými specifikacemi proto bývají podporovány více programy.

Patenty

K ochraně formátu souboru se častěji používá patentové právo než autorské právo . Ačkoli patenty na formáty souborů nejsou podle zákonů USA přímo povoleny, některé formáty kódují data pomocí patentovaných algoritmů . Například použití komprese ve formátu souboru GIF vyžaduje použití patentovaného algoritmu, a přestože majitel patentu svůj patent zpočátku nevymáhal, později začali vybírat honoráře . To vedlo k významnému snížení používání GIF a je částečně zodpovědné za vývoj alternativního formátu PNG . Patent GIF však v USA vypršel v polovině roku 2003 a celosvětově v polovině roku 2004.

Identifikace typu souboru

Různé operační systémy tradičně zvolily různé přístupy k určování formátu konkrétního souboru, přičemž každý přístup má své vlastní výhody a nevýhody. Většina moderních operačních systémů a jednotlivých aplikací potřebuje ke čtení „cizích“ formátů souborů použít všechny následující přístupy, pokud s nimi nepracuje úplně.

Přípona názvu souboru

Jednou z populárních metod používaných mnoha operačními systémy, včetně Windows , macOS , CP/M , DOS , VMS a VM/CMS, je určit formát souboru na základě konce jeho názvu, konkrétněji písmen následujících po posledním období. Tato část názvu souboru je známá jako přípona názvu souboru . Například, HTML dokumenty jsou poznány jmény, která koncem s html (nebo HTM ), a GIF obrazy od GIF . V původním systému souborů FAT byly názvy souborů omezeny na osmiznakový identifikátor a tříznakovou příponu, známou jako 8.3 název souboru . Existuje pouze tolik třípísmenných přípon, takže často může být jakékoli dané rozšíření spojeno s více než jedním programem. Mnoho formátů stále používá tříznaková rozšíření, přestože moderní operační systémy a aplikační programy již toto omezení nemají. Protože neexistuje žádný standardní seznam přípon, více než jeden formát může používat stejné rozšíření, což může zmást operační systém i uživatele.

Jedním z artefaktů tohoto přístupu je, že systém lze snadno přimět, aby soubor považoval za jiný formát pouhým přejmenováním - soubor HTML lze například snadno považovat za prostý text přejmenováním z filename.html na název souboru. txt . Přestože byla tato strategie užitečná pro zkušené uživatele, kteří snadno porozuměli těmto informacím a manipulovali s nimi, byla často matoucí pro méně technické uživatele, kteří mohli omylem znehodnocovat soubor (nebo jej „ztratit“) nesprávným přejmenováním.

To vedlo většinu verzí Windows a Mac OS k skrytí rozšíření při uvádění souborů. Tím se zabrání tomu, aby uživatel omylem změnil typ souboru, a umožňuje zkušeným uživatelům tuto funkci vypnout a zobrazit přípony.

Skrytí přípony však může vytvořit vzhled dvou nebo více stejných názvů souborů ve stejné složce. Například může být potřeba logo společnosti ve formátu .eps (pro publikování) i .png (pro webové stránky). S viditelnými příponami by se tyto zobrazovaly jako jedinečné názvy souborů: „ CompanyLogo.eps “ a „ CompanyLogo.png “. Na druhou stranu, skrývání rozšíření by způsobilo, že se oba budou zobrazovat jako „ CompanyLogo “, což může vést ke zmatku.

Skrytí rozšíření může také představovat bezpečnostní riziko. Zlovolný uživatel by například mohl vytvořit spustitelný program s nevinným názvem, například „ Holiday photo.jpg.exe “. Soubor „ .exe “ by byl skryt a nic netušícímu uživateli by se zobrazilo „ Prázdninové foto.jpg “, což by vypadalo jako obrázek ve formátu JPEG , který obvykle nemůže poškodit počítač. Operační systém by však stále viděl příponu „ .exe “ a spustil program, který by pak mohl způsobit poškození počítače. Totéž platí pro soubory s pouze jednou příponou: jelikož se uživateli nezobrazuje, nelze bez výslovného prozkoumání souboru odvodit žádné informace o souboru. Abychom uživatele dále oklamali, je možné do programu uložit ikonu. V takovém případě by přiřazení ikon některých operačních systémů spustitelnému souboru ( .exe ) bylo přepsáno ikonou běžně používanou k reprezentaci obrázků JPEG, čímž by program vypadal jako obrázek. Rozšíření lze také podvrhnout: některé viry maker aplikace Microsoft Word vytvoří soubor Word ve formátu šablony a uloží jej s příponou .doc . Protože aplikace Word obecně ignoruje rozšíření a hledá formát souboru, otevřely by se jako šablony, spustily a šířily virus. To představuje praktický problém pro systémy Windows, kde je ve výchozím nastavení zapnuto skrývání rozšíření.

Interní metadata

Druhým způsobem, jak identifikovat formát souboru, je použít informace týkající se formátu uloženého uvnitř samotného souboru, buď informace určené k tomuto účelu, nebo binární řetězce, které se shodou okolností vždy nacházejí na konkrétních místech v souborech některých formátů. Jelikož je nejsnadněji najdete, je taková oblast obvykle nazývána záhlavím souboru, pokud je větší než několik bajtů , nebo magickým číslem, pokud je dlouhé jen několik bajtů.

Záhlaví souboru

Metadata obsažená v záhlaví souboru jsou obvykle uložena na začátku souboru, ale mohou být přítomna i v jiných oblastech, často včetně konce, v závislosti na formátu souboru nebo typu obsažených dat. Znakové (textové) soubory mají obvykle záhlaví na základě znaků, zatímco binární formáty obvykle mají binární záhlaví, i když to není pravidlem. Textová záhlaví souborů obvykle zabírají více místa, ale protože jsou čitelná pro lidi, lze je snadno prozkoumat pomocí jednoduchého softwaru, jako je textový editor nebo hexadecimální editor.

Kromě identifikace formátu souboru mohou záhlaví souborů obsahovat metadata o souboru a jeho obsahu. Například většina obrazových souborů ukládá informace o formátu obrázku, velikosti, rozlišení a barevném prostoru a volitelně informace o autorovi , například kdo obrázek vytvořil, kdy a kde byl vytvořen, jaký model fotoaparátu a fotografické nastavení bylo použito ( Exif ) a již brzy. Taková metadata mohou být použita při čtení nebo interpretaci softwaru během procesu načítání a poté.

Záhlaví souborů může operační systém použít k rychlému shromažďování informací o souboru, aniž by byl celý načten do paměti, ale přitom využívá více prostředků počítače než čtení přímo z informací o adresáři . Když například správce grafických souborů musí zobrazit obsah složky, musí před zobrazením příslušných ikon přečíst záhlaví mnoha souborů, ale tyto budou umístěny na různých místech paměťového média, takže přístup bude trvat déle . Složka obsahující mnoho souborů se složitými metadaty, jako jsou informace o miniaturách, může před zobrazením trvat hodně času.

Pokud je záhlaví binárně napevno zakódováno , takže záhlaví samo o sobě potřebuje komplexní interpretaci, aby bylo možné jej rozpoznat, zejména kvůli ochraně obsahu metadat, existuje riziko, že formát souboru může být nesprávně interpretován. Možná to bylo dokonce špatně napsáno u zdroje. To může mít za následek poškození metadat, která v extrémně špatných případech mohou dokonce způsobit nečitelnost souboru.

Složitějšími příklady hlaviček souborů jsou ty, které se používají pro formáty souborů wrapperů (nebo kontejnerů).

Kouzelné číslo

Jedním ze způsobů, jak začlenit metadata typu souboru, často spojená s Unixem a jeho deriváty, je jednoduše uložit „magické číslo“ do samotného souboru. Původně byl tento termín použit pro specifickou sadu dvoubajtových identifikátorů na počátcích souborů, ale protože jakoukoli binární sekvenci lze považovat za číslo, lze pro identifikaci použít jakoukoli vlastnost formátu souboru, která jej jednoznačně odlišuje. Obrázky GIF například vždy začínají reprezentací ASCII buď GIF87a nebo GIF89a , v závislosti na standardu, ke kterému se hlásí. Mnoho typů souborů, zejména soubory prostého textu, je touto metodou hůře rozpoznatelné. HTML soubory, například, by mohl začínat řetězcem <html> (což není malá a velká písmena), nebo vhodná definice typu dokumentu , který začíná <! DOCTYPE HTML> , nebo pro XHTML , na XML identifikátor, který začne s < ? xml . Soubory mohou také začínat komentáři HTML, náhodným textem nebo několika prázdnými řádky, ale stále mohou být použitelné HTML.

Přístup magického čísla nabízí lepší záruky, že formát bude správně identifikován a často může určit přesnější informace o souboru. Protože přiměřeně spolehlivé testy „magického čísla“ mohou být poměrně složité a každý soubor musí být efektivně testován proti všem možnostem v magické databázi, je tento přístup relativně neefektivní, zejména pro zobrazování velkých seznamů souborů (naopak název souboru a metadata- založené metody musí kontrolovat pouze jeden kus dat a porovnat je s tříděným indexem). Data je také nutné číst ze samotného souboru, což zvyšuje latenci oproti metadatům uloženým v adresáři. Tam, kde se typy souborů nehodí k uznání tímto způsobem, musí systém přejít zpět k metadatům. Je to však nejlepší způsob, jak program může zkontrolovat, zda soubor, o kterém bylo řečeno, že jej zpracovává, má správný formát: zatímco název souboru nebo metadata mohou být změněny nezávisle na jeho obsahu, pokud selže dobře navržený test magického čísla je zcela jistým znakem toho, že soubor je poškozený nebo je nesprávného typu. Na druhou stranu platné magické číslo nezaručuje, že soubor není poškozen nebo je správného typu.

Takzvané řádky shebangu v souborech skriptů jsou zvláštním případem magických čísel. Zde je magické číslo textem čitelným pro člověka, který identifikuje konkrétní interpret příkazů a možnosti, které mají být předány interpretovi příkazů.

Dalším operačním systémem využívajícím magická čísla je AmigaOS , kde se magická čísla nazývala „Magic Cookies“ a byla přijata jako standardní systém pro rozpoznávání spustitelných souborů ve formátu spustitelných souborů Hunk a také k tomu, aby jednotlivé programy, nástroje a nástroje mohly automaticky zpracovávat uložené datové soubory. , nebo jakýkoli jiný druh typů souborů při ukládání a načítání dat. Tento systém byl poté rozšířen o standardní systém rozpoznávání datových typů Amiga . Další metodou byla metoda FourCC , pocházející z OSType na Macintoshi, později upravená formátem Interchange File Format (IFF) a deriváty.

Externí metadata

Konečným způsobem uložení formátu souboru je explicitní ukládání informací o formátu do systému souborů, nikoli do samotného souboru.

Tento přístup udržuje metadata oddělená jak od hlavních dat, tak od názvu, ale je také méně přenosný než rozšíření souborů nebo „magická čísla“, protože formát musí být převeden ze souborového systému na souborový systém. I když to do určité míry platí i pro přípony souborů-například kvůli kompatibilitě s limitem tří znaků v systému MS-DOS -většina forem úložiště má zhruba ekvivalentní definici dat a názvu souboru, ale může mít různé nebo žádné zastoupení dalších metadat.

Soubory zip nebo archivní soubory řeší problém se zpracováním metadat. Obslužný program shromažďuje více souborů společně s metadaty o každém souboru a složkách/adresářích, ze kterých pochází, v rámci jednoho nového souboru (např. Soubor zip s příponou .zip ). Nový soubor je také komprimovaný a případně šifrovaný, ale nyní je přenosný jako jeden soubor mezi operačními systémy systémy FTP nebo připojený k e -mailu. Aby byl v cíli užitečný, musí být rozbalen kompatibilním nástrojem, ale problémy s přenosem jsou vyřešeny tímto způsobem.

Typové kódy Mac OS

V Mac OS " Hierarchical File System ukládá kódy pro tvůrce a typ jako součást položky adresáře pro každý soubor. Tyto kódy se označují jako OSTypes. Tyto kódy mohou být libovolné 4bajtové sekvence, ale často byly vybrány tak, aby reprezentace ASCII tvořila posloupnost smysluplných znaků, jako je například zkratka názvu aplikace nebo iniciály vývojáře. Pro instanci HyperCard soubor „stack“ má tvůrce z WILD (od Hypercard v předchozím názvem „divoká karta“) a typ z STAK . BBEdit textový editor má tvůrce kód R*chs odkazem na své původní programátor, Rich Siegel . Typový kód určuje formát souboru, zatímco kód tvůrce určuje výchozí program, pomocí kterého jej otevřete, když na něj dvakrát klikne uživatel. Například uživatel může mít několik textových souborů, všechny s typovým kódem TEXT , ale každý z nich se otevře v jiném programu, protože má odlišné kódy tvůrců. Tato funkce byla zamýšlena tak, aby například soubory čitelného textu čitelné lidmi mohly být otevřeny v textovém editoru pro obecné účely, zatímco soubory programování nebo HTML kódu by se otevíraly ve specializovaném editoru nebo IDE . Tato funkce však byla často zdrojem zmatku uživatelů, protože jaký program se spustí, když na soubory dvakrát kliknete, bylo často nepředvídatelné. RISC OS používá podobný systém, skládající se z 12bitového čísla, které lze vyhledat v tabulce popisů-např. Hexadecimální číslo FF5je „ aliasováno “ pro PoScript , což představuje soubor PostScriptu .

Jednotné identifikátory typu Mac OS X (UTI)

Uniform Type Identifier (UTI) je metoda používaná v systému macOS k jedinečné identifikaci „zadaných“ tříd entit, například formátů souborů. Byl vyvinut společností Apple jako náhrada za OSType (kódy typu a tvůrce).

UTI je řetězec Core Foundation , který používá řetězec reverzního DNS . Některé běžné a standardní typy používají doménu zvanou public (např. Public.png pro obrázek Portable Network Graphics ), zatímco jiné domény lze použít pro typy třetích stran (např. Com.adobe.pdf pro Portable Document Format ). UTI lze definovat v hierarchické struktuře, známé jako hierarchie shody. Tak, public.png je shodné s supertypu z public.image , které samo o sobě je shodné s supertypu z public.data . UTI může existovat ve více hierarchiích, což poskytuje velkou flexibilitu.

Kromě formátů souborů lze UTI použít také pro jiné entity, které mohou existovat v systému macOS, včetně:

  • Vložit data
  • Složky (adresáře)
  • Translatable types (as handled by the Translation Manager)
  • Svazky
  • Rámce
  • Streamování dat
  • Aliasy a symbolické odkazy

Rozšířené atributy OS/2

HPFS , FAT12 a FAT16 (ale ne FAT32) filesystems umožňují ukládání „rozšířených atributů“ se soubory. Patří mezi ně libovolná sada trojic s názvem, kódovaným typem hodnoty a hodnotou, kde jsou názvy jedinečné a hodnoty mohou mít délku až 64 kB. Pro určité typy a názvy existují standardizované významy (pod OS/2 ). Jedním z nich je, že k určení typu souboru se používá rozšířený atribut „.TYPE“. Jeho hodnota obsahuje seznam jednoho nebo více typů souborů spojených se souborem, z nichž každý je řetězec, například „prostý text“ nebo „dokument HTML“. Soubor tedy může mít několik typů.

Systém souborů NTFS také umožňuje ukládání rozšířených atributů OS/2 jako jedné z vidliček souborů , ale tato funkce je k dispozici pouze pro podporu subsystému OS/2 (není k dispozici v XP), takže subsystém Win32 považuje tyto informace za neprůhledné datový blok a nevyužívá je. Místo toho spoléhá na jiné vidlice souborů k ukládání metainformací ve formátech specifických pro Win32. Rozšířené atributy OS/2 lze stále číst a zapisovat programy Win32, ale data musí být zcela analyzována aplikacemi.

Rozšířené atributy POSIX

V systémech Unix a Unix podobné systémy ext2 , ext3 , ReiserFS verze 3, XFS , JFS , FFS a HFS+ umožňují ukládání rozšířených atributů se soubory. Mezi ně patří libovolný seznam řetězců „name = value“, kde jsou názvy jedinečné a k hodnotě lze přistupovat prostřednictvím jejího souvisejícího názvu.

Unikátní identifikátory PRONOM (PUID)

PRONOM Trvalé jedinečný identifikátor (PUID) je rozšiřitelný systém persistentních, jedinečných a jednoznačných identifikátorů pro formáty souborů, které byly vyvinuty Národním archivu ve Spojeném království v rámci svého PRONOM technické registru služby. PUID lze vyjádřit jako jednotné identifikátory prostředků pomocí informací: pronom/ namespace. Přestože schéma PUID dosud není široce používáno mimo britskou vládu a některé programy digitálního uchovávání , poskytuje větší granularitu než většina alternativních schémat.

MIME typy

Typy MIME jsou široce používány v mnoha aplikacích souvisejících s internetem a stále více i jinde, i když jejich použití pro informace o typu na disku je vzácné. Ty se skládají ze standardizovaného systému identifikátorů (spravovaných IANA ) skládající se z typu a podtypu , oddělených lomítkem- například text/html nebo image/gif . Ty byly původně určeny jako způsob identifikace toho, jaký typ souboru byl připojen k e-mailu , nezávisle na zdrojovém a cílovém operačním systému. Typy MIME identifikují soubory v systémech BeOS , AmigaOS 4.0 a MorphOS a také ukládají jedinečné podpisy aplikací pro spouštění aplikací. V AmigaOS a MorphOS pracuje systém typu Mime souběžně se specifickým systémem Amiga Datatype.

Existují však problémy s typy MIME; několik organizací a lidí si vytvořilo vlastní typy MIME, aniž by je řádně zaregistrovali v IANA, což v některých případech činí použití tohoto standardu nepříjemným.

Identifikátory formátu souboru (FFID)

Identifikátory formátu souboru jsou dalším, ne příliš používaným způsobem identifikace formátů souborů podle jejich původu a kategorie souborů. Byl vytvořen pro software Description Explorer. Skládá se z několika číslic formuláře NNNNNNNNN-XX-YYYYYYY. První část označuje původ/správce organizace (toto číslo představuje hodnotu v databázi organizace společnosti/standardů), následující 2 číslice kategorizují typ souboru v hexadecimálním formátu . Poslední část je tvořena obvyklou příponou názvu souboru nebo mezinárodním standardním číslem souboru, které je vlevo vyplněno nulami. Specifikace souboru PNG má například FFID 000000001-31-0015948kde 31označuje soubor obrázku, 0015948je standardní číslo a 000000001označuje Mezinárodní organizaci pro normalizaci (ISO).

Identifikace formátu podle obsahu souboru

Dalším, ale méně populárním způsobem, jak identifikovat formát souboru, je prozkoumat v obsahu souboru rozlišitelné vzory mezi typy souborů. Obsah souboru je posloupnost bajtů a bajt má 256 jedinečných permutací (0–255). Počítání výskytu bajtových vzorů, které jsou často označovány jako distribuce frekvencí bajtů, poskytuje rozlišitelné vzory pro identifikaci typů souborů. Existuje mnoho schémat identifikace typů souborů založených na obsahu, které používají distribuci frekvencí bajtů k vytváření reprezentativních modelů pro typ souboru a k identifikaci typů souborů používají jakékoli statistické a metody dolování dat

Struktura souboru

Existuje několik typů způsobů, jak strukturovat data v souboru. Nejběžnější jsou popsány níže.

Nestrukturované formáty (výpisy surové paměti)

Dřívější formáty souborů používaly formáty nezpracovaných dat, které spočívaly v přímém ukládání obrazů paměti jedné nebo více struktur do souboru.

To má několik nevýhod. Pokud obrázky paměti také nemají vyhrazená místa pro budoucí rozšíření, je rozšíření a vylepšení tohoto typu strukturovaného souboru velmi obtížné. Vytváří také soubory, které mohou být specifické pro jednu platformu nebo programovací jazyk (například struktura obsahující řetězec Pascal není v C jako taková rozpoznána ). Na druhou stranu je vývoj nástrojů pro čtení a zápis těchto typů souborů velmi jednoduchý.

Omezení nestrukturovaných formátů vedla k vývoji dalších typů formátů souborů, které lze snadno rozšířit a být zpětně kompatibilní současně.

Formáty založené na kusu

V tomto druhu struktury souborů je každý kus dat vložen do kontejneru, který data nějak identifikuje. Rozsah kontejneru může být identifikován nějakými počátečními a koncovými značkami, někde s explicitním délkovým polem nebo pevnými požadavky na definici formátu souboru.

V průběhu sedmdesátých let používalo mnoho programů formáty tohoto obecného druhu. Například textové procesory, jako jsou troff , Script a Scribe , a soubory pro export databáze, jako je CSV . Electronic Arts a Commodore - Amiga také používala tento typ formátu souboru v roce 1985 s formátem souborů IFF (Interchange File Format).

Kontejner se někdy nazývá „kus“ , ačkoli „kus“ může také znamenat, že každý kus je malý a/nebo že kusy neobsahují jiné kusy; mnoho formátů tyto požadavky neukládá.

Informacím, které identifikují konkrétní „kus“, lze říkat mnoho různých věcí, často výrazy včetně „názvu pole“, „identifikátoru“, „štítku“ nebo „štítku“. Identifikátory jsou často čitelné pro člověka a klasifikují části údajů: například jako „příjmení“, „adresa“, „obdélník“, „název písma“ atd. Nejedná se o totéž jako identifikátory ve smyslu databázového klíče nebo sériového čísla (ačkoli identifikátor může dobře identifikovat jeho přidružená data jako takový klíč).

U tohoto typu struktury souborů nástroje, které neznají určité identifikátory bloků, jednoduše přeskočí ty, kterým nerozumí. V závislosti na skutečném významu přeskočených dat to může, ale nemusí být užitečné ( CSS takové chování výslovně definuje).

Tento koncept byl znovu a znovu používán RIFF (Microsoft-IBM ekvivalent IFF), PNG, úložiště JPEG, DER ( Distinguished Encoding Rules ) kódované streamy a soubory (které byly původně popsány v CCITT X.409: 1984, a proto před IFF ) a formát strukturované výměny dat (SDXF) .

Ve skutečnosti jakýkoliv formát dat je třeba nějakým způsobem identifikovat význam jeho jednotlivých částí, a vestavěné okrajové markery jsou zřejmý způsob, jak tak učinit:

  • Záhlaví MIME to dělají pomocí štítku odděleného dvojtečkou na začátku každého logického řádku. Záhlaví MIME nemohou obsahovat jiná záhlaví MIME, i když datový obsah některých záhlaví má dílčí části, které lze extrahovat jinými konvencemi.
  • CSV a podobné soubory to často dělají pomocí záznamů záhlaví s názvy polí a čárkami k označení hranic polí. Stejně jako MIME nemá CSV žádné ustanovení pro struktury s více než jednou úrovní.
  • XML a jeho příbuznost lze volně považovat za druh formátu založeného na blocích, protože datové prvky jsou identifikovány značením, které je podobné identifikátorům bloků. Má však formální výhody, jako jsou schémata a ověřování , a také schopnost reprezentovat složitější struktury, jako jsou stromy , DAG a grafy . Pokud je XML považován za „kusový“ formát, pak SGML a jeho předchůdce IBM GML patří mezi nejranější příklady takových formátů.
  • JSON je podobný XML bez schémat, křížových odkazů nebo definice významu opakovaných názvů polí a je často vhodný pro programátory.
  • YAML je podobný JSON, ale používá odsazení k oddělení datových bloků a snaží se být čitelnější pro lidi než JSON nebo XML.
  • Protokolové vyrovnávací paměti jsou zase podobné JSON, zejména nahrazují hraniční značky v datech čísly polí, která jsou mapována do/z názvů nějakým externím mechanismem.

Formáty založené na adresáři

Toto je další rozšiřitelný formát, který se velmi podobá souborovému systému ( dokumenty OLE jsou skutečné souborové systémy), kde je soubor složen z „adresářových položek“, které obsahují umístění dat v samotném souboru a také jeho podpisy (a v některých případy jeho typu). Dobrými příklady těchto typů struktur souborů jsou obrazy disků , dokumenty OLE TIFF , knihovny . ODT a DOCX, založené na PKZIP , jsou blokové a také nesou adresář.

Viz také

Reference

externí odkazy