ZIP（ジップ）は、データ圧縮やアーカイブのフォーマット。パーソナルコンピュータでは一般的なフォーマットである。ZIPファイルフォーマット（以下ZIPフォーマット、またはZIP）は複数のファイルを一つのファイルとしてまとめて取り扱うアーカイブフォーマットであり、1つ以上のファイルが格納されているものである。必要に応じて各種ある圧縮アルゴリズムを選択・使用し、ファイルサイズを圧縮して格納することも可能である。ZIPフォーマットは1989年にフィル・カッツが考案したもので、が考案したそれまでのフォーマットに置き換わるものとして、のユーティリティに実装された。ZIPフォーマットは現在多くのユーティリティによってサポートされている（を参照）。オペレーティングシステムでのサポートとしては、マイクロソフトがWindows 98以降の各バージョンに「圧縮フォルダー」という名前でZIPの機能を組み込んでいるほか、アップルもMac OS X v10.3以降に他の圧縮フォーマットも含めてZIPの機能を組み込んでいる。ZIPファイルは一般的に ".zip" か ".ZIP" といった拡張子が付けられる。MIMEタイプはcodice_1。ZIPフォーマットは、圧縮伸長を主目的としない多くのアプリケーションでも使用されているが、その際、拡張子には個々のアプリケーション固有に ".zip" とは異なる名前が用いられていることが多い。例えば、Java Archiveの拡張子は ".jar"、伺か用アーカイブファイルの拡張子は ".nar" であるが、これらのフォーマットの実態は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" という名前を使った標準化仕様やフォーマットがたくさんある。フィル・カッツはどんなアーカイブ種別でも "zip" という名前を使って良いと表明した。同じDeflate圧縮アルゴリズムを使用していながら、ヘッダー・フッターの異なる物としては、gzip (RFC 1952) や zlib (RFC 1950) などがある。その他、よく似た名前の異なるファイルフォーマットや圧縮アルゴリズムとして7z、bzip2、などがある。.ZIPファイルフォーマット仕様にはバージョン番号がある。しかし、それは必ずしもPKZIPツールのバージョン番号とは対応せず、特にPKZIPバージョン 6以降がそれに該当する。PKWAREは、 PKZIP製品が先進的な機能を利用してアーカイブを展開できるように予備的な機能を幾度も追加している。しかし、そのようなアーカイブを作成するPKWARE仕様はPKZIPの次の主要なリリースまで公開されない。他の会社や組織は自分たちのペースでPKWAREの仕様をサポートしている。PKWARE仕様による各バージョンの主な機能は以下の通り。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互換の"最小圧縮アーカイブフォーマット"と考えられる。現在のZIPフォーマットはオープンフォーマットの要求仕様にあわないことがある。それは "目に見える形で公開されたコミュニティ駆動開発" を通して開発されていないからである。"オープンな産業機構" や "標準化団体が賛同してメンテナンスされている" ものでもない。現在の ZIP フォーマットの一部は フリー なファイルフォーマットの要求仕様にあっていない。"誰もが ZIP フォーマットを、如何なる目的であっても金銭的な負担がなく利用できるようにするため、著作権、特許、商標などの制約がない。" PKWARE サイトにある最新の資料は、著作権表示があるが、"フォーマット仕様" とその機能拡張がパブリックドメインに置かれていることを認めている。ZIPは複数のファイルを格納するシンプルなアーカイブフォーマットである。圧縮はzipアーカイブのオプションであり、圧縮が行われる場合はファイル単位に圧縮される。ZIPは32ビットのCRCアルゴリズムを使用し、データの破損に備えて優れた保護機構を提供するためにアーカイブのディレクトリ構造のコピーを2つ持っている。ZIPファイルはファイルの最後に置かれる"セントラルディレクトリ"の存在によって認識される。この仕組みにより、セントラルディレクトリの後ろに新たなファイルを追加することが可能である。そのディレクトリはZIPファイルに格納されたエントリ（ファイルまたはディレクトリ）の名前のリスト、エントリに関するその他のメタデータ、ZIPファイルへのオフセット、実際のエントリデータへのポインタを格納している。これにより、ファイルリストを参照するためにアーカイブ全体を読み込む必要がないため、アーカイブのファイルリストを比較的速く表示することが可能である。またZIPファイルに格納されているエントリも冗長性の確保のためにこの情報を持っている。ディレクトリのファイルエントリの順番はそのアーカイブのファイルエントリの順番と同じであるとは限らない。それぞれのエントリはローカルヘッダにそのファイルの情報を保持している。コメント、ファイルサイズやファイル名、オプションの 「拡張」 データフィールド、あるいは圧縮、あるいは暗号化されたファイルデータ等で構成されている。「拡張」 フィールドはZIP64フォーマット、WinZip互換のAES暗号化、ファイル属性やより詳細なNTFSやUnixファイルのタイムスタンプをサポートするために使用される。その他にも「拡張」フィールドを使用して機能拡張することが可能。認識しない拡張フィールドを無視するための機能をZIPツールに組み込む必要がある。ZIPフォーマットはファイル内の様々な構造を表すために特別な4バイトの「シグネチャ」を使用する。それぞれのファイルエントリは特別なシグネチャによって目印が付けられる。セントラルディレクトリの開始位置は違うシグネチャで表される。セントラルディレクトリ内の各エントリはまた別の特別な4バイトのシグネチャによって目印が付けられる。ZIPの仕様にはBOFもしくはEOFといった目印がない。多くの場合、ZIPファイルの最初にあるデータがZIPエントリであり、そのシグネチャによって簡単に認識できる。但し、ZIPファイルはZIPエントリを最初に置く必要はなく、ZIPの仕様においても必要としていない。ZIPアーカイブを正しく読み込むツールは様々なフィールドやセントラルディレクトリのシグネチャを検査する必要がある。そのディレクトリのみがファイルチャンクを開始する場所を特定するので、そういったツールでエントリを検査する必要はない。ZIPフォーマットはチャンク間に他のデータを含められるのでファイルの検査処理はフォールス・ポジティブになるだろう。 また ZIPの仕様では複数のファイルシステムのファイルにアクセスしてアーカイブを扱うこともサポートされている。もともとは複数の1.44MBフロッピーディスク にアクセスすることによる、巨大なzipファイルの格納を目的としていた。現在、この機能は分割されたzipアーカイブをメールで送信したり、その他の転送方法やリムーバブルメディアで使用されている。DOSのFATファイルシステムは2秒単位でタイムスタンプを保持する。ZIPファイルはこの仕組みを模倣している。結果としてZIPアーカイブ内にあるファイルのタイムスタンプも2秒単位で丸められる。但し、より正確なタイムスタンプを格納するために拡張フィールドを使用することができる。2007年9月にPKZIPはUTF-8のファイル名を格納するための仕組みを含むZIP仕様のリビジョンをリリースした。それは最終的にZIPに対するユニコード互換を追加するものである。拡張フィールドはOSに特化した属性のような様々なオプションデータを含む。それは16ビットIDと16ビット長のチャンクに分割される。圧縮データの後ろにデータが続くときがある。汎用目的のビットフラグフィールドの3ビット目がセットされている場合、ヘッダの書き込み時にCRC-32とファイルサイズが分からないことがある。そして、圧縮データの後ろに12バイトのデータを追加する。ローカルヘッダのCRC-32とファイルサイズのフィールドはゼロが書き込まれる。セントラルディレクトリファイルヘッダはローカルファイルヘッダを拡張したもの。全てのローカルディレクトリエントリの最後に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 暗号メソッド, Digital Certificate ベースの暗号 / 認証 (X.509) やアーカイブヘッダ暗号化をサポートする。オリジナルの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に追加されてへの同梱を予定している。ZIPファイルのようにファイルを分割して圧縮するとランダムアクセスが可能である。他のデータを読み込むことなく個々のファイルを取り出すことができる。DEFLATE圧縮の可能性を限定するときでさえ、それぞれのファイルのために違う辞書圧縮を利用するとアーカイブ全体のサイズをより小さくできることがある。この圧縮の手法は一般的に小さなファイルが大量にあるときのアーカイブとしては適切ではない。ZIPアーカイブフォーマットでは、個々のエントリに関する情報を持つメタデータは圧縮しない。これは、特に個々のエントリのサイズを小さくして、そのエントリ向けのメタデータのサイズを扱うようにアーカイブ可能な最大圧縮比率を設けて制限されているためである。別の手法としては 圧縮されたtarアーカイブ（codice_2 または codice_3） が使用される。それはファイルデータとメタデータがgzipで圧縮される1つの単位として圧縮される。この手法の欠点はランダムアクセスの効率が悪くなってしまうことである。ZIPファイルフォーマットにはセントラルディレクトリの後に続くファイルの最後にどんなデータでも含められるコメントがある。さらに、セントラルディレクトリはアーカイブ内の各ファイルの開始位置を表すオフセットを指定するため、最初のファイルエントリへの開始位置に対してゼロ以外のオフセットをセットすることが可能である。この仕組みにより、ZIPアーカイブの前後どちらでも任意のデータを配置できる上にZIPアプリケーションがそのアーカイブを読み込める。この仕組みの短所はZIPアーカイブと他のフォーマットの両方を1つのファイルに追加できるということである。ZIPアーカイブの最後か最初、もしくは中間のどの位置でも他のフォーマットを許容して任意のデータを提供することが可能。WinZipやDotNetZipがサポートする (SFX) はこの利点を活用している。そういったファイルはPKZIP AppNote.txtの仕様に準拠した.exeファイルであり、規格に準拠したzipツールやライブラリで読み込むことができる。ZIPフォーマットやZIPの亜種であるJARフォーマットの特性は、一見普通のファイルに見えるが、コンピューター内部に害を及ぼすJavaクラスを隠して悪用することが出来てしまう。例えば、ウェブにアップロードされるGIFイメージがある。これはGIFARと呼ばれる手法でFacebookのようなウェブアプリケーションに対して効率的な攻撃として知られている。多くのZIPツールとZIPライブラリは様々なプログラミング環境の上で利用できる。ライセンスは商用やオープンソースのものがある。例えば、WinZipはWindows上で動作する有名なZIPツールである。他にも様々なプラットホームでWinRAR、、、7-Zip、PeaZipやDotNetZip等が利用できる。これらのツールのいくつかはライブラリ、またはプログラミングインタフェースを持つ。オープンソースで開発されているライブラリの例としてはGNUプロジェクトのgzipやがある。JavaではJava Platform, Standard Editionに標準的なzipファイルを扱う "java.util.zip" パッケージがある。Zip64Fileライブラリは特別に4GBを超える巨大なファイルをサポートして、ランダムアクセスを使用してZIPファイルを扱う。Apache AntツールにはApache Software Licenseでより完全なツールが実装されている。.NETアプリケーションでは、Microsoft Public License でソースとバイナリが利用できる DotNetZipと呼ばれる無償のオープンソースライブラリがある。従来のパスワードを用いたZIP暗号化、WinZip互換のAES暗号化、ユニコード、ZIP64、コメント、分割アーカイブ、自己展開アーカイブといった多くのZIP機能をサポートする。Microsoft .NET 3.5 ランタイムライブラリはZIPフォーマットをサポートするクラスSystem.IO.Packaging.Packageを含む。主としてISO/IEC国際標準を使用するドキュメントフォーマットのために設計されている。ZIPフォーマットの実装は、ユーザやグループID、ファイルパーミッション、シンボリックリンクのようなUnixファイルシステムの機能のサポートを追加する。Apache Antの実装はUnixパーミッションが事前に定義されたファイルを作成できる範囲に対して注意を払っている。Info-ZIPの実装もZIP圧縮フォーマットに組み込まれたエラー訂正機能の使用方法が分かっている。（のような）一部のプログラムはエラーがあるファイルの処理中に失敗する可能性がある。また Info-ZIP WindowsツールもNTFSファイルシステムパーミッションをサポートする。展開時にNTFSパーミッションをUnixパーミッションへ、もしくはその逆へ変換しようとする。これは潜在的な意図しない結果をもたらすことがある。例として、NTFSボリューム上で実行権限を付けて作成された.exeファイルは拒否されることなどが挙げられる。マイクロソフト Windowsの各バージョンはWindows 98のためにリリースされたPlus!パック以降、エクスプローラーからZIP圧縮をサポートしている。マイクロソフトはこの機能を「圧縮フォルダー」と呼んでいる。Windows 圧縮フォルダーは全てのZIPの機能をサポートしていない。例えば、Windows XPまたはWindows Vistaの圧縮フォルダーでは読み書きできないユニコードエントリ、ZIP64、AES暗号化、分割アーカイブ等がある。そのため、日本語版Windowsではファイル名をMicrosoftコードページ932でエンコードしている。また、Mac OS XのFinder（UTF-8でエンコード）で作成したアーカイブをWindowsで復元すると、ファイル名によっては文字化けする。内容には影響しない。Windows→Macでは問題ない。現在この問題に対応するhotfixが配布されている。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 移植された が行うことで）ZIPファイルのAESをサポートしている。アプリケーション固有のファイル形式のなかには、あるファイルを一定のディレクトリの階層構造に格納しZIP形式で圧縮したものが存在する。そのようなファイルの大半はそのアプリケーション固有の物であることを示すために専用の拡張子を定義しており、以下に示す例はその一部である。ただし、圧縮アルゴリズムにzlibを使っているものでも、ZIP互換の格納方式を使っていないものは掲載しない。

出典:wikipedia