ファイル形式

ファイル形式は、情報をコンピュータ ファイルに保存するためにエンコードする標準的な方法です。デジタル ストレージメディアで情報をエンコードするためにビットがどのように使用されるかを指定します。ファイル形式は、独自のものでもフリーのものでもかまいません。

一部のファイル形式は、非常に特殊なタイプのデータ用に設計されています。たとえば、PNGファイルは、ロスレス データ圧縮を使用してビットマップ 画像を保存します。ただし、他のファイル形式は、いくつかの異なるタイプのデータの保存用に設計されています。Ogg形式は、オーディオとビデオの任意の組み合わせ、テキストの有無 (字幕など)、およびメタデータを含むさまざまな種類のマルチメディアのコンテナーとして機能します。テキスト ファイルには、制御文字を含む任意の文字ストリームを含めることができ、さまざまな文字エンコード スキームのいずれかでエンコードされます。HTML 、スケーラブル ベクター グラフィックス、コンピューター ソフトウェアのソース コードなどの一部のファイル形式は、特定の目的に使用できるように 定義された構文を持つテキスト ファイルです。

ファイル形式には、エンコード方法を記述し、プログラムが意図する機能をテストできるようにする公開された仕様がしばしばあります。すべての形式に自由に利用できる仕様書があるわけではありません。その理由の 1 つは、一部の開発者が仕様書を企業秘密と見なしていること、もう 1 つの理由は、正式な仕様書を作成しない開発者がいて、その形式を使用する他の既存のプログラムによって設定された前例によって、これらの既存のプログラムが形式をどのように使用するかによって形式が定義されるためです。

ある形式の開発者が無料の仕様を公開していない場合、その種類のファイルを利用しようとする別の開発者は、そのファイルをリバース エンジニアリングしてそのファイルの読み方を調べるか、料金を支払って秘密保持契約に署名し、その形式の開発者から仕様書を入手する必要があります。後者のアプローチは、正式な仕様書が存在する場合にのみ可能です。どちらの戦略も、かなりの時間、費用、またはその両方を必要とするため、公開されている仕様を持つファイル形式は、より多くのプログラムでサポートされる傾向があります。

ファイル形式の保護には、著作権よりも特許法が使われることが多い。ファイル形式の特許は米国法では直接認められていないが、一部の形式では特許取得済みのアルゴリズムを使用してデータをエンコードしている。たとえば、2004年以前は、GIFファイル形式で圧縮を行うには特許取得済みのアルゴリズムを使用する必要があり、特許所有者は当初特許を執行しなかったものの、後に特許使用料を徴収し始めた。これによりGIFの使用が大幅に減少し、代替のPNG形式が開発された一因にもなっている。しかし、GIFの特許は米国では2003年半ばに、全世界では2004年半ばに失効した。

従来、オペレーティング システムごとに特定のファイルの形式を決定する方法が異なり、それぞれの方法には長所と短所があります。最新のオペレーティング システムと個々のアプリケーションのほとんどは、完全に機能しないとしても、「外部」のファイル形式を読み取るために、次のすべての方法を使用する必要があります。

Windows、macOS、CP/M、DOS、VMS、VM/CMSなど、多くのオペレーティング システムで使用されている一般的な方法の 1 つは、ファイル名の末尾、より具体的には最後のピリオドの後の文字に基づいてファイルの形式を決定することです。ファイル名のこの部分は、ファイル名拡張子と呼ばれます。たとえば、HTMLドキュメントは.html (または.htm )で終わる名前で識別され、GIF画像は.gifで識別されます。元のFATファイル システムでは、ファイル名は 8 文字の識別子と 3 文字の拡張子に制限されており、8.3 ファイル名と呼ばれていました。3文字の拡張子の数には限りがあり、特定の拡張子が複数のプログラムで使用される可能性があります。最新のオペレーティング システムやアプリケーション プログラムではこの制限がなくなりましたが、多くの形式ではまだ 3 文字の拡張子が使用されています。拡張子の標準リストがないため、複数の形式で同じ拡張子が使用されることがあり、オペレーティング システムとユーザーの両方を混乱させる可能性があります。

