ZIP（ファイル形式）

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

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

PKWAREソフトウェアおよび／または仕様の各種バージョンにおける主な進歩の概要：

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

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

2010 年 4 月、ISO/IEC JTC 1 は、 ZIP と互換性のある ISO/IEC 国際標準フォーマットを作成するプロジェクトを開始すべきかどうかを決定するための投票を開始しました。^{[ 33 ]}文書パッケージングと題された提案されたプロジェクトは、OpenDocument、Office Open XML、EPUBなど、既存の多くの標準で使用できる ZIP 互換の「最小限の圧縮アーカイブ フォーマット」を想定していました。これは、正式な標準の必要性、ZIP のさまざまな拡張機能、オープン スタンダードに使用される技術が独自の拡張機能や「潜伏」特許 (予期せず浮上する可能性がある) を持つ可能性の望ましくなさ、より良い国際化の必要性、PKWARE APPNOTE 文書の代替仕様を提供すると称して実際に技術をさらに細分化したくないという要望などの問題を解決するものでした。

2015年にISO/IEC 21320-1「ドキュメントコンテナファイル - パート1：コア」が発行され、PKWARE APPNOTE文書を規範的に参照し、「ドキュメントコンテナファイルは準拠したZipファイルである」と規定されています。ZIPファイル形式には以下の主な制限が課せられています。^{[ 34 ]}

• ZIPアーカイブ内のファイルは、非圧縮、または「deflate」圧縮（つまり、圧縮方法には「0」（保存）または「8」（圧縮）の値が含まれる）を使用してのみ保存できます。コアとなる「deflate」圧縮方法の特許は2010年末に失効しました。^{[ 35 ]}
• 暗号化機能は禁止されています。
• （SESの）デジタル署名機能は禁止されています。
• （PKPatchMakerの）「パッチ適用済みデータ」機能は禁止されています。
• アーカイブは複数巻にまたがったり、分割されたりしてはならない。

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

例えば、ファイル A、B、C を含む ZIP ファイルから始めるとします。次に、ファイル B を削除し、C を更新します。これは、元の ZIP ファイルの末尾に新しいファイル C を追加し、ファイル 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文字列として見ると、発明者フィル・カッツのイニシャルである「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はUTF-8を使用したファイル名の保存を可能にするZIP仕様の改訂版をリリースし、ついにZIPにUnicode互換性を追加した。^{[ 20 ]}

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

.ZIP ファイル形式仕様では、次の圧縮方法が文書化されています: Store (圧縮なし)、Shrink ( LZW )、Reduce (レベル 1～4、LZ77 + 確率的)、Implode、Deflate、Deflate64、bzip2、LZMA、Zstandard、WavPack、PPMd 、およびIBM z/OS CMPSC 命令によって提供される LZ77 バリアント。 ^{[ 39 ] [ 30 ]}最も一般的に使用される圧縮方法はDEFLATEであり、IETF RFC 1951で説明されています。 

仕様書には記載されていないが言及されている他の方法には、PKWARE DCL Implode (旧 IBM TERSE)、新IBM TERSE、IBM LZ77 z アーキテクチャ (PFS)、および JPEG バリアントがある。「Tokenize」メソッドはサードパーティ用に予約されていたが、サポートは追加されなかった。^{[ 25 ]}

PKWARE ではImplodeという単語が多用されています。DCL/TERSE Implode は、Deflate の前身である古い PKZIP Implode とは異なります。DCL Implode は IBM が所有する独自の性質のため、ドキュメント化されていませんが、Mark Adler はzlib とともに「blast」と呼ばれるデコンプレッサを提供しています。^{[ 40 ]}

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

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

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

オリジナルの.ZIPフォーマットでは、さまざまな項目（ファイルの非圧縮サイズ、圧縮ファイルサイズ、アーカイブの合計サイズ）に4 GiB（2 ³²バイト）の制限があり、ZIPアーカイブ内のエントリ数にも65,535（ 2 ¹⁶ - 1）の制限がありました。仕様のバージョン4.5（特定のツールのv4.5とは異なります）で、PKWAREはこれらの制限を回避するために「ZIP64」フォーマット拡張機能を導入し、制限を16 EiB（2 ⁶⁴バイト）に増やしました。基本的には、ファイルに対して「通常の」中央ディレクトリエントリを使用し、その後にオプションの「zip64」ディレクトリエントリを追加して、より大きなフィールドを持たせています。^{[ 44 ]}  

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

一方、ZIP64 の EOCD の形式は、通常の ZIP バージョンとは若干異なります。^{[ 37 ]}

