.ZIP ファイルは、複数のファイルを格納するアーカイブです。 ZIP は、含まれるファイルを圧縮せずに単に保存するだけでなく、多くの異なる方法を使用して圧縮することができます。 各ファイルは別々に保存され、同じアーカイブ内の異なるファイルを異なる方法で圧縮することができます。 ZIPアーカイブ内のファイルは個別に圧縮されているので、アーカイブ全体に圧縮や解凍を適用することなく、ファイルを取り出したり、新しいファイルを追加したりすることが可能です。 これは、このようなランダムアクセス処理が容易でない圧縮された tar ファイルの形式とは対照的です。
ZIP ファイルの末尾にはディレクトリが置かれます。 これは、どのファイルが ZIP に含まれているかを識別し、そのファイルが ZIP のどこに位置しているかを識別します。 これにより、ZIP リーダーは ZIP アーカイブ全体を読み込むことなく、ファイルのリストを読み込むことができます。 ZIPアーカイブは、ZIPアーカイブとは関係のない余分なデータを含むこともできます。 これは、ZIPアーカイブにプログラムコードを前置きして、そのファイルを実行可能としてマークすることによって、ZIPアーカイブを自己解凍型アーカイブ（含まれるデータを解凍するアプリケーション）にすることを可能にします。 また、カタログを最後に格納することで、GIF 画像ファイルなどの無害なファイルに付加して、ZIP ファイルを隠すことができます。
.ZIP 形式は 32 ビット CRC アルゴリズムを使用し、アーカイブのディレクトリ構造のコピーを 2 つ含んで、データ損失に対する保護を強化します。
StructureEdit
ZIP ファイルは End of Central Directory レコードの存在によって正しく識別され、新しいファイルを容易に追加できるようアーカイブ構造の末端に位置しています。 end of central directory recordが空でないアーカイブを示す場合、アーカイブ内の各ファイルやディレクトリの名前は、エントリに関する他のメタデータ、および実際のエントリデータを指すZIPファイルへのオフセットと共に、central directoryエントリに指定されるべきです。 これにより、ファイルのリストを見るためにアーカイブ全体を読み込む必要がないため、アーカイブのファイルリストを比較的迅速に実行することができます。 ZIPファイル内のエントリーは、冗長性のために、この情報をローカルファイルのヘッダーに含めます。 ZIP ファイルは追記されることがあるため、ファイルの最後にある中心ディレクトリで指定されたファイルのみが有効である。 ローカルファイルヘッダのために ZIP ファイルをスキャンすることは、 (破損したアーカイブの場合を除いて) 無効です。中央のディレクトリは、 あるファイルが削除され、他のファイルが更新されたことを宣言するかもしれないからです。 これは、単にオリジナルの ZIP ファイルの最後に新しいファイル C を追加し、ファイル A と新しいファイル C のみをリストする新しい中央ディレクトリを追加することによって達成されるかもしれません。 ZIP が最初に設計されたとき、フロッピー ディスクによるファイルの転送は一般的でしたが、ディスクへの書き込みは非常に時間のかかるものでした。 もしあなたが大きなZIPファイルを持っていて、おそらく複数のディスクにまたがっていて、いくつかのファイルを更新する必要があるだけなら、すべてのファイルを読んで書き直すよりも、古いセントラルディレクトリを読んで、新しいファイルを追加し、それから更新されたセントラルディレクトリを追加するほうが実質的に速くなるでしょう。
ZIP アーカイブに格納された各エントリは、コメント、ファイル サイズ、ファイル名などのファイルに関する情報を持つローカル ファイル ヘッダーと、オプションの「追加」データ フィールド、そしておそらく圧縮、暗号化されたファイル データで始まります。 エクストラ” データフィールドは、ZIP フォーマットの拡張性の鍵となるものです。 「Extra” フィールドは、ZIP64 フォーマット、WinZip 互換の AES 暗号化、ファイル属性、高解像度の NTFS または Unix ファイルのタイムスタンプをサポートするために利用されます。 その他の拡張は、”Extra” フィールドを介して可能です。
ZIP フォーマットは、 ファイルの様々な構造を示すために、 特定の 4 バイトの “署名” を使用することが要求されています。 各ファイルエントリは特定のシグネチャによってマークされる。 中央ディレクトリレコードの終わりは、その特定の署名で示され、中央ディレクトリの各エントリは、4バイトの中央ファイルヘッダ署名で始まります。
ZIP仕様にはBOFまたはEOFマーカーはありません。 慣習的に ZIP ファイルの最初のものは ZIP エントリであり、 そのローカルファイルヘッダー署名によって簡単に識別することができる。 しかし、これは ZIP 仕様で要求されていないため、必ずしもそうではない。最も顕著なのは、自己解凍アーカイブは実行ファイルヘッダで始まることである。
ZIP アーカイブを正しく読むツールは、中央ディレクトリレコード署名の終わりをスキャンし、次に、必要に応じて、他の、示された、中央ディレクトリレコードをスキャンしなければならない。 なぜなら、(このセクションで既に述べたように) ファイルの塊がどこで始まり、それが削除されていないことを特定するのは中央ディレクトリだけだからです。 このフォーマットはチャンク間に他のデータがあることを禁じておらず、またファイルデータストリームがそのような署名を含むことを禁じていないため、スキャンは誤検知につながる可能性があります。 しかし、破損した ZIP アーカイブからデータを復元しようとするツールは、ほとんどの場合、ローカル ファイル ヘッダー署名のアーカイブをスキャンします。これは、ファイル チャンクの圧縮サイズがファイル チャンクの後に格納される場合があるという事実によってより困難になり、順次処理が困難になります。 ASCII 文字列として見ると、これは発明者 Phil Katz のイニシャルである “PK” と読み取れます。 したがって、ZIPファイルをテキストエディタで表示すると、ファイルの最初の2バイトは通常 “PK “になります。 (DOS, OS/2, Windows の自己解凍型 ZIP は、ZIP の前に EXE があるので “MZ” で始まります。他のオペレーティングシステムの自己解凍型 ZIP は、同様にそのプラットフォームでアーカイブの内容を展開するための実行コードが前にあるかもしれません。)
.ZIP 仕様は、複数のファイルシステムファイルにわたってアーカイブを展開することもサポートしています。 元々は、複数のフロッピーディスクにまたがる大きな ZIP ファイルの保存のために意図されていましたが、この機能は現在、電子メール、または他のトランスポートやリムーバブルメディア上で部分的に ZIP アーカイブを送信するために使用されています。 その結果、ZIP アーカイブのファイルの組み込みのタイムスタンプ分解能は、より正確なタイムスタンプを格納するために追加のフィールドを使用できるものの、わずか 2 秒です。
In September 2007, PKWARE は UTF-8 を使ったファイル名の保存を提供する ZIP 仕様の改訂をリリースし、ついに ZIP に Unicode 互換性を追加しました。 すべての長さフィールドは、バイト単位で長さを数えます。
Local file headerEdit
| Offset | Bytes | Description | |
|---|---|---|---|
| 0 | 4 | Local file header signature = 0x04034b50 (read as a little-endian byte order) | ファイルヘッダー署名 = 0x04034b50（リトルエンディアンと読みます。エンディアン番号） |
| 4 | 2 | 抽出に必要なバージョン（最小） | |
| 6 | 2 | 汎用ビットフラグ | |
| 8 | 2 | 圧縮方法 | |
| 10 | 2 | ファイル最終更新時刻 | |
| 12 | 2 | ||
| 14 | 4 | CRC-> | 10 | 10 | 2 | 1 | 2 |
| 18 | 4 | 圧縮サイズ（ZIP64では0xffffff） | |
| 22 | 4 | 非圧縮サイズ（ZIP64の場合は0xffffff） | |
| 26 | 2 | ファイル名長（n） | |
| 28 | 2 | エクストラフィールド長（m） | |
| 30 | n | ファイル名 | 30+n | m | Extra field |
エクストラフィールドにはOSなど様々なオプションデータが含まれます。固有の属性です。 チャンクに分割され、それぞれ16ビットのIDコードと16ビットの長さを持つ。 ZIP64の場合、少なくとも1つのチャンク（IDコード0001、サイズ32バイト）が常に存在します。
この直後に圧縮データが続きます。 ローカルヘッダのフィールドは0で埋められ、CRC-32とサイズは圧縮データの直後に12バイトの構造体（オプションで4バイトのシグネチャが先行する）で付加されます。
| オフセット | バイト | 説明 | |||||
|---|---|---|---|---|---|---|---|
| 0 | 0/4 | オプションデータディスクリプタ署名 = 0x08074b50 | |||||
| 0/4 | 4 | CRC-> | 0 | 0/4 | 0 | 4 | Optimum非圧縮データ32個 |
| 4/8 | 4 | 圧縮サイズ | |||||
| 8/12 | 4 | 非圧縮サイズ size |
Central directory file headerEdit
中央ディレクトリエントリは、ローカルヘッダの展開形式です。
| Offset | Bytes | Description | ||
|---|---|---|---|---|
| 0 | 4 | Central ディレクトリファイルのヘッダー署名 = 0x02014b50 | ||
| 4 | 2 | 作成バージョン | ||
| 6 | 2 | 2 | 展開に必要なバージョン (最小) | |
| 8 | 2 | 汎用ビットフラグ | ||
| 10 | 2 | |||
| 12 | 2 | ファイルの最終更新時刻 | ||
| 14 | ファイルの最終更新日 | |||
| 16 | 4 | CRC-」。非圧縮データ32個 | ||
| 20 | 4 | 圧縮サイズ（ZIP64では0xffffff） | ||
| 24 | 4 | 非圧縮データサイズ (ZIP64の場合は0xffffff) | ||
| 28 | 2 | ファイル名長 (n) | ||
| 30 | 2 | エクストラフィールド長 (m) | ||
| 32 | 2 | ファイルコメント長（k） | ||
| 34 | 2 | ファイルが始まるディスク番号 | ||
| 36 | 2 | 内部ファイル属性 | ||
| 38 | 4 | 外部ファイル属性 | ||
| 42 | 4 | ローカルファイルヘッダの相対的オフセットです。 これは、ファイルが発生する最初のディスクの開始位置と、ローカルファイルヘッダの開始位置との間のバイト数である。 これにより、中央のディレクトリを読み取るソフトウェアが、ZIPファイル内のファイルの位置を特定することができます。 | ||
| 46 | n | ファイル名 | ||
| 46+n | m | エキストラフィールド | ||
| 46+n+m | k | ファイルコメント |
End of central directory record (EOCD)Edit
すべてのセントラルディレクトリのエントリの後に、EOCD (end of central directory) レコードが来ます。 ZIPファイルの終わりを示すものです。
| オフセット | バイト | 説明 | |
|---|---|---|---|
| 0 | 4 | End of 中央ディレクトリ署名 = 0x06054b50 | |
| 4 | 2 | このディスクの番号 | |
| 6 | 2 | 中央ディレクトリがあるディスク。 開始 | |
| 8 | 2 | このディスクの中央ディレクトリレコード数 | |
| 10 | 2 | 中央ディレクトリの総数 | |
| 8 | 2 | 2 | このディスクの中央ディレクトリ数 1347> |
| 12 | 4 | 中央ディレクトリのサイズ（バイト） | |
| 16 | 4 | 中央ディレクトリの開始位置のオフセットです。 アーカイブの開始点からの相対位置 | |
| 20 | 2 | コメントの長さ (n) | |
| 22 | n | コメント |
この順序によりZIPファイルが一度に作成されるようになりました。 しかし、複数のパーツからファイルを取り出しやすくするために、中心ディレクトリもファイルの末尾に配置されています（例．
Compression methodsEdit
The .ZIP File Format Specification documentation of the following compression methods: Store (圧縮なし), Shrink (LZW), Reduce (レベル 1-4; LZ77 + probabilistic), Implode, Deflate, Deflate64, bzip2, LZMA, WavPack, PPMd, IBM z/OS CMPSC 命令による LZ77 variant. 最もよく使われる圧縮方法はDEFLATEで、これはIETF RFC 1951で説明されている。
言及されているが、仕様で詳細に文書化されていない他の方法には以下のものがある。 PKWARE DCL Implode (old IBM TERSE), new IBM TERSE, IBM LZ77 z Architecture (PFS), and a JPEG variant. Tokenize」メソッドはサードパーティのために予約されていましたが、サポートは追加されませんでした。
Implodeという単語はPKWAREによって乱用されています。 DCL Implode は、部分的には IBM の所有物であるため文書化されていませんが、 Mark Adler は zlib と共に “blast” と呼ばれる解凍器を提供しています。
EncryptionEdit
ZIP は一般的に ZipCrypto として知られているシンプルなパスワードベースの対称型暗号化システムをサポートしています。 これは ZIP の仕様の中で文書化されており、深刻な欠陥があることが知られている。 特に、それは既知の平文攻撃に対して脆弱であり、 いくつかの場合、乱数生成器の貧弱な実装によって悪化しています。
新しい圧縮と暗号化 (例えば AES) の方法を含む新機能は、 バージョン 5.2 以降の ZIP File Format Specification で文書化されています。 WinZip が開発した AES ベースのオープンスタンダード (“AE-x” in APPNOTE) は 7-Zip と Xceed でも使われていますが、他のフォーマットを使っているベンダーもあります。 PKWARE SecureZIP (SES, 専用) は、RC2, RC4, DES, Triple DESの暗号化方式、デジタル証明書ベースの暗号化および認証 (X.509) 、アーカイブのヘッダー暗号化もサポートしています。
ファイル名の暗号化は .ZIP ファイルフォーマット仕様 6.2 で導入され、アーカイブのセントラルディレクトリ部分に格納されたメタデータは暗号化されますが、ローカルヘッダ部分は暗号化されません。 Central Directory Encryption を使用する場合、準拠したアーカイバは Local Header データを改竄することができます。
ZIP64Edit
オリジナルの .ZIP 形式では、さまざまなもの（ファイルの非圧縮サイズ、ファイルの圧縮サイズ、アーカイブの合計サイズ）に 4 GiB（232 バイト）の制限があり、また ZIP アーカイブのエントリ数は 65,535（216） に制限されていました。 仕様のバージョン4.5（特定のツールのv4.5とは異なります）では、PKWAREはこれらの制限を回避するために「ZIP64」形式拡張を導入し、制限を16 EiB（264バイト）に増やしました。 本質的には、ファイルのために「通常の」中央ディレクトリエントリを使用し、オプションの「ZIP64」ディレクトリエントリが続き、より大きなフィールドを持っています。
ローカル・ファイル・ヘッダーとセントラル・ディレクトリ・エントリーのフォーマットは、ZIPとZIP64で同じですが、サイズについては常に0xffffffが格納され、追加のフィールドが常に存在します。
| Offset | Bytes | Description | Offset | Bytes | Description | 0 | 2 | ヘッダーID 0x0001 |
|---|---|---|
| 2 | Size of extra field chunk (16, 24または28） | |
| 4 | 8 | 圧縮前のファイルサイズ |
| 12 | 8 | 圧縮データの大きさ |
| 20 | 8 | ローカルヘッダーレコードのオフセット |
| 28 | 4 | このファイルが始まるディスク番号 |
一方で、このファイルが始まるのは、以下の通り。 ZIP64用のEOCDは、通常のZIP版とは若干フォーマットが異なります（appnote 4.項参照）。3.14).
| オフセット | バイト | 説明 |
|---|---|---|
| 0 | 4 | 中央ディレクトリの終了署名 = 0x06064b50 |
| 4 | 8 | EOCD64の大きさ-… 8 |
| 12 | 2 | 製バージョン |
| 14 | 抽出に必要なバージョン（最小） | 16 | 4 | このディスクの番号 |
| 20 | 4 | 中央ディレクトリが始まるディスク |
| 24 | 8 | このディスクの中央ディレクトリレコード数 |
| 32 | 8 | 中央ディレクトリレコード数 |
| 40 | 8 | 中央ディレクトリのサイズ（バイト） |
| 48 | 8 | 中央ディレクトリの開始位置のオフセットです。 アーカイブの開始位置からの相対値 |
| 56 | n | コメント（EOCD64のサイズまで） |
また必ずしもファイルの最後のレコードではなく、オプションとして中央ディレクトリ終了ロケータ（最後に追加の20バイト）が後に続く場合があります。
Windows XP のファイル エクスプローラーは ZIP64 をサポートしていませんが、Windows Vista 以降のエクスプローラーではサポートされています。 同様に、DotNetZip、QuaZIP、Perl の IO::Compress::Zip など、いくつかの拡張ライブラリは ZIP64 をサポートしています。 Python の組み込み zipfile は 2.5 からサポートし、3.4 からはデフォルトでサポートされるようになりました。 OpenJDK のビルトイン java.util.zip はバージョン Java 7 から ZIP64 をサポートしています。 Android の Java API は Android 6.0 から ZIP64 をサポートしています。 Mac OS SierraのArchive Utilityは特にZIP64をサポートしておらず、ZIP64が必要な場合に破損したアーカイブを作成することがあります。 しかし、Mac OSに搭載されているdittoコマンドは、ZIP64ファイルを解凍することができます。 より最近のバージョンの Mac OS では、ZIP64 をサポートする info-zip の zip と unzip コマンドラインツールが同梱されています: 確認するには zip -v を実行して “ZIP64_SUPPORT” を探してください。
他のファイルフォーマットとの組み合わせ編集
.ZIP ファイルフォーマットでは、中心ディレクトリの後のファイルの最後に 65,535 (216-1) バイトまでのデータを含むコメントを置くことができます。 また、中央のディレクトリは、アーカイブの各ファイルの開始に対するオフセットを指定するので、最初のファイルエントリがゼロ以外のオフセットで始まることは可能ですが、いくつかのツール、たとえば gzip は、オフセットゼロのファイルエントリで始まらないアーカイブファイルを処理しません。 この副作用として、他の形式がその末尾、先頭、または中間で任意のデータを許容する場合、作業用 ZIP アーカイブと他の形式の両方を持つファイルを作成することが可能です。 WinZip でサポートされている自己展開アーカイブ (SFX) は、 PKZIP AppNote.txt 仕様に準拠した実行ファイル (.exe) であり、準拠した zip ツールやライブラリで読み込むことができるという点でこの利点を生かすことができるのです。
この .ZIP 形式および ZIP の亜種である JAR 形式の特性を利用すると、Web にアップロードされた GIF イメージなど、一見無害に見えるファイルの中に不正なコンテンツ (有害な Java クラスなど) を隠すことができます。 このいわゆる GIFAR exploit は、Facebook などの Web アプリケーションに対する効果的な攻撃として実証されています。
LimitsEdit
.ZIP ファイルの最小サイズは 22 バイトです。 このような空の ZIP ファイルには End of Central Directory Record (EOCD) だけが含まれます。
アーカイブ ファイルとその中の個々のファイルの最大サイズは、標準 ZIP では 4,294,967,295 バイト (232-1 バイト、または 4 GiB から 1 バイトを引いたサイズ) になっています。 ZIP64の場合、最大サイズは18,446,744,073,709,551,615バイト（264-1バイト、または16EiBマイナス1バイト）です。
独自の拡張機能 編集
Extra field 編集
.ZIP ファイルフォーマットはファイルヘッダ内にエクストラフィールド機能を持ち、既存の ZIP 仕様では定義されていない追加データを格納するために使用でき、フィールドを認識しない準拠したアーカイバが安全にそれらをスキップすることを可能にします。 ヘッダーID 0-31は、PKWAREが使用するために予約されています。 残りのIDはサードパーティベンダーが独自に使用することができます。
Strong encryption controversyEdit
WinZip 9.0 public betaが2003年にリリースされたとき、 WinZipは新しい仕様に対するドキュメントとともに、 異なるファイル形式による独自の AES-256 暗号化方式を導入しました。 暗号化規格自体は独自のものではありませんでしたが、PKWARE社はPKZIPのバージョン5.0と6.0で使用されていたStrong Encryption Specification (SES) を含むように2001年からAPPNOTE.TXTを更新していませんでした。 WinZip の技術コンサルタント Kevin Kearney と StuffIt プロダクトマネージャー Mathew Covington は PKWARE が SES を保留していると非難しましたが、PKZIP の最高技術責任者 Jim Peterson は証明書ベースの暗号化はまだ不完全だと主張しました。
別の論争の的になる動きとしては、PKWare は 2003年7月16日に ZIP と強い暗号化を組み合わせて安全なファイルを作成する方法について述べた特許を申請しています。 2004年1月21日、PKWAREはWinZipベースのAES圧縮フォーマットのサポートを発表した。 後のWinZipのベータ版では、SESベースのZIPファイルをサポートできるようになった。 PKWAREは最終的に.ZIP File Format Specificationのバージョン5.2を公開し、SESを文書化した。 Free Software プロジェクトの 7-Zip も AES をサポートしますが、ZIP ファイルの SES はサポートしません (その POSIX ポート p7zip も同様)。
WinZip で AES 暗号化を使用する場合、圧縮方法は常に 99 に設定され、実際の圧縮方法は AES 追加データフィールドに保存されています。 一方、Strong Encryption 仕様では、メタデータのマスク/暗号化に Central Directory Encryption を使用しない限り、圧縮方式は Local Header および Central Directory の基本ファイルヘッダーセグメントに格納されます
。