このアプローチの欠点の 1 つは、ファイル名を変更するだけで、システムがファイルを別の形式として扱うように簡単に騙されてしまうことです。たとえば、HTMLファイルは、ファイル名をfilename.htmlからfilename.txtに変更するだけで、簡単にプレーン テキストとして扱うことができます。この戦略は、この情報を簡単に理解して操作できる熟練したユーザーには便利ですが、技術に詳しくないユーザーにとっては混乱を招くことが多く、ファイル名を誤って変更することで、誤ってファイルを使用不可にしてしまう (または「失う」) 可能性があります。

このため、Windows と Mac OS のほとんどのバージョンでは、ファイルを一覧表示するときに拡張子が非表示になります。これにより、ユーザーが誤ってファイルの種類を変更することを防ぎ、熟練したユーザーはこの機能をオフにして拡張子を表示できます。

ただし、拡張子を非表示にすると、同じフォルダー内に 2 つ以上の同じファイル名が存在する可能性があります。たとえば、会社のロゴが.eps形式 (公開用) と.png形式 (Web サイト用) の両方で必要になる場合があります。拡張子を表示すると、これらは「 CompanyLogo.eps」と「CompanyLogo.png 」という固有のファイル名として表示されます。一方、拡張子を非表示にすると、両方とも「CompanyLogo」と表示され、混乱を招く可能性があります。

拡張子を隠すことは、セキュリティ上のリスクをもたらすこともあります。^[1]たとえば、悪意のあるユーザーが「 Holiday photo.jpg.exe 」などの無害な名前の実行可能プログラムを作成する可能性があります。「.exe」は隠されているため、何も知らないユーザーは「Holiday photo.jpg」を見ることになりますが、これはJPEG画像のように見え、通常はマシンに害を及ぼすことはありません。ただし、オペレーティングシステムは「.exe」拡張子を認識してプログラムを実行し、コンピューターに害を及ぼす可能性があります。拡張子が 1 つだけのファイルでも同じことが言えます。拡張子はユーザーに表示されないため、ファイルを明示的に調査しない限り、ファイルに関する情報を推測することはできません。ユーザーをさらに騙すために、プログラム内にアイコンを格納することもできます。その場合、一部のオペレーティングシステムによる実行可能ファイル ( .exe ) のアイコン割り当ては、JPEG 画像を表すために一般的に使用されるアイコンで上書きされ、プログラムが画像のように見えます。拡張子も偽装される可能性があります。Microsoft Wordマクロ ウイルスの中には、Word ファイルをテンプレート形式で作成し、.doc拡張子で保存するものがあります。Word は一般に拡張子を無視してファイルの形式を確認するため、これらのファイルはテンプレートとして開かれ、実行され、ウイルスが拡散します。^{[引用が必要]}これは、拡張子の非表示がデフォルトでオンになっている Windows システムでは実際的な問題となります。

ファイル形式を識別する 2 つ目の方法は、ファイル自体に格納されている形式に関する情報を使用することです。この情報は、この目的のために用意されたものか、一部の形式のファイルでは必ず特定の場所にあるバイナリ文字列です。最も簡単に見つけられる場所はファイルの先頭であるため、このような領域は、数バイトを超える場合はファイル ヘッダー、数バイトしかない場合は マジック ナンバーと呼ばれます。

ファイル ヘッダーに含まれるメタデータは、通常はファイルの先頭に保存されますが、ファイル形式や含まれるデータの種類によっては、他の領域 (多くの場合、末尾を含む) にも存在する場合があります。文字ベース (テキスト) ファイルは通常、文字ベースのヘッダーを持ちますが、バイナリ形式は通常、バイナリ ヘッダーを持ちますが、これは規則ではありません。テキスト ベースのファイル ヘッダーは通常、より多くのスペースを占有しますが、人間が読めるため、テキスト エディターや 16 進エディターなどの簡単なソフトウェアを使用して簡単に調べることができます。

