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のパッケージに同梱されていたファイルAPPNOTE.TXTで初めて公開された。
ZIPフォーマットはオープンフォーマットとしてパブリックドメインでリリースされたものであり、ZIPフォーマットは誰しもが自由に利用でき、個人、団体、組織、あらゆる形態の利用において法的にもモラル的にも全く制約はない。
PKWAREもまた基本フォーマットをパブリックドメインとしており、誰でもZIPファイルを扱うアプリケーションを開発することができる。同じ見解がFOSS Info-ZIPバージョンのプロダクトに付属するUNIX/Linuxドキュメント内でも見られる。そのドキュメントではzipファイルフォーマット、圧縮フォーマット、.ZIPの拡張子やファイルフォーマットへの小さな変更をパブリックドメインに置いたフィル・カッツへの感謝の念を示している。
起源
ZIPファイルフォーマットはPKWAREのフィル・カッツが考案し、PKZIPで実装された。ちなみにカッツは以前に「PKXARC」なるアーカイブ・ユーティリティを公開していたが、システム・エンハンス・アソシエイツ社のARCというユーティリティの著作権を著しく侵害しているとして民事訴訟を起こされている。
よく似た名前のフォーマット 名前の一部に「zip」という名前を使った標準化仕様やフォーマットがたくさんある。同じDeflate圧縮アルゴリズムを使用していながら、ヘッダー・フッターの異なる物としては、gzip () や zlib ()などがある。その他、よく似た名前の異なるファイルフォーマットや圧縮アルゴリズムとして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のメソッドを使用したファイルの拡張子にが使用されている。JpegとWavPackは「最適メソッド」圧縮が選択されたときに適切なファイル種別に対して適用されている。
標準化 2010年4月ISO/IEC JTC 1で、ZIP互換のISO / IECの国際標準フォーマットを作成するために開始されるプロジェクトを決めるための投票が行われたhttps://web.archive.org/web/20110501115847/http://www.itscj.ipsj.or.jp/sc34/open/1414.pdf。「ドキュメントパッケージング」という表題で提案されたプロジェクトはOpenDocument、Office Open XMLやEPUBを含む既存の標準規格の利用に適したZIP互換の最小圧縮アーカイブフォーマットと考えられる。そして2015年、ISO/IEC 21320-1:2015 Information technology — Document Container File — Part 1: Coreが制定された。
現在のZIPフォーマットはオープンフォーマットの要求仕様にあわないことがある。それは目に見える形で公開されたコミュニティ駆動開発を通して開発されていないからである。オープンな産業機構や標準化団体が賛同してメンテナンスされているものでもない。現在のZIPフォーマットの一部は自由なファイルフォーマットの要求仕様にあっていない。誰もがZIPフォーマットを、如何なる目的であっても金銭的な負担がなく利用できるようにするため、著作権、特許、商標などの制約がない。 PKWAREサイトにある最新の資料は、著作権表示があるが、フォーマット仕様とその機能拡張がパブリックドメインに置かれていることを認めている。
技術的な情報 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フォーマットは、チャンク間に他のデータを含めることや、シグネチャと同じ4バイト列を含むようなデータを禁止していないため、そのようなスキャンは誤検出（フォールス・ポジティブ）を起こすだろう。 ただし、破損したZIPアーカイブからデータを修復するためのツールは、ローカルヘッダシグネチャを探索するのが普通である。この場合、ファイルチャンクの後ろにファイルチャンクの圧縮サイズが格納されることが、シーケンシャルな処理を困難にしている。
またZIPの仕様では、複数のファイルシステムにまたがって分散したアーカイブを扱うこともサポートしている。もともとは、複数の1.44MBフロッピーディスクにまたがった大きなzipファイルの格納を目的としていた。現在この機能は、ZIPアーカイブを分割してメールなどで送ったり、リムーバブルメディアで持ち運ぶのに使用されている。
DOSのFATファイルシステムは2秒単位でタイムスタンプを保持し、ZIPファイルレコードはこれを模倣している。結果として、ZIPアーカイブ内にあるファイルのタイムスタンプも2秒単位で丸められる。但し、より正確なタイムスタンプを格納するために拡張フィールドを使用することができる。なお、ZIPフォーマットにはタイムゾーンという概念がないため、タイムスタンプが意味を持つのは、作成されたタイムゾーンを知っている場合だけである。
2007年9月にPKZIPは、UTF-8のファイル名を格納するための仕組みを含むZIP仕様のリビジョンをリリースした。それは最終的にZIPに対するユニコード互換を追加するものであるhttp://www.pkware.com/documents/casestudies/APPNOTE.TXT。
ファイルヘッダ 全てのヘッダ内の複数バイトの値は、リトルエンディアンで格納される。全ての長さを示すフィールドは、バイト単位で数える。
+ 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 に記載されている。
圧縮メソッドに挙げられていても、PKWARE Data Compression Library (DCL) Imploding (old IBM TERSE), IBM TERSE (new), IBM LZ77 z Architecture (PFS)の仕様の詳細は記載されていない。
暗号化
ZIPはシンプルなパスワードベースの共通鍵暗号をサポートすると仕様に記載されている。但し、重大な脆弱性があることが知られている。特に、既知平文攻撃に対して脆弱性があり、貧弱なランダム数生成器の実装によってさらに安全性が低くなる場合もあるStay, Michael. "ZIP Attacks with Reduced Known Plaintext". https://math.ucr.edu/~mike/zipattacks.pdf。
バージョン5.2以降の.ZIPファイルフォーマット仕様には、圧縮 と 暗号化 (例えば AES) を含む新しい機能のメソッドが追加されている、と記載されている。WinZipはAESベースの標準規格を使用し、それは7-Zip、XCeedやDotNetZipでも使用されている。しかし、ベンダによっては他のフォーマットを使用するものであるAES Encryption Information: Encryption Specification AE-1 and AE-2PKZIPまた、SecureZIP は RC2, RC4, DES, Triple DES 暗号メソッド, 電子証明書ベースの暗号 / 認証 (X.509) やアーカイブヘッダ暗号化をサポートするApplication Note on the .ZIP file format。
ZIP64 オリジナルのZIPフォーマットは、ZIPアーカイブ内のエントリに65535の制限があるのと同様に、様々なサイズ（ファイルの圧縮/非圧縮サイズ、アーカイブの合計サイズ）に4 GiBの制限があった。仕様のバージョン4.5（それは特定ツールのバージョン4.5と同じではない）では、PKWAREはこういった制限を回避するために16 EiB（264 バイト）まで増加させた"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のようなウェブアプリケーションに対して効率的な攻撃として知られているA photo that can steal your online credentials。
実装 多くの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 http://www.codeplex.com/DotNetZip/license でソースとバイナリが利用できる DotNetZiphttp://www.codeplex.com/DotNetZipと呼ばれる無償のオープンソースライブラリがある。従来のパスワードを用いたZIP暗号化、WinZip互換のAES暗号化、ユニコード、ZIP64、コメント、分割アーカイブ、自己展開アーカイブといった多くのZIP機能をサポートする。Microsoft .NET 3.5ランタイムライブラリはZIPフォーマットをサポートするクラスSystem.IO.Packaging.Packagehttps://learn.microsoft.com/en-us/dotnet/api/system.io.packaging.package?view=windowsdesktop-9.0&redirectedfrom=MSDNを含む。主として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に変換している。変換できない文字が含まれるファイル名は圧縮できない。）展開時はhotfixFile names are corrupted after you decompress a .zip file in Windows 7 or in Windows Server 2008 R2を適用したWindows 7もしくはWindows 8以降でUTF-8に対応したため、ファイル名がMicrosoftコードページ932とUTF-8のどちらであっても問題なく展開できる。
パスワード付きZIPファイルの脆弱性 パスワード付きZIPファイルの暗号化方式として、最も標準的なのはTraditional PKWARE Encryption (ZipCrypto)であり、Windows 11のファイルエクスプローラで復元できるのもこの方式だけである。しかし、Traditional PKWARE Encryption (ZipCrypto) は暗号化方式としては脆弱であり、bkcrack などのツールを使うと、普通のパソコンで数分程度で暗号が解けてしまうので、暗号化方式としては無意味である。
強力な暗号化についての議論