ZIP（ファイル形式）

ZIP は、ロスレス データ圧縮をサポートするアーカイブ ファイル形式です。ZIP ファイルには、圧縮されている可能性のある 1 つ以上のファイルまたはディレクトリを含めることができます。ZIP ファイル形式では、さまざまな圧縮アルゴリズムを使用できますが、最も一般的なのはDEFLATEです。この形式は、もともと 1989 年に作成され、PKWARE, Inc.のPKZIPユーティリティ^{[2]で、トム ヘンダーソンによって以前の}ARC圧縮形式の代替として最初に実装されました。ZIP 形式は、その後すぐに PKZIP 以外の多くのソフトウェア ユーティリティでサポートされるようになりました。Microsoft は、 1998 年以降、Windows 98 の「Plus! 98」アドオンを介して、 Microsoft Windowsのバージョンに組み込みの ZIP サポート (「圧縮フォルダ」という名前で) を含めています。ネイティブ サポートは、2000 年に Windows ME に追加されました。^{[要出典] Apple は、} Mac OS X 10.3 (BOMArchiveHelper、現在のArchive Utility経由)以降に組み込みの ZIP サポートを含めています。ほとんどの無料オペレーティング システムには、Windows や macOS と同様の方法で ZIP のサポートが組み込まれています。

ZIPファイルは通常、ファイル拡張子 .zipまたは.ZIPとMIMEメディアタイプを使用します。^[1] ZIPは、通常別の名前で、多くのプログラムで基本ファイル形式として使用されます。ユーザーインターフェイスを介してファイルシステムをナビゲートする場合、ZIPファイルを表すグラフィカルアイコンは、ジッパーを目立つように特徴とするドキュメントまたはその他のオブジェクトとして表示されることがよくあります。 application/zip

.ZIPファイル形式は、PKWARE の Phil Katz と Infinity Design Concepts の Gary Conway によって設計されました。この形式は、Systems Enhancement Associates (SEA) がPKWARE に対して、PKARC というアーカイブ製品が SEA のARCアーカイブ システムの派生製品であると主張して訴訟を起こした後に作成されました。^[3] 「zip」(「高速で移動する」という意味) という名前は、Katz の友人である Robert Mahoney によって提案されました。^[4]彼らは、自分たちの製品が当時のARCやその他の圧縮形式 よりも高速であることを暗示したかったのです。 ^[4] .ZIPファイル形式仕様の最も古いバージョンは、 1989年にPKZIP 0.9パッケージの一部としてAPPNOTE.TXTファイルとして初めて公開されました。 ^[要出典] APPNOTE.TXT内でzipファイル形式を配布することにより、1990年代にパブリックインターネット上でzipファイル形式との互換性が広く普及しました。^[5]

PKWAREとInfinity Design Conceptsは1989年2月14日に共同プレスリリースを行い、.ZIPファイル形式をパブリックドメインにリリースしました。^{[6] [7] [8] [9] [10]}

.ZIP ファイル形式仕様には独自のバージョン番号がありますが、特に PKZIP 6 以降では、PKZIP ツールのバージョン番号と必ずしも一致しません。PKWARE はさまざまな時点で、PKZIP 製品が高度な機能を使用してアーカイブを抽出できるようにする予備的な機能を追加してきましたが、そのようなアーカイブを作成する PKZIP 製品は次のメジャー リリースまで利用できません。他の企業や組織は、独自のペースで PKWARE 仕様をサポートしています。

.ZIP ファイル形式の仕様は正式には「APPNOTE - .ZIP ファイル形式の仕様」と呼ばれ、1990 年代後半から PKWARE.com の Web サイトで公開されています。^{[11]仕様のいくつかのバージョンは公開されていません。BZIP2}圧縮、強力な暗号化仕様などの一部の機能の仕様は、作成から数年後に PKWARE によって公開されました。PKWARE Web サイト上のオンライン仕様の URL は、何度か変更されました。

PKWARE 仕様のさまざまなバージョンにおける主な進歩の概要:

• 2.0: (1993) ^{[1]ファイルエントリは}DEFLATEで圧縮でき、従来のPKWARE暗号化(ZipCrypto)を使用できます。
• 2.1: (1996) Deflate64 圧縮
• 4.5: (2001) ^[12] 64ビットzip形式を文書化。
• 4.6: (2001) BZIP2 圧縮 (APPNOTE 5.2 の公開までオンラインでは公開されませんでした)
• 5.0: (2002) SES:暗号化にDES、Triple DES、RC2、RC4をサポート (APPNOTE 5.2 の公開までオンラインでは公開されませんでした)
• 5.2: (2003) ^{[13] [14]} SES(オンラインでは公開されていないAPPNOTE 5.1で定義)およびWinZipのAES("AE-x")に対するAES暗号化のサポート。SES暗号化でサポートされているRC2-64の修正バージョン。
• 6.1: (2004) ^[15]証明書の保管について文書化しました。
• 6.2.0: (2004) ^[16]中央ディレクトリ暗号化について文書化。
• 6.3.0: (2006) ^[17] Unicode( UTF-8 )ファイル名の保存について文書化。サポートされる圧縮アルゴリズム( LZMA、PPMd+ )、暗号化アルゴリズム( Blowfish、Twofish )、ハッシュのリストを拡張。
• 6.3.1: (2007) ^[18] SHA-256/384/512の標準ハッシュ値を修正しました。
• 6.3.2: (2007) ^[19]文書化された圧縮方法97（WavPack）。
• 6.3.3: (2012) ^[20] JTC 1/SC 34 N 1621の指示に従って、JTC 1参照説明レポート(RER)などの方法を使用して、他の標準からPKWAREアプリケーションノートを参照しやすくするために文書の書式が変更されました。
• 6.3.4: (2014) ^[21] PKWARE, Inc.のオフィス住所を更新しました。
• 6.3.5: (2018) ^[22]圧縮方式16、96、99、DOSタイムスタンプのエポックと精度を文書化し、キーと復号化用の追加フィールドを追加し、タイプミスと説明を修正しました。
• 6.3.6: (2019) ^[23]誤植を修正しました。
• 6.3.7: (2020) ^[24] Zstandard圧縮方式ID20を追加しました。
• 6.3.8: (2020) ^[25] Zstandard圧縮方式IDを20から93に移動しました。前者は非推奨です。方式ID94と95（それぞれMP3とXZ）を文書化しました。
• 6.3.9: (2020) ^[26]データストリームアライメントの説明の誤字を修正しました。
• 6.3.10: (2022) ^[27]付録Bにいくつかのz/OS属性値を追加しました。サードパーティの追加フィールドマッピングをいくつか追加しました。

WinZip はバージョン12.1以降、DEFLATEよりも新しい圧縮方式、具体的にはBZip、LZMA、PPMd、Jpeg、Wavpackを使用するZIPファイルに拡張子.zipxを使用します。最後の2つは、「最適な方法」圧縮が選択されたときに適切なファイルタイプに適用されます。^{[28] [29]}

2010年4月、ISO/IEC JTC 1は、 ZIPと互換性のあるISO/IEC国際標準フォーマットを作成するプロジェクトを開始すべきかどうかを決定するための投票を開始しました。^[30] Document Packagingと題された提案されたプロジェクトは、OpenDocument、Office Open XML、EPUBなどの既存の標準規格での使用に適した、ZIPと互換性のある「最小限の圧縮アーカイブフォーマット」を想定していました。

2015年にISO/IEC 21320-1「ドキュメントコンテナファイル - パート1：コア」が発行され、「ドキュメントコンテナファイルはZipファイルに準拠している」と規定されています。ZIPファイル形式には、主に以下の制限が課されています。^[31]

• ZIP アーカイブ内のファイルは、圧縮されていない状態で、または「deflate」圧縮を使用してのみ保存できます (つまり、圧縮方法には、保存された値「0」または圧縮された値「8」が含まれます)。
• 暗号化機能は禁止されています。
• デジタル署名機能 (SES から) は禁止されています。
• 「パッチされたデータ」機能（PKPatchMaker から）は禁止されています。
• アーカイブは複数のボリュームにまたがったり、セグメント化したりすることはできません。

.ZIPファイルは、複数のファイルを保存するアーカイブです。ZIP では、ファイルを圧縮せずに保存するだけでなく、さまざまな方法で圧縮することもできます。各ファイルは別々に保存されるため、同じアーカイブ内の異なるファイルをさまざまな方法で圧縮できます。ZIP アーカイブ内のファイルは個別に圧縮されるため、アーカイブ全体に圧縮や解凍を適用せずに、ファイルを抽出したり、新しいファイルを追加したりできます。これは、このようなランダム アクセス処理が簡単にはできない 圧縮されたtarファイルの形式とは対照的です。

ディレクトリは ZIP ファイルの末尾に配置されます。これにより、ZIP に含まれるファイルと、そのファイルが ZIP 内のどこにあるのかが識別されます。これにより、ZIP リーダーは ZIP アーカイブ全体を読み込まなくても、ファイルの一覧を読み込むことができます。ZIP アーカイブには、ZIP アーカイブに関係のない追加データも含まれる場合があります。これにより、ZIP アーカイブの先頭にプログラム コードを追加し、ファイルを実行可能としてマークすることで、ZIP アーカイブを自己解凍アーカイブ (含まれているデータを解凍するアプリケーション) にすることができます。最後にカタログを保存することで、GIF 画像ファイルなどの無害なファイルに ZIP ファイルを付加して非表示にすることもできます。