ファイル ヘッダーには、ファイル形式を識別するだけでなく、ファイルとその内容に関するメタデータも含まれる場合があります。たとえば、ほとんどの画像ファイルには、画像形式、サイズ、解像度、色空間に関する情報が保存され、オプションで、画像の作成者、作成日時、場所、使用されたカメラ モデルと写真設定 ( Exif ) などのオーサリング情報も保存されます。このようなメタデータは、読み込みプロセス中やその後に、ファイルを読み取ったり解釈したりするソフトウェアによって使用される場合があります。

ファイル ヘッダーは、オペレーティング システムによって、ファイルに関する情報をすべてメモリにロードせずにすばやく収集するために使用されることがあります。ただし、これを行うと、ディレクトリ情報から直接読み取るよりも多くのコンピューター リソースが使用されます。たとえば、グラフィック ファイル マネージャーがフォルダーの内容を表示する必要がある場合、適切なアイコンを表示する前に多くのファイルのヘッダーを読み取る必要がありますが、これらのアイコンはストレージ メディア上のさまざまな場所にあるため、アクセスに時間がかかります。サムネイル情報などの複雑なメタデータを持つ多くのファイルを含むフォルダーは、表示までにかなりの時間がかかることがあります。

ヘッダーがバイナリ ハードコードされていて、特にメタデータ コンテンツ保護のためにヘッダー自体が認識されるために複雑な解釈が必要な場合、ファイル形式が誤って解釈されるリスクがあります。ソースで不適切に記述されている可能性もあります。その結果、メタデータが破損し、最悪の場合、ファイルが読み取り不能になることもあります。^{[説明が必要]}

ファイル ヘッダーのより複雑な例としては、ラッパー(またはコンテナー) ファイル形式に使用されるものがあります。

ファイル タイプ メタデータを組み込む方法の 1 つは、ファイル自体の中に「マジック ナンバー」を保存することです。これは、Unixおよびその派生製品によく関連付けられます。元々、この用語は、ファイルの先頭にある特定の 2 バイト識別子のセットに対して使用されていましたが、バイナリ シーケンスはすべて数字と見なすことができるため、ファイル形式を一意に区別する任意の機能を識別に使用できます。たとえば、GIF画像は、準拠する標準に応じて、常にまたは のASCII表現で始まります。多くのファイル タイプ、特にプレーン テキスト ファイルは、この方法では見つけるのが困難です。たとえば、HTML ファイルは、文字列(大文字と小文字は区別されません) または で始まる適切なドキュメント タイプ定義で始まる場合や、XHTMLの場合は で始まるXML識別子で始まる場合があります。ファイルは、 HTML コメント、ランダム テキスト、または複数の空行で始まる場合もありますが、それでも HTML として使用できます。 GIF87aGIF89a<html><!DOCTYPE html<?xml

マジック ナンバー アプローチでは、形式が正しく識別されることがより確実に保証され、ファイルに関するより正確な情報も判断できます。適度に信頼できる「マジック ナンバー」テストはかなり複雑になる可能性があり、各ファイルはマジック データベースのすべての可能性に対して効果的にテストする必要があるため、このアプローチは、特に大量のファイル リストを表示する場合には比較的非効率的です (対照的に、ファイル名とメタデータ ベースの方法では、1 つのデータのみをチェックし、それをソートされたインデックスと照合する必要があります)。また、データはファイル自体から読み取る必要があるため、ディレクトリに保存されているメタデータとは対照的に、待ち時間が長くなります。ファイルの種類がこのように認識できない場合、システムはメタデータにフォールバックする必要があります。ただし、これは、プログラムが処理するように指示されたファイルの形式が正しいかどうかを確認するための最良の方法です。ファイル名またはメタデータは、その内容とは無関係に変更される可能性がありますが、適切に設計されたマジック ナンバー テストに失敗するということは、ファイルが破損しているか、間違った種類であることを示すかなり確実な兆候です。一方、有効なマジック ナンバーは、ファイルが破損していないことや正しい種類であることを保証するものではありません。

スクリプト ファイル内のいわゆるシバン行は、マジック ナンバーの特殊なケースです。ここで、マジック ナンバーは、特定のコマンド インタープリターと、コマンド インタープリターに渡されるオプションを識別する、人間が判読できるテキストです。

