ZIP (ファイルフォーマット)

ZIP

拡張子	.zip .zipx (WinZip固有の拡張子)
MIMEタイプ	application/zip
UTI	com.pkware.zip-archive
マジック ナンバー	PK\003\004 PK\005\006（空のアーカイブ） PK\007\008（またがったアーカイブ）
開発者	フィル・カッツ, PKWARE
種別	データ圧縮
拡張	EAR、 EPUB、 JAR、 Office Open XML、 OpenDocument、 RAR (Java)、 WAR、 XPI
国際標準	PKWARE が提供する APPNOTE ISO/IEC 21320-1:2015

ZIP（ジップ）は、データ圧縮やアーカイブのフォーマット。Windowsでよく使用されるフォーマットである。

概要

ZIPファイルフォーマット（以下ZIPフォーマット、またはZIP）は複数のファイルを一つのファイルとしてまとめて取り扱うアーカイブフォーマットであり、1つ以上のファイルが格納されているものである。必要に応じて各種ある圧縮アルゴリズムを選択・使用し、ファイルサイズを圧縮して格納することも可能である。

ZIPフォーマットは1989年にフィル・カッツが考案したもので、トム・ヘンダーソンが考案したそれまでのARCフォーマットに置き換わるものとして、PKWAREのPKZIPユーティリティ に実装された。 ZIPフォーマットは現在多くのユーティリティによってサポートされている（ファイルアーカイバのリストを参照）。オペレーティングシステムでのサポートとしては、マイクロソフトがWindows 98以降の各バージョンに「圧縮フォルダー」という名前でZIPの機能を組み込んでいるほか、AppleもMac OS X v10.3以降に他の圧縮フォーマットも含めてZIPの機能を組み込んでいる。

ZIPファイルは一般的に ".zip" か ".ZIP" といった拡張子が付けられる。MIMEタイプはapplication/zip。ZIPフォーマットは、圧縮伸長を主目的としない多くのアプリケーションでも使用されているが、その際、拡張子には個々のアプリケーション固有に ".zip" とは異なる名前が用いられていることが多い。例えば、Java Archiveの拡張子は ".jar"であるが、このフォーマットの実態はZIPフォーマットである。他の具体例については「#ソフトにおける固有の拡張子」節を参照のこと。

歴史

「zip」 （「速さ」を意味する） という名前はフィル・カッツの友人であるロバート・マホーニーの提案によるものであり、従来から有るARCやその他の圧縮フォーマットの圧縮時間よりも、自分たちのプロダクトの方が速いということをほのめかすという意図を持っていた。

ZIPファイルフォーマット仕様は、PKZIP0.9のパッケージに同梱されていたファイルで初めて公開された。

ZIPフォーマットはオープンフォーマットとしてパブリックドメインでリリースされたものであり、ZIPフォーマットは誰しもが自由に利用でき、個人、団体、組織、あらゆる形態の利用において法的にもモラル的にも全く制約はない。

PKWAREもまた基本フォーマットをパブリックドメインとしており、誰でもZIPファイルを扱うアプリケーションを開発することができる。同じ見解がFLOSS Info-ZIPバージョンのプロダクトに付属するUNIX/LINUXドキュメント内でも見られる。そのドキュメントではzipファイルフォーマット、圧縮フォーマット、.ZIPの拡張子やファイルフォーマットへの小さな変更をパブリックドメインに置いたフィル・カッツへの感謝の念を示している。

起源

→詳細は「フィル・カッツ」を参照

ZIPファイルフォーマットはPKWAREのフィル・カッツが考案し、PKZIPで実装された。ちなみにカッツは以前に「PKXARC」なるアーカイブ・ユーティリティーを公開していたが、システム・エンハンス・アソシエイツ社のARCというユーティリティの著作権を著しく侵害しているとして民事訴訟を起こされている。

よく似た名前のフォーマット

名前の一部に「zip」という名前を使った標準化仕様やフォーマットがたくさんある。同じDeflate圧縮アルゴリズムを使用していながら、ヘッダー・フッターの異なる物としては、gzip (RFC 1952) や zlib (RFC 1950) などがある。その他、よく似た名前の異なるファイルフォーマットや圧縮アルゴリズムとして7z、bzip2、rzipなどがある。

