ファイル形式

ウィキペディアから、無料の百科事典
ナビゲーションにジャンプ 検索にジャンプ
wavファイル:2.1メガバイト。
oggファイル:154キロバイト。

ファイル形式は、ある標準の情報を記憶するためにエンコードされている方法、コンピュータ・ファイル。これは、ビットを使用してデジタル記憶媒体の情報をエンコードする方法を指定します。ファイル形式は、プロプライエタリまたは無料のいずれかであり、未公開またはオープンのいずれかです。

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

仕様

多くの場合、ファイル形式には、エンコード方法を説明し、プログラムが意図する機能のテストを可能にする仕様が公開されています。一部の開発者が仕様書を企業秘密見なしていることや、他の開発者が正式な仕様書を作成していないため、すべての形式に自由に利用できる仕様書があるわけではありません。これらの既存のプログラムはそれを使用します。

フォーマットの開発者が無料の仕様を公開していない場合、その種類のファイルを利用しようとしている別の開発は、ファイルをリバースエンジニアリングして読み取り方法を見つけるか、フォーマットの開発者から有料で署名して仕様ドキュメントを取得する必要があります。非開示契約後者のアプローチは、正式な仕様書が存在する場合にのみ可能です。どちらの戦略にも、かなりの時間、お金、またはその両方が必要です。したがって、公開されている仕様のファイル形式は、より多くのプログラムでサポートされる傾向があります。

特許

ファイル形式を保護するために、著作権ではなく特許がよく使用されます。ファイル形式の特許は米国の法律では直接許可されていませんが、一部の形式は特許取得済みのアルゴリズムを使用してデータをエンコードしますたとえば、GIFファイル形式で圧縮を使用するには、特許取得済みのアルゴリズムを使用する必要があります。特許所有者は最初は特許を行使しませんでしたが、後で使用料の徴収を開始しましたこれにより、GIFの使用が大幅に減少し、代替PNG形式の開発に部分的に関与しています。ただし、GIF特許は、米国では2003年半ばに、世界中では2004年半ばに失効しました。

ファイルタイプの識別

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

ファイル名拡張子

WindowsmacOSCP / MDOSVMSVM / 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]たとえば、悪意のあるユーザーがHolidayphoto.jpg.exeなどの無実の名前で実行可能プログラム作成する可能性があります。 「.exe」は非表示になり、疑いを持たないユーザーには「Holidayphoto.jpg」が表示されます。これはJPEG画像のように見え、通常はマシンに害を及ぼすことはありません。ただし、オペレーティングシステムには引き続き「.exe」が表示されます。"拡張子を付けてプログラムを実行すると、コンピュータに害を及ぼす可能性があります。拡張子が1つしかないファイルでも同じことが言えます。ユーザーには表示されないため、明示的に調査しないとファイルに関する情報を推測できません。ユーザーをさらに騙すために、プログラム内にアイコンを保存することができます。その場合、実行可能ファイル(.exeに対する一部のオペレーティングシステムのアイコン割り当ては、JPEG画像を表すために一般的に使用されるアイコンで上書きされます。プログラムは画像のように見えます。拡張子を偽装することもできます。一部のMicrosoftWordマクロウイルスは、テンプレート形式でWordファイルを作成し、.docで保存します。拡大。Wordは通常、拡張子を無視してファイルの形式を調べるため、これらはテンプレートとして開き、ウイルスを実行して拡散します。[要出典]これは、拡張機能の非表示がデフォルトでオンになっているWindowsシステムの実際的な問題を表しています。

内部メタデータ

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

ファイルヘッダー

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

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

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

ヘッダーがバイナリハードコーディングされているため、ヘッダー自体が認識されるために複雑な解釈が必要な場合、特にメタデータコンテンツの保護のために、ファイル形式が誤って解釈される可能性があります。ソースでひどく書かれているかもしれません。これにより、メタデータが破損し、非常に悪い場合には、ファイルが読み取れなくなる可能性があります。[説明が必要]

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

マジックナンバー

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

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

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

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

外部メタデータ

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

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

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

MacOSタイプコード

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

Mac OS XのUniform Type Identifier(UTI)

ユニフォームタイプ識別子(UTI)は、ファイル形式などのエンティティの「型付き」クラスを一意に識別するためmacOS使用されるメソッドです。これは、OSType(タイプおよびクリエーターコード)の代わりとしてAppleによって開発されました。