マジックナンバーを使用する別のオペレーティングシステムはAmigaOSです。マジックナンバーは「マジッククッキー」と呼ばれ、Hunk実行可能ファイル形式の実行可能ファイルを認識する標準システムとして採用され、また、単一のプログラム、ツール、ユーティリティが、データの保存および読み込み時に、保存されたデータファイルやその他の種類のファイルタイプを自動的に処理できるようにするために採用されました。このシステムは、その後、Amiga 標準のデータ型認識システムによって拡張されました。別の方法は、Macintosh のOSTypeで始まり、後にInterchange File Format (IFF) および派生製品によって採用されたFourCC方式でした。

ファイルの形式を保存する最後の方法は、ファイル自体ではなく、ファイル システムに形式に関する情報を明示的に保存することです。

このアプローチでは、メタデータはメイン データと名前の両方から分離されますが、フォーマットをファイル システム間で変換する必要があるため、ファイル名拡張子や「マジック ナンバー」よりも移植性が低くなります。これは、ファイル名拡張子についてもある程度当てはまりますが (たとえば、 MS-DOSの 3 文字制限との互換性のため)、ほとんどのストレージ形式では、ファイルのデータと名前の定義はほぼ同等ですが、それ以上のメタデータの表現はさまざまであったり、まったくなかったりする場合があります。

zip ファイルまたはアーカイブ ファイルは、メタデータの処理の問題を解決します。ユーティリティ プログラムは、複数のファイルを、各ファイルに関するメタデータと、それらのファイルが属するフォルダー/ディレクトリとともに、1 つの新しいファイル (拡張子.zipのzipファイルなど) にまとめて収集します。新しいファイルも圧縮され、場合によっては暗号化されますが、FTP転送によってオペレーティング システム間で 1 つのファイルとして転送したり、電子メールの添付ファイルとして送信したりできるようになります。送信先では、受信した 1 つのファイルを互換性のあるユーティリティで解凍して使用する必要があります。メタデータの処理の問題は、zip ファイルまたはアーカイブ ファイルを使用してこのように解決されます。

Mac OSの階層ファイル システムは、各ファイルのディレクトリ エントリの一部としてクリエータとタイプのコードを保存します。これらのコードは OSTypes と呼ばれます。これらのコードは任意の 4 バイト シーケンスにすることができますが、多くの場合、ASCII 表現がアプリケーション名の略語や開発者のイニシャルなどの意味のある文字のシーケンスを形成するように選択されます。たとえば、HyperCard の「スタック」ファイルの場合、クリエータはWILD ( Hypercardの以前の名前である「WildCard」から) で、タイプはSTAKです。BBEditテキスト エディタの場合、クリエータ コードは元のプログラマである Rich Siegel を参照します。タイプ コードはファイルの形式を指定し、クリエータ コードはユーザーがダブルクリックしたときにファイルを開くデフォルトのプログラムを指定します。たとえば、クリエータコードが異なるため、タイプ コードがすべてTEXTである複数のテキスト ファイルをユーザーが持つことができますが、それぞれ異なるプログラムで開かれます。この機能は、たとえば、人間が読めるプレーンテキスト ファイルを汎用テキスト エディターで開くことができ、プログラミング ファイルや HTML コード ファイルは専用のエディターまたはIDEで開くことができるようにするために用意されました。ただし、この機能は、ファイルをダブルクリックしたときにどのプログラムが起動するかが予測できないことが多く、ユーザーの混乱の原因になることがよくありました。RISC OS は、説明の表で検索できる 12 ビットの数値で構成される同様のシステムを使用します。たとえば、16 進数は、 PostScriptファイルを表すPoScriptに「エイリアス」されます。 R*chFF5

Uniform Type Identifier (UTI) は、ファイル形式などのエンティティの「型付けされた」クラスを一意に識別するためにmacOSで使用される方法です。これは、OSType (タイプと作成者のコード) の代わりとして Appleによって開発されました。

UTI はCore Foundation 文字列で、逆 DNS文字列を使用します。一般的な標準タイプにはpublic と呼ばれるドメインを使用するもの(例: Portable Network Graphicsイメージの場合はpublic.png ) があり、その他のドメインはサードパーティのタイプに使用できます (例: Portable Document Formatの場合はcom.adobe.pdf )。UTI は、適合階層と呼ばれる階層構造内で定義できます。つまり、public.png はpublic.imageのスーパータイプに準拠し、public.image 自体はpublic.dataのスーパータイプに準拠しています。UTI は複数の階層に存在できるため、柔軟性が高まります。