バージョン履歴

.ZIPファイルフォーマット仕様にはバージョン番号がある。しかし、それは必ずしもPKZIPツールのバージョン番号とは対応せず、特にPKZIPバージョン 6以降がそれに該当する。PKWAREは、 PKZIP製品が先進的な機能を利用してアーカイブを展開できるように予備的な機能を幾度も追加している。しかし、そのようなアーカイブを作成するPKWARE仕様はPKZIPの次の主要なリリースまで公開されない。他の会社や組織は自分たちのペースでPKWAREの仕様をサポートしている。

PKWARE仕様による各バージョンの主な機能は以下の通り。

• 2.0: ファイルエントリをDeflateで圧縮可能となった。
• 4.5: 64ビットZIPフォーマットが記載された。
• 5.0: DES、Triple DES、RC2、RC4を暗号化のためにサポートした。
• 5.2: RC2-64を暗号化のためにサポートした。
• 6.1: 承認されたストレージについて記載した。
• 6.2.0: セントラルディレクトリの暗号化について記載した。
• 6.3.0: Unicode (UTF-8) ファイル名のストレージについて記載した。サポートされるハッシュ、圧縮、暗号化アルゴリズムが追加された。
• 6.3.1: SHA-256 / 384 / 512の標準的なハッシュ値に訂正した。
• 6.3.2: 圧縮メソッド 97 (WavPack) について記載した。

WinZipのバージョン12.1からDeflateよりも新しい圧縮メソッド、特にBZipやLZMA、PPMd、Jpeg、Wavpackのメソッドを使用したファイルの拡張子に.zipxが使用されている。JpegとWavPackは「最適メソッド」圧縮が選択されたときに適切なファイル種別に対して適用されている。

標準化

2010年4月ISO/IEC JTC 1で、ZIP互換のISO / IECの国際標準フォーマットを作成するために開始されるプロジェクトを決めるための投票が行われた。「ドキュメントパッケージング」という表題で提案されたプロジェクトはOpenDocument、Office Open XMLやEPUBを含む既存の標準規格の利用に適したZIP互換の最小圧縮アーカイブフォーマットと考えられる。そして2015年、ISO/IEC 21320-1:2015 Information technology — Document Container File — Part 1: Coreが制定された。

現在のZIPフォーマットはオープンフォーマットの要求仕様にあわないことがある。それは目に見える形で公開されたコミュニティ駆動開発を通して開発されていないからである。オープンな産業機構や標準化団体が賛同してメンテナンスされているものでもない。現在の ZIP フォーマットの一部は フリー なファイルフォーマットの要求仕様にあっていない。誰もが ZIP フォーマットを、如何なる目的であっても金銭的な負担がなく利用できるようにするため、著作権、特許、商標などの制約がない。 [1] PKWARE サイトにある最新の資料は、著作権表示があるが、フォーマット仕様とその機能拡張がパブリックドメインに置かれていることを認めている。[2]

技術的な情報

ZIPは複数のファイルを格納するシンプルなアーカイブフォーマットである。圧縮はzipアーカイブのオプションであり、圧縮が行われる場合はファイル単位に圧縮される。

ZIPは、データの破損に備えて優れた保護機構を提供するため、32ビットのCRCアルゴリズムを利用し、またアーカイブのディレクトリ構造を2箇所に含んでいる。

構造

ZIPファイルはファイルの最後に置かれるセントラルディレクトリの終端レコード（EOCD）の存在によって正しく認識される。この仕組みにより、新たなファイルを追加することが容易である。ZIPファイルに格納されているエントリ（ファイルまたはディレクトリ）数がゼロで無い場合、格納されている各エントリの名前、エントリに関するその他のメタデータ、ZIPファイル内でエントリデータが位置するオフセットが、セントラルディレクトリエントリに記載される。これにより、ファイルリストを参照するためにアーカイブ全体を読み込む必要がないため、アーカイブのファイルリストを比較的速く表示することが可能である。また冗長性の確保のため、各エントリも、エントリ情報をローカルファイルヘッダとして保持している。zipファイルには後からファイルが追加されることもあるため、ファイルの最後にあるセントラルディレクトリに載っているファイルだけが、正しいファイルである。セントラルディレクトリが、いくつかのファイルは削除された、あるい更新された、と宣言していることもありうるため、ZIPファイル全体を検索してローカルファイルヘッダを探しても、正しい情報は得られない（ただし、アーカイブが破損している場合は、そのような探索は役に立つだろう）。