.ZIP形式は32 ビット CRC アルゴリズムを使用し、各エントリ メタデータのコピーを 2 つ含むため、データ損失に対する保護が強化されます。CRC-32 アルゴリズムは David Schwaderer によって提供され、Howard W. Sams & Co. Inc. が発行した著書「C Programmers Guide to NetBIOS」に記載されています。^[32]

ZIP ファイルは、新しいファイルを簡単に追加できるように、アーカイブ構造の末尾に配置されている中央ディレクトリの終了レコードの存在によって正しく識別されます。中央ディレクトリの終了レコードが空でないアーカイブを示している場合、アーカイブ内の各ファイルまたはディレクトリの名前を、エントリに関するその他のメタデータ、および実際のエントリ データを指す ZIP ファイル内のオフセットとともに、中央ディレクトリエントリに指定する必要があります。これにより、ファイルのリストを表示するためにアーカイブ全体を読み取る必要がないため、アーカイブのファイル リストを比較的迅速に実行できます。ZIP ファイル内のエントリには、冗長性のために、ローカル ファイル ヘッダーにもこの情報が含まれています。ZIP ファイルに追加できるため、ファイルの末尾にある中央ディレクトリで指定されたファイルのみが有効です。ZIP ファイルのローカル ファイル ヘッダーをスキャンすることは無効です (アーカイブが破損している場合を除く)。中央ディレクトリは、一部のファイルが削除され、他のファイルが更新されたと宣言する可能性があるためです。

たとえば、ファイル A、B、C を含む ZIP ファイルがあるとします。その後、ファイル B が削除され、ファイル C が更新されます。これは、新しいファイル C を元の ZIP ファイルの末尾に追加し、ファイル A と新しいファイル C のみをリストする新しい中央ディレクトリを追加するだけで実現できます。ZIP が最初に設計されたときは、フロッピー ディスクでファイルを転送するのが一般的でしたが、ディスクへの書き込みには非常に時間がかかりました。複数のディスクにまたがる可能性のある大きな ZIP ファイルがあり、いくつかのファイルのみを更新する必要がある場合は、すべてのファイルを読み取って再書き込みするよりも、古い中央ディレクトリを読み取り、新しいファイルを追加してから更新された中央ディレクトリを追加する方がはるかに高速です。

中央ディレクトリ内のファイル エントリの順序は、アーカイブ内のファイル エントリの順序と一致する必要はありません。

ZIP アーカイブに保存される各エントリは、コメント、ファイル サイズ、ファイル名などのファイルに関する情報を含むローカル ファイル ヘッダーで始まり、その後にオプションの「追加」データ フィールド、そして圧縮または暗号化された可能性のあるファイル データが続きます。「追加」データ フィールドは、ZIP 形式の拡張性の鍵となります。「追加」フィールドは、ZIP64 形式、WinZip 互換の AES 暗号化、ファイル属性、および高解像度の NTFS または Unix ファイル タイムスタンプをサポートするために活用されます。「追加」フィールドを介して他の拡張も可能です。ZIP ツールは、仕様により、認識できない追加フィールドを無視する必要があります。

ZIP 形式では、ファイル内のさまざまな構造を示すために、特定の 4 バイトの「署名」が使用されます。各ファイル エントリは、特定の署名によってマークされます。中央ディレクトリ レコードの終了は、その特定の署名によって示され、中央ディレクトリ内の各エントリは、4 バイトの中央ファイル ヘッダー署名で始まります。

ZIP 仕様には BOF または EOF マーカーはありません。通常、ZIP ファイルの先頭は ZIP エントリであり、ローカル ファイル ヘッダー シグネチャによって簡単に識別できます。ただし、これは ZIP 仕様で必須ではないため、必ずしもそうであるとは限りません。特に、自己解凍アーカイブは実行可能ファイル ヘッダーで始まります。

ZIP アーカイブを正しく読み取るツールは、中央ディレクトリ レコードの署名の末尾をスキャンし、次に必要に応じて、指定された他の中央ディレクトリ レコードをスキャンする必要があります。ZIP ファイルの先頭からエントリをスキャンしてはなりません。これは、(このセクションで前述したように) 中央ディレクトリのみがファイル チャンクの開始位置を指定し、中央ディレクトリが削除されていないためです。この形式ではチャンク間に他のデータが存在することや、ファイル データ ストリームにそのような署名が含まれることが禁止されていないため、スキャンによって誤検知が発生する可能性があります。ただし、破損した ZIP アーカイブからデータを回復しようとするツールは、アーカイブをスキャンしてローカル ファイル ヘッダー署名を探す可能性が高くなります。ファイル チャンクの圧縮サイズがファイル チャンクの後に格納される可能性があるため、これはさらに困難になり、連続処理が困難になります。