ファイル形式に加えて、UTI は macOS に存在する可能性のある他のエンティティにも使用できます。

• ペーストボードデータ
• フォルダ（ディレクトリ）
• 翻訳可能なタイプ（翻訳マネージャによって処理される）
• バンドル
• フレームワーク
• ストリーミングデータ
• エイリアスとシンボリックリンク

IBM OS/VSからz/OSでは、VSAM カタログ ( ICF カタログの前) と VSAM ボリューム データ セット (VVDS) (ICF カタログを含む) 内の VSAM ボリューム レコードによって、VSAM データ セットのタイプが識別されます。

IBM OS/360からz/OSでは、ボリューム目次 (VTOC) 内のフォーマット 1 または 7 のデータ セット制御ブロック(DSCB)は、それによって記述されるデータ セットの データ セット編成 ( DSORG ) を識別します。

HPFS 、 FAT12、および FAT16 (FAT32 は不可) ファイルシステムでは、ファイルとともに「拡張属性」を保存できます。拡張属性は、名前、値のコード化されたタイプ、および値の 3 つの任意のセットで構成されます。名前は一意で、値は最大 64 KB までです。特定のタイプと名前には標準化された意味があります ( OS/2の場合)。その 1 つは、ファイル タイプを決定するために「.TYPE」拡張属性が使用されることです。その値は、ファイルに関連付けられた 1 つ以上のファイル タイプのリストで構成され、各ファイルは「プレーン テキスト」や「HTML ドキュメント」などの文字列です。したがって、ファイルには複数のタイプがある場合があります。

NTFSファイルシステムでは、ファイルフォークの 1 つとして OS/2 拡張属性の保存も許可されていますが、この機能は OS/2 サブシステムをサポートするためだけに存在するため (XP には存在しません)、Win32 サブシステムはこの情報を不透明なデータ ブロックとして扱い、使用しません。代わりに、他のファイル フォークを使用して、Win32 固有の形式でメタ情報を保存しています。OS/2 拡張属性は Win32 プログラムで引き続き読み取りおよび書き込みできますが、データはアプリケーションによって完全に解析される必要があります。

Unix およびUnix ライクなシステムでは、ext2、ext3、ext4、ReiserFSバージョン 3、XFS、JFS、FFS、およびHFS+ファイルシステムにより、ファイルとともに拡張属性を保存できます。これらには、任意の「名前 = 値」文字列のリストが含まれます。名前は一意であり、関連する名前を通じて値にアクセスできます。

PRONOM永続的一意識別子 (PUID)は、ファイル形式に対する永続的、一意的、かつ明確な識別子の拡張可能なスキームであり、英国国立公文書館がPRONOM 技術レジストリサービスの一環として開発したものです。PUID は、 info:pronom/名前空間を使用してUniform Resource Identifiersとして表現できます。英国政府および一部のデジタル保存プログラム以外ではまだ広く使用されていませんが、PUID スキームは、ほとんどの代替スキームよりも粒度が細かくなっています。

MIMEタイプは、多くのインターネット関連のアプリケーションで広く使用されており、他の場所でも使用が増えていますが、ディスク上のタイプ情報に使用されることはまれです。これらは、タイプとサブタイプをスラッシュで区切った標準化された識別子システム ( IANAによって管理)で構成されます(例: text/htmlまたはimage/gif ) 。これらは、もともと、ソース オペレーティング システムとターゲット オペレーティング システムとは関係なく、電子メールに添付されたファイルの種類を識別する方法として意図されていました。MIMEタイプは、 BeOS、AmigaOS 4.0、およびMorphOS上のファイルを識別し、アプリケーション起動用の一意のアプリケーション署名を保存します。AmigaOS および MorphOS では、MIME タイプ システムは Amiga 固有のデータ型システムと並行して動作します。