セントラルディレクトリ内でのファイルエントリの順番は、アーカイブの中での実際のファイルエントリの順番と同じである必要はない。

ZIPファイル内のそれぞれのエントリは、ローカルファイルヘッダ（コメント、ファイルサイズやファイル名などの情報を含む）と、オプションの 「拡張」 データフィールドと、ファイルデータそのもの（圧縮されたり暗号化されている場合もある）で構成されている。「拡張」フィールドは、ZIP64フォーマット、WinZip互換のAES暗号化、ファイル属性やより詳細なNTFSやUnixファイルのタイムスタンプをサポートするために使用される。その他にも「拡張」フィールドを使用して機能拡張することが可能。認識しない拡張フィールドを無視するための機能をZIPツールに組み込む必要がある。

ZIPフォーマットはファイル内の様々な構造を表すために、特定の4バイトの「シグネチャ」を使用する。それぞれのファイルエントリは、ある特定のシグネチャによって目印が付けられる。セントラルディレクトリの終端レコードは、それ用のシグネチャでマークされ、セントラルディレクトリ内の各エントリは別の特定の4バイトシグネチャによって目印が付けられる。

ZIPの仕様にはBOFもしくはEOFといった目印がない。慣例として、ZIPファイルの最初にはZIPエントリが置かれ、そのシグネチャによって簡単にそれとわかる。しかし、ZIPの仕様においては、ZIPエントリで始まる必要はなく、特に、自己解凍型のアーカイブは、実行可能なファイルヘッダで始まる。

ZIPアーカイブを正しく読み込むには、まず初めにセントラルディレクトリの終端レコードのシグネチャを探し、次に、適宜、他のセントラルレコードを探索する必要がある。ファイルチャンクが開始する場所を特定するのはセントラルディレクトリのみであるため、ZIPファイルの頭からエントリを検査すべきではない。ただし、破損したZIPアーカイブからデータを修復するためのツールは、ローカルヘッダシグネチャを探索するのが普通である。この場合、ファイルチャンクの後ろにファイルチャンクの圧縮サイズが格納されることが、シーケンシャルな処理を困難にしている。

また ZIPの仕様では、複数のファイルシステムにまたがって分散したアーカイブを扱うこともサポートしている。現在この機能は、ZIPアーカイブを分割してメールなどで送ったり、リムーバブルメディアで持ち運ぶのに使用されている。

DOSのFATファイルシステムは2秒単位でタイムスタンプを保持し、ZIPファイルレコードはこれを模倣している。結果として、ZIPアーカイブ内にあるファイルのタイムスタンプも2秒単位で丸められる。但し、より正確なタイムスタンプを格納するために拡張フィールドを使用することができる。なお、ZIPフォーマットにはタイムゾーンという概念がないため、タイムスタンプが意味を持つのは、作成されたタイムゾーンを知っている場合だけである。

2007年9月にPKZIPは、UTF-8のファイル名を格納するための仕組みを含むZIP仕様のリビジョンをリリースした。それは最終的にZIPに対するユニコード互換を追加するものである。

ファイルヘッダ

全てのヘッダ内の複数バイトの値は、リトルエンディアンで格納される。全ての長さを示すフィールドは、バイト単位で数える。

ZIPローカルファイルヘッダ

オフセット	サイズ	内容
0	4	ローカルファイルヘッダのシグネチャ = 0x504B0304（PK\003\004）
4	2	展開に必要なバージョン (最小バージョン)
6	2	汎用目的のビットフラグ
8	2	圧縮メソッド
10	2	ファイルの最終変更時間
12	2	ファイルの最終変更日付
14	4	CRC-32
18	4	圧縮サイズ
22	4	非圧縮サイズ
26	2	ファイル名の長さ (n)
28	2	拡張フィールドの長さ (m)
30	n	ファイル名
30+n	m	拡張フィールド

