ZIP (ファイルフォーマット)
読み:ジップ
外語:ZIP

 ファイルアーカイバーPKZIPで採用され、普及したアーカイブファイル形式の一つ。世界的なデファクトスタンダードの一つとなっている。
目次

情報

概要

由来等
 オリジナルのPKZIPは、Phillip Walter Katzにより作られたシェアウェアであった。またMicrosoft Windows用として作られたWinZipは製品である。
 但し、ZIPファイルフォーマットの仕様自体は無償で公開されており、PKZIPと互換のあるファイルを作成できるソフトウェアがオープンソースソフトウェアなどとしても広く流通している。
 ZIPファイルフォーマットには様々な圧縮アルゴリズムを含めることができるが、現在の主流は古くからあるDeflate方式である。ファイルを暗号化をすることもでき、標準の方法は古くからあるZipCryptoではあるが極めて脆弱で、ZIPファイルフォーマット自体はAES-128などに対応できる仕様に更新されているものの対応するソフトウェアは少ない。

ライブラリ
 ZIP形式で圧縮、アーカイブするためのライブラリは様々なものがある。
 日本国内で使われている主流は、次のものがある。
 庄田隆司版UNZIP32.DLLはフリーではないため、互換DLLがある。

特徴

仕様

RFC
 ZIPは、大きく器となるファイルフォーマットと圧縮アルゴリズムとに分けることができ、それぞれRFCとなっている。

フォーマット
 RFC 1950(ZLIB Compressed Data Format Specification version 3.3)は、zlibとして知られるデータ圧縮ライブラリで使われるファイルフォーマットの仕様
 このRFCでチェックサム計算「adler-32アルゴリズム」についても述べられている。
 しかし実際には、これを読んでも殆ど実装の役に立たない。PKWARE Inc.が公開していたAPPNOTE.TXTにフォーマットの詳細がある。
 なお、gzipのフォーマットはRFC 1952に書かれている。

Deflateアルゴリズム
 主流であるDeflateアルゴリズムは、RFC 1951に書かれている。
 PKZIPや互換ソフトウェアのほか、gzipなどでも使われている方式である。

ヘッダーの拡張
 元々MS-DOS用に作られたフォーマットであるため、ZIPファイルフォーマットのヘッダーには、もはやそのままでは時代遅れで使い物にならない情報欄が多々ある。
 日付と時刻のフィールドはMS-DOS形式の各2バイトであったり、CRC-32を格納する4バイトの欄があったりするほか、圧縮サイズや非圧縮サイズは4バイトしかない。当時はこれで充分だったが、いまでは不足する。
 そこで、こういった足りない情報を補うために、追加ヘッダーを挿入することが可能になっている。大きなファイルはヘッダーID 0x0001でファイルサイズが指定できたり、UNIXのユーザーID等はヘッダーID 0x000dを用いて格納したりできる。機能が不足するタイムスタンプの格納については0x0020が予約されているが使われている形跡がなく、NTFS用の0x000aで8バイト形式、UNIX用の0x000dで4バイト形式で、おのおののシステム向けのタイムスタンプ情報が格納できるようにはなっている。
 フォーマット仕様書6.3.9(2020(令和2)年7月15日)時点では以下がPKWAREによって予約されているとされる。
 また、以下がサードパーティーによって使用されていることが確認されているとされる。
 拡張されたヘッダーについては、対応するアプリでなければ当然処理できない。読み飛ばすことは可能だが、その内容に依存したデータが格納されている場合は、専用に対応したソフトウェアを用いなければそのファイルは利用できないことになる。

圧縮アルゴリズム
 ZIP形式の基本は、32Kスライド窓の「Deflate/Inflate compression」と呼ばれる、初段にハッシュを用いたLZSS、後段にハフマン符号を用いるLZ77の変形アルゴリズムである。
 日本のLZHUFと似たようなもので、DEFLATEについてはRFC 1951としてその仕様が公開されており、広く使われている。
 フォーマット仕様書6.3.9(2020(令和2)年7月15日)時点では以下に対応する。
 様々なアルゴリズムに対応しているが、互換性などの問題から、古くて性能も普通ながら、今もDeflateが主流として使われている。無圧縮のまま格納するときは0を使うが、1〜6についてはレガシーアルゴリズムであり、もはや推奨されない。

暗号化アルゴリズム
 書庫の暗号化も可能で、元々の暗号化(ZipCrypto)のほかに、拡張機能として様々な暗号化アルゴリズムにも対応する。当然、拡張された暗号化については、展開する側が対応していなければ復元することができない。
 ZIPファイルフォーマット内の各ヘッダー内にある汎用ビットフラグには、暗号化されている場合TRUEになるフラグに加えて、強力な暗号化を使用する場合TRUEになるフラグが存在する。
 強力な暗号化を使用する場合はその暗号化のIDを設定する仕様で、拡張性が考慮されている。フォーマット仕様書6.3.9(2020(令和2)年7月15日)時点では以下に対応する。
 現在はAESが使われている。AESの前は3DESが使われていた。

ハッシュアルゴリズム
 ZIPファイルフォーマットは、書庫内にファイルが正しく格納されているか、ダウンロード中に破損や改竄がされていないかを確認するために、ファイルのハッシュを記録する機能を有する。
 フォーマット仕様書6.3.9(2020(令和2)年7月15日)時点では以下に対応する。
 元々はCRC-32が使われていた。ダウンロー中に生じうる破損検出には当時でも今でもこれで充分ではあるが、改竄検出などでよりセキュアが求められる時代になり、様々なハッシュアルゴリズムに対応するようになった。

関連フォーマット
 拡張子は.zipではないが、ZIP形式(アルゴリズム、フォーマットの双方)を採用しているファイルフォーマットは多数確認されている。
 以下、確認されたもの(拡張子ABC順)。

再検索