UTIは、Core Foundationのの 文字列使用して、逆DNSの文字列を。いくつかの一般的な標準タイプと呼ばれるドメインを使用パブリック(例えばpublic.pngポータブルネットワークグラフィックスの他のドメインは、サードパーティのタイプのために使用することができる一方で、(例えば画像)をcom.adobe.pdfためのポータブルドキュメントフォーマットを)。 UTIは、適合階層と呼ばれる階層構造内で定義できます。したがって、public.pngpublic.imageのスーパータイプに準拠しpublic.image自体はpublic.dataのスーパータイプに準拠します。 UTIは複数の階層に存在できるため、柔軟性が高くなります。

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

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

OS / 2拡張属性

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

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

POSIX拡張属性

UnixおよびUnixのようなシステムでは、ext2ext3ReiserFSバージョン3、XFSJFSFFS、およびHFS +ファイルシステムにより、ファイルとともに拡張属性を保存できます。これらには、「name = value」文字列の任意のリストが含まれます。ここで、名前は一意であり、関連する名前を介して値にアクセスできます。

PRONOM一意識別子(PUID)

PRONOM永続一意識別子(PUID)は、によって開発されたファイル形式のため、永続的なユニークで明確な識別子の拡張可能なスキームである英国の国立公文書館そのの一環としてPRONOM技術レジストリサービス。PUIDは次のように表すことができるユニフォームリソース識別子使っpronom /:情報名前空間を。英国政府や一部のデジタル保存プログラム以外ではまだ広く使用されていませんが、PUIDスキームは、ほとんどの代替スキームよりも優れた粒度を提供します。

MIMEタイプ

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

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

ファイル形式識別子(FFID)

ファイル形式識別子は、ファイルの出所とファイルカテゴリに従ってファイル形式を識別するためのもう1つの、広く使用されていない方法です。これは、DescriptionExplorerソフトウェアスイート用に作成されました。の形式の数桁で構成されNNNNNNNNN-XX-YYYYYYYます。最初の部分は組織の起源/メンテナを示し(この番号は会社/標準化団体データベースの値を表します)、次の2桁はファイルのタイプを16進数で分類します。最後の部分は、ファイルの通常のファイル名拡張子またはファイルの国際標準番号で構成され、左にゼロが埋め込まれます。例えば、PNGファイル仕様はFFID有する000000001-31-0015948場合31、画像ファイルを示すが0015948、標準的な数であると000000001示しています国際標準化機構(ISO)。

ファイルコンテンツベースのフォーマット識別

ファイル形式を識別するもう1つの、しかしあまり一般的ではない方法は、ファイルの種類間で識別可能なパターンについてファイルの内容を調べることです。ファイルの内容は一連のバイトであり、1バイトには256の一意の順列(0〜255)があります。したがって、バイト頻度分布と呼ばれることが多いバイトパターンの発生をカウントすると、ファイルタイプを識別するための識別可能なパターンが得られます。バイト頻度分布を使用してファイルタイプの代表的なモデルを構築し、統計およびデータマイニング技術を使用してファイルタイプを識別する、多くのコンテンツベースのファイルタイプ識別スキームがあります[2]。

ファイル構造

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

非構造化フォーマット(rawメモリダンプ)

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

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

非構造化フォーマットの制限により、簡単に拡張でき、同時に下位互換性のある他のタイプのファイルフォーマットが開発されました。

チャンクベースのフォーマット

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

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

コンテナは「チャンク」と呼ばれることもありますが、「チャンク」は、各ピースが小さいこと、および/またはチャンクに他のチャンクが含まれていないことを意味する場合もあります。多くのフォーマットはそれらの要件を課していません。

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

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

この概念は、RIFF(Microsoft-IBMのIFFに相当)、PNG、JPEGストレージ、DER(Distinguished Encoding Rules)でエンコードされたストリームおよびファイル(元々はCCITT X.409:1984で記述されていたため、IFFより前のもの)で何度も使用されています。 )、および構造化データ交換フォーマット(SDXF)

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

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

ディレクトリベースのフォーマット

これは別の拡張可能な形式であり、ファイルシステム(OLEドキュメントは実際のファイルシステムです)によく似ています。ファイルは、ファイル自体内のデータの場所とその署名(および特定の場合)を含む「ディレクトリエントリ」で構成されます。そのタイプの場合)。これらのタイプのファイル構造の良い例はディスクイメージ、OLEドキュメントTIFFライブラリです。PKZIPベースのODTとDOCXはチャンク化されており、ディレクトリも持っています。

も参照してください

参考文献

  1. ^ PCワールド(2003年12月23日)。「Windowsのヒント:セキュリティ上の理由から、ファイル拡張子を知っておくとよいでしょう」2008年4月23日にオリジナルからアーカイブされまし検索された20年6月2008年
  2. ^ 「ファイル形式の識別」アーカイブされたオリジナルの2009年8月14日に2009年7月21日取得

外部リンク