拡張フィールドはOSに特化した属性のような様々なオプションデータを含む。それは16ビットIDと16ビット長のチャンクに分割される。

このヘッダの直後には圧縮データのデータが続く。

汎用目的のビットフラグフィールドの3ビット目がセットされている場合、ヘッダの書き込み時にはCRC-32とファイルサイズが不明である。ローカルヘッダのCRC-32とファイルサイズのフィールドにはゼロが書き込まれ、CRC-32とファイルサイズは圧縮データの後ろに12バイトのデータとして追加される。（オプションの4バイトのシグネチャが前に付く場合もある。）

Data descriptor

オフセット	サイズ	内容
0	0/4	（オプショナル） data descriptor シグネチャ = 0x08074b50
0/4	4	CRC-32
4/8	4	圧縮サイズ
8/12	4	非圧縮サイズ

セントラルディレクトリエントリはローカルファイルヘッダを拡張したものである。

セントラルディレクトリエントリ

オフセット	サイズ	内容
0	4	セントラルディレクトリエントリのシグネチャ = 0x504B0102（PK\001\002）
4	2	作成されたバージョン
6	2	展開に必要なバージョン (最小バージョン)
8	2	汎用目的のビットフラグ
10	2	圧縮メソッド
12	2	ファイルの最終変更時間
14	2	ファイルの最終変更日付
16	4	CRC-32
20	4	圧縮サイズ
24	4	非圧縮サイズ
28	2	ファイル名の長さ (n)
30	2	拡張フィールドの長さ (m)
32	2	ファイルコメントの長さ (k)
34	2	ファイルが開始するディスク番号
36	2	内部ファイル属性
38	4	外部ファイル属性
42	4	ローカルファイルヘッダの相対オフセット
46	n	ファイル名
46+n	m	拡張フィールド
46+n+m	k	ファイルコメント

全てのセントラルディレクトリエントリの後に、ZIPファイルの終わりを表すセントラルディレクトリの終端レコードが続く。

ZIPセントラルディレクトリの終端レコード(EOCD)

オフセット	サイズ	内容
0	4	セントラルディレクトリの終端レコードのシグネチャ = 0x504B0506（PK\005\006）
4	2	このディスクの数
6	2	セントラルディレクトリが開始するディスク
8	2	このディスク上のセントラルディレクトリレコードの数
10	2	セントラルディレクトリレコードの合計数
12	4	セントラルディレクトリのサイズ (バイト)
16	4	セントラルディレクトリの開始位置のオフセット
20	2	ZIPファイルのコメントの長さ (n)
22	n	ZIPファイルのコメント

この順番により、ZIPファイルをワンパスで作成することができるが、通常、展開では最後のセントラルディレクトリを最初に読み込むことになる。

圧縮メソッド

現在のZIPファイルフォーマット仕様では次のメソッドの詳細が記載されている。

• stored（無圧縮）
• Shrunk
• Reduced（メソッド 1-4）
• Imploded
• Tokenizing
• Deflated
• Deflate64
• BZIP2
• LZMA (EFS)
• WavPack
• PPMd

最も一般的な圧縮メソッドはDEFLATEでIETF RFC 1951に記載されている。

圧縮メソッドに挙げられていても、PKWARE Data Compression Library (DCL) Imploding (old IBM TERSE), IBM TERSE (new), IBM LZ77 z Architecture (PFS) の仕様の詳細は記載されていない。

暗号化

→「§ 強力な暗号化についての議論」も参照

ZIPはシンプルなパスワードベースの共通鍵暗号をサポートすると仕様に記載されている。但し、重大な脆弱性があることが知られている。特に、既知平文攻撃に対して脆弱性があり、貧弱なランダム数生成器の実装によってさらに安全性が低くなる場合もある。