EOCD64は必ずしもファイル内の最後のレコードではありません。その後に20バイトの中央ディレクトリ終端ロケータと、従来のEOCDレコードが続きます。

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

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

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

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

.ZIPファイルの最小サイズは22バイトです。このような空のzipファイルには、中央ディレクトリレコードの終了（EOCD）のみが含まれます。50 4B 05 06 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

^{標準ZIPの場合、}アーカイブファイルとその中に含まれる個々のファイルの最大サイズは4,294,967,295バイト（2³² - 1バイト、つまり4GiBから1バイトを引いた値）です。ZIP64の場合 、最大サイズは18,446,744,073,709,551,615バイト（2⁶⁴ - 1バイト、つまり16EiBから1バイトを引いた値）^です 。^{[ 52 ]}

6.3.0 より前のバージョンのフォーマットでは、ファイル名をUnicodeで保存することはサポートされていませんでした。^{[ 64 ]}標準によれば、^{[ 64 ]}ファイル名はIBM PCの標準であるCP437エンコーディングで保存する必要がありますが、^{[ 64 ]}実際には、DOSアーカイバはシステムにインストールされている文字エンコーディングを使用していました。Windows 11 までの組み込みアーカイバも、アーカイブを作成する際に、DOS との下位互換性のために、選択されたシステム言語に対応するシステムの「ANSI」エンコーディングを使用していました。

その後、Unicode でファイル名を格納するための 2 つのオプションを含むように標準が更新されました。1) 汎用ビットフラグフィールドの 11 番目のビットが設定されている場合、ヘッダーの「ファイル名」フィールドのファイル名は、シングルバイト エンコーディングではなくUTF-8として扱われるべきであり、2) ファイル名を UTF-8 エンコーディングで格納するために Unicode パス追加フィールドが追加されました。^{[ 64 ]}次のアルゴリズムは、新しい「ファイル名」フィールドと、英語以外の文字を含む名前のファイルを正しく抽出するための従来の慣行の両方を考慮しています。^{[ 65 ]}

1. Unicode Path Extra Field が存在するかどうかを確認し、存在する場合は、そこから UTF-8 でエンコードされたファイル名を使用します。
2. 汎用ビットフラグフィールドにフラグ11が存在するかどうかを確認し、それが設定されている場合は、「ファイル名」フィールドのファイル名エンコーディングをUTF-8とみなします。
3. 「packing OS」フィールドに値11（NTFS、Windows）が含まれており、「version of the packer」フィールドの値が20以上の場合、「ファイル名」フィールドのファイル名エンコーディングは、システムロケールに対応するANSI（Windows）エンコーディングであるとみなします（判別可能な場合）。そうでない場合は、CP437を使用します。
4. 「packing OS」フィールドに値0（FAT、DOS）が含まれており、「version of the packer」フィールドの値が25～40（両端を含む）の場合、ローカルヘッダーの「ファイル名」フィールドのファイル名エンコーディングはANSI（Windows）エンコーディング、中央ヘッダーの「ファイル名」フィールドのファイル名エンコーディングは、システムロケールが特定できる場合はそれに対応するOEM（DOS）エンコーディングとみなします。そうでない場合は、CP437を使用します。
5. その他の場合、「OS パッケージング」フィールドに値 0 (FAT、DOS)、6 (HPFS、OS/2)、または 11 (NTFS、Windows) が含まれている場合は、「ファイル名」フィールドのファイル名エンコーディングを、システムロケールが特定できる場合はそれに対応する OEM (DOS) エンコーディングとみなします。そうでない場合は、CP437 を使用します。
6. その他のすべての場合において、「ファイル名」フィールドに表示されているファイル名のエンコーディングは、アンパッカーが実行されているオペレーティングシステムのシステムエンコーディングとみなしてください。

ファイル名のデコードに誤ったエンコーディングが使用されると、ユーザーは各国のアルファベットの代わりに「文字化け」と呼ばれる文字の羅列を目にすることになります。上記のアルゴリズムは、このような事態を避けるために最大限の努力を払っています。「システムロケール」と「システムエンコーディング」の代わりに、一部のプログラムではユーザーが希望する非Unicodeエンコーディングを選択できるようになっています。

2016年に、この問題はLinux、BSD、Mac用のfar2lファイルおよびアーカイブマネージャで解決されました^{。[ 66 ] 2024}年には、同様の解決策がDebianディストリビューションとその派生ディストリビューションで使用されている7zipのバージョン、およびUbuntu^{ディストリビュー}ションとその派生ディストリビューションで使用されているunzipのバージョンに追加されました。^{[ 67] [ 65 ]}