ZIP (ファイルフォーマット)
ZIP（ジップ）は、データ圧縮やアーカイブのフォーマット。Windowsでよく使用されるフォーマットである[1]。 概要ZIPファイルフォーマット（以下ZIPフォーマット、またはZIP）は複数のファイルを一つのファイルとしてまとめて取り扱うアーカイブフォーマットであり、1つ以上のファイルが格納されているものである。必要に応じて各種ある圧縮アルゴリズムを選択・使用し、ファイルサイズを圧縮して格納することも可能である。[要出典] ZIPフォーマットは1989年にフィル・カッツが考案したもので、トム・ヘンダーソンが考案したそれまでのARCフォーマットに置き換わるものとして、PKWAREのPKZIPユーティリティ [2]に実装された。 ZIPフォーマットは現在多くのユーティリティによってサポートされている（ファイルアーカイバのリストを参照）。オペレーティングシステムでのサポートとしては、マイクロソフトがWindows 98以降の各バージョンに「圧縮フォルダー」という名前でZIPの機能を組み込んでいるほか、AppleもMac OS X v10.3以降に他の圧縮フォーマットも含めてZIPの機能を組み込んでいる。[要出典] ZIPファイルは一般的に ".zip" か ".ZIP" といった拡張子が付けられる。MIMEタイプは 歴史「zip」 （「速さ」を意味する） という名前はフィル・カッツの友人であるロバート・マホーニーの提案によるものであり、従来から有るARCやその他の圧縮フォーマットの圧縮時間よりも、自分たちのプロダクトの方が速いということをほのめかすという意図を持っていた。[要出典] ZIPファイルフォーマット仕様は、PKZIP0.9のパッケージに同梱されていたファイル[3]で初めて公開された。 ZIPフォーマットはオープンフォーマットとしてパブリックドメインでリリースされたものであり、ZIPフォーマットは誰しもが自由に利用でき、個人、団体、組織、あらゆる形態の利用において法的にもモラル的にも全く制約はない[4]。 PKWAREもまた基本フォーマットをパブリックドメインとしており、誰でもZIPファイルを扱うアプリケーションを開発することができる。同じ見解がFOSS 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仕様による各バージョンの主な機能は以下の通り。
WinZipのバージョン12.1からDeflateよりも新しい圧縮メソッド、特にBZipやLZMA、PPMd、Jpeg、Wavpackのメソッドを使用したファイルの拡張子に.zipxが使用されている。JpegとWavPackは「最適メソッド」圧縮が選択されたときに適切なファイル種別に対して適用されている[5][6]。 標準化
2010年4月ISO/IEC JTC 1で、ZIP互換のISO / IECの国際標準フォーマットを作成するために開始されるプロジェクトを決めるための投票が行われた[7]。「ドキュメントパッケージング」という表題で提案されたプロジェクトは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に対するユニコード互換を追加するものである[8]。 ファイルヘッダ全てのヘッダ内の複数バイトの値は、リトルエンディアンで格納される。全ての長さを示すフィールドは、バイト単位で数える。[要出典]
拡張フィールドはOSに特化した属性のような様々なオプションデータを含む。それは16ビットIDと16ビット長のチャンクに分割される。[要出典] このヘッダの直後には圧縮データのデータが続く。[要出典] 汎用目的のビットフラグフィールドの3ビット目がセットされている場合、ヘッダの書き込み時にはCRC-32とファイルサイズが不明である。ローカルヘッダのCRC-32とファイルサイズのフィールドにはゼロが書き込まれ、CRC-32とファイルサイズは圧縮データの後ろに12バイトのデータとして追加される。（オプションの4バイトのシグネチャが前に付く場合もある。）[要出典]
セントラルディレクトリエントリはローカルファイルヘッダを拡張したものである。[要出典]
全てのセントラルディレクトリエントリの後に、ZIPファイルの終わりを表すセントラルディレクトリの終端レコードが続く。[要出典]
この順番により、ZIPファイルをワンパスで作成することができるが、通常、展開では最後のセントラルディレクトリを最初に読み込むことになる。[要出典] 圧縮メソッド
現在のZIPファイルフォーマット仕様では次のメソッドの詳細が記載されている。
最も一般的な圧縮メソッドはDEFLATEでIETF RFC 1951に記載されている。 圧縮メソッドに挙げられていても、PKWARE Data Compression Library (DCL) Imploding (old IBM TERSE), IBM TERSE (new), IBM LZ77 z Architecture (PFS) の仕様の詳細は記載されていない。[要出典] 暗号化→「§ 強力な暗号化についての議論」も参照
ZIPはシンプルなパスワードベースの共通鍵暗号をサポートすると仕様に記載されている。但し、重大な脆弱性があることが知られている。特に、既知平文攻撃に対して脆弱性があり、貧弱なランダム数生成器の実装によってさらに安全性が低くなる場合もある[9]。 バージョン5.2以降の.ZIPファイルフォーマット仕様には、圧縮 と 暗号化 (例えば AES) を含む新しい機能のメソッドが追加されている、と記載されている。WinZipはAESベースの標準規格を使用し、それは7-Zip、XCeedやDotNetZipでも使用されている。しかし、ベンダによっては他のフォーマットを使用するものである[10] PKZIP また、SecureZIP は RC2, RC4, DES, Triple DES 暗号メソッド, 電子証明書ベースの暗号 / 認証 (X.509) やアーカイブヘッダ暗号化をサポートする[11]。 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への同梱を予定している[12]。 長所と短所
ZIPファイルのようにファイルを分割して圧縮するとランダムアクセスが可能である。他のデータを読み込むことなく個々のファイルを取り出すことができる。DEFLATE圧縮の可能性を限定するときでさえ、それぞれのファイルのために違う辞書圧縮を利用するとアーカイブ全体のサイズをより小さくできることがある。 この圧縮の手法は一般的に小さなファイルが大量にあるときのアーカイブとしては適切ではない。ZIPアーカイブフォーマットでは、個々のエントリに関する情報を持つメタデータは圧縮しない。これは、特に個々のエントリのサイズを小さくして、そのエントリ向けのメタデータのサイズを扱うようにアーカイブ可能な最大圧縮比率を設けて制限されているためである。 別の手法としては 圧縮されたtarアーカイブ（ ZIPと他のファイルフォーマットとの組み合わせZIPファイルフォーマットでは、セントラルディレクトリの後（ファイルの末尾）に、65,535バイト以下のデータを入れることのできるコメント欄がある[8]。また、セントラルディレクトリがアーカイブ内の各ファイルの開始位置を表すオフセットを指定しているため、最初のエントリがオフセットゼロの位置から開始していなくてもよい。（gzipのようないくつかのツールでは、ファイルエントリがオフセットゼロで始まらないようなZIPファイルを処理できないが。）つまり、ZIPアーカイブの前や後に任意のデータを配置しても、ZIPアプリケーションはそのアーカイブを読み込むことができる。[要出典] この事実を利用すると、ZIPアーカイブとしても、別のフォーマットとしても扱えるようなファイルを作成することができる。ただし、別のフォーマットでは、ファイルの最初か末尾かあるいは中ほどに任意のデータを配置できる必要がある。WinZipやDotNetZipがサポートするSelf-extracting archives (SFX) はこの利点を活用している。そういったファイルはPKZIP AppNote.txtの仕様に準拠した.exeファイルであり、規格に準拠したzipツールやライブラリで読み込むことができる。[独自研究?] ZIPフォーマットやZIPの亜種であるJARフォーマットが持つこのような特性は、一見普通のファイルに見えるが、コンピューター内部に害を及ぼすJavaクラスを隠すことに悪用できてしまう。例えば、ウェブにアップロードされるGIFイメージがある。これはGIFARと呼ばれる手法で、Facebookのようなウェブアプリケーションに対して効率的な攻撃として知られている[13]。 実装多くのZIPツールとZIPライブラリは様々なプログラミング環境の上で利用できる。ライセンスは商用やオープンソースのものがある。例えば、WinZipはWindows上で動作する有名なZIPツールである。他にも様々なプラットホームでWinRAR、IZarc、Info-ZIP、7-Zip、PeaZipやDotNetZip等が利用できる。これらのツールのいくつかはライブラリ、またはプログラミングインタフェースを持つ。[要出典] オープンソースで開発されているライブラリの例としてはGNUプロジェクトのgzipやInfo-ZIPがある。JavaではJava Platform, Standard Editionに標準的なzipファイルを扱う .NETアプリケーションでは、.NET Framework 4.5で追加されたSystem.IO.Compression名前空間のZipArchiveクラスやZipFileクラスなどが使用できる[14]。それ以前の場合、Microsoft Public License [15] でソースとバイナリが利用できる DotNetZip[16]と呼ばれる無償のオープンソースライブラリがある。従来のパスワードを用いたZIP暗号化、WinZip互換のAES暗号化、ユニコード、ZIP64、コメント、分割アーカイブ、自己展開アーカイブといった多くのZIP機能をサポートする。Microsoft .NET 3.5 ランタイムライブラリはZIPフォーマットをサポートするクラスSystem.IO.Packaging.Package[17]を含む。主として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[18]を適用したWindows 7もしくはWindows 8以降でUTF-8に対応したため、ファイル名がMicrosoftコードページ932とUTF-8のどちらであっても問題なく展開できる。macOSのFinderでは原則として圧縮・展開ともにUTF-8を想定しているため、macOSで作成したZIPファイルはhotfixを適用したWindows 7以降であればで問題なく展開できるが、逆にWindowsで作成したZIPファイルをmacOSで展開するとファイル名によっては文字化けもしくはエラーとなる。（これはファイル名の話でファイルの内容には影響しない。）[要出典] パスワード付きZIPファイルの脆弱性パスワード付きZIPファイルの暗号化方式として、最も標準的なのは Traditional PKWARE Encryption (ZipCrypto) であり、Windows 11のファイルエクスプローラで復元できるのもこの方式だけである[19]。しかし、Traditional PKWARE Encryption (ZipCrypto) は暗号化方式としては脆弱であり、bkcrack[20] などのツールを使うと、普通のパソコンで数分程度[21]で暗号が解けてしまうので、暗号化方式としては無意味である。 強力な暗号化についての議論2003年にWinZip 9.0パブリックベータをリリースしたとき、WinZipは独自のAES-256暗号を導入した。それは違うファイルフォーマットを用いた新たな仕様としてドキュメントに記載された[22]。暗号の標準規格はプロプライエタリでは無いが、 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暗号化を実装した[23]。 また別の議論では、PKWAREは2003年7月16日に安全な.ZIPファイルを作成するために強力な暗号と.ZIPを組み合わせるための方法を記載した特許を適用した[24]。 結局PKWAREとWinZipはお互いのプロダクトをサポートすることに同意した。2004年1月21日にPKWAREはWinZipベースのAES互換フォーマットをサポートするとアナウンスした[25]。WinZipベータの次のバージョンではSESベースのZIPファイルのサポートが行われた[26]。PKWAREは最終的にSESを記載した.ZIPファイルフォーマット仕様のバージョン 5.2を公式にリリースした。自由ソフトウェア プロジェクト 7-Zipも（そのPOSIX 移植された p7zip が行うことで）ZIPファイルのAESをサポートしている。[要出典] ソフトにおける固有の拡張子
アプリケーション固有のファイル形式のなかには、あるファイルを一定のディレクトリの階層構造[注 1]に格納しZIP形式で圧縮したものが存在する。そのようなファイルの大半はそのアプリケーション固有の物であることを示すために専用の拡張子を定義しており[要出典]、以下に示す例はその一部である。ただし、圧縮アルゴリズムにzlibを使っているものでも、ZIP互換の格納方式を使っていないものは掲載しない。
脚注注釈
出典
関連項目外部リンク
|
Portal di Ensiklopedia Dunia