バージョン5.2以降の.ZIPファイルフォーマット仕様には、圧縮 と 暗号化 (例えば AES) を含む新しい機能のメソッドが追加されている、と記載されている。WinZipはAESベースの標準規格を使用し、それは7-Zip、XCeedやDotNetZipでも使用されている。しかし、ベンダによっては他のフォーマットを使用するものである PKZIP また、SecureZIP は RC2, RC4, DES, Triple DES 暗号メソッド, 電子証明書ベースの暗号 / 認証 (X.509) やアーカイブヘッダ暗号化をサポートする。

ZIP64

オリジナルのZIPフォーマットは、ZIPアーカイブ内のエントリに 65535 の制限があるのと同様に、様々なサイズ（ファイルの圧縮/非圧縮サイズ、アーカイブの合計サイズ）に4 GiBの制限があった。仕様のバージョン4.5（それは特定ツールのバージョン4.5と同じではない） では、PKWAREはこういった制限を回避するために16 EiB（2⁶⁴ バイト）まで増加させた "ZIP64" フォーマット拡張を導入した。ZIP64サポートは新規に発生したものである。例えば、Windows XPのファイルエクスプローラーはZIP64をサポートしないが、 Windows Vistaのエクスプローラーではサポートする。同様にDotNetZipやPerlのIO::Compress::Zip、PythonのzipfileのようなライブラリはZIP64をサポートする。Javaの組み込みモジュールjava.util.zipは 2010年9月現在ではサポートしていない。今後、OpenJDKに追加されてJava 7への同梱を予定している。

長所と短所

ZIPファイルのようにファイルを分割して圧縮するとランダムアクセスが可能である。他のデータを読み込むことなく個々のファイルを取り出すことができる。DEFLATE圧縮の可能性を限定するときでさえ、それぞれのファイルのために違う辞書圧縮を利用するとアーカイブ全体のサイズをより小さくできることがある。

この圧縮の手法は一般的に小さなファイルが大量にあるときのアーカイブとしては適切ではない。ZIPアーカイブフォーマットでは、個々のエントリに関する情報を持つメタデータは圧縮しない。これは、特に個々のエントリのサイズを小さくして、そのエントリ向けのメタデータのサイズを扱うようにアーカイブ可能な最大圧縮比率を設けて制限されているためである。

別の手法としては 圧縮されたtarアーカイブ（.tar.gz または .tgz） が使用される。それはファイルデータとメタデータがgzipで圧縮される1つの単位として圧縮される。この手法の欠点はランダムアクセスの効率が悪くなってしまうことである。

ZIPと他のファイルフォーマットとの組み合わせ

ZIPファイルフォーマットでは、セントラルディレクトリの後（ファイルの末尾）に、65,535バイト以下のデータを入れることのできるコメント欄がある。また、セントラルディレクトリがアーカイブ内の各ファイルの開始位置を表すオフセットを指定しているため、最初のエントリがオフセットゼロの位置から開始していなくてもよい。（gzipのようないくつかのツールでは、ファイルエントリがオフセットゼロで始まらないようなZIPファイルを処理できないが。）つまり、ZIPアーカイブの前や後に任意のデータを配置しても、ZIPアプリケーションはそのアーカイブを読み込むことができる。

この事実を利用すると、ZIPアーカイブとしても、別のフォーマットとしても扱えるようなファイルを作成することができる。ただし、別のフォーマットでは、ファイルの最初か末尾かあるいは中ほどに任意のデータを配置できる必要がある。WinZipやDotNetZipがサポートするSelf-extracting archives (SFX) はこの利点を活用している。そういったファイルはPKZIP AppNote.txtの仕様に準拠した.exeファイルであり、規格に準拠したzipツールやライブラリで読み込むことができる。

ZIPフォーマットやZIPの亜種であるJARフォーマットが持つこのような特性は、一見普通のファイルに見えるが、コンピューター内部に害を及ぼすJavaクラスを隠すことに悪用できてしまう。例えば、ウェブにアップロードされるGIFイメージがある。これはGIFARと呼ばれる手法で、Facebookのようなウェブアプリケーションに対して効率的な攻撃として知られている。

実装