ただし、MIME タイプには問題があります。いくつかの組織や個人が、IANA に適切に登録せずに独自の MIME タイプを作成しているため、場合によってはこの標準の使用が困難になります。

ファイル形式識別子は、ファイル形式をその出所とファイル カテゴリによって識別するもう 1 つの方法ですが、あまり広く使用されていません。これは、Description Explorer ソフトウェア スイート用に作成されました。これは、 という形式の複数の数字で構成されていますNNNNNNNNN-XX-YYYYYYY。最初の部分は組織の出所/管理者を示し (この数字は、会社/標準化団体のデータベース内の値を表します)、次の 2 桁はファイルの種類を16 進数で分類します。最後の部分は、ファイルの通常のファイル名拡張子またはファイルの国際標準番号で構成され、左側はゼロで埋められます。たとえば、PNG ファイル仕様の FFID は000000001-31-0015948で、 は31画像ファイル、0015948は標準番号、国際標準化機構(ISO) 000000001を示します。

ファイル形式を識別するもう 1 つのあまり一般的ではない方法は、ファイルの内容を調べてファイルの種類を区別できるパターンを探すことです。ファイルの内容はバイトのシーケンスで、1 バイトには 256 の一意の組み合わせ (0 ～ 255) があります。したがって、バイト頻度分布と呼ばれるバイト パターンの発生回数をカウントすると、ファイルの種類を識別するための識別可能なパターンが得られます。バイト頻度分布を使用してファイルの種類を表すモデルを構築し、統計およびデータ マイニング手法を使用してファイルの種類を識別する、コンテンツ ベースのファイルの種類識別スキームは多数あります。^[2]

ファイル内のデータを構造化する方法にはいくつかの種類があります。最も一般的な方法を以下に説明します。

以前のファイル形式では、1 つ以上の構造のメモリ イメージをファイルに直接ダンプする生データ形式が使用されていました。

これにはいくつかの欠点があります。メモリ イメージに将来の拡張用に予約された領域がない限り、このタイプの構造化ファイルの拡張と改善は非常に困難です。また、1 つのプラットフォームまたはプログラミング言語に固有のファイルも作成される可能性があります (たとえば、Pascal文字列を含む構造は、 Cではそのように認識されません)。一方、これらのタイプのファイルを読み書きするためのツールの開発は非常に簡単です。

非構造化形式の制限により、簡単に拡張でき、同時に下位互換性も確保できる他の種類のファイル形式が開発されました。

このようなファイル構造では、各データは、何らかの方法でデータを識別するコンテナに埋め込まれます。コンテナのスコープは、何らかの開始マーカーと終了マーカー、どこかの明示的な長さフィールド、またはファイル形式の定義の固定要件によって識別できます。

1970 年代を通じて、多くのプログラムがこの一般的な種類の形式を使用していました。たとえば、 troff、Script、Scribeなどのワードプロセッサや、 CSVなどのデータベースエクスポートファイルです。Electronic ArtsとCommodore - Amigaも 1985 年に IFF (Interchange File Format) ファイル形式でこのタイプのファイル形式を使用していました。

コンテナは「チャンク」と呼ばれることもありますが、「チャンク」は各部分が小さいことや、チャンクに他のチャンクが含まれていないことを意味する場合もあります。多くの形式では、これらの要件は課されません。

特定の「チャンク」を識別する情報は、さまざまな名前で呼ばれることがあります。多くの場合、「フィールド名」、「識別子」、「ラベル」、または「タグ」などの用語が含まれます。識別子は多くの場合、人間が判読可能で、データの一部を分類します。たとえば、「姓」、「住所」、「四角形」、「フォント名」などです。これらは、データベース キーやシリアル番号という意味での識別子と同じものではありません (ただし、識別子は、関連するデータをそのようなキーとして識別することはできます)。

このタイプのファイル構造では、特定のチャンク識別子を認識しないツールは、理解できないチャンク識別子を単にスキップします。スキップされたデータの実際の意味に応じて、これが役立つ場合と役に立たない場合があります ( CSS はこのような動作を明示的に定義します)。