署名のほとんどは、リトルエンディアン順序で保存される短い整数 0x4b50 で終わります。ASCII 文字列として表示すると、これは発明者 Phil Katz のイニシャルである「PK」と表示されます。したがって、ZIP ファイルをテキスト エディタで表示すると、ファイルの最初の 2 バイトは通常「PK」です。(DOS、OS/2、Windows の自己解凍型 ZIP では、 ZIP の前にEXEがあるため、「MZ」で始まります。他のオペレーティング システムの自己解凍型 ZIP も同様に、そのプラットフォームでアーカイブのコンテンツを抽出するための実行可能コードが先頭に付く場合があります。)

.ZIP仕様では、アーカイブを複数のファイル システム ファイルに分散することもサポートされています。この機能は、もともと複数のフロッピー ディスクにまたがる大きな ZIP ファイルを保存するために意図されていましたが、現在では、ZIP アーカイブを電子メール、その他のトランスポート、またはリムーバブル メディア経由で分割して送信するために使用されています。

DOS のFATファイルシステムのタイムスタンプ解像度は 2 秒のみです。ZIP ファイル レコードはこれを模倣しています。その結果、ZIP アーカイブ内のファイルの組み込みタイムスタンプ解像度は 2 秒のみですが、追加のフィールドを使用してより正確なタイムスタンプを保存できます。ZIP 形式にはタイム ゾーンの概念がないため、タイムスタンプは、どのタイム ゾーンで作成されたかがわかっている場合にのみ意味を持ちます。

2006年9月、PKWAREはZIP仕様の改訂版をリリースし、UTF-8を使用したファイル名の保存を可能にし、最終的にZIPにUnicode互換性を追加しました。^[17]

ヘッダー内のすべてのマルチバイト値は、リトルエンディアンのバイト順で保存されます。すべての長さフィールドは、長さをバイト単位でカウントします。

追加フィールドには、OS 固有の属性など、さまざまなオプション データが含まれます。これはレコードに分割され、各レコードは少なくとも 16 ビットの署名と 16 ビットの長さを持ちます。たとえば、ZIP64 ローカル ファイルの追加フィールド レコードには、署名 0x0001 と 16 バイト (またはそれ以上) の長さがあり、2 つの 64 ビット値 (非圧縮サイズと圧縮サイズ) が続く場合があります。もう 1 つの一般的なローカル ファイル拡張子は 0x5455 (または「UT」) で、これには 32 ビットの UTC UNIX タイムスタンプが含まれます。

その直後に圧縮データが続きます。

汎用フラグフィールドのオフセット 3 (0x08) のビットが設定されている場合、ヘッダーの書き込み時に CRC-32 とファイルサイズは不明です。アーカイブが Zip64 形式の場合、圧縮サイズフィールドと非圧縮サイズフィールドは 4 バイトではなく 8 バイト長になります (セクション 4.3.9.2 ^[34]を参照)。ローカルヘッダー (または Zip64 形式のアーカイブの場合は Zip64 拡張情報追加フィールド) の同等のフィールドはゼロで埋められ、CRC-32 とサイズは 12 バイト構造 (オプションで 4 バイトの署名が前に付く) で圧縮データの直後に追加されます。

中央ディレクトリ ファイルのヘッダー エントリは、ローカル ヘッダーの拡張形式です。

すべての中央ディレクトリ エントリの後に、ZIP ファイルの終わりを示す中央ディレクトリの終了 (EOCD) レコードが続きます。

この順序付けにより、ZIP ファイルを 1 回のパスで作成できますが、前述のように、複数の部分(「複数のフロッピー ディスク」など) のアーカイブからファイルを簡単に削除できるように、中央ディレクトリもファイルの最後に配置されます。

.ZIPファイルフォーマット仕様では、Store（圧縮なし）、Shrink（LZW）、Reduce（レベル1～4、LZ77 + 確率的）、Implode、Deflate、Deflate64、bzip2、LZMA、Zstandard、WavPack、PPMd 、およびIBM z/OS CMPSC命令で提供されるLZ77バリアントの圧縮方式が規定されています。 ^{[35] [27]}最も一般的に使用される圧縮方式はDEFLATEで、IETF RFC  1951 で説明されています。

仕様書には詳細が記載されていないが、言及されている他の方法としては、PKWARE DCL Implode（旧IBM TERSE）、新IBM TERSE、IBM LZ77 z Architecture（PFS）、JPEGバリアントなどがある。「Tokenize」メソッドはサードパーティ用に予約されていたが、サポートは追加されなかった。^[22]