多くのZIPツールとZIPライブラリは様々なプログラミング環境の上で利用できる。ライセンスは商用やオープンソースのものがある。例えば、WinZipはWindows上で動作する有名なZIPツールである。他にも様々なプラットホームでWinRAR、IZarc、Info-ZIP、7-Zip、PeaZipやDotNetZip等が利用できる。これらのツールのいくつかはライブラリ、またはプログラミングインタフェースを持つ。

オープンソースで開発されているライブラリの例としてはGNUプロジェクトのgzipやInfo-ZIPがある。JavaではJava Platform, Standard Editionに標準的なzipファイルを扱う java.util.zip パッケージがある。Zip64Fileライブラリは特別に4GBを超える巨大なファイルをサポートして、ランダムアクセスを使用してZIPファイルを扱う。Apache AntツールにはApache Software Licenseでより完全なツールが実装されている。

.NETアプリケーションでは、.NET Framework 4.5で追加されたSystem.IO.Compression名前空間のZipArchiveクラスやZipFileクラスなどが使用できる。それ以前の場合、Microsoft Public License でソースとバイナリが利用できる DotNetZipと呼ばれる無償のオープンソースライブラリがある。従来のパスワードを用いたZIP暗号化、WinZip互換のAES暗号化、ユニコード、ZIP64、コメント、分割アーカイブ、自己展開アーカイブといった多くのZIP機能をサポートする。Microsoft .NET 3.5 ランタイムライブラリはZIPフォーマットをサポートするクラスSystem.IO.Packaging.Packageを含む。主としてISO/IEC国際標準Open Packaging Conventionsを使用するドキュメントフォーマットのために設計されている。

ZIPフォーマットのInfo-ZIP実装は、ユーザやグループID、ファイルパーミッション、シンボリックリンクのようなUnixファイルシステムの機能のサポートを追加する。Apache Antの実装はUnixパーミッションが事前に定義されたファイルを作成できる範囲に対して注意を払っている。Info-ZIPの実装もZIP圧縮フォーマットに組み込まれたエラー訂正機能の使用方法が分かっている。（IZarcのような）一部のプログラムはエラーがあるファイルの処理中に失敗する可能性がある。

また Info-ZIP WindowsツールもNTFSファイルシステムパーミッションをサポートする。展開時にNTFSパーミッションをUnixパーミッションへ、もしくはその逆へ変換しようとする。これは潜在的な意図しない結果をもたらすことがある。例として、NTFSボリューム上で実行権限を付けて作成された.exeファイルは拒否されることなどが挙げられる。

Windows 圧縮フォルダー

Windowsでは、Windows 98のためにリリースされたPlus!パック以降、エクスプローラーからZIP形式の圧縮と展開をサポートしている。マイクロソフトはこの機能を「圧縮フォルダー」と呼んでいる。圧縮フォルダーはZIPの機能を全てサポートしているわけではなく、例えばWindows 10ではAES暗号化、分割アーカイブ、パスワード付き圧縮などが行えない。また圧縮時にはシステムロケールが日本語に設定されたWindowsではファイル名にMicrosoftコードページ932を使用している。（Windows NT系の内部文字コード及びファイルシステムの文字コードはUnicodeであるが、互換性のためにMicrosoftコードページ932に変換している。変換できない文字が含まれるファイル名は圧縮できない。）展開時はhotfixを適用したWindows 7もしくはWindows 8以降でUTF-8に対応したため、ファイル名がMicrosoftコードページ932とUTF-8のどちらであっても問題なく展開できる。macOSのFinderでは原則として圧縮・展開ともにUTF-8を想定しているため、macOSで作成したZIPファイルはhotfixを適用したWindows 7以降であればで問題なく展開できるが、逆にWindowsで作成したZIPファイルをmacOSで展開するとファイル名によっては文字化けもしくはエラーとなる。（これはファイル名の話でファイルの内容には影響しない。）

強力な暗号化についての議論