この概念は、RIFF (IFF に相当する Microsoft-IBM 規格)、PNG、JPEG ストレージ、DER ( Distinguished Encoding Rules ) でエンコードされたストリームとファイル (元々は CCITT X.409:1984 で記述されていたため、IFF より前のものです)、およびStructured Data Exchange Format (SDXF)で繰り返し使用されてきました。

実際、あらゆるデータ形式では、何らかの方法でその構成要素の重要性を識別する必要があり、埋め込まれた境界マーカーはそれを行う明白な方法です。

• MIME ヘッダーは、各論理行の先頭にコロンで区切られたラベルを付けてこれを行います。一部のヘッダーのデータ コンテンツには、他の規則で抽出できるサブパーツがありますが、MIME ヘッダーには他の MIME ヘッダーを含めることはできません。
• CSVや類似のファイルでは、多くの場合、フィールド名とフィールド境界を示すコンマを含むヘッダー レコードを使用してこれを行います。MIME と同様に、CSV では複数レベルの構造は規定されていません。
• XMLおよびその類似形式は、データ要素がチャンク識別子に似たマークアップによって識別されるため、大まかに言えばチャンクベースの形式の一種であると考えられます。ただし、スキーマや検証などの形式的な利点があり、ツリー、DAG、チャートなどのより複雑な構造を表す機能もあります。XML が「チャンク」形式であると考えられる場合、SGMLとその前身であるIBM GML は、そのような形式の最も初期の例の 1 つです。
• JSON は、スキーマ、相互参照、または繰り返されるフィールド名の意味の定義がない点で XML に似ており、プログラマーにとって便利な場合が多くあります。
• YAML はJSON に似ていますが、インデントを使用してデータ チャンクを区切り、JSON や XML よりも人間が読みやすい形式を目指しています。
• プロトコル バッファーはJSON に似ており、特にデータ内の境界マーカーをフィールド番号に置き換え、外部メカニズムによって名前との間でマッピングされる点が異なります。

これは、ファイル システム ( OLEドキュメントは実際のファイル システム) によく似た、もう 1 つの拡張可能な形式です。ファイルは、ファイル自体内のデータの場所と署名 (場合によってはタイプ) を含む「ディレクトリ エントリ」で構成されます。これらのタイプのファイル構造の良い例としては、ディスク イメージ、実行可能ファイル、OLE ドキュメントTIFF、ライブラリなどがあります。

ODT や DOCX などの一部のファイル形式はPKZIPベースであり、チャンク化されており、ディレクトリを保持します。^{[引用が必要]}

ディレクトリベースのファイル形式の構造は、非構造化形式やチャンクベースの形式よりも簡単に変更することができます。^[要出典]このタイプの形式の性質により、ユーザーはファイルを慎重に作成することができ、リーダー ソフトウェアは形式の作成者が決して意図していなかったことを実行します。この例としては、zip 爆弾があります。ディレクトリベースのファイル形式は、ファイル内の他の領域を指す値も使用しますが、後続のデータ値が以前に読み込まれたデータを指す場合、入力ファイルが有効であると想定して盲目的にループに従うリーダー ソフトウェアでは、無限ループが発生する可能性があります。^[要出典]

• オーディオファイル形式
• 化学ファイル形式
• 実行ファイル形式の比較
• デジタルコンテナフォーマット
• ドキュメントファイル形式
• DROIDファイル形式識別ユーティリティ
• ファイル（コマンド）、ファイルタイプ識別ユーティリティ
• ファイル変換
• 将来への備え
• グラフィックファイル形式の概要
• 画像ファイル形式
• アーカイブ形式のリスト
• ファイル形式のリスト
• ファイル署名のリスト、または「マジックナンバー」
• ファイル名拡張子のリスト（アルファベット順）
• 無料のファイル形式のリスト
• モーションおよびジェスチャーファイル形式のリスト
• マジックナンバー（プログラミング）
• オブジェクトファイル
• ビデオファイル形式
• Windows ファイルの種類
• ファイル名拡張子

無料の辞書「Wiktionary」でファイル形式を調べてください。

• ファイル形式のベストプラクティス、米国：スタンフォード大学図書館、データ管理サービス（「使用するファイル形式は、後でファイルを開く能力や他の人がそのデータにアクセスする能力に直接影響します」）