Implode という言葉はPKWARE で多用されています。DCL/TERSE Implode は、Deflate の前身である古い PKZIP Implode とは異なります。DCL Implode は、IBM が所有しているため部分的に文書化されていませんが、Mark Adler はzlib とともに「blast」と呼ばれる解凍プログラムを提供しています。^[36]

ZIP は、一般的に ZipCrypto として知られる単純なパスワードベースの対称暗号化システムをサポートしています。これは ZIP 仕様で文書化されており、重大な欠陥があることが知られています。特に、既知平文​​攻撃に対して脆弱であり、乱数ジェネレータの実装が不十分な場合、状況が悪化することがあります。^[5]サードパーティのアーカイバなしでネイティブMicrosoft Windowsで実行されているコンピューターは、ZipCrypto で暗号化された ZIP ファイルを開くことはできますが、作成することはできません。また、異なる暗号化を使用したファイルの内容を抽出することはできません。^[37]

新しい圧縮および暗号化（例：AES ）方式を含む新機能は、バージョン5.2以降のZIPファイルフォーマット仕様に記載されています。WinZipが開発したAESベースのオープンスタンダード（APPNOTEでは「AE-x」）は、7-ZipやXceedでも使用されていますが、ベンダーによっては他のフォーマットを使用しています。^[38] PKWARE SecureZIP（SES、独自仕様）も、RC2、RC4、DES、トリプルDES暗号化方式、デジタル証明書ベースの暗号化と認証（X.509）、アーカイブヘッダー暗号化をサポートしています。ただし、特許を取得しています（§ 強力な暗号化論争を参照）。^[39]

ファイル名の 暗号化は .ZIP ファイル形式仕様 6.2 で導入され、アーカイブの中央ディレクトリ部分に保存されているメタデータを暗号化しますが、ローカル ヘッダー セクションは暗号化されません。準拠したアーカイバは、中央ディレクトリ暗号化を使用すると、ローカル ヘッダー データを偽造できます。仕様のバージョン 6.2 では、ローカル ヘッダー内の圧縮方法と圧縮サイズ フィールドはまだマスクされていません。

オリジナルの.ZIP形式では、さまざまな項目 (ファイルの非圧縮サイズ、ファイルの圧縮サイズ、アーカイブの合計サイズ) に 4 GB (2 ^{32バイト) の制限があり、ZIP アーカイブ内のエントリ数は 65,535 (2 16} -1) に制限されていました。仕様のバージョン 4.5 (特定のツールのバージョン 4.5 と同じではありません) では、PKWARE はこれらの制限を回避するために「ZIP64」形式拡張機能を導入し、制限を 16  EB (2 ⁶⁴バイト) に増やしました。本質的には、ファイルに対して「通常の」中央ディレクトリ エントリを使用し、その後にオプションでより大きなフィールドを持つ「zip64」ディレクトリ エントリを使用します。^[40]

ローカル ファイル ヘッダー (LOC) と中央ディレクトリ ファイル ヘッダー (CDFH) の形式は、ZIP と ZIP64 で同じです。ただし、ZIP64 では、圧縮プログラムの判断でこれらのレコードに追加できる追加フィールドが指定されています。このフィールドの目的は、従来の LOC または CDFH レコードに収まらない値を格納することです。実際の値が ZIP64 追加フィールドに格納されていることを示すために、対応する LOC または CDFH レコードでそれらの値は 0xFFFF または 0xFFFFFFFF に設定されます。1 つのエントリが従来の LOC または CDFH レコードに収まらない場合は、そのエントリのみを ZIP64 追加フィールドに移動する必要があります。その他のエントリは従来のレコードに残すことができます。したがって、次の表に示すすべてのエントリが ZIP64 追加フィールドに格納されるわけではありません。ただし、エントリが表示される場合は、その順序は表に示すとおりである必要があります。

一方、ZIP64のEOCDのフォーマットは通常のZIPバージョンとは少し異なります。^[33]

また、これは必ずしもファイル内の最後のレコードではありません。End of Central Directory Locator (末尾に 20 バイト追加) が続きます。

Windows XP のファイルエクスプローラーは ZIP64 をサポートしていませんが、Windows Vista 以降のエクスプローラーはサポートしています。^{[要出典]同様に、DotNetZip、QuaZIP [41]}、Perl の IO::Compress::Zipなど、一部の拡張ライブラリも ZIP64 をサポートしています。Pythonの組み込み zipfile は 2.5 以降でサポートしており、3.4 以降ではデフォルトで ZIP64 に設定されています。[ ^42] OpenJDKの組み込み java.util.zip は、Java 7バージョンから ZIP64 をサポートしています。^[43] Android Java API は、Android 6.0 以降で ZIP64 をサポートしています。^{[44] Mac OS Sierra のアーカイブユーティリティは特に ZIP64 をサポートしておらず、 ZIP64が}必要な場合に破損したアーカイブを作成する可能性があります。^[45] ただし、Mac OS に付属の ditto コマンドは ZIP64 ファイルを解凍します。^{[46] ]} Mac OS のバージョンには、Zip64 をサポートする info-zip の zip および unzip コマンドライン ツールが付属しています。確認するには、zip -v を実行して「ZIP64_SUPPORT」を探します。