2003年にWinZip 9.0パブリックベータをリリースしたとき、WinZipは独自のAES-256暗号を導入した。それは違うファイルフォーマットを用いた新たな仕様としてドキュメントに記載された。暗号の標準規格はプロプライエタリでは無いが、 PKWARE は2001年以降、PKZIP 5.0や6.0では使用されていた強力な暗号化仕様 (SES) を含めるようにAPPNOTE.TXTを更新しなかった。WinZipの技術コンサルタント Kevin KearneyやスタッフイットプロダクトマネージャMathew CovingtonはSESを差し控えるようにPKWAREを非難。これに対し、PKZIPチーフ技術オフィサーのJim Petersonは承認に基づく暗号化規格はまだ完全ではないと主張。しかし、バージョン 4.5の頃（PKWARE の FTP サイトで確認できる）に公開された最新のAPPNOTE.TXTには、SESだけではなく、同時期に存在したPKZIPプロダクトで作成された.ZIPファイルが用いたDeflate64、DCL Implode、BZip2も除外された。

この欠点を克服するためにPentaZipのような同時期に存在したプロダクトは違うファイルフォーマットにZIPアーカイブを暗号化する強力なZIP暗号化を実装した。

また別の議論では、PKWAREは2003年7月16日に安全な.ZIPファイルを作成するために強力な暗号と.ZIPを組み合わせるための方法を記載した特許を適用した。

結局PKWAREとWinZipはお互いのプロダクトをサポートすることに同意した。2004年1月21日にPKWAREはWinZipベースのAES互換フォーマットをサポートするとアナウンスした。WinZipベータの次のバージョンではSESベースのZIPファイルのサポートが行われた。PKWAREは最終的にSESを記載した.ZIPファイルフォーマット仕様のバージョン 5.2を公式にリリースした。フリーソフトウェア プロジェクト 7-Zipも（そのPOSIX 移植された p7zip が行うことで）ZIPファイルのAESをサポートしている。

ソフトにおける固有の拡張子

アプリケーション固有のファイル形式のなかには、あるファイルを一定のディレクトリの階層構造に格納しZIP形式で圧縮したものが存在する。そのようなファイルの大半はそのアプリケーション固有の物であることを示すために専用の拡張子を定義しており、以下に示す例はその一部である。ただし、圧縮アルゴリズムにzlibを使っているものでも、ZIP互換の格納方式を使っていないものは掲載しない。

apk

Android のアプリケーションアーカイブ

crx

Google ChromeやChromiumの拡張機能のアーカイブファイル

docx, xlsx, pptx

Microsoft Office（2007以降）の文書フォーマット (Office Open XML)

epub

IDPFが提唱する電子書籍の標準フォーマット

ipa

iPhoneシリーズをはじめとしたiOS搭載デバイス向けのアプリケーションアーカイブ

ipg

iPodゲームのアーカイブファイル

jar

Javaのアーカイブファイル

kmz

Google Earthの標準ファイル形式。kmlをZIP圧縮したもの。

nar

伺かのINSTALL/1.x仕様に準拠したアーカイブファイル

odt, ods, odp, odb, odg, odf

OpenDocumentの文書フォーマット

smzip

StepManiaの各種の自動インストール型パッケージファイル

wgt

W3C Packaged Web Apps (W3C Widgets) のパッケージファイル。Bada widget、Tizen Web application、Opera widget など。

wsz

Winamp用のスキンファイル

wmz

Windows Media Player用のスキンファイル

xpi

Mozilla Firefox（及びそれをベースとするNetscapeシリーズのウェブブラウザなど）やMozilla Thunderbirdなどの拡張機能（アドオン）のインストーラファイル (XPInstall)

3mf

3Dプリンター向けの3Dファイル

関連項目

• PKZIP
• アーカイブフォーマットのリスト
• Lempel–Ziv–Welch (LZW)
• ファイルアーカイバの比較
• WinZip
• DEFLATE
• Implode
• Bzip2
• 7-Zip
• PeaZip
• Info-ZIP
• LHA
• CAB
• DGCA
• GCA
• RAR
• ZIPボム
• tar

外部リンク

• RFC 1950 (zlib)
• RFC 1951 (Deflate)

• Judgment in favor of SEA in SEA v. PKWARE and Phil Katz
• Current file format specification from PKWARE (including many recent features that are not widely supported)
• Comparison of the performances of various methods of data compression (french)
• ZIP2 file format specification
• Zip Files All The Way Down
• ZIP File Quine
• Limitations of java.util.zip