.ZIPファイル形式では、中央ディレクトリの後のファイル末尾に、最大65,535（2 ^{16 −1）バイトのデータを含むコメントを記述することができます。 [33]}また、中央ディレクトリはアーカイブ内の各ファイルの先頭からのオフセットを指定するため、最初のファイルエントリがゼロ以外のオフセットから始まる可能性がありますが、ツールによっては、オフセットゼロのファイルエントリで始まらないアーカイブファイルを処理できない場合があります。たとえば、プログラムgzipは、オフセットゼロにあるエントリであれば、.ZIPファイルからエントリを抽出できます。

これにより、ZIP アーカイブ データの前後に任意のデータが存在することが可能になります。また、ZIP アプリケーションでアーカイブを読み取ることができます。この副作用として、別の形式が末尾、先頭、または中間に任意のデータがあっても許容するのであれば、ZIP アーカイブとして機能し、別の形式としても機能するファイルを作成できます。WinZipでサポートされている形式の自己解凍アーカイブ(SFX) は、PKZIP AppNote.txt 仕様に準拠した実行可能 ( .exe ) ファイルであり、準拠する zip ツールまたはライブラリで読み取ることができるという点で、この機能を活用しています。

.ZIP形式、およびZIPの変形であるJAR形式のこの特性は、WebにアップロードされたGIF画像など、一見無害なファイル内に不正なコンテンツ（有害なJavaクラスなど）を隠すために悪用される可能性があります。このいわゆるGIFARエクスプロイトは、FacebookなどのWebアプリケーションに対する効果的な攻撃として実証されています。^[47]

.ZIPファイルの最小サイズは22 バイトです。このような空の zip ファイルには、End of Central Directory Record (EOCD) のみが含まれます。
[0x50,0x4B,0x05,0x06,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00]

アーカイブファイルとその中の個々のファイルの最大サイズは、標準ZIPでは4,294,967,295バイト（2 ³² −1 バイト、つまり4 GBマイナス1バイト）です。ZIP64の場合、最大サイズは18,446,744,073,709,551,615バイト（2 ⁶⁴ −1 バイト、つまり16 EBマイナス1バイト）です。^[48]

ZIP 形式には、シーク最適化 ZIP ファイル (SOZip) プロファイル^[49]が提案されています。このファイルには、SOZip 対応のリーダーが圧縮ファイル内で非常に高速なランダム アクセス (シーク) を実行できるように整理され、注釈が付けられた 1 つまたは複数の Deflate 圧縮ファイルが含まれています。SOZip を使用すると、事前の解凍なしに .zip ファイルから直接大きな圧縮ファイルにアクセスできます。これは、定期的に発行される ZLib ブロック フラッシュの使用と、圧縮されていないファイルのオフセットを圧縮ストリームのオフセットにマッピングする隠しインデックス ファイルを組み合わせています。この拡張機能を認識しない ZIP リーダーは、SOZip 対応ファイルを通常どおり読み取り、効率的なシーク機能をサポートする拡張機能を無視できます。

.ZIPファイル形式には、ファイル ヘッダー内に追加フィールド機能が含まれています。この機能は、既存の ZIP 仕様で定義されていない追加データを保存するために使用でき、フィールドを認識しない準拠アーカイバは、それらのフィールドを安全にスキップできます。ヘッダー ID 0 ～ 31 は、PKWARE が使用するために予約されています。残りの ID は、サードパーティ ベンダーが独自の用途で使用できます。

2003年にWinZip 9.0パブリックベータがリリースされたとき、WinZipは新しい仕様のドキュメントとともに、異なるファイル形式を使用した独自のAES-256暗号化を導入しました。 ^[50]暗号化標準自体は独自のものではありませんでしたが、PKWAREは2001年以来、PKZIPバージョン5.0および6.0で使用されていたStrong Encryption Specificaion (SES)を含めるようにAPPNOTE.TXTを更新していませんでした。WinZipの技術コンサルタントであるKevin KearneyとStuffIt製品マネージャーのMathew Covingtonは、PKWAREがSESを差し控えていると非難しましたが、PKZIPの最高技術責任者Jim Petersonは、証明書ベースの暗号化はまだ不完全であると主張しました。

もう一つの物議を醸した動きとして、PKWareは2003年7月16日にZIPと強力な暗号化を組み合わせて安全なファイルを作成する方法を説明した特許を申請した。^[51]

最終的に、PKWAREとWinZipは互いの製品をサポートすることに合意した。2004年1月21日、PKWAREはWinZipベースのAES圧縮形式のサポートを発表した。^[52] WinZipベータ版の後のバージョンでは、SESベースのZIPファイルをサポートできるようになった。^[53] PKWAREは最終的に、SESを文書化した.ZIPファイル形式仕様のバージョン5.2を一般に公開した。フリーソフトウェアプロジェクトの7-ZipもAESをサポートしているが、ZIPファイルではSESをサポートしていない（ POSIX ポートの p7zipも同様）。

WinZipでAES暗号化を使用する場合、圧縮方法は常に99に設定され、実際の圧縮方法はAES追加データフィールドに保存されます。^[54]対照的に、強力な暗号化仕様では、中央ディレクトリ暗号化を使用してメタデータをマスク/暗号化しない限り、圧縮方法はローカルヘッダーと中央ディレクトリの基本ファイルヘッダーセグメントに保存されます。

利用可能な.ZIPツールは数多くあり、さまざまなプログラミング環境向けの.ZIPライブラリも数多くあります。使用されるライセンスには、プロプライエタリソフトウェアとフリー ソフトウェアがあります。WinZip 、WinRAR、Info-ZIP、ZipGenius、7-Zip、PeaZip、B1 Free Archiverは、さまざまなプラットフォームで利用できるよく知られた.ZIPツールです。これらのツールの一部には、ライブラリ インターフェイスまたはプログラム インターフェイスがあります。

オープンソース契約に基づいてライセンスされている開発ライブラリには、 libzip、libarchive、Info-ZIP などがあります。Java の場合: Java Platform, Standard Editionには、標準の.ZIPファイルを処理するためのパッケージ「java.util.zip」が含まれています。Zip64File ライブラリは特に大きなファイル (4 GB を超える) をサポートし、ランダム アクセスを使用して.ZIPファイルを処理します。Apache Antツールには、 Apache Software Licenseに基づいてリリースされたより完全な実装が含まれています。

.ZIP形式の Info-ZIP 実装では、ユーザーIDやグループ ID、ファイル権限、シンボリック リンクのサポートなど、Unix ファイルシステムの機能のサポートが追加されています。Apache Ant実装では、これらの機能を認識しており、定義済みの Unix 権限でファイルを作成できます。Info-ZIP 実装では、 .ZIP圧縮形式に組み込まれているエラー修正機能の使用方法も認識しています。一部のプログラムではこの機能が認識されず、エラーのあるファイルでは失敗します。

Info-ZIP Windows ツールはNTFS ファイルシステムの権限もサポートしており、ファイルを抽出するときに NTFS 権限から Unix 権限へ、またはその逆の変換を試みます。これにより、実行権限が拒否された NTFS ボリューム上に.exeファイルが作成されるような、予期しない組み合わせが発生する可能性があります。

Microsoft Windows のバージョンには、 Windows 98 用のMicrosoft Plus!パックがリリースされて以来、エクスプローラーでの.ZIP圧縮のサポートが含まれています。Microsoft はこの機能を「圧縮フォルダー」と呼んでいます。Windows の圧縮フォルダー機能では、すべての.ZIP機能がサポートされているわけではありません。たとえば、Windows 10 Home エディションでは暗号化はサポートされていませんが、 ^[55]復号化は可能です。Unicode エントリ エンコーディングはWindows 7までサポートされていません。分割アーカイブやスパン アーカイブは圧縮フォルダー機能で読み取りも書き込みもできません。また、AES 暗号化もサポートされていません。^{[56] Windows の .zip サポートは、} Dave Plummerが作成した「VisualZip」の買収に端を発しています。^{[57] [58] [59]}

OpenDocument Format (ODF) は 2005 年に zip アーカイブ形式の使用を開始しました。ODF はあらゆる種類のオフィス文書のオープン フォーマットであり、Collabora Online、LibreOfficeなどで使用される既定のファイル形式です。^{[60] Microsoft Office は 2006 年に}Office Open XML .docx、.xlsx、.pptx などのファイル に zip アーカイブ形式の使用を開始し、 Microsoft Office 2007で既定のファイル形式になりました。

6.3.0より前のバージョンのフォーマットでは、ファイル名をUnicodeで保存することはサポートされていませんでした。^[61]標準によれば、^{[61]ファイル名は}IBM PCの標準であるCP437エンコーディングで保存する必要がありますが、^[61]実際には、DOSアーカイバはシステムにインストールされている文字エンコーディングを使用していました。 Windows 11までの組み込みアーカイバも、アーカイブを作成するときに下位互換性のために、選択したシステム言語に対応するDOSエンコーディングを使用していました。 その後、標準は更新され、ファイル名をUnicodeで保存するための2つのオプションが含まれるようになりました。1) 汎用ビットフラグフィールドの11番目のビットが設定されている場合、ヘッダーの「ファイル名」フィールドのファイル名は、シングルバイトエンコーディングではなくUTF-8と見なす必要があります。 2) ファイル名をUTF-8エンコーディングで保存するために、Unicodeパス追加フィールドが追加されました。^[61] Windowsプラットフォーム上のアーカイバの一部のバージョンでは、過去にANSIエンコーディングも使用されていました。したがって、英語以外の文字を含む名前のファイルを正しく抽出するには、次のことが必要です。^[62]

1. Unicode パス追加フィールドの存在を確認し、存在する場合は、UTF-8 でエンコードされたファイル名を使用します。
2. 汎用ビット フラグ フィールドにフラグ 11 が存在するかどうかを確認し、フラグ 11 が設定されている場合は、「ファイル名」フィールドのファイル名のエンコードが UTF-8 であると見なします。
3. 「パッキング OS」フィールドに値 11 (NTFS、Windows) が含まれており、「パッカーのバージョン」フィールドの値が 20 以上である場合、「ファイル名」フィールドのファイル名エンコーディングは、システム ロケールに対応する ANSI (Windows) エンコーディングであると判断できます (それ以外の場合)。それ以外の場合は、CP437 を使用します。
4. 「パッキング OS」フィールドに値 0 (FAT、DOS) が含まれており、「パッカーのバージョン」フィールドの値が 25 から 40 までの間である場合、ローカル ヘッダーの「ファイル名」フィールドのファイル名エンコーディングは ANSI (Windows) エンコーディングであるとみなされ、中央ヘッダーの「ファイル名」フィールドのファイル名エンコーディングは OEM (DOS) エンコーディングであるとみなされます (システム ロケールが特定できる場合)。それ以外の場合は、CP437 を使用します。
5. それ以外の場合、「OS パッキング」フィールドに値 0 (FAT、DOS)、6 (HPFS、OS/2)、または 11 (NTFS、Windows) が含まれている場合は、「ファイル名」フィールドのファイル名エンコーディングを、システム ロケールが判別できる場合はそれに対応する OEM (DOS) エンコーディングと見なします。それ以外の場合は、CP437 を使用します。
6. それ以外の場合は、「ファイル名」フィールドのファイル名のエンコーディングは、アンパッカーが実行されているオペレーティング システムのシステム エンコーディングであるとみなします。

zip解凍ソフトの中にはこのアルゴリズムを実装していないものや部分的にしか実装していないものもあり、その結果、アーカイブの内容を表示したり解凍したりすると、アルファベットの文字ではなく「mojibake」と呼ばれる混沌とした文字セットが表示される。2016年、この問題はLinux、BSD、Mac用のfar2lファイルおよびアーカイブマネージャで解決された。^{[63] 2024年には、} Debianディストリビューションおよびその派生版で使用される7zipのバージョンと、 Ubuntuディストリビューションおよびその派生版で使用されるunzipのバージョンに同様の解決策が追加された^[64]。^[62]

名前の一部に「zip」を使用する標準や形式は他にも多数あります。たとえば、 zip はgzipとは異なり、後者はIETF RFC  1952 で定義されています。 zip と gzip はどちらも、主に圧縮にDEFLATEアルゴリズムを使用します。同様に、 ZLIB形式 (IETF RFC  1950) も DEFLATE 圧縮アルゴリズムを使用しますが、エラーと一貫性のチェックに別のヘッダーを指定します。その他の一般的な、同様の名前の形式や、ネイティブ形式が異なるプログラムには、7-Zip、bzip2、rzipなどがあります。

生のDEFLATEストリームの理論上の最大圧縮率は約1032対1ですが^[65]、ZIP形式を意図しない方法で利用することで、圧縮率が数十億対1のZIPアーカイブを作成できます。これらのZIP爆弾は、非常に大きなサイズに解凍され、解凍先のコンピュータの容量を圧倒します。^[66]

• ファイルアーカイバの比較
• アーカイブ形式の比較
• アーカイブ形式のリスト

• .ZIP アプリケーション ノート 2017 年 7 月 17 日にアーカイブされたWayback MachineのPKWARE の現在の .ZIP ファイルと過去の .ZIP ファイルのランディング ページ
• ISO/IEC 21320-1:2015 — ドキュメントコンテナファイル — パート1: コア
• Zip ファイル: 歴史、説明、実装
• 縮小、縮小、そして崩壊: 従来の Zip 圧縮方法
• APPNOTE.TXTミラー
• PKZip ファイルの構造 フォーマット仕様、グラフィカルな表