原文： http://www.pkware.com/documents/casestudies/APPNOTE.TXT (http://www.pkware.com/support/zip-app-note/ より) 訳注： 1. 当文書は私的に試訳したものです。 2. 当然、翻訳上の誤りがあるものとして扱ってください。 3. 当文書によって生じる全ての事象に関して、 利害得失の責は利用者にあるものとします。 4. 原文の更新に追随できていない場合があります。 awazo ozawa (awazo.the.8@gmail.com) ================================================================ File: APPNOTE.TXT - .ZIP File Format Specification Version: 6.3.2 Revised: September 28, 2007 Copyright (c) 1989 - 2007 PKWARE Inc., All Rights Reserved. 現状の APPNOTE で公開されている技術的内容は、 後述の "あなたの製品に PKWARE 所有の技術を組み込む" の項に従って 利用可能です。 I. 目的 ---------- この仕様は、クロスプラットフォームで相互運用可能なファイルの保存と転送の フォーマットを定義するものです。1989 年に公開して以来、PKWARE はこの仕様の 公開と保守を通して .ZIP ファイルフォーマットの相互運用性を保ち続けてきました。 私たちは、このフォーマットを採用し受益するすべての .ZIP 互換のベンダーや アプリケーション開発者が、この相互運用性の保持を共有し支持するだろうことを 信じています。 II. PKWARE の連絡先 --------------------- PKWARE, Inc. 648 N. Plankinton Avenue, Suite 220 Milwaukee, WI 53203 +1-414-289-9788 +1-414-289-9789 FAX zipformat@pkware.com III. 免責事項 --------------- PKWARE は、このファイルフォーマットやアルゴリズム、主なプログラムに関連する 最新かつ正確な情報を提供するよう努めるつもりですが、誤りまたは手落ちの 可能性は排除できません。PKWARE はゆえに、次のものに関連する付随要素に含まれる、 これらの情報が、配付されたときのままに、最新、正当、または正確であるという、 あらゆる保証を明確に放棄します。次のものとは、主なプログラム、かつ、または、 主なプログラムによって作られたりアクセスされたりするファイルのフォーマット、 かつ、または、主なプログラムや他のあらゆる要素で使われるアルゴリズムです。 ありえるどんな不正確な情報による損害の、あらゆるリスクをも、これらの情報の 使用者は当然起こりえると想定するものとします。なおかつ、次のものに関連する これらの情報は、告知なく変更されるものとします。次のものとは、主なプログラム、 かつ、または、主なプログラムによって作られたりアクセスされたりするファイルの フォーマット、かつ、または、主なプログラムで使われるアルゴリズムです。 もしこのファイルのバージョンが NOTIFICATION OF CHANGE (変更告知) と なっていたら、その内容は .ZIP ファイルフォーマットの変更点である、 初期要点仕様 (EFS: Early Feature Specification) を定義しています。 EFS は、最終要点仕様 (FFS: Final Feature Specification) の公開までに 変更されうるものです。この文書は、認識されている将来の拡張を定義する、 予期要点仕様 (PFS: Planned Feature Specifications) の情報を含むこともあります。 IV. 変更履歴 -------------- Version Change Description Date ------- ------------------ ---------- 5.2 -Single Password Symmetric Encryption 06/02/2003 ストレージ 6.1.0 -Smartcard 互換性 01/20/2004 -証明書ストレージの文書化 6.2.0 -メタデータの暗号化に Central Directory 04/26/2004 Encryption を導入 -version made by 値に OS/X を追加 6.2.1 -POSZIP の Extra Field プレースホルダを 04/01/2005 ID 0x4690 を使用して追加 -"zip64 end of central directory record" の サイズフィールドを説明 6.2.2 -Strong Encryption の最終要点仕様を 01/06/2006 文書化 -説明と誤字の修正 6.3.0 -テープ位置取りストレージのパラメタを 09/29/2006 追加 -サポートするハッシュアルゴリズムの リストを拡張 -サポートする圧縮アルゴリズムのリストを拡張 -サポートする暗号化アルゴリズムの リストを拡張 -Unicode ファイル名ストレージの オプションを追加 -Data Descriptor レコードの不変使用の説明 -追加の "Extra Field" 定義を追加 6.3.1 -SHA-256/384/512 の標準ハッシュ値を修正 04/11/2007 6.3.2 -圧縮メソッド 97 を追加 09/28/2007 -InfoZIP の UTF-8 file name と file comment ストレージの "Extra Field" 値を文書化 V. .ZIP ファイルのフォーマット -------------------------------- 複数のファイルは任意の順で保存されます。大きな .ZIP ファイルは 複数の volume やユーザ定義のセグメントサイズで分割することもできます。 すべての値は、別途の指定が無いかぎり、リトルエンディアンのバイト順で 保存されます。 .ZIP ファイルフォーマットの全体像: [local file header 1] [file data 1] [data descriptor 1] . . . [local file header n] [file data n] [data descriptor n] [archive decryption header] [archive extra data record] [central directory] [zip64 end of central directory record] [zip64 end of central directory locator] [end of central directory record] A. Local file header: local file header signature 4 bytes (0x04034b50) version needed to extract 2 bytes general purpose bit flag 2 bytes compression method 2 bytes last mod file time 2 bytes last mod file date 2 bytes crc-32 4 bytes compressed size 4 bytes uncompressed size 4 bytes file name length 2 bytes extra field length 2 bytes file name (variable size) extra field (variable size) B. File data 各ファイルの local header の直後には、そのファイルを 圧縮したり保存したデータがあります。 各ファイルのための [local file header][file data][data descriptor] の 連続が、.ZIP アーカイブ内では繰り返されます。 C. Data descriptor: crc-32 4 bytes compressed size 4 bytes uncompressed size 4 bytes この descriptor は general purpose bit flag の bit 3 がセットされる ときのみ存在します (下記参照) 。これはバイト境界にアライメントされ、 圧縮されたデータの最後のバイトの直後にあります。 この descriptor は出力の .ZIP ファイルをシークできないときのみに 使われます。例えば、出力の .ZIP ファイルが標準出力やシークできない デバイスに出力されたときなどです。ZIP64(tm) フォーマットの アーカイブでは、compressed size と uncompressed size は各 8 バイトです。 ファイルを圧縮する場合は、compressed size と uncompressed size は ファイルサイズが 0xFFFFFFFF を超える場合には、ZIP64 フォーマットで (8 バイトの値として) 保存されるべき (should be) です。しかし、 ZIP64 フォーマットはファイルサイズに関わらず使われることもあるでしょう。 展開するときには、当該ファイルの zip64 extended information extra field が存在したならば、compressed size と uncompressed size は 8 バイトの値でしょう。 オリジナルでは signature を決めてはいませんが、一般的に値 0x08074b50 が data descriptor の signature として使われます。実装者は、 ZIP ファイルが data descriptor を示すこの signature が あったり無かったりする状況に遭遇することを 認識しているべき (should be) で、かつ ZIP ファイルを 読み込んでいるときにはどちらの場合でも互換性を保証することに 責任を持つべき (should be) です。ZIP ファイルを書き込むときには、 data descriptor を示すこの signature 値を含めることを推奨します。 この signature が使われる場合、現在 data descriptor に定義されている フィールドはこの signature の直後にくるでしょう。 extensible data descriptor が将来の APPNOTE のバージョンでは リリースされるでしょう。この新しい record は、この record を 順当に使うにあたっての齟齬を解決し、ストリームでのファイル処理のために より良いサポートを提供することを意図されています。 Central Directory Encryption メソッドを使う場合、 この data descriptor は必須ではありませんが、使われるかもしれません。 もし存在して、かつ存在を示すために general purpose bit の bit 3 が セットされているなら、data descriptor の各フィールドの値はバイナリの ゼロに設定すべき (should be) です。 D. Archive decryption header: archive decryption header は ZIP フォーマット仕様のバージョン 6.2 で 導入されました。この record は、この文書における Strong Encryption 仕様の ように実装されている Central Directory Encryption Feature を サポートするときに存在します。Central Directory が暗号化された場合、 この decryption header は、暗号化されたデータセグメントよりも 前にあるでしょう。暗号化されたデータセグメントは、 (もしあれば) Archive extra data record と 暗号化された Central Directory のデータから成ります。 この data record のフォーマットは、圧縮されたファイルデータの 前にある Decryption header record と同一です。 もし central directory が暗号化されるなら、この data record の 開始位置は、Zip64 End of Central Directory record にある Start of Central directory field を使って決定されます。 Archive Decryption Header record で使われる field についての情報は、 Strong Encryption 仕様のセクションを参照してください。 E. Archive extra data record: archive extra data signature 4 bytes (0x08064b50) extra field length 4 bytes extra field data (variable size) archive extra data record は ZIP フォーマット仕様のバージョン 6.2 で 導入されました。 この record は、この文書における Strong Encryption 仕様の ように実装されている Central Directory Encryption Feature を サポートするときに存在します。存在するときには、この record は central directory のデータの直前にあります。この record のサイズは End of Central Directory record にある Size of the Central Directory field に含まれるでしょう。 central directory が圧縮されているけれど、暗号化されていない場合、 この record の開始位置は、Zip64 End of Central Directory record にある Start of Central Directory field を使って決められます。 F. Central directory structure: [file header 1] . . . [file header n] [digital signature] File header: central file header signature 4 bytes (0x02014b50) version made by 2 bytes version needed to extract 2 bytes general purpose bit flag 2 bytes compression method 2 bytes last mod file time 2 bytes last mod file date 2 bytes crc-32 4 bytes compressed size 4 bytes uncompressed size 4 bytes file name length 2 bytes extra field length 2 bytes file comment length 2 bytes disk number start 2 bytes internal file attributes 2 bytes external file attributes 4 bytes relative offset of local header 4 bytes file name (variable size) extra field (variable size) file comment (variable size) Digital signature: header signature 4 bytes (0x05054b50) size of data 2 bytes signature data (variable size) この仕様のバージョン 6.2 における Central Directory Encryption 機能の導入に伴って、 Central Directory は圧縮かつ暗号化されて保存されることもあるでしょう。 必須 (required) ではありませんが、Central Directory を 暗号化するときには、ストレージの有効活用のために圧縮されるだろうことが 想定されます。Central Directory Encryption 機能の情報は、 Strong Encryption 仕様を記述したセクションにあります。 Digital Signature record は圧縮も暗号化もされないでしょう。 G. Zip64 end of central directory record zip64 end of central dir signature 4 bytes (0x06064b50) size of zip64 end of central directory record 8 bytes version made by 2 bytes version needed to extract 2 bytes number of this disk 4 bytes number of the disk with the start of the central directory 4 bytes total number of entries in the central directory on this disk 8 bytes total number of entries in the central directory 8 bytes size of the central directory 8 bytes offset of start of central directory with respect to the starting disk number 8 bytes zip64 extensible data sector (variable size) size of zip64 end of central directory record に保存される値は、 残りの record のサイズであるべき (should be) で、かつ先頭の 12 バイトを含めるべきではありません (should not) 。 Size = 固定長Fieldのサイズ + 可変長データのサイズ - 12 上記の record の構造は zip64 end of central directory record の 第 1 版の定義です。第 1 版は、この仕様の 6.2 に先立つバージョンでは ZIP64 large file 機能においてサポートされていました。 バージョン 6.2 で Strong Encryption 仕様の一部として、 Central Directory Encryption 機能が導入された際に、 この record の第 2 版が定義されました。 この record の第 2 版のフォーマットについての詳細は、 Strong Encryption 仕様のセクションを参照してください。 特別な目的のデータが、このレコードの第 1 版でも第 2 版でも、 後に続く zip64 extensible data sector field に置かれるでしょう。 この特別な目的のデータを確実に識別するために、これらのデータは 次に示すような identifying header block を 含めなくてはなりません (must) 。 Header ID - 2 bytes Data Size - 4 bytes header id field は、後に続く data block に含まれるデータのタイプを 示します。 data size は、この data block のタイプで続くバイト数を示します。 複数の特別な目的のデータが存在するかもしれませんが、それぞれが header id と data size の field で始まらなければなりません (must) 。 この field でサポートしている header id の値の現在の割り当ては、 APPENDIX C で定義しています。 H. Zip64 end of central directory locator zip64 end of central dir locator signature 4 bytes (0x07064b50) number of the disk with the start of the zip64 end of central directory 4 bytes relative offset of the zip64 end of central directory record 8 bytes total number of disks 4 bytes I. End of central directory record: end of central dir signature 4 bytes (0x06054b50) number of this disk 2 bytes number of the disk with the start of the central directory 2 bytes total number of entries in the central directory on this disk 2 bytes total number of entries in the central directory 2 bytes size of the central directory 4 bytes offset of start of central directory with respect to the starting disk number 4 bytes .ZIP file comment length 2 bytes .ZIP file comment (variable size) J. field の説明 version made by (2 bytes) 上位バイトは file attribute の互換性を示します。 external file attribute が、MS-DOS と互換性をもち、 かつ PKZIP for DOS version 2.04g で読み込めるなら、 この値はゼロでしょう。もし、こうした互換性がなければ、 この値は attribute が互換性をもつホストシステムを示すでしょう。 ソフトウェアはこの情報を、テキストファイルの行の記録形式を 知るためなどに用いることができます。現在の割り当ては次のとおりです。 0 - MS-DOS and OS/2 (FAT / VFAT / FAT32 file systems) 1 - Amiga 2 - OpenVMS 3 - UNIX 4 - VM/CMS 5 - Atari ST 6 - OS/2 H.P.F.S. 7 - Macintosh 8 - Z-System 9 - CP/M 10 - Windows NTFS 11 - MVS (OS/390 - Z/OS) 12 - VSE 13 - Acorn Risc 14 - VFAT 15 - alternate MVS 16 - BeOS 17 - Tandem 18 - OS/400 19 - OS/X (Darwin) 20 thru 255 - unused 下位バイトは、ファイルのエンコードに使われたソフトウェアが サポートしている ZIP 仕様のバージョン (この文書のバージョン) を示します。値/10 が メジャーバージョン番号を示し、値の 10 での剰余が マイナーバージョン番号を示します。 version needed to extract (2 bytes) ファイルを展開するために必要な、ZIP 仕様の最小バージョンで、 上記のように割り当てています。この値は、ZIP プログラムがファイルを 展開するためにサポートしなければならない (must) 特定の フォーマットの特徴に基づきます。複数の特徴がファイルに 適用されるならば、最小バージョンとしては、最高の値をもつ特徴が 設定されるべき (should) です。新しい特徴や、既存のフォーマット仕様に 影響を与えるような、特徴の改変は、混乱を避けるために、 最後に世に出た値より高いバージョン番号が使われるでしょう。 現在の最小特徴バージョンは以下のように定義されています。 1.0 - デフォルト値 1.1 - ファイルはボリュームラベル 2.0 - ファイルはフォルダ (ディレクトリ) 2.0 - ファイルは Deflate で圧縮されている 2.0 - ファイルは traditional PKWARE encryption で暗号化されている 2.1 - ファイルは Deflate64(tm) で圧縮されている 2.5 - ファイルは PKWARE DCL Implode で圧縮されている 2.7 - ファイルはパッチデータのセット 4.5 - ファイルは ZIP64 形式の拡張を使う 4.6 - ファイルは BZIP2 で圧縮されている * 5.0 - ファイルは DES で暗号化されている 5.0 - ファイルは 3DES で暗号化されている 5.0 - ファイルは original RC2 encryption で暗号化されている 5.0 - ファイルは RC4 で暗号化されている 5.1 - ファイルは AES で暗号化されている 5.1 - ファイルは corrected RC2 encryption で暗号化されている ** 5.2 - ファイルは corrected RC2-64 encryption で暗号化されている ** 6.1 - ファイルは non-OAEP key wrapping で暗号化されている *** 6.2 - central directory の暗号化 6.3 - ファイルは LZMA で圧縮されている 6.3 - ファイルは PPMd で圧縮されている + 6.3 - ファイルは Blowfish で暗号化されている 6.3 - ファイルは Twofish で暗号化されている * 初期の 7.x (pre-7.2) の PKZIP バージョンは、BZIP2 圧縮の展開に 必要なバージョンを 46 にすべきところを、誤って 50 に設定します。 ** RC2 corrections についての追加の情報は、Strong Encryption 仕様の セクションを参照してください。 *** non-OAEP key wrapping を用いた証明書の暗号化は 6.1 以降の すべてのバージョンで行えるように意図されています。 OAEP key wrapping のサポートは、ZIP ファイルを PKZIP の 6.1 よりも 古いバージョン (5.0 や 6.0) で開くために送るような、 後方互換性のためにのみ使われるべき (should) です。 + PPMd で圧縮されたファイルは version needed to extract field を 6.3 に設定すべき (should) ですが、すべての ZIP プログラムが これを強制されることはなく、かつこの値が設定された場合に PPMd で 圧縮されたファイルを伸張できないかもしれません。 ZIP64 拡張を使うとき、zip64 end of central directory record の 対応する値もまた設定されるべき (should) です。この field は、 使っているのが第 1 版か第 2 版かを示すために 適切に設定されるべき (should) です。 general purpose bit flag: (2 bytes) Bit 0: 設定されれば、ファイルが暗号化されていることを示します。 (Method 6 - Imploding 用) Bit 1: 使用された圧縮方法が type 6 の Imploding であった場合には、 このビットが設定されていると、8K スライド辞書が使われたことを 示します。クリアされていると、4K スライド辞書が使われました。 Bit 2: 使用された圧縮方法が type 6 の Imploding であった場合には、 このビットが設定されていると、3 Shannon-Fano 木が スライド辞書の出力をエンコードするのに使われたことを示します。 クリアされていると、2 Shannon-Fano 木が使われました。 (Methods 8 and 9 - Deflating 用) Bit 2 Bit 1 0 0 通常の圧縮オプション (-en) が使われました。 0 1 最大の圧縮オプション (-exx/-ex) が使われました。 1 0 速い圧縮オプション (-ef) が使われました。 1 1 とても速い圧縮オプション (-es) が使われました。 (Method 14 - LZMA 用) Bit 1: 使用された圧縮方法が type 14 の LZMA であった場合には、 このビットが設定されていると、end-of-stream (EOS) マーカが、 圧縮データのストリームの終端を示すために使われることを 示します。クリアされていると、EOS マーカは存在せず、 かつ圧縮データのサイズは展開のために知っていなくては なりません (must) 。 注: Bit 1 と Bit 2 は、他の圧縮方法の場合には未定義です。 Bit 3: このビットが設定されると、local header における crc-32 と compressed size と uncompressed size の field はゼロに 設定されます。正しい値は、圧縮データの直後にある data descriptor に置かれます。 (注: PKZIP version 2.04g for DOS は、 method 8 の圧縮のときのみにこのビットを認識します。 より新しい PKZIP のバージョンはどんな圧縮方法でも このビットを認識します。) Bit 4: method 8 で用い、deflate を改良するために予約されています。 Bit 5: このビットが設定されると、ファイルは 圧縮されたパッチデータであることを示します。 (注: PKZIP version 2.70 以上が必要です) Bit 6: Strong encryption です。このビットが設定されると、 version needed to extract の値には 50 以上を 設定すべき (should) で、かつ bit 0 をも 設定しなければなりません (must) 。もし AES 暗号化が 使用されるなら、version needed to extract の値は 51 以上にしなければなりません (must) 。 Bit 7: 現在は未使用です。 Bit 8: 現在は未使用です。 Bit 9: 現在は未使用です。 Bit 10: 現在は未使用です。 Bit 11: Language encoding flag (EFS) です。このビットが 設定されると、このファイルの filename と comment の field は UTF-8 を用いて符号化されなければなりません (must) 。 (APPENDIX D を見てください) Bit 12: さらなる圧縮のために PKWARE が予約しています。 Bit 13: Central Directory を暗号化しているときに、Local Header の 選択されたデータの値が、それらの実際の値を隠すために、 マスクされていることを示すために使われます。 Bit 14: PKWARE が予約しています。 Bit 15: PKWARE が予約しています。 compression method: (2 bytes) (アルゴリズムを解説している文書も見てください) 0 - ファイルは単に保存されている (非圧縮) 1 - ファイルは Shrunk 圧縮 2 - ファイルは factor 1 で Reduce 圧縮 3 - ファイルは factor 2 で Reduce 圧縮 4 - ファイルは factor 3 で Reduce 圧縮 5 - ファイルは factor 4 で Reduce 圧縮 6 - ファイルは Implode 圧縮 7 - Tokenizing 圧縮のために予約されている 8 - ファイルは deflate 圧縮 9 - Deflate64(tm) を用いた Enhanced Deflating 10 - PKWARE Data Compression Library Imploding (old IBM TERSE) 11 - PKWARE が予約している 12 - ファイルは BZIP2 で圧縮されている 13 - PKWARE が予約している 14 - LZMA (EFS) 15 - PKWARE が予約している 16 - PKWARE が予約している 17 - PKWARE が予約している 18 - ファイルは IBM TERSE (new) で圧縮されている 19 - IBM LZ77 z アーキテクチャ (PFS) 97 - WavPack 圧縮 98 - PPMd version I, Rev 1 date and time fields: (2 bytes each) date and time は標準の MS-DOS フォーマットでエンコードされています。 入力が標準入力から与えられた場合は、date and time は、このデータの 圧縮を開始した時点のものです。central directory が暗号化されていて、 かつ general purpose bit flag 13 が設定されていて マスクしていることを示しているなら、Local Header に保存される値は ゼロでしょう。 CRC-32: (4 bytes) CRC-32 アルゴリズムは David Schwaderer によって気前良く 寄贈されたもので、Howard W. Sams & Co. Inc. から出版された、 彼の素晴らしい著書 "C Programmers Guide to NetBIOS" で読むことが できます。この CRC の 'マジックナンバー' は 0xdebb20e3 です。 適切な CRC の前後処理を行います、つまり CRC のレジスタはあらかじめ、 すべて 1 にしておき (初期値が 0xffffffff) 、かつ CRC 計算の最後には 1 の補数をとるようにします。 general purpose flag の bit 3 が設定される場合には、 local header と central directory におけるこの field はゼロに 設定されます。central directory を暗号化するときには、 local header が ZIP64 フォーマットでなく、 かつ general purpose bit flag 13 が設定されていて マスクしていることを示しているなら、Local Header に保存される値は ゼロでしょう。 compressed size: (4 bytes) uncompressed size: (4 bytes) それぞれ、圧縮された状態と圧縮されていない状態の ファイルのサイズです。decryption header が存在するときは、 それはファイルデータの前に位置し、 かつ compressed file size の値には decryption header のバイト数が 含まれるでしょう。general purpose bit flag の bit 3 が 設定される場合には、local header におけるこれらの field は ゼロが設定され、かつ正しい値は data descriptor と central directory に置かれます。ZIP64 フォーマットで、 かつこの field の値が 0xFFFFFFFF の場合、size は対応する 8 バイトの ZIP64 extended information extra field にあるでしょう。 central directory を暗号化しているとき、local header が ZIP64 フォーマットではなく、かつ general purpose bit flag 13 が 設定されていてマスクしていることを示しているなら、 Local Header の uncompressed size に保存される値はゼロでしょう。 file name length: (2 bytes) extra field length: (2 bytes) file comment length: (2 bytes) それぞれ、ファイル名、extra field 、コメント field の長さです。 あらゆる directory record の合計の長さと、この三つの field は、 一般的に 65,535 バイトを超えるべきではありません (should not) 。 入力が標準入力から与えられた場合には、file name length は ゼロに設定されます。 disk number start: (2 bytes) このファイルの先頭があるディスクの番号です。ZIP64 フォーマットで、 かつこの field の値が 0xFFFF の場合には、値は対応する 4 バイトの zip64 extended information extra field にあるでしょう。 internal file attributes: (2 bytes) Bit 1 と Bit 2 は PKWARE が使うために予約しています。 この field の最下位ビットは、設定されていればファイルは ASCII またはテキストファイルのようだということを示します。 設定されていなければ、ファイルはバイナリデータが 入っているようです。残りのビットはバージョン 1.0 では未使用です。 この field の 0x0002 ビットは、設定されれば、4 バイトの可変の record length control field が、その record の長さを示している 各 logical record の前にあります。record length control field は リトルエンディアンのバイト順で保存されます。この flag は text control character とは独立していて、テキストデータと合わせて 用いられるなら、あらゆる control character をその record の 合計の長さに含めます。この値はメインフレームのデータ転送の サポートのために提供されます。 external file attributes: (4 bytes) external attribute の割り当てはホストシステム依存です ('version made by' を見てください) 。MS-DOS では、 下位バイトは MS-DOS directory attribute byte です。 入力が標準入力から与えられた場合、この field はゼロに設定されます。 relative offset of local header: (4 bytes) これは、このファイルが出現する最初のディスクの先頭から、 local header が見つかるべき場所までの、オフセットです。 ZIP64 フォーマットで、かつこの field の値が 0xFFFFFFFF の場合、 値は対応する 8 バイトの zip64 extended information extra field に あるでしょう。 file name: (Variable) ファイルの名前で、オプションで相対パスです。保存されるパスは ドライブやデバイスレターを含むべきではありません (should not) 。 すべてのスラッシュは、Amiga や UNIX ファイルシステムなどとの 互換性のために、バックスラッシュ '\' ではなく、 通常のスラッシュ '/' であるべきです (should) 。 入力が標準入力から与えられた場合は、file name field は存在しません。 central directory を暗号化していて、 かつ general purpose bit flag 13 が設定されていて マスクしていることを示しているなら、Local Header に保存された file name は、実際の file name ではないでしょう。 マスクに使われる、ユニークな十六進の値が保存されるでしょう。 この値はアーカイブ中で、ファイルごとに連続的に増加するでしょう。 暗号化された file name を取得するための詳細は、 Strong Encryption 仕様のセクションを見てください。 extra field: (Variable) これは拡張のためのものです。追加の情報が、特別な要請や特定の プラットフォームのために保存される必要があるなら、それはここに 保存されるべきです (should) 。ソフトウェアの初期のバージョンでは、 それゆえこのファイルを安全にスキップし、次のファイルやヘッダを 探すことができます。この field はバージョン 1.0 では長さ 0 でしょう。 異なるプログラムや異なるタイプの情報が .ZIP ファイルの 'extra' field に保存されることを許容するために、 この field にデータを保存するすべてのプログラムは、 次の構造を用いるべきです (should) 。 header1+data1 + header2+data2 . . . 各ヘッダは次のように構成されるべきです (should) 。 Header ID - 2 bytes Data Size - 2 bytes 注: すべての field は Intel low-byte/high-byte order で保存されます。 Header ID field は、後続の data block にあるデータの タイプを示します。 Header ID の 0 から 31 は PKWARE が使うために予約しています。 残りの ID はサードパーティのベンダがプロプライエタリな 用法のために使うことができます。 PKWARE が定義する現在の Header ID の割り当ては次のとおりです。 0x0001 Zip64 extended information extra field 0x0007 AV Info 0x0008 Reserved for extended language encoding data (PFS) (see APPENDIX D) 0x0009 OS/2 0x000a NTFS 0x000c OpenVMS 0x000d UNIX 0x000e Reserved for file stream and fork descriptors 0x000f Patch Descriptor 0x0014 PKCS#7 Store for X.509 Certificates 0x0015 X.509 Certificate ID and Signature for individual file 0x0016 X.509 Certificate ID for Central Directory 0x0017 Strong Encryption Header 0x0018 Record Management Controls 0x0019 PKCS#7 Encryption Recipient Certificate List 0x0065 IBM S/390 (Z390), AS/400 (I400) attributes - uncompressed 0x0066 Reserved for IBM S/390 (Z390), AS/400 (I400) attributes - compressed 0x4690 POSZIP 4690 (reserved) サードパーティの割り当てで一般的に使われるのは次のとおりです。 0x07c8 Macintosh 0x2605 ZipIt Macintosh 0x2705 ZipIt Macintosh 1.3.5+ 0x2805 ZipIt Macintosh 1.3.5+ 0x334d Info-ZIP Macintosh 0x4341 Acorn/SparkFS 0x4453 Windows NT security descriptor (binary ACL) 0x4704 VM/CMS 0x470f MVS 0x4b46 FWKCS MD5 (see below) 0x4c41 OS/2 access control list (text ACL) 0x4d49 Info-ZIP OpenVMS 0x4f4c Xceed original location extra field 0x5356 AOS/VS (ACL) 0x5455 extended timestamp 0x554e Xceed unicode extra field 0x5855 Info-ZIP UNIX (original, also OS/2, NT, etc) 0x6375 Info-ZIP Unicode Comment Extra Field 0x6542 BeOS/BeBox 0x7075 Info-ZIP Unicode Path Extra Field 0x756e ASi UNIX 0x7855 Info-ZIP UNIX (new) 0xa220 Microsoft Open Packaging Growth Hint 0xfd4a SMS/QDOS サードパーティの割り当てで定義される Extra Field の詳細な説明は、 PKWARE に示されたそれらのデータ構造についての情報として 文書化されるでしょう。PKWARE は世に出たいかなるサードパーティの データの正確さも保証しません。 Data Size field は、後続の data block のサイズを示します。 プログラムはこの値を、関心の無いあらゆる data block をとばして、 次の header block までスキップするために使うことができます。 注: 上に明記されているように、file name と comment と extra field も含めて .ZIP ファイルヘッダ全体のサイズは 64K を超えないようにすべき (should) です。 二つの異なるプログラムが同一の Header ID 値を用いるべき場合には、 各プログラムが 2 バイト以上の (そして、なるべく 4 バイトか より大きな) ユニークなシグニチャを、各データ領域の先頭に 置くことを、強く推奨します。すべてのプログラムは、 既知のタイプの block だと想定する前に、Header ID 値が 正しいことに加えて、そのユニークなシグニチャが存在することを 確認すべき (should) です。 -Zip64 Extended Information Extra Field (0x0001): 以下は、zip64 extended information "extra" block の構造です。 もし、Local または Central directory record において、 サイズまたはオフセットの field のいずれかが、必要なデータを 保存するのに小さすぎるなら、Zip64 extended information record が 作られます。zip64 extended information record の field の順序は 固定ですが、各 field は、対応する Local または Central directory record の field が 0xFFFF や 0xFFFFFFFF に 設定されたときにのみ、存在します。 注: すべての field は Intel low-byte/high-byte order で保存されます。 Value Size Description ----- ---- ----------- (ZIP64) 0x0001 2 bytes この "extra" block のタイプを示すタグ Size 2 bytes この "extra" block のサイズ Original Size 8 bytes 圧縮しない状態でのファイルサイズ Compressed Size 8 bytes 圧縮した状態でのファイルサイズ Relative Header Offset 8 bytes local header record のオフセット Disk Start Number 4 bytes このファイルの先頭が置かれるディスクの番号 Local header においては、このエントリは original と compressed の ファイルサイズの field を【どちらも】含めなければなりません (must) 。 central directory を暗号化していて、 かつ general purpose bit flag の bit 13 が設定されていて マスクしていることを示しているなら、Local Header に 保存された original file size の値はゼロでしょう。 -OS/2 Extra Field (0x0009): 以下は、OS/2 attributes "extra" block の 構造です。(最終更新 09/05/95) 注: すべての field は Intel low-byte/high-byte order で保存されます。 Value Size Description ----- ---- ----------- (OS/2) 0x0009 2 bytes この "extra" block のタイプを示すタグ TSize 2 bytes 後続の data block のサイズ BSize 4 bytes 圧縮しない状態での Block のサイズ CType 2 bytes 圧縮タイプ EACRC 4 bytes 圧縮しない状態の block の CRC 値 (var) variable 圧縮した block OS/2 extended attribute structure (FEA2LIST) は圧縮され、 そのままこの structure へ保存されます。必ず、ただひとつの データの "block" が VarFields[] にあるでしょう。 -NTFS Extra Field (0x000a): 以下は、NTFS attributes "extra" block の構造です。 (注: 現時点では、Mtime と Atime と Ctime は、 あらゆる WIN32 システムで使われるでしょう。) 注: すべての field は Intel low-byte/high-byte order で保存されます。 Value Size Description ----- ---- ----------- (NTFS) 0x000a 2 bytes この "extra" block のタイプを示すタグ TSize 2 bytes "extra" block の合計サイズ Reserved 4 bytes 今後の使用のために予約している Tag1 2 bytes 第 1 NTFS attribute タグの値 Size1 2 bytes 第 1 attribute のバイト数でのサイズ (var.) Size1 第 1 attribute のデータ . . . TagN 2 bytes 第 N NTFS attribute タグの値 SizeN 2 bytes 第 N attribute のバイト数でのサイズ (var.) SizeN 第 N attribute のデータ NTFS における、Tag1 から TagN の値は以下のとおりです。 (現在のところ NTFS 用に定義されている attribute はひとつだけです。) Tag Size Description ----- ---- ----------- 0x0001 2 bytes 第 1 attribute のタグ Size1 2 bytes 第 1 attribute のバイト数でのサイズ Mtime 8 bytes ファイルの最終更新時刻 Atime 8 bytes ファイルの最終アクセス時刻 Ctime 8 bytes ファイルの作成時刻 -OpenVMS Extra Field (0x000c): 以下は、OpenVMS attributes "extra" block の構造です。 注: すべての field は Intel low-byte/high-byte order で保存されます。 Value Size Description ----- ---- ----------- (VMS) 0x000c 2 bytes この "extra" block のタイプを示すタグ TSize 2 bytes "extra" block の合計サイズ CRC 4 bytes block の残りの部分の 32-bit CRC Tag1 2 bytes 第 1 OpenVMS attribute タグの値 Size1 2 bytes 第 1 attribute のバイト数でのサイズ (var.) Size1 第 1 attribute のデータ . . . TagN 2 bytes 第 N OpenVMS attribute タグの値 SizeN 2 bytes 第 N attribute のバイト数でのサイズ (var.) SizeN 第 N attribute のデータ ルール: 1. ひとつ以上の attribute が存在するでしょうけれど、それらは 上記の TagX & SizeX の値が先頭にあるでしょう。これらの値は OpenVMS C の ATR.H で定義されている ATR$C_XXXX と ATR$S_XXXX という定数と同一です。これらの値のどれもが ゼロではないでしょう。 2. word 境界でのアライメントやパディングは行われません。 3. 十分に動作する PKZIP/OpenVMS プログラムは、同じ TagX 値をもつ 複数の sub-block を作るべきではありません (should never) 。 また、各 directory record においては、0x000c タイプの "extra" block を複数作らないでしょう。 -UNIX Extra Field (0x000d): 以下は、UNIX "extra" block の構造です。 注: すべての field は Intel low-byte/high-byte order で保存されます。 Value Size Description ----- ---- ----------- (UNIX) 0x000d 2 bytes この "extra" block のタイプを示すタグ TSize 2 bytes 後続の data block のサイズ Atime 4 bytes ファイルの最終アクセス時刻 Mtime 4 bytes ファイルの最終更新時刻 Uid 2 bytes ファイルの user ID Gid 2 bytes ファイルの group ID (var) variable 可変長の data field 可変長の data field はファイルタイプに特有なデータを 含むでしょう。現在のところ、ハードリンクやシンボリックリンクの、 元々の "リンクされた側の" ファイル名と、キャラクタデバイスと ブロックデバイスの、デバイスノードのメジャー番号と マイナー番号のみが、可能な値です。デバイスノードは シンボリックリンクやハードリンクにはならないため、 ただひとつの可変長データが保存されます。リンクファイルは、 元々のファイル名を保存しているでしょう。この名前は NULL 終端ではありません。そのサイズは TSize - 12 を 確かめることで決められます。デバイスのエントリであれば、 8 バイトが 2 つの 4 バイトの (リトルエンディアンの フォーマットの) エントリとして保存されるでしょう。 最初のエントリはメジャーデバイス番号で、ふたつ目は マイナーデバイス番号でしょう。 -PATCH Descriptor Extra Field (0x000f): 以下は、Patch Descriptor "extra" block の構造です。 注: すべての field は Intel low-byte/high-byte order で保存されます。 Value Size Description ----- ---- ----------- (Patch) 0x000f 2 bytes この "extra" block のタイプを示すタグ TSize 2 bytes "extra" block の合計サイズ Version 2 bytes descriptor のバージョン Flags 4 bytes Action と reaction (以下を参照) OldSize 4 bytes patch を当てられるファイルのサイズ OldCRC 4 bytes patch を当てられるファイルの 32-bit CRC NewSize 4 bytes 結果のファイルサイズ NewCRC 4 bytes 結果のファイルの 32-bit CRC Action と reaction Bits Description ---- ---------------- 0 自動検出に使用 1 self-patch として扱う 2-3 予約 4-5 action (以下を参照) 6-7 予約 8-9 存在しないファイルに対する reaction (以下を参照) 10-11 新たなファイルに対する reaction (以下を参照) 12-13 不明なファイルに対する reaction (以下を参照) 14-15 予約 16-31 予約 Actions Action Value ------ ----- 無し 0 追加 1 削除 2 patch 3 Reactions Reaction Value -------- ----- 問う 0 スキップ 1 無視 2 失敗 3 patch のサポートは PKPatchMaker(tm) テクノロジによって提供され、 U.S. Patents and Patents Pending の保護下にあります。 現在の APPNOTE にあるような、なんらかの技術的な点における、 製品での使用や実装は、strong encryption や patching や extended tape operation とみなされるものと併せての 使用や実装を含めて、PKWARE からの許諾が必要です。 ライセンスを取得するためには PKWARE に連絡をください。 -PKCS#7 Store for X.509 Certificates (0x0014): この field は、署名されているであろう各証明書ファイルについての 情報を含みます。ZIP ファイルにおいて Central Directory Encryption 機能が有効な場合、 この record が Archive Extra Data Record に存在するか、 さもなくば、最初の central directory record に存在して、 他のあらゆる record では無視されるでしょう。 注: すべての field は Intel low-byte/high-byte order で保存されます。 Value Size Description ----- ---- ----------- (Store) 0x0014 2 bytes この "extra" block のタイプを示すタグ TSize 2 bytes store data のサイズ TData TSize store のデータ -X.509 Certificate ID and Signature for individual file (0x0015): この field は、PKCS#7 store のどの証明書が、 各ファイルの署名に使われたかの情報が含まれます。 また、この field には署名データも含まれます。この field は 複数存在することができますが、各証明書ごとには一度だけ存在できます。 注: すべての field は Intel low-byte/high-byte order で保存されます。 Value Size Description ----- ---- ----------- (CID) 0x0015 2 bytes この "extra" block のタイプを示すタグ TSize 2 bytes 後続のデータのサイズ TData TSize 署名データ -X.509 Certificate ID and Signature for central directory (0x0016): この field は、PKCS#7 store のどの証明書が、 central directory structure の署名に使われたかの情報が含まれます。 ZIP ファイルにおいて Central Directory Encryption 機能が 有効な場合、この record が Archive Extra Data Record に存在するか、 さもなくば、最初の central directory record に存在するでしょう。 注: すべての field は Intel low-byte/high-byte order で保存されます。 Value Size Description ----- ---- ----------- (CDID) 0x0016 2 bytes この "extra" block のタイプを示すタグ TSize 2 bytes 後続のデータのサイズ TData TSize データ -Strong Encryption Header (0x0017): Value Size Description ----- ---- ----------- 0x0017 2 bytes この "extra" block のタイプを示すタグ TSize 2 bytes 後続のデータのサイズ Format 2 bytes この record のフォーマット定義 AlgID 2 bytes 暗号化アルゴリズムの識別子 Bitlen 2 bytes encryption key のビット長 Flags 2 bytes 処理フラグ CertData TSize-8 Certificate decryption extra field data (Strong Encryption 仕様における Certificate Processing Method を説明している セクションの CertData に関する解説を参照) -Record Management Controls (0x0018): Value Size Description ----- ---- ----------- (Rec-CTL) 0x0018 2 bytes この "extra" block のタイプを示すタグ CSize 2 bytes extra block のデータの合計サイズ Tag1 2 bytes 第 1 record control attribute Size1 2 bytes 第 1 attribute のバイト数でのサイズ Data1 Size1 第 1 attribute のデータ . . . TagN 2 bytes 第 N record control attribute SizeN 2 bytes 第 N attribute のバイト数でのサイズ DataN SizeN 第 N attribute のデータ -PKCS#7 Encryption Recipient Certificate List (0x0019): この field は暗号化処理で使われた各証明書の情報を含み、これを、 暗号化されたファイルの復号を許された人を識別するために 使うことができます。この field は archive extra data record にのみ 存在すべきです (should) 。この field は必須ではなく、 public encryption key data を保存することでアーカイブの変更を 助けるためにのみ使われます。個々のセキュリティの要請においては、 情報の露出を避けるために、このデータを省略するように 指定されるでしょう。 注: すべての field は Intel low-byte/high-byte order で保存されます。 Value Size Description ----- ---- ----------- (CStore) 0x0019 2 bytes この "extra" block のタイプを示すタグ TSize 2 bytes store data のサイズ TData TSize store についてのデータ TData: Value Size Description ----- ---- ----------- Version 2 bytes フォーマットのバージョン番号 - 現時点では 0x0001 にしなければならない (must) CStore (var) PKCS#7 データの塊 -MVS Extra Field (0x0065): 以下は、MVS "extra" block の構造です。 注: いくつかの field はビッグエンディアンのフォーマットで 保存されます。 全てのテキストは、別記ない場合は EBCDIC フォーマットです。 Value Size Description ----- ---- ----------- (MVS) 0x0065 2 bytes この "extra" block のタイプを示すタグ TSize 2 bytes 後続の data block のサイズ ID 4 bytes EBCDIC "Z390" 0xE9F3F9F0 または TargetFour の "T4MV" (var) TSize-4 attribute データ (APPENDIX B を参照) -OS/400 Extra Field (0x0065): 以下は、OS/400 "extra" block の構造です。 注: いくつかの field はビッグエンディアンのフォーマットで 保存されます。 全てのテキストは、別記ない場合は EBCDIC フォーマットです。 Value Size Description ----- ---- ----------- (OS400) 0x0065 2 bytes この "extra" block のタイプを示すタグ TSize 2 bytes 後続の data block のサイズ ID 4 bytes EBCDIC "I400" 0xC9F4F0F0 または TargetFour の "T4MV" (var) TSize-4 attribute データ (APPENDIX A を参照) サードパーティの割り当て: -ZipIt Macintosh Extra Field (long) (0x2605): 以下は、Macintosh 用の ZipIt extra block の構造です。 local-header と central-header 用は同じものです。 この block はファイルが MacBinary-encoded で保存されているならば 存在しなければなりません (must) し、ファイルが MacBinary-encoded で 保存されていなければ使うべきではありません (should not) 。 Value Size Description ----- ---- ----------- (Mac2) 0x2605 Short この extra block のタイプを示すタグ TSize Short この block の合計サイズ "ZPIT" beLong extra-field のシグニチャ FnLen Byte FileName の長さ FileName variable フル Macintosh ファイル名 FileType Byte[4] 4 バイトの Mac ファイルタイプ文字列 Creator Byte[4] 4 バイトの Mac 作成者文字列 -ZipIt Macintosh Extra Field (short, for files) (0x2705): 以下は、Macintosh 用の ZipIt extra block の短縮版の 構造です ("full name" エントリがありません) 。この短縮版は ZipIt 1.3.5 以降で、MacBinary encoded ファイルを持たない、 ファイルの (ディレクトリではない) エントリに使われます。 local-header と central-header 用は同じものです。 Value Size Description ----- ---- ----------- (Mac2b) 0x2705 Short この extra block のタイプを示すタグ TSize Short この block の合計サイズ (12) "ZPIT" beLong extra-field のシグニチャ FileType Byte[4] 4 バイトの Mac ファイルタイプ文字列 Creator Byte[4] 4 バイトの Mac 作成者文字列 fdFlags beShort FInfo.frFlags 由来の attribute 、 省略されるでしょう 0x0000 beShort 予約、省略されるでしょう -ZipIt Macintosh Extra Field (short, for directories) (0x2805): 以下は、ディレクトリのエントリのみに用いられる、 Macintosh 用の ZipIt extra block の短縮版の構造です。 この短縮版は ZipIt 1.3.5 以降で、ディレクトリに関するいくつかの Mac 独特のオプションの情報を保存するために使われます。 local-header と central-header 用は同じものです。 Value Size Description ----- ---- ----------- (Mac2c) 0x2805 Short この extra block のタイプを示すタグ TSize Short この block の合計データサイズ (12) "ZPIT" beLong extra-field のシグニチャ frFlags beShort DInfo.frFlags 由来の attribute 、 省略されるでしょう View beShort ZipIt view flag 、省略されるでしょう View field は ZipIt の内部設定を以下のように指定します: Bits of the Flags: bit 0 設定されれば、アーカイブの中身を ZipIt で 見ているときに、フォルダは 展開 (オープン) 状態で表示 bits 1-15 予約、ゼロ -FWKCS MD5 Extra Field (0x4b46): ファイル名とは独立に自動でファイルを識別するために用いる、 FWKCS Contents_Signature System がオプションで追加し、 extra field を、強化された contents_signature の高速生成を サポートするために用います。 Header ID = 0x4b46 Data Size = 0x0013 Preface = 'M','D','5' 圧縮されない状態でのファイルの 128_bit MD5 hash ((1) を参照) を入れた 16 バイトが後に続きます。下位バイトが先です。 FWKCS が、あるファイルに対してこの extra field を 追加するにあたって、.ZIP ファイルの central directory を 更新するとき、同時に、そのファイルの圧縮されない状態での長さを 格納する central directory のエントリを、計測した値で置き換えます。 FWKCS は .ZIP ファイルの central directory に この extra field があった場合、それを取り除くオプションを 提供しています。この extra field のほかに、FWKCS は .ZIP ファイルの Authenticity Verification を保存します。 この extra field を取り除いたとしても、FWKCS は PKZIP version 2.04g からのすべての AV のバージョンを保存します。 FWKCS と FWKCS Contents_Signature System は Frederick W. Kantor の trademarks です。 (1) R. Rivest, RFC1321.TXT, MIT Laboratory for Computer Science and RSA Data Security, Inc., April 1992. ll.76-77: "The MD5 algorithm is being placed in the public domain for review and possible adoption as a standard." -Info-ZIP Unicode Comment Extra Field (0x6375): file comment の UTF-8 版を保存するもので、 central directory header に置かれます。(最終更新 20070912) Value Size Description ----- ---- ----------- (UCom) 0x6375 Short この "extra" block のタイプを示すタグ ("uc") TSize Short この block のデータの合計サイズ Version 1 byte この extra field のバージョンで、現在は 1 ComCRC32 4 bytes comment field の CRC32 チェックサム UnicodeCom Variable comment エントリの UTF-8 版 現在のバージョンは数値 1 を設定します。この field を 変更する必要がある場合、バージョンは増加するでしょう。 変更は後方互換性を持たないでしょうから、バージョンが 認識されないときには、この extra field を使うべきでは ありません (should not) 。 ComCRC32 は central directory header における File Comment field の標準 zip CRC32 チェックサムです。 これは comment field が、Unicode Comment extra field が 作成されてから変更されていないことを確認するために使われます。 こうしたことは、ユーティリティが File Comment field を 変更しても UTF-8 Comment extra field を更新しないときに 起こります。CRC チェックが失敗した場合は、 この Unicode Comment extra field は無視されるべき (should) で、 代わりにその header の File Comment field が 使われるべき (should) です。 UnicodeCom field は、その header にある File Comment field の UTF-8 版です。UnicodeCom は UTF-8 であると定義されているので、 UTF-8 byte order mark (BOM) は使われません。この field の長さは、 TSize から先行する field のサイズを引いて求められます。もし、 File Name と Comment の field が両方とも UTF-8 であれば、 新たな General Purpose Bit Flag の bit 11 (Language encoding flag (EFS)) が、その header の File Name と Comment の field が両方とも UTF-8 であると 示すために使えますし、この場合には、Unicode Path と Unicode Comment の extra field は必要なく、作成されるべきでも ありません (should not) 。注意すべきは、後方互換性のために、 bit 11 は zip 化される path と comment のネイティブ文字セットが 既に UTF-8 であるときのみに使われるべきです (should) 。 あるファイルに対しては、Local と Central Directory Header の 両方において、general purpose bit 11 も extra field も、 同一の file comment の保存方法を使用することが期待されます。 -Info-ZIP Unicode Path Extra Field (0x7075): file name field の UTF-8 版を保存するもので、local header と central directory header に置かれます。(最終更新 20070912) Value Size Description ----- ---- ----------- (UPath) 0x7075 Short この extra block のタイプを示すタグ ("up") TSize Short この block のデータの合計サイズ Version 1 byte この extra field のバージョン、現在は 1 NameCRC32 4 bytes File Name Field の CRC32 チェックサム UnicodeName Variable File Name エントリの UTF-8 版 現在のバージョンは数値 1 を設定します。この field を 変更する必要がある場合、バージョンは増加するでしょう。 変更は後方互換性を持たないでしょうから、バージョンが 認識されないときには、この extra field を使うべきでは ありません (should not) 。 NameCRC32 はその header における File Name field の 標準 zip CRC32 チェックサムです。これはその header の File Name field が、Unicode Path extra field が 作成されてから変更されていないことを確認するために使われます。 こうしたことは、ユーティリティが File Name を付け直しても UTF-8 path extra field を更新しないときに起こります。 CRC チェックが失敗した場合は、この UTF-8 Path Extra Field は 無視されるべき (should) で、代わりにその header の File Name field が使われるべき (should) です。 UnicodeName は、その header にある File Name field の内容の UTF-8 版です。UnicodeName は UTF-8 であると定義されているので、 UTF-8 byte order mark (BOM) は使われません。この field の長さは、 TSize から先行する field のサイズを引いて求められます。もし、 File Name と Comment の field が両方とも UTF-8 であれば、 新たな General Purpose Bit Flag の bit 11 (Language encoding flag (EFS)) が、その header の File Name と Comment の field が両方とも UTF-8 であると 示すために使えますし、この場合には、Unicode Path と Unicode Comment の extra field は必要なく、作成されるべきでも ありません (should not) 。注意すべきは、後方互換性のために、 bit 11 は zip 化される path と comment のネイティブ文字セットが 既に UTF-8 であるときのみに使われるべきです (should) 。 あるファイルに対しては、Local と Central Directory Header の 両方において、general purpose bit 11 も extra field も、 同一の file name の保存方法を使用することが期待されます。 -Microsoft Open Packaging Growth Hint (0xa220): Value Size Description ----- ---- ----------- 0xa220 Short この extra block のタイプを示すタグ TSize Short Sig + PadVal + Padding のサイズ Sig Short 確認のためのシグニチャ (A028) PadVal Short padding の初期値 Padding variable NULL 文字で埋められる file comment: (Variable) このファイルに対するコメントです。 number of this disk: (2 bytes) この disk の番号で、central directory end record を 含んでいます。アーカイブが ZIP64 フォーマットで、かつ この field の値が 0xFFFF のとき、値は対応する 4 バイトの zip64 end of central directory field に置かれるでしょう。 number of the disk with the start of the central directory: (2 bytes) central directory の先頭が置かれる disk の番号です。 アーカイブが ZIP64 フォーマットで、かつこの field の値が 0xFFFF のとき、値は対応する 4 バイトの zip64 end of central directory field に置かれるでしょう。 total number of entries in the central dir on this disk: (2 bytes) この disk にある central directory のエントリの数です。 アーカイブが ZIP64 フォーマットで、かつこの field の値が 0xFFFF のとき、値は対応する 8 バイトの zip64 end of central directory field に置かれるでしょう。 total number of entries in the central dir: (2 bytes) .ZIP ファイルに含まれる合計のファイル数です。アーカイブが ZIP64 フォーマットで、かつこの field の値が 0xFFFF のとき、 値は対応する 8 バイトの zip64 end of central directory field に 置かれるでしょう。 size of the central directory: (4 bytes) central directory 全体のサイズ (バイト数) です。アーカイブが ZIP64 フォーマットで、かつこの field の値が 0xFFFFFFFF のとき、 値は対応する 8 バイトの zip64 end of central directory filed に 置かれるでしょう。 offset of start of central directory with respect to the starting disk number: (4 bytes) central directory の先頭がある disk における、central directory の 先頭のオフセットです。アーカイブが ZIP64 フォーマットで、 かつこの field の値が 0xFFFFFFFF のとき、値は対応する 8 バイトの zip64 end of central directory field に置かれるでしょう。 .ZIP file comment length: (2 bytes) この .ZIP ファイルに対するコメントの長さです。 .ZIP file comment: (Variable) この .ZIP ファイルに対するコメントです。ZIP file comment data は 安全性をもつように保存されません。この area に対する、 暗号化やデータアクセスの権限確認は、現時点では適用されません。 機密情報はこの section に保存されるべきではありません (should not) 。 zip64 extensible data sector (variable size) (現在のところ PKWARE が使うために予約しています) K. ZIP ファイルの分割 Spanning は ZIP ファイルを複数の removable media へ分割する 処理です。このサポートは典型的には DOS フォーマットされた フロッピーディスクに対してのみ提供されます。 File splitting は spanning の新しい派生です。splitting は spanning と同じ分割処理を行いますが、分割したそれぞれを単一の removable medium へ書き込むことを必要とせず、代わりに全ての 分割物を、ローカルや、ファイルシステムやローカルドライブや フォルダなどといった non-removable な場所に置くことをサポートします。 ZIP ファイルの span と split の主な違いは、 span された ZIP ファイルはすべて同じ名前を持つことです。 各分割物が別々の volume に書き込まれるために、名前の衝突は 起こらず、それぞれの分割物はそのアーカイブに与えられた元々の .ZIP ファイル名を再利用できるのです。 DOS の span されたアーカイブの順序付けにおいては、 DOS volume label を segment number の決定に用います。 各 segment に対する volume label は、PKBACK#xxx の形式を用いて 記述され、xxx には segment number が 10 進数の 001 - nnn で入ります。 split された ZIP ファイルは典型的には同一の場所に書き込まれます。 そして、span された名前の形式が用いられるとすれば、各 segment が 同一の drive に置かれるだろうことから、名前衝突を免れません。 名前衝突を避けるために、split されたアーカイブは 次のように命名されます。 Segment 1 = filename.z01 Segment n-1 = filename.z(n-1) Segment n = filename.zip .ZIP という拡張子は、central directory の迅速な読み込みを サポートするために、最後の segment に使われます。 segment number の n は 10 進数の値であるべきです (should) 。 span された ZIP ファイルは PKSFX 自己解凍 ZIP ファイルでしょう。 PKSFX ファイルもまた、split されるでしょうけれど、この場合には 最初の segment はファイル名.exe と名付けられなければ なりません (must) 。split された PKSFX アーカイブの 最初の segment は、実行可能なプログラムの全体が入るだけの 十分な大きさがなくてはなりません (must) 。 split されたアーカイブの容量は以下のとおりです。 最大 segment 数 = 4,294,967,295 - 1 最大 .ZIP segment サイズ = 4,294,967,295 bytes 最小 segment サイズ = 64K 最大 PKSFX segment サイズ = 2,147,483,647 bytes segment のサイズは慣習によって異なるでしょうけれど、 すべての segment は同じサイズであるべき (should) で、 例外は最後のもので、それは小さくなるでしょう。 Local と central directory header record は segment 境界を またいで split されてはいけません (must never) 。 header record を書き込むときには、その segment の残りの バイト数が header record のサイズより小さい場合、 現在の segment を終わりにして、その header は次の segment の 先頭から書き込みます。central directory は segment 境界で span されるでしょうけれど、central directory の単一の record は segment を越えて split されるべきではありません (should) 。 PKZIP for Windows (V2.50 以降) と PKZIP Command Line (V2.50 以降) と PKZIP Explorer で作られた Span や Split されたアーカイブは、アーカイブの最初の segment の 先頭 4 バイトに special spanning signature を含むでしょう。 この signature (0x08074b50) の直後には、アーカイブ内の 最初のファイルの local header signature があるでしょう。 span や split の処理を始めたものの 1 つの segment しか 必要なかった場合に、special spanning marker が、 span や split されたアーカイブに現れることもあります。 この場合には、0x08074b50 signature は、 0x30304b50 という temporary spanning marker signature で 置き換えられるでしょう。split されたアーカイブは、 split アーカイブの作り方を知っている他のバージョンの PKZIP によってのみ展開されることができます。 シグニチャ値 0x08074b50 は、いくつかの ZIP 実装では Data Descriptor record のマーカとして使われてもいます。 この再定義による衝突は、ZIP ファイル内のシグニチャの 位置によって、どちらのために使っているのかを決めることで 回避できます。 L. 全体的な注釈: 1) 別記ない場合は、すべての field が unsigned で、 Intel low-byte:high-byte, low-word:high-word order で保存されます。 2) 文字列の field は、長さが明示されているため、 null 終端ではありません。 3) central directory のエントリは、.ZIP ファイルに現れるファイルの 順序と同じである必要はないでしょう。 4) end of central directory record の field のどれかが、 必要なデータを保持するのに小さすぎた場合には、その field は -1 (0xFFFF または 0xFFFFFFFF) に設定されるべき (should) で、 かつ ZIP64 フォーマットの record が作られるべき (should) です。 5) end of central directory record と Zip64 end of central directory locator record は、 split や span されたアーカイブであっても 同じ disk に置かれなければなりません (must) 。 VI. 圧縮方法の説明 -------------------------------------- UnShrinking - Method 1 ---------------------- Shrink は partial clearing つきの動的 Ziv-Lempel-Welch 圧縮アルゴリズムです。 初期の符号サイズは 9 ビットで、最大の符号サイズは 13 ビットです。 通常の動的 Ziv-Lempel-Welch 実装とはいくつかの点で異なります。 1) 符号サイズは圧縮器によって制御され、現在の符号サイズよりも長い符号が 作られた (けれど使われる必要のない) ときに、自動で増えることもありません。 伸張器が符号シーケンス 256 (10進数) に続く 1 に遭遇したとき、 入力ストリームから読み込む符号サイズを、次のビットサイズに 増やすべきです (should) 。これらの符号をブロック化することはないため、 増えたサイズである次の符号は、前のコードが小さなビットサイズで 読み込まれた直後に入力ストリームから読み込まれるべきです (should) 。 繰り返しますが、伸張器は使っている符号サイズを 256,1 のシーケンスが 現れるまで増やすべきではありません (should not) 。 2) テーブルがいっぱいになったとき、total clearing は行いません。代わりに、 圧縮器が 256,2 (10進数) のシーケンスを発行したところで、伸張器は Ziv-Lempel 木から全ての葉ノードを clear し、現在の符号サイズを 使い続けるべきです (should) 。Ziv-Lempel 木から clear されたノードは その後、符号の値が最小のものから再利用され、符合の値が最大のものが 最後に再利用されます。圧縮器はいつでも 256,2 のシーケンスを発行できます。 Expanding - Methods 2-5 ----------------------- Reduce アルゴリズムは、実際はふたつの別のアルゴリズムの組み合わせです。 ひとつめのアルゴリズムは繰り返しのバイトシーケンスを圧縮し、ふたつめの アルゴリズムは、ひとつめのアルゴリズムから圧縮ストリームを引き継いで、 確率論的圧縮方法を適用します。 確率論的圧縮は '後続の集合' S(j) の配列を保存します。j=0 から 255 で、 これはそれぞれ可能な ASCII 文字に対応します。それぞれの集合は 0 から 32 の 文字を含んでいて、それらは S(j)[0],...,S(j)[m] で m<32 において表されます。 それらの集合は Reduce されたファイルの data area の先頭に、逆順で、 つまり S(255) が最初で S(0) が最後になるように保存されます。 この集合は { N(j), S(j)[0],...,S(j)[N(j)-1] } のように符号化されます。 N(j) は集合 S(j) のサイズです。N(j) は 0 の場合もあり、そのとき 後続の S(j) は空になります。それぞれの N(j) の値は 6 ビットで符号化され、 S(j)[0] から S(j)[N(j)-1] のそれぞれに対応する N(j) の 8 ビットの文字値が そのあとに続きます。N(j) が 0 の場合は、S(j) の値は全く保存されませんし、 N(j-1) に関する値が直後に続きます。 後続の集合の直後には、圧縮されたデータストリームがあります。 圧縮されたデータストリームは、以下のように、確率論的な伸張によって 解釈されます。 let Last-Character <- 0. loop until done if the follower set S(Last-Character) is empty then read 8 bits from the input stream, and copy this value to the output stream. otherwise if the follower set S(Last-Character) is non-empty then read 1 bit from the input stream. if this bit is not zero then read 8 bits from the input stream, and copy this value to the output stream. otherwise if this bit is zero then read B(N(Last-Character)) bits from the input stream, and assign this value to I. Copy the value of S(Last-Character)[I] to the output stream. 変数 Last-Character を 0 にする。 loop until done 後続集合 S(Last-Character) が空の場合 入力ストリームから 8 ビットを読み込み、 この値を出力ストリームへコピーする。 そうでなく、後続集合 S(Last-Character) が空でない場合 入力ストリームから 1 ビット読み込む。 このビットがゼロでない場合 入力ストリームから 8 ビットを読み込み、 この値を出力ストリームへコピーする。 そうでなく、このビットがゼロの場合 入力ストリームから B(N(Last-Character)) ビットを読み込み、 この値を変数 I に代入する。 S(Last-Character)[I] の値を出力ストリームへコピーする。 最後に出力ストリームに置かれた値を Last-Character に代入する。 end loop B(N(j)) は N(j)-1 の値をエンコードするのに必要な最小のビット数として 定義されます。 上記のようにして伸張したストリームは、つぎに以下のようにして、 元のファイルを再作成するために展開できます。 変数 State を 0 にする。 loop until done 入力ストリームから 8 ビットを読み込んで変数 C に代入する。 State の値で分岐する。 0: C が DLE (10 進数で 144) と等しくない場合 C を出力ストリームへコピーする。 そうでなく、C が DLE に等しい場合 State に 1 を代入する。 1: C がゼロでない場合 V に C を代入する。 Len に L(V) を代入する。 State に F(Len) を代入する。 そうでなく、C がゼロの場合 値 144 (10 進数) を出力ストリームにコピーする。 State に 0 を代入する。 2: Len に Len + C を代入する。 State に 3 を代入する。 3: move backwards D(V,C) bytes in the output stream 出力ストリームで D(V,C) バイト前方へ戻る (もしこの位置が出力ストリームの先頭より前だった場合、 出力ストリームの先頭以前のデータが全てゼロで 埋められていると仮定する) 。 この位置から Len+3 バイトを出力ストリームへコピーする。 State に 0 を代入する。 分岐終了 end loop 関数 F と L と D は '圧縮因子' の 1 から 4 に依存し、 以下のように定義されます。 圧縮因子 1 用: L(X) は X の下位 7 ビットになる。 F(X) は、X が 127 なら 2 で、それ以外は 3 になる。 D(X,Y) は (X の最上位 1 ビット) * 256 + Y + 1 になる。 圧縮因子 2 用: L(X) は X の下位 6 ビットになる。 F(X) は、X が 63 なら 2 で、それ以外は 3 になる。 D(X,Y) は (X の上位 2 ビット) * 256 + Y + 1 になる。 圧縮因子 3 用: L(X) は X の下位 5 ビットになる。 F(X) は、X が 31 なら 2 で、それ以外は 3 になる。 D(X,Y) は (X の上位 3 ビット) * 256 + Y + 1 になる。 圧縮因子 4 用: L(X) は X の下位 4 ビットになる。 F(X) は、X が 15 なら 2 で、それ以外は 3 になる。 D(X,Y) は (X の上位 4 ビット) * 256 + Y + 1 になる。 Imploding アルゴリズムは実際は二つの別々のアルゴリズムの組み合わせです。 最初のアルゴリズムは繰り返されるバイトの並びをスライド辞書を使って 圧縮します。ふたつ目のアルゴリズムはスライド辞書によって 符号化された出力を、複数の Shannon-Fano 木を用いて圧縮します。 Imploding アルゴリズムは 4K または 8K のサイズのスライド辞書を 使うことができます。使われる辞書のサイズは general purpose flag word の bit 1 で判別できます。そのビットが 0 ならば 4K の辞書が使われ、 1 ならば 8K の辞書が使われます。 Shannon-Fano 木は圧縮されたファイルの先頭に保存されます。 保存される木の数は general purpose flag word の bit 2 で判別できます。 そのビットが 0 ならば 2 つの木が保存され、1 ならば 3 つの木が 保存されます。3 つの木が保存されているとき、最初の Shannon-Fano 木は リテラルの符号を表し、ふたつ目の木は長さの情報の符号を表し、 みっつ目は距離の情報の符号を表します。2 つの Shannon-Fano 木が 保存されているときは、長さの木が最初に保存され、次に距離の木が保存されます。 リテラルの Shannon-Fano 木があるとき、それは ASCII 文字セット全体を 表すのに使われ、256 個の値を含みます。この木はスライド辞書アルゴリズムで 圧縮されないあらゆるデータを圧縮するのに使われます。この木が存在するとき、 スライド辞書の最短の一致長さは 3 です。この木が存在しないならば、 最短の一致長さは 2 です。 長さの Shannon-Fano 木は、スライド辞書の出力における (長さ, 距離) の ペアのうち、長さの部分を圧縮するのに使われます。長さの木は、 最短の一致長さから (63 + 最短の一致長さ) までの、64 個の値を含みます。 距離の Shannon-Fano 木はスライド辞書の出力における (長さ, 距離) の ペアのうち、距離の部分を圧縮するのに使われます。距離の木は、 0 から 63 までの、64 個の値を含み、これらは距離の値の上位 6 ビットを 表します。距離の値そのものは、0 からスライド辞書のサイズである 4K か 8K までの間になるでしょう。 Shannon-Fano 木それ自体も圧縮されたフォーマットで保存されます。 木のデータの最初のバイトは (圧縮された状態での) Shannon-Fano 木を 表すデータのバイト数 - 1 の数になります。残りのバイトは以下のように 符号化された Shannon-Fano 木を表しています。 上位 4 ビット: このビット長となる値の個数 + 1 (1 - 16) 下位 4 ビット: 値を表すのに要するビット長 + 1 (1 - 16) Shannon-Fano 符号は、以下のアルゴリズムを使って、ビット長から 値を構築することができます。 1) 昇順にビット長をソートし、一方でファイルに保存されている 元のビット長の順序は保持しておく。 2) Shannon-Fano 木を生成する。 変数 Code を 0 にする 変数 CodeIncrement を 0 にする 変数 LastBitLength を 0 にする 変数 i を Shannon-Fano 木の符号の数 - 1 にする (255 か 63 のどちらか) loop while i >= 0 Code = Code + CodeIncrement if BitLength(i) <> LastBitLength then LastBitLength=BitLength(i) // 元の順序で i 番目のビット長 CodeIncrement = 1 を (16 - LastBitLength) だけ左シフト ShannonCode(i) = Code i <- i - 1 end loop 3) 上で生成した ShannonCode() 配列の全てのビットの順序を反転する。 すなわち最上位ビットが最下位ビットになる。例えば、 0x1234 (16 進数) という値は 0x2C48 (16 進数) になる。 4) Shannon-Fanno 符号の順序を、元々ファイルに保存されていたように戻す。 例: この例はサイズが 8 の Shannon-Fano 木の符号を示すでしょう。 実際に Imploding に使われる Shannon-Fano 木のサイズは 64 か 256 個の 符号を持つことに注意してください。 例: 0x02, 0x42, 0x02, 0x13 最初のバイトが、このテーブルに 3 つの値があることを示します。 続く各バイトを復号すると、 0x42 = ビット長 3 の符号が 5 つある 0x01 = ビット長 2 の符号が 1 つある 0x13 = ビット長 4 の符号が 2 つある これらから元のビット長の配列が次のように生成されます。 (3, 3, 3, 3, 3, 2, 4, 4) このテーブルにある 8 つの符号を 0 から 7 と番号付けます。 Shannon-Fano 符号を得るアルゴリズムを用いると以下のように生成されます。 番号 ソート後 生成されたコード 反転した値 戻した並び 元のビット長 --- ------ ----------------- -------- -------- ------ 0: 2 1100000000000000 11 101 3 1: 3 1010000000000000 101 001 3 2: 3 1000000000000000 001 110 3 3: 3 0110000000000000 110 010 3 4: 3 0100000000000000 010 100 3 5: 3 0010000000000000 100 11 2 6: 4 0001000000000000 1000 1000 4 7: 4 0000000000000000 0000 0000 4 番号 (Val) と戻した並び (Order Restored) と 元のビット長 (Original Length) の列こそが Shannon-Fano 符号木を 表しており、これを使って Shannon-Fano 符号化されたデータを復号できます。 データストリームから、長さがさまざまである Shannon-Fano の値を どのように読み取るのかについては、この文書の範囲外です。 (詳しくは、この文書の末尾に付したリファレンスを見てください。) ともあれ、従来より Huffman の可変長の復号に用いられる 手法である Greenlaw アルゴリズムなどが成功裏に適用できます。 圧縮されたデータストリームは、圧縮された Shannon-Fano データの 直後にあります。圧縮されたデータストリームは以下のように 読み取ることができます。 loop until done 入力ストリームから 1 ビット読み取る。 このビットが 0 でない場合 (符号化されたデータはリテラルである) リテラルの Shannon-Fano 木が存在する場合 文字を読み取り、リテラルの Shannon-fano 木で復号する。 そうでない場合 入力ストリームから 8 ビット読み取る。 文字を出力ストリームへコピーする。 そうでない場合 (符号化されたデータはスライド辞書で一致させる) 辞書サイズが 8K の場合 距離のオフセットとして 7 ビット読み取る (距離の下位 7 ビットになる) 。 そうでない場合 距離のオフセットとして 6 ビット読み取る (距離の下位 6 ビットになる) 。 距離の Shannon-Fano 木を用いて、距離の値の上位 6 ビットを 読み取り、復号する。 長さの Shannon-Fano 木を用いて、長さを読み取り、復号する。 長さを (長さ + 最短の一致長さ) にする。 長さが (63 + 最短の一致長さ) に等しい場合 入力ストリームから 8 ビット読み取り、長さの値にそれを足す。 出力ストリームにおいて、距離 + 1 バイト前方へ戻り、この位置から 長さ分の文字を出力ストリームへコピーする。(もしこの位置が 出力ストリームの先頭より前だった場合、出力ストリームの 先頭以前のデータが全てゼロで埋められていると仮定する) 。 end loop Tokenizing - Method 7 --------------------- この方法は PKZIP では使われていません。 Deflating - Method 8 -------------------- Deflate アルゴリズムは Implode アルゴリズムに似ていて、スライド辞書を 最大 32K まで用い、そのあとに Huffman/Shannon-Fano 符号で圧縮します。 圧縮データはブロック毎に保存され、各ブロックには、そのブロックと、 そのブロックで使われている Huffman 符号を表すヘッダがあります。 ヘッダのフォーマットは以下のようになっています。 Bit 0: Last Block bit このビットは、このブロックがデータ内で 最後の圧縮ブロックのときに 1 に設定されます。 Bits 1-2: Block type 00 (0) - ブロックは単に保存されている - 全ての保存されているデータは バイト境界で揃えられています。次のバイトまでビットを スキップし、その次の word はブロック長で、そのあとに ブロック長 word の 1 の補数が続きます。ブロックの 残りのデータは保存されたデータです。 01 (1) - リテラルと距離の符号に、固定 Huffman 符号を用いる Lit Code Bits Dist Code Bits --------- ---- --------- ---- 0 - 143 8 0 - 31 5 144 - 255 9 256 - 279 7 280 - 287 8 リテラルコードの 286-287 と距離コードの 30-31 が 使われることはありませんが、Huffman を生成するときには 考慮します。 10 (2) - 動的 Huffman 符号 (expanding Huffman codes の項を参照) 11 (3) - 予約 - これが出てきたなら "圧縮データにエラー" を示します。 データブロックが動的 Huffman 符号を用いて保存されている場合、 Huffman 符号は以下の圧縮されたフォーマットで与えられます。 5 Bits: リテラルコードの数 - 256 (256 - 286 を表します) 他のあらゆるコードは与えられません。 5 Bits: 距離コードの数 - 1 (1 - 32 を表します) 4 Bits: ビット長コードの数 - 3 (3 - 19 を表します) Huffman 符号はビット長で与えられ、その符号は Implode アルゴリズムの項で 説明したような方法で生成されます。ビット長それ自体も Huffman 符号で 圧縮されます。ビット長コードは 19 個あります。 0 - 15: ビット長 0 - 15 を表します 16: 前のビット長を 3 - 6 回コピーします。 次の 2 ビットが繰返す回数を示します (0 = 3, ..., 3 = 6) 例: 符号 8, 16 (続く 2 ビットが 11), 16 (続く 2 ビットが 10) は 12 個のビット長 8 へと展開されます (1 + 6 + 5) 17: ビット長 0 を 3 - 10 回、繰返します。 (回数を表す 3 ビットが続きます) 18: ビット長 0 を 11 - 138 回、繰返します。 (回数を表す 7 ビットが続きます) ビット長コードのコード長は、以下の順で各値が 3 ビット (0 - 7) として 与えられます。 16, 17, 18, 0, 8, 7, 9, 6, 10, 5, 11, 4, 12, 3, 13, 2, 14, 1, 15 Huffman 符号は Implode アルゴリズムの項で示したように 生成されるべき (should) ですが、ただし符号はビット長が最短のものから順に 割り当てられます。例えば、最短の符号はオール 1 よりもオール 0 で あるべき (should) です。また、ビット長が 0 の符号は木の構築に関与しません。 このコードは、続いてリテラルと距離のテーブルのビット長を復号するために 使われます。 リテラルのテーブルのためのビット長は、初めはエントリ数として、 先に与えられた 5 ビットで示されます。リテラルの最大数は 286 個です。 このうち始めの 256 個はそれぞれ 8 ビット文字を表し、コード 256 は End-Of-Block コードを表し、残りの 29 個のコードでコピーする長さの 3 から 258 を表します。最大 30 個の距離コードがあり、1 から 32k の距離を 以下のように表します。 長さコード ------------ Extra Extra Extra Extra Code Bits Length Code Bits Lengths Code Bits Lengths Code Bits Length(s) ---- ---- ------ ---- ---- ------- ---- ---- ------- ---- ---- --------- 257 0 3 265 1 11,12 273 3 35-42 281 5 131-162 258 0 4 266 1 13,14 274 3 43-50 282 5 163-194 259 0 5 267 1 15,16 275 3 51-58 283 5 195-226 260 0 6 268 1 17,18 276 3 59-66 284 5 227-257 261 0 7 269 2 19-22 277 4 67-82 285 0 258 262 0 8 270 2 23-26 278 4 83-98 263 0 9 271 2 27-30 279 4 99-114 264 0 10 272 2 31-34 280 4 115-130 距離コード -------------- Extra Extra Extra Extra Code Bits Dist Code Bits Dist Code Bits Distance Code Bits Distance ---- ---- ---- ---- ---- ------ ---- ---- -------- ---- ---- -------- 0 0 1 8 3 17-24 16 7 257-384 24 11 4097-6144 1 0 2 9 3 25-32 17 7 385-512 25 11 6145-8192 2 0 3 10 4 33-48 18 8 513-768 26 12 8193-12288 3 0 4 11 4 49-64 19 8 769-1024 27 12 12289-16384 4 1 5,6 12 5 65-96 20 9 1025-1536 28 13 16385-24576 5 1 7,8 13 5 97-128 21 9 1537-2048 29 13 24577-32768 6 2 9-12 14 6 129-192 22 10 2049-3072 7 2 13-16 15 6 193-256 23 10 3073-4096 圧縮されたデータのストリームは、圧縮されたヘッダの直後から始まります。 圧縮されたデータのストリームは以下のように読み取ることができます。 do 入力ストリームからヘッダを読み込む。 単に保存されているブロックの場合 バイト境界までビットをスキップする バイト数と、その 1 の補数を読み込む バイト数のぶんデータブロックをコピーする そうでない場合 loop End-Of-Block コードが現れるまで 入力ストリームからリテラル文字を復号する リテラル < 256 の場合 文字を出力ストリームへコピーする そうでない場合 リテラルが End-Of-Block の場合 loop を抜ける そうでない場合 入力ストリームから距離を復号する 距離のバイト数だけ出力ストリームを前方へ戻り、 この位置から長さ分の文字を出力ストリームへコピーする。 end loop while 最終ブロックでない間 if data descriptor があれば バイト境界までビットをスキップする crc とサイズを読み込む endif Enhanced Deflating - Method 9 ----------------------------- Enhanced Deflating アルゴリズムは Deflate と同様ですが、 スライド辞書を最大 64K まで使います。Deflate64(tm) は Deflate extractor でサポートされます。 BZIP2 - Method 12 ----------------- BZIP2 はオープンソースのデータ圧縮アルゴリズムで、Julian Seward によって 開発されました。このアルゴリズムについての情報とソースコードは インターネットで見つけることができます。 LZMA - Method 14 (EFS) ---------------------- LZMA はブロックに基づいた、一般に用いられるデータ圧縮アルゴリズムで、 Igor Pavlov によって開発され、保守されています。これは、マルコフ連鎖と レンジコーダを利用した LZ77 の派生です。このアルゴリズムについての 情報とソースコードはインターネットで見つけることができます。 使用にあたっての条件や制限については、このアルゴリズムの作者に 問い合わせてください。 ZIP フォーマットでの LZMA サポートは以下のように定義されます。 ZIP の Local と Central Header record にある Compression method field は、 データが LZMA を用いて圧縮されたことを示すために 14 という値が 設定されるでしょう (will be) 。 ZIP の Local と Central Header record にある Version needed to extract field は、この機能をサポートする 最小の ZIP フォーマットのバージョンを示すために 6.3 に 設定されるでしょう (will be) 。 LZMA アルゴリズムを用いて圧縮されたファイルデータは、 そのファイルの Local Header の直後に置かれなければなりません (must) 。 もし standard ZIP encryption header が必要ならば、 これが Local Header に続くでしょう (will) し、 LZMA で圧縮されたファイルデータ区画の前にあるでしょう (will) 。 LZMA で圧縮されたデータ区画の、ZIP フォーマットにおける位置は、 次のように示されるでしょう (will) 。 [local header file 1] [encryption header file 1] [LZMA compressed data segment for file 1] [data descriptor 1] [local header file 2] encryption header と data descriptor record が存在するのは 場合によるでしょう (may be) 。LZMA Compressed Data Segment は、 以下に示すように、LZMA Properties Header とそれに続く LZMA Compressed Data から成るでしょう (will) 。 [LZMA properties header for file 1] [LZMA compressed data for file 1] LZMA Compressed Data は LZMA 圧縮ライブラリが出力したものを 保存するでしょう (will) 。圧縮されているファイルについての compressed size と uncompressed size とファイル関連の他の値は、 標準の ZIP 保存フォーマットで保存されなければなりません (must) 。 LZMA Properties Header は LZMA compressed Data を伸張するのに必要な 特定のデータを保存するでしょう (will) 。このデータは、 LZMA compression engine が、LZMA SDK の文書にあるように WriteCoderProperties() 関数を用いて設定します。 LZMA Properties Header におけるプロパティ情報を保存する field は 以下のようになっています。 LZMA Version Information 2 バイト LZMA Properties Size 2 バイト LZMA Properties Data 可変 ("LZMA Properties Size" で定義される) LZMA Version Information - この field は、LZMA SDK のどのバージョンが ファイルを圧縮するのに使われたかを示します。最初のバイトは LZMA SDK のメジャーバージョン番号を保存するでしょう (will) し、 二番目のバイトはマイナー番号を保存するでしょう (will) 。 LZMA Properties Size - この field は、このあとのプロパティデータの サイズを定義します。典型的には、このサイズは SDK のバージョンで 決まるべき (should) です。このサイズ field は、利便性のためと、 将来においてこの圧縮アルゴリズムの変更により発生するであろう 何らかの曖昧さを避ける助けのために、含まれています。 LZMA Properties Data - この可変サイズの field は LZMA SDK によって定義される、 伸張器で必要な値を記録します。この field に保存されたデータは、 "LZMA Version Information" field で定義された SDK のバージョンにおける WriteCoderProperties() を使って取得されるべき (should) です。 "LZMA Properties Data" field をレイアウトすることは LZMA 圧縮アルゴリズムの ひとつの機能です。このレイアウトはいつでも作者によって 変更されうる (may be) 可能性があります。LZMA SDK のバージョン 4.32 での このデータのレイアウトは、5 バイトの配列で、うち 4 バイトが辞書サイズを リトルエンディアンの順序で保存するのに使われます。あとの 1 バイトが その前にきて配列の先頭の要素となり、以下の field を含みます。 PosStateBits LiteralPosStateBits LiteralContextBits これらの field のより詳しい説明については LZMA の文書を参照してください。 圧縮方法 14 の LZMA で圧縮されたデータは、圧縮データのストリーム末尾に end-of-stream (EOS) マーカを含むでしょう (may) 。このマーカは必須では ありませんが、処理の利便のために使用することが強く推奨されており、 実装者は可能なかぎり EOS マーカを含めるべき (should) です。 EOS マーカが使われるとき、general purpose bit 1 が設定されなければ なりません (must) 。general purpose bit 1 が設定されていないならば、 EOS マーカは存在しません。 WavPack - Method 97 ------------------- 圧縮方法 97 の使い方に関する情報は WinZIP International, LLC によって 提供されます。この方法は、David Bryant によって開発された オープンソースの WavPack オーディオ圧縮ユーティリティに依存しています。 WavPack についての情報は www.wavpack.com で入手できます。 使用にあたっての条件や制限については、このアルゴリズムの作者に 問い合わせてください。 あるファイルに対する WavPack データは、その local header データの末尾の 直後から始まります。このデータは WavPack 圧縮ルーチンの出力です。 ZIP ファイルにおいては、WavPack 圧縮の使用は、local header と central directory header の両方にある compression method field の値を 97 に設定することで示されます。version needed to extract と version made by の field は、Deflate アルゴリズムを用いて データが圧縮される場合と同じ値を使います。 WavPack 圧縮を ZIP ファイルで用いてデジタルサンプルデータを保存する際の 実装上の注意としては、サンプルデータの全てのバイトが 圧縮されるべき (should) ということです。これによりバイト境界に達するまでの 不使用のビットが含まれます。例えば、2 バイトのサンプルが 12 ビットだけを サンプルデータとして使用し、4 ビットが不使用とします。WavPack ルーチンに サンプルサイズとして 12 ビットだけが渡された場合、それらの元の状態に 関わらず、展開時には不使用の 4 ビットが 0 に設定されるでしょう (will) 。 これを避けるためには、サンプルデータサイズの 16 ビットいっぱいを 渡すべき (should) です。 PPMd - Method 98 ---------------- PPMd は Dmitry Shkarin によって開発されたデータ圧縮アルゴリズムで、 それには Dmitry Subbotin によって開発された桁上がりの無いレンジコーダが 含まれます。このアルゴリズムは multiple order contexts における predictive phrase matching に基づいています。このアルゴリズムについての 情報とソースコードはインターネットで見つけることができます。 使用にあたっての条件や制限については、このアルゴリズムの作者に 問い合わせてください。 ZIP フォーマットにおける PPMd のサポートは現在のところバージョン I 、 アルゴリズムのリビジョン 1 のみが提供されています。このアルゴリズムを 使うにあたっての保存に関する要件は以下のとおりです。 アルゴリズムを制御するためのパラメタは、圧縮データの直前に 2 バイトで 保存されます。これらのバイトは、以下の field を保存するために使われます。 Model order - 最大の model order を設定します。デフォルトは 8 で、 値は 2 から 16 を表します。 Sub-allocator size - sub-allocator のサイズを MB 単位で設定します。 デフォルトは 50 で値は 1MB から 256MB を表します。 Model restoration method - メモリが十分でなくなった際の context model の restart に使用する method を設定します。値は以下のとおりです。 0 - scratch から model を restart します - デフォルト 1 - model を切り詰めます - 2 倍ほどパフォーマンスが落ちます 2 - context tree を freeze します - 推奨されません これらの field を 2 バイトの保存領域に格納する例は以下で説明されます。 これらの値は Intel low-byte/high-byte order で保存されます。 wPPMd = (Model order - 1) + ((Sub-allocator size - 1) << 4) + (Model restoration method << 12) VII. 従来の PKWARE 暗号 ---------------------------------- 以下の情報は、従来の PKWARE 暗号のサポートに必要な復号のステップを 記述したものです。この暗号形式は、現在の標準的な方法よりも弱いと 考えられていて、また、これを使うことは、低いセキュリティを 必要とする状況や古い .ZIP アプリケーションとの互換性のためにのみ、 推奨されています。 復号 ---------- PKWARE は Roger Schlafly 氏の、PKWARE の従来の暗号を開発するに あたっての専門的な貢献に敬意を表します。 PKZIP は圧縮したデータストリームを暗号化します。暗号化されたファイルを 伸張できるようにする前に、復号しなければなりません (must) 。 暗号化されたファイルそれぞれは、データ領域の先頭に追加の 12 バイトが 保存され、これがそのファイルの encryption header と定義されています。 encryption header には要するに乱数が設定されますが、これ自体も 三つの 32 ビットのキーで暗号化されます。キーの値は、与えられる 暗号化パスワードを使って初期化されます。各バイトを暗号化したあと、 各キーは、擬似乱数を生成する方法を、PKZIP で使われているのと同じ CRC-32 アルゴリズムと組み合わせて使って更新されます。 CRC-32 アルゴリズムについてはこの文書の別の場所で記述しています。 以下は、ファイルを復号するのに要する基本的なステップです。 1) パスワードによって、三つの 32 ビットのキーを初期化する。 2) 12 バイトの encryption header を読み込んで復号し、 さらに暗号化キーを初期化する。 3) 暗号化キーを使って、圧縮されたデータストリームを読み込んで復号する。 Step 1 - 暗号化キーの初期化 ----------------------------------------- Key(0) を 305419896 にする Key(1) を 591751049 にする Key(2) を 878082192 にする loop i を 0 から (パスワードの長さ - 1) まで update_keys(password(i)) end loop update_keys() は以下のように定義されています。 update_keys(char): Key(0) を crc32(key(0),char) にする Key(1) を Key(1) + (Key(0) & 0x000000ff) にする Key(1) を Key(1) * 134775813 + 1 にする Key(2) を crc32(key(2),key(1) >> 24) にする end update_keys crc32(old_crc,char) は CRC の値と文字を与えられて、CRC-32 アルゴリズムを 適用して更新した CRC の値を返すルーチンです。CRC-32 アルゴリズムに ついてはこの文書の別の場所で記述しています。 Step 2 - encryption header の復号 ----------------------------------------- このステップの目的は、乱数データに基づいて暗号化キーを さらに初期化することで、無効なデータでの plaintext attack に 対することです。 12 バイトの encryption heeader を Buffer へ読み込み、 これを Buffer(0) から Buffer(11) とします。 loop i を 0 から 11 まで C を Buffer(i) ^ decrypt_byte() にする update_keys(C) Buffer(i) を C にする。 end loop decrypt_byte() は次のように定義されます。 unsigned char 型を返す decrypt_byte() 変数 temp を local unsigned short 型とする temp を Key(2) | 2 にする (temp * (temp ^ 1)) >> 8 を decrypt_byte の返り値とする end decrypt_byte header を復号すると、Buffer に残った最後の 1 または 2 バイトは、 復号対象のファイルの CRC の high-order word/byte でしょう (should be) し、 Intel low-byte/high-byte order で保存されます。PKZIP の 2.0 より前の バージョンでは 2 バイト CRC チェックが使われています。2.0 以降の バージョンでは 1 バイトの CRC チェックが使われています。この値を、 与えられたパスワードが正しいか否かをテストするために使うことができます。 Step 3 - 圧縮されたデータストリームの復号 ----------------------------------------------- 圧縮されたデータストリームは以下のように復号できます。 loop until done C にひと文字読み込む temp を C ^ decrypt_byte() にする update_keys(temp) temp を出力する end loop VIII. Strong Encryption 仕様 ------------------------------------- この文書で定義されている Strong Encryption の技術は特許として出願中です。 現在の APPNOTE にあるような、なんらかの技術的な点における、製品での 使用や実装は、strong encryption や patching や extended tape operation と みなされるものと併せての使用や実装を含めて、PKWARE からの許諾が必要です。 この Strong Encryption 技術のいくつかの部分は、無料で使用することができます。 許諾の条件などについては PKWARE に問い合わせてください。PKWARE への 連絡方法は、APPNOTE のセクション II (PKWARE の連絡先) を参照してください。 この仕様のバージョン 5.x で、strong encryption アルゴリズムのサポートが 導入されました。これらのアルゴリズムは、パスワードでも X.509v3 の デジタル証明書でも、それぞれのファイルの暗号化するために使うことができます。 このフォーマット仕様では、現在のセキュリティの要請に合わせてパスワード または証明書に基づいた暗号化をサポートしています。これにより PKI を 使う環境と使わない環境のユーザ間で相互に運用できたり、ZIP プログラムを 実行する異なるコンピュータのプラットフォーム間での相互の運用を 確実にすることを見込んでいます。 パスワードに基づいた暗号化は、人々に馴染みのある最も一般的な 暗号化の形式です。しかし、パスワードの本質的な弱点 (例えば dictionary/brute force attack にやられやすい点) は パスワードの管理やサポート状況にもあり、こうしたことが 証明書に基づいた暗号化をより安全でスケール可能な選択肢にしています。 産業界の尽力と助力は、X.509v3 のデジタル証明書と Public Key Infrastructures (PKI) の周辺に構築されたより先進的な セキュリティのソリューションを定義し、それに向けて動いています。 なぜなら、それらは従来のパスワードに基づいた暗号化よりも、 よりスケール可能で、管理における選択肢も多く、より強固だからです。 最も標準的な暗号化アルゴリズムがこの仕様ではサポートされています。 これらのアルゴリズムの多くが、参照実装として商業とオープンソースとを 問わず配付されています。すぐに利用できる暗号ツールキットによって この暗号化の機能を簡単に実装できます。この文書はデータ暗号化の原理 や理論の専門書であることは意図していません。この文書の目的は、 .ZIP フォーマットでの相互に運用可能なデータ暗号化の実装に要する データ構造を文書化することです。以下を読む前に、読者には データ暗号化について十分に理解することを強く推奨します。 この仕様のバージョン 5.0 で導入されたアルゴリズムには以下が含まれています。 バージョン 5.1 では以下のサポートが追加されました。 AES 128 bit, 192 bit, and 256 bit バージョン 6.1 ではスマートカードや USB トークンの certificate storage method との相互の運用性をサポートするために 暗号データが変更されました。ここでは OAEP strengthening standard は サポートされません。 バージョン 6.2 では情報の漏れを減らすために、 central directory data structure を圧縮して暗号化することで、メタデータの 暗号化のサポートが追加されました。情報の漏れは古い ZIP アプリケーションで、 ファイルについての情報がさらけ出されていることによって、たとえそのファイルが 暗号化されて保存されていたとしても、起こりえます。さらけ出されていた情報とは、 この仕様で定義されている record や field に保存されているファイル関連の 値です。これにはファイル名やファイルの圧縮前のサイズやタイムスタンプ、 CRC32 の値などが含まれます。 バージョン 6.3 では Blowfish と Twofish のアルゴリズムを使ったデータの 暗号化のサポートが追加されました。これらは Bruce Schneier によって 開発された対称ブロック暗号です。Blowfish は 32 から 448 ビットの 可変長のキーをサポートします。ブロックのサイズは 64 ビットです。 実装は 16 ラウンドを使うべき (should) で、ZIP ファイルでサポートしている モードは CBC のみです。Twofish は 128 と 192 と 256 ビットのキーのサイズを サポートします。ブロックのサイズは 128 ビットです。実装は 16 ラウンドを 使うべき (should) で、ZIP ファイルでサポートしているモードは CBC のみです。 Blowfish と Twofish のアルゴリズムについての情報とソースコードは インターネットで見つけることができます。使用にあたっての 条件や制限については、これらのアルゴリズムの作者に問い合わせてください。 Central Directory Encryption は情報の漏れに対して、 Central Directory structure を暗号化し、暗号化されない Local Header にもある 鍵となる値をマスクすることによって、より良い保護を与えます。 暗号化された Central Directory structure を解釈できない ZIP 互換の プログラムは、伸張の際の情報として対応する Local Header にあるデータに 頼ることはできません。 Extra Field はファイルに関する情報を含むでしょうけれど、それらを さらけ出したくなければ、Local Header には保存されるべきでなく (should not) 、 Central Directory なら暗号化できるので、そちらにのみ 書き込まれるべき (should) です。この設計は現在はストリーミングを サポートしていません。End of Central Directory record と Zip64 End of Central Directory Locator と Zip64 End of Central directory record にある情報は暗号化されません。 Central Directory を暗号化している ZIP ファイルに含まれているファイルの データを見るためにアクセスするには、適切なパスワードまたは秘密鍵が 復号のために、アーカイブ内のあらゆるファイルや ファイルに関するあらゆる情報を見るよりも前に必要とされます。 Central Directory Encryption 機能に馴染みのない古い ZIP 互換のプログラムは、 もはや Central Directory を認識することができないでしょう (will) し、 その ZIP ファイルを不正なものと決めつけるでしょう (may) 。 Local Header を使ったストリーミングアクセスをしようとするプログラムは、 それぞれのファイルについて無効な情報に遭遇するでしょう (will) 。 Central Directory Encryption は全ての ZIP ファイルに対して使われる必要は ありません。より強いセキュリティのために使うことを推奨します。 Central Directory Encryption を使わない ZIP ファイルは以前と同様に 操作されるべき (should) です。 この strong encryption 機能の仕様は、単なるパスワードによる暗号化から 認証された公開鍵や秘密鍵での暗号化までをカバーするようなスケール可能で クロスプラットフォームな暗号の必要性に対応しようとするものです。 暗号はデータの機密性とプライバシーを提供します。暗号と組み合わせて X.509 デジタル署名を用いて、認証や否認防止を追加することが推奨されています。 Single Password Symmetric Encryption Method: -------------------------------------------- strong encryption アルゴリズムを用いた Single Password Symmeetric Encryption Method は、このフォーマットにおいて 定義されている従来の PKWARE 暗号と同様に扱います。strong アルゴリズムの 処理に必要なデータ構造が追加されます。 Strong Encryption のデータ構造は以下のようになっています。 1. General Purpose Bits - local と central header record の両方にある General Purpose bit flag の bit 0 と bit 6 について。両方のビットを 設定することで strong encryption を示します。bit 13 は設定されているとき Central Directory が暗号化されていることを示しますが、 これは Local Header にある選択された field が、それらの実際の値を隠すために マスクされていることをも示します。 2. central header にのみある Extra Field 0x0017 について。 この record にある考慮すべき field は以下のとおりです。 Format - この record のデータフォーマットの識別子です。現在のところは integer の 2 のみが許容される値です。 AlgId - integer の値で暗号化アルゴリズムの識別子を示します。値の範囲は 以下のとおりです。 0x6601 - DES 0x6602 - RC2 (version needed to extract < 5.2) 0x6603 - 3DES 168 0x6609 - 3DES 112 0x660E - AES 128 0x660F - AES 192 0x6610 - AES 256 0x6702 - RC2 (version needed to extract >= 5.2) 0x6720 - Blowfish 0x6721 - Twofish 0x6801 - RC4 0xFFFF - Unknown algorithm Bitlen - キーの明示的なビット長です。 Flags - 復号のために必要な、処理のフラグです。 0x0001 - 復号にはパスワードが必要 0x0002 - 証明書のみ 0x0003 - 復号にはパスワードまたは証明書のいずれかが必要 0x0003 より大きい値は証明書の処理のために予約されています。 3. 圧縮されたファイルのデータの前にある Decryption header record について。 -Decryption Header: Value Size Description ----- ---- ----------- IVSize 2 bytes initialization vector (IV) のサイズ IVData IVSize このファイル用の initialization vector Size 4 bytes このあとに続く decryption header のデータのサイズ Format 2 bytes この record のフォーマットの定義 AlgID 2 bytes 暗号化アルゴリズムの識別子 Bitlen 2 bytes 暗号化キーのビット長 Flags 2 bytes 処理のフラグ ErdSize 2 bytes Encrypted Random Data のサイズ ErdData ErdSize Encrypted Random Data Reserved1 4 bytes 予約された証明書の処理のデータ Reserved2 (var) 証明書の処理のデータのために予約されている VSize 2 bytes password validation data のサイズ VData VSize-4 password validation data VCRC32 4 bytes password validation data の標準 ZIP CRC32 IVData - IV のサイズはアルゴリズムのブロックサイズと 一致すべき (should) です。IVData は完全にランダムなデータで ありえます。ランダムに生成されたデータのサイズが ブロックサイズと一致しない場合は、ゼロで補完されるか 必要なだけ切り詰められるべき (should) です。IVSize が 0 ならば、 IV = CRC32 + 圧縮前のファイルサイズ (64 ビットの リトルエンディアンで unsigned integer の値とする) です。 Format - この record のためのデータフォーマットの識別子です。 現在のところは integer の 3 のみが許容される値です。 AlgId - integer の値で暗号化アルゴリズムの識別子を示します。値の範囲は 以下のとおりです。 0x6601 - DES 0x6602 - RC2 (version needed to extract < 5.2) 0x6603 - 3DES 168 0x6609 - 3DES 112 0x660E - AES 128 0x660F - AES 192 0x6610 - AES 256 0x6702 - RC2 (version needed to extract >= 5.2) 0x6720 - Blowfish 0x6721 - Twofish 0x6801 - RC4 0xFFFF - Unknown algorithm Bitlen - キーの明示的なビット長です。 Flags - 復号のために必要な、処理のフラグです。 0x0001 - Password is required to decrypt 0x0002 - Certificates only 0x0003 - Password or certificate required to decrypt 0x0001 - 復号にはパスワードが必要 0x0002 - 証明書のみ 0x0003 - 復号にはパスワードまたは証明書のいずれかが必要 0x0003 より大きい値は証明書の処理のために予約されています。 ErdData - Encrypted random data には、ファイルのセッションキーを 生成するのに使われたランダムなデータを置きます。 セッションキーは、それぞれのファイルを暗号化するためのものです。 SHA1 を用いて、キーを生成するのに使われたハッシュデータを 計算します。ファイルのセッションキーはマスターの セッションキーから生成され、マスターはユーザの入力した パスワードから生成されます。decryption header の Flags field が値 0x4000 を含んでいた場合、ErdData field は 3DES を使って復号されなければなりません (must) 。 値 0x4000 が設定されていない場合、ErdData field は AlgId を使って復号されなければなりません (must) 。 Reserved1 - 証明書の処理のために予約されており、値がゼロならば Reserved2 のデータは存在しません。このデータ構造の 詳細については Certificate Processing Method の項にある 説明を参照してください。 Reserved2 - 存在するなら、Reserved2 のデータ構造のサイズは、 この field の最初の 4 バイトをスキップした先の 2 バイトに 位置し、残りのサイズを示します。このデータ構造の詳細については Certificate Processing Method の項にある説明を参照してください。 VSize - このサイズの値は、いつでも VCRC32 の 4 バイトを 含むでしょう (will) し、かつ 4 バイトよりも 大きいでしょう (will) 。 VData - パスワードの判定のためのランダムなデータです。このデータは VSize の長さがあり、かつ VSize は暗号化のブロックサイズの 倍数でなければなりません (must) 。VCRC32 は VData の チェックサム値です。VData と VCRC32 は暗号化されて 保存されますし、ファイルの暗号化されたデータのストリームの 先頭です。 4. 便利な Tips Strong Encryption は、いつでも圧縮後のファイルに適用されます。 ブロックによるアルゴリズムのすべては Cypher Block Chaining (CBC) mode で 操作します。AES 暗号で使われるブロックサイズは 16 です。他のすべての ブロックアルゴリズムはブロックサイズに 8 を使います。RC2 にはふたつの ID が定義されており、これらを Windows XP SP1 とそれ以前の 全てのバージョンの Windows での暗号ライブラリにおける RC2 アルゴリズムの 実装に含まれる矛盾を区別するために用います。長さゼロのファイルは 暗号化しないことを推奨しますが、それらが ZIP ファイルにあるならば、 プログラムはそれらを展開する準備をするべき (should) です。 暗号化プロセスの擬似コードによる説明は以下のとおりです。 関数名と引数については選択した暗号ツールキットでどうなっているか 次第でしょう (will)。ほとんどどんなツールキットでも、それぞれの アルゴリズムの参照実装をサポートしているものは使えます。 RSA BSAFE(r) と OpenSSL と Microsoft CryptoAPI といったライブラリは、 どれも十分に機能することが知られています。 Single Password - Central Directory Encryption: ------------------------------------------------ Central Directory Encryption は .ZIP フォーマットにおいては、 その Central Directory structure を暗号化することで達成されます。 こういったメタデータをこうしてカプセル化することは .ZIP ファイルの処理で しばしば行われます。追加のメタデータが冗長性のために各ファイルの Local Header に保存されます。Central Directory を暗号化することで メタデータを秘密にする処理は、そうした Local Header にあるデータを 保護するものではありません。Local Header にあるメタデータが さらけ出されることによる情報の漏れを避けるために、ファイルに関する情報を 含む field はマスクされます。 Local Header: マスクすることで、Local Header にあるファイルに関する field の本当の内容は、 偽の情報で置き換えられます。マスクされていると、Local Header は ストリーミングアクセスに適していませんし、損傷したアーカイブからの データリカバリのためのオプションは省略されます。Extra Data field が 機密データを含むようならば、Local Header に保存すべきでは ありません (should not) 。Version needed to extract field に設定される値は、 Central Directory Encryption を考慮しないときのファイルの展開に必要な 正しい値にすべき (should) です。Local Header にある field で、 Central Directory が暗号化されたときにマスクする対象となるものは 以下のとおりです。 Field Name Mask Value ------------------ --------------------------- compression method 0 last mod file time 0 last mod file date 0 crc-32 0 compressed size 0 uncompressed size 0 file name (variable size) Base 16 の値で、 1 - 0xFFFFFFFFFFFFFFFF の範囲の 文字列であり、サイズは file name length field に 設定されているだろう (will) マスクされた file name に設定される Base 16 の値というのは、単に 最初のファイルを 1 として、ファイルごとに順次増えていく値のことです。 ZIP ファイルをこのように変更することで、それぞれのファイルには異なる値が 設定されるでしょう (may) 。互換性のために Local Header の file name field は、 けっして空にしておくべきではありません (should) 。この仕様の バージョン 6.2 では Compression Method と Compressed Size の field は、 まだマスクされていません。ZIP64 フォーマットにおいて、field が 0xFFFF や 0xFFFFFFFF の値をもつならば、マスクされるべきでは ありません (should not) 。 Encrypting the Central Directory: Central Directory の暗号化では、暗号化しないものとして、 Central Directory Signature data と Zip64 End of Central Directory record と Zip64 End of Central Directory Locator と End of Central Directory record が あります。また、ZIP file comment data が暗号化されることはありません。 Central Directory を暗号化するまえに、それは圧縮されていることも あるでしょう (may) 。圧縮することは必須ではありませんが、保存容量の 有効利用のために、この構造が暗号化前に圧縮されているだろう (will) ことが 想定されます。同時に、この仕様では Central Directory を圧縮しても 暗号化は必須ではないという仕様もサポートしています。この機能の初期の実装では、 ファイルの暗号化に使われた encryption method が Central Directory の 暗号化にも適用されることを想定するでしょう (will) 。 Central Directory の暗号化はファイルの暗号化と同様に行います。 暗号化されたデータの前には decryption header が付きます。 この decryption header は Archive Decryption Header として知られています。 この record の field は暗号化された各ファイルの先頭にある decryption header と同じです。Archive Decryption Header の位置は、 Zip64 End of Central Directory record にある Start of the Central Directory field で決まります。 Central Directory を暗号化するときは、 Zip64 End of Central Directory record が常に存在するでしょう (will) 。 Zip64 End of Central Directory record の構成は、この仕様の 6.2 以降の すべてのバージョンで Version 2 のフォーマットでしょう (will) 。 Version 2 のフォーマットは以下のとおりです。 この record の Version 1 にもある、先頭のほうの固定長の field は そのまま残ります。record signature は Version 1 でも Version 2 でも 0x06064b50 でしょう (will) 。この record の Version 2 で定義される 新しい field が始まるのは、 Offset of Start of Central Directory With Respect to the Starting Disk Number という field の最後のバイトの直後からでしょう (will) 。 New fields for Version 2: 注: すべての field は Intel low-byte/high-byte order で保存されます。 Value Size Description ----- ---- ----------- Compression Method 2 bytes Central Directory の圧縮に 使われた Method Compressed Size 8 bytes 圧縮されたデータのサイズ Original Size 8 bytes 元々の圧縮されていないサイズ AlgId 2 bytes 暗号化のアルゴリズムの ID BitLen 2 bytes 暗号化キーの長さ Flags 2 bytes 暗号化のフラグ HashID 2 bytes ハッシュアルゴリズムの識別子 Hash Length 2 bytes ハッシュデータの長さ Hash Data (variable) ハッシュデータ Compression Method の値の範囲は、Central Header の対応する field の 値の範囲と同じです。 Compressed Size と Original Size の値には、 Central Directory Signature のデータは、圧縮されたり暗号化されたりしていても、 含まれないでしょう (will not) 。 AlgId と BitLen と Flags の field には、 0x0017 record にある対応する field と同じ範囲の値が入ります。 Hash ID は Central Directory のデータをハッシュするのに使われた アルゴリズムを識別します。このデータがハッシュされる必要が無いのは、 HashID と Hash Length の両方が 0 であろう (will) 場合です。 HashID のとりうる値は以下のとおりです。 Value Algorithm ------ --------- 0x0000 none 0x0001 CRC32 0x8003 MD5 0x8004 SHA1 0x8007 RIPEMD160 0x800C SHA256 0x800D SHA384 0x800E SHA512 Central Directory のデータが署名されているときには、 同じハッシュアルゴリズムが Central Directory の署名用のハッシュにも 使われるべき (should) です。これは処理の効率のために推奨されていますが、 上記のどのアルゴリズムでも署名の処理にだけ使うことが許されています。 Hash Data には Central Directory のためのハッシュデータが 保存されているでしょう (will) 。このデータの長さは使われたアルゴリズムに 応じて可変でしょう (will) 。 Version Needed to Extract は 62 が設定されるべき (should) です。 Total Number of Entries on the Current Disk の値は 0 でしょう (will) 。 これらの record は Central Directory を暗号化するのであれば、 ランダムアクセスをサポートしなくなるでしょう (will) 。 Central Directory が圧縮と暗号化の両方またはどちらかをされているとき、 End of Central Directory record は Total Number of Entries in the Central Directory の値として 0xFFFFFFFF を保存するでしょう (will) 。 Total Number of Entries in the Central Directory on this Disk field は 0 でしょう (will) 。本物の値は Zip64 End of Central Directory record の 同様の field に保存されるでしょう (will) 。 Central Directory を復号して伸張するには、ファイルを復号して伸張するのと 同じ方法を行います。 Certificate Processing Method: ----------------------------- ZIP ファイルの暗号化のための Certificate Processing Method は 以下のような追加のデータ field を定義しています。 1. Certificate Flag Values 追加の処理フラグは、central directory の Extra Field での 0x0017 の field と、 圧縮されたファイルのデータの直前にある Decryption header record との 両方の Flags field において、以下のようになっています。 0x0007 - 将来の使用のために予約されている 0x000F - 将来の使用のために予約されている 0x0100 - non-OAEP key wrapping が使われたことを示します。 この field がこの値に設定された場合、 version needed to extract は 61 以上にしなければ なりません (must) 。これは、Master Session Key が 生成される際に ErdData が使われるときには、 OAEP key wrapping が使われないという意味です。 0x4000 - ErdData は 3DES-168 を使って復号されなければ なりません (must) 。他の場合は、ファイルの内容を 暗号化するのに使われたアルゴリズムと同じものを使います。 0x8000 - 将来の使用のために予約されている 2. CertData - Extra Field 0x0017 record certificate data structure Extra Field の中に証明書のデータを保存するために使われるデータ構造は、 0x0017 の record で CertData field として定義されていて、 以下に示すようになっています。 Value Size Description ----- ---- ----------- RCount 4 bytes 受取人の数 HashAlg 2 bytes ハッシュアルゴリズムの識別子 HSize 2 bytes ハッシュのサイズ SRList (var) 受取人の公開鍵をハッシュしたものの単なるリスト RCount 想定される受取人の数を定義しており、それらの想定される受取人の 公開鍵が暗号化に使われています。これは SRList にある要素の数を 示します。 HashAlg 暗号化に使われたそれぞれの公開鍵の公開鍵ハッシュを 計算するのに使われたハッシュアルゴリズムを定義します。 この field は現在のところ SHA-1 用の以下の値のみを サポートしています。 0x8004 - SHA1 HSize ハッシュされた公開鍵のサイズを定義します。 SRList これは可変長のリストで、想定される受取人それぞれの公開鍵を ハッシュしたものが並べられています。このリストの それぞれの要素は HSize です。SRList の合計のサイズは RCount * HSize で求められます。 3. Reserved1 - Certificate Decryption Header Reserved1 Data: Value Size Description ----- ---- ----------- RCount 4 bytes 受取人の数 RCount これは想定される受取人の数を定義します。この受取人の公開鍵が 暗号化に使われています。これは以下で定義される REList field にある要素の数を定義します。 4. Reserved2 - Certificate Decryption Header Reserved2 Data Structures: Value Size Description ----- ---- ----------- HashAlg 2 bytes ハッシュアルゴリズムの識別子 HSize 2 bytes ハッシュのサイズ REList (var) 受取人のデータを要素に持つリスト HashAlg これはハッシュアルゴリズムを定義します。このアルゴリズムが、 暗号化に使われた各公開鍵のハッシュを計算するのに 使われています。この field は現在のところ以下の SHA-1 用の 値のみをサポートしています。 0x8004 - SHA1 HSize これは REHData で定義されるハッシュされた公開鍵のサイズを 定義します。 REList これは可変長のリストで受取人のデータが並んでいます。 このリストのそれぞれの要素は、以下のような Recipient Element のデータ構造で構成されます。 Recipient Element (REList の要素) のデータ構造 Value Size Description ----- ---- ----------- RESize 2 bytes REHData + REKData のサイズ REHData HSize 受取人の公開鍵のハッシュ値 REKData (var) Simple Key Blob RESize これは REList の各個の要素のサイズを定義します。この値は REHData field + REKData field の合計サイズです。 REHData は HSize で定義されます。REKData は可変長で、 それぞれの REList の要素に対して、RESize と HSize を使って 計算できます。 REHData この受取人についてのハッシュされた公開鍵です。 REKData Simple Key Blob です。このデータ構造のフォーマットは Microsoft CryptoAPI で定義されているものと同じで、 CryptExportKey() 関数を使って生成されます。 現在サポートしている Simple Key Blob のバージョンは、 Microsoft によって定義されているように 0x02 です。 Certificate Processing - Central Directory Encryption: ------------------------------------------------------- 電子証明書を用いた Central Directory Encryption は Sigle Password Central Directory Encryption のそれと同様の方法で 操作されるでしょう (will) 。この record は、ここに置くデータが あるときにのみ存在するでしょう (will) 。現在のところ、データが この record に置かれるのは、電子証明書が ZIP ファイルに含まれるファイルの 暗号化または署名に使われるときです。password encryption のみが、 証明書での暗号化や電子署名を伴わずに用いられるとき、この record は 現在のところ必要ではありません。存在するとき、この record は、実際の Central Directory のデータ構造の先頭より前に出現するでしょう (will) し、 Central Directory が暗号化されているなら Archive Decryption Header の直後に 置かれるでしょう (will) 。 Archive Extra Data record は以下の情報を保存するのに使われるでしょう (will) 。 追加のデータは将来のバージョンで追加されるでしょう (may) 。 Extra Data Fields: 0x0014 - X.509 証明書のための PKCS#7 Store 0x0016 - central directory のための X.509 証明書 ID と Signature 0x0019 - PKCS#7 Encryption Recipient Certificate List 0x0014 と 0x0016 の Extra Data record は他に、電子証明書の処理のために Central Directory のひとつめの record にも置かれるでしょう (would be) 。 Central Directory を暗号化または圧縮するとき、0x0014 と 0x0016 の record は Archive Extra Data record に置かれなくてはなりません (must) し、 Central Directory のひとつめの record に残っているべきでは ありません (should not) 。Archive Extra Data record は 0x0019 のデータを 保存するのにも使われるでしょう (will) 。 存在するとき、Archive Extra Data record のサイズは Central Directory の サイズに含まれるでしょう (will) 。Archive Extra Data record のデータもまた、 Central Directory のデータ構造に伴って圧縮されたり暗号化されたり するでしょう (will) 。 証明書の処理の違い 暗号化における Certificate Processing Method の、 Single Password Symmetric Encryption Method との違いは、以下のように なっています。Master Session Key を生成するためにユーザ定義の パスワードを用いる代わりに、暗号的にランダムなデータが用いられます。 こうした鍵の素材となるものは、それから標準的な key-wrapping 技術を使って wrap されます。この鍵の素材は、それぞれの受取人の公開鍵を使って wrap されますし、それらの対になる私有鍵を使ってファイルを復号する際に 必要となるでしょう (will) 。 この仕様では現在のところ、電子証明書は、1024 ビット以上の RSA 形式の 電子証明書用の X.509 V3 のフォーマットに従うだろう (will) ことを 想定しています。この Certificate Processing Method の実装では、 鍵のアクセスと管理のためのロジックをサポートすることが必須です。 このロジックについては、この仕様の範囲外です。 証明書に基づいた暗号化を併用した OAEP の処理 OAEP は Optimal Asymmetric Encryption Padding の略です。これは強化のための テクニックで、復号キーのような小さな、符号化された要素に対して用いられます。 これは一般的には暗号の key-wrapping 技術において適用され、 かつ PKCS #1 によってサポートされます。この仕様の version 5.0 と 6.0 は、 OAEP key-wrapping を、証明書に基づいた復号キーのセキュリティ補強のために サポートするよう設計されました。 スマートカードや USB トークンに保存された私有鍵のサポートは、 この OAEP のロジックと競合します。多くのカードやトークンの製品は、 OAEP key-wrap されたデータに適用する追加の強化をサポートしていません。 この競合を解決するために、この仕様の version 6.1 以上は、暗号化が 電子証明書を用いて行われるとき、もはや OAEP をサポートしないでしょう (will) 。 PKZIP の複数のバージョンで、証明書の処理手法の開発初期において、 61 という値を各ファイルの version needed to extract field に設定することが できます。これは non-OAEP key wrapping が使われるということを示します。 これによって影響を受けるのは、証明書による暗号化のみで、 パスワードによる暗号化の機能は、この値による影響を受けるべきでは ありません (should not) 。これはつまり、61 という値は証明書のみによって 暗号化されたファイルか、またはパスワードと証明書の両方で 暗号化されたファイルかの、いずれかなら現れるだろう (may) ということです。 両方の方法で暗号化されたファイルは、文書化されているような パスワードに関する手法を使って安全に復号できます。 IX. 改訂のプロセス ------------------ .ZIP ファイルのフォーマットが有用な定義であり続けるために、この仕様は 定期的なレビューと改訂がオープンに行われるべきです。このフォーマットが 元々は一定の拡張性を持った設計がされていたとしても、 すべての (現在や将来の) 技術の変化がこの設計に取り込まれる必要があった、 または必要があるだろうということはないのです。もしあなたの設計が このフォーマットの拡張可能なセクションに新たな定義を追加する必要があったり、 あなたが新しいデータ構造を送りたいのでしたら、どうぞその要望を zipformat@pkware.com まで送ってください。送られた全ては ZIP File Specification Committee によって、この仕様の将来のバージョンに 含める候補としてレビューされるでしょう。この仕様の定期的な改訂は 相互運用性を確保しつつ世に出されるでしょう。私たちは明快さや内容の改良を 助けてくれるだろうコメントやフィードバックを歓迎します。 X. あなたの製品に PKWARE 所有の技術を組み込む ----------------------------------------------------------------- PKWARE は .ZIP フォーマットの相互運用性と進化を維持し続けています。 PKWARE は、なんらかの制約と条件の下で、上述のようななんらかの技術的な点に 対して、フリーなライセンスを提示しています。しかしながら、 現在の APPNOTE にあるような、なんらかの技術的な点における、 製品での使用や実装は、strong encryption や patching や extended tape operation とみなされるものと併せての使用や実装を含めて、 PKWARE からの許諾が必要です。ライセンスを取得するためには PKWARE に 連絡をください。 XI. 謝辞 --------------------- 上述した PKZIP と PKUNZIP への貢献者に加えて、このソフトウェアに .ZIP という拡張子を提案してくれた Robert Mahoney にも特に感謝したいと思います。 XII. リファレンス --------------- Fiala, Edward R., and Greene, Daniel H., "Data compression with finite windows", Communications of the ACM, Volume 32, Number 4, April 1989, pages 490-505. Held, Gilbert, "Data Compression, Techniques and Applications, Hardware and Software Considerations", John Wiley & Sons, 1987. Huffman, D.A., "A method for the construction of minimum-redundancy codes", Proceedings of the IRE, Volume 40, Number 9, September 1952, pages 1098-1101. Nelson, Mark, "LZW Data Compression", Dr. Dobbs Journal, Volume 14, Number 10, October 1989, pages 29-37. Nelson, Mark, "The Data Compression Book", M&T Books, 1991. Storer, James A., "Data Compression, Methods and Theory", Computer Science Press, 1988 Welch, Terry, "A Technique for High-Performance Data Compression", IEEE Computer, Volume 17, Number 6, June 1984, pages 8-19. Ziv, J. and Lempel, A., "A universal algorithm for sequential data compression", Communications of the ACM, Volume 30, Number 6, June 1987, pages 520-540. Ziv, J. and Lempel, A., "Compression of individual sequences via variable-rate coding", IEEE Transactions on Information Theory, Volume 24, Number 5, September 1978, pages 530-536. APPENDIX A - AS/400 Extra Field (0x0065) Attribute Definitions --------------------------------------------------------------- Field Definition Structure: a. field length including length 2 bytes b. field code 2 bytes c. data x bytes Field Code Description 4001 Source type i.e. CLP etc 4002 The text description of the library 4003 The text description of the file 4004 The text description of the member 4005 x'F0' or 0 is PF-DTA, x'F1' or 1 is PF_SRC 4007 Database Type Code 1 byte 4008 Database file and fields definition 4009 GZIP file type 2 bytes 400B IFS code page 2 bytes 400C IFS Creation Time 4 bytes 400D IFS Access Time 4 bytes 400E IFS Modification time 4 bytes 005C Length of the records in the file 2 bytes 0068 GZIP two words 8 bytes APPENDIX B - z/OS Extra Field (0x0065) Attribute Definitions ------------------------------------------------------------- Field Definition Structure: a. field length including length 2 bytes b. field code 2 bytes c. data x bytes Field Code Description 0001 File Type 2 bytes 0002 NonVSAM Record Format 1 byte 0003 Reserved 0004 NonVSAM Block Size 2 bytes Big Endian 0005 Primary Space Allocation 3 bytes Big Endian 0006 Secondary Space Allocation 3 bytes Big Endian 0007 Space Allocation Type1 byte flag 0008 Modification Date Retired with PKZIP 5.0 + 0009 Expiration Date Retired with PKZIP 5.0 + 000A PDS Directory Block Allocation 3 bytes Big Endian binary value 000B NonVSAM Volume List variable 000C UNIT Reference Retired with PKZIP 5.0 + 000D DF/SMS Management Class 8 bytes EBCDIC Text Value 000E DF/SMS Storage Class 8 bytes EBCDIC Text Value 000F DF/SMS Data Class 8 bytes EBCDIC Text Value 0010 PDS/PDSE Member Info. 30 bytes 0011 VSAM sub-filetype 2 bytes 0012 VSAM LRECL 13 bytes EBCDIC "(num_avg num_max)" 0013 VSAM Cluster Name Retired with PKZIP 5.0 + 0014 VSAM KSDS Key Information 13 bytes EBCDIC "(num_length num_position)" 0015 VSAM Average LRECL 5 bytes EBCDIC num_value padded with blanks 0016 VSAM Maximum LRECL 5 bytes EBCDIC num_value padded with blanks 0017 VSAM KSDS Key Length 5 bytes EBCDIC num_value padded with blanks 0018 VSAM KSDS Key Position 5 bytes EBCDIC num_value padded with blanks 0019 VSAM Data Name 1-44 bytes EBCDIC text string 001A VSAM KSDS Index Name 1-44 bytes EBCDIC text string 001B VSAM Catalog Name 1-44 bytes EBCDIC text string 001C VSAM Data Space Type 9 bytes EBCDIC text string 001D VSAM Data Space Primary 9 bytes EBCDIC num_value left-justified 001E VSAM Data Space Secondary 9 bytes EBCDIC num_value left-justified 001F VSAM Data Volume List variable EBCDIC text list of 6-character Volume IDs 0020 VSAM Data Buffer Space 8 bytes EBCDIC num_value left-justified 0021 VSAM Data CISIZE 5 bytes EBCDIC num_value left-justified 0022 VSAM Erase Flag 1 byte flag 0023 VSAM Free CI % 3 bytes EBCDIC num_value left-justified 0024 VSAM Free CA % 3 bytes EBCDIC num_value left-justified 0025 VSAM Index Volume List variable EBCDIC text list of 6-character Volume IDs 0026 VSAM Ordered Flag 1 byte flag 0027 VSAM REUSE Flag 1 byte flag 0028 VSAM SPANNED Flag 1 byte flag 0029 VSAM Recovery Flag 1 byte flag 002A VSAM WRITECHK Flag 1 byte flag 002B VSAM Cluster/Data SHROPTS 3 bytes EBCDIC "n,y" 002C VSAM Index SHROPTS 3 bytes EBCDIC "n,y" 002D VSAM Index Space Type 9 bytes EBCDIC text string 002E VSAM Index Space Primary 9 bytes EBCDIC num_value left-justified 002F VSAM Index Space Secondary 9 bytes EBCDIC num_value left-justified 0030 VSAM Index CISIZE 5 bytes EBCDIC num_value left-justified 0031 VSAM Index IMBED 1 byte flag 0032 VSAM Index Ordered Flag 1 byte flag 0033 VSAM REPLICATE Flag 1 byte flag 0034 VSAM Index REUSE Flag 1 byte flag 0035 VSAM Index WRITECHK Flag 1 byte flag Retired with PKZIP 5.0 + 0036 VSAM Owner 8 bytes EBCDIC text string 0037 VSAM Index Owner 8 bytes EBCDIC text string 0038 Reserved 0039 Reserved 003A Reserved 003B Reserved 003C Reserved 003D Reserved 003E Reserved 003F Reserved 0040 Reserved 0041 Reserved 0042 Reserved 0043 Reserved 0044 Reserved 0045 Reserved 0046 Reserved 0047 Reserved 0048 Reserved 0049 Reserved 004A Reserved 004B Reserved 004C Reserved 004D Reserved 004E Reserved 004F Reserved 0050 Reserved 0051 Reserved 0052 Reserved 0053 Reserved 0054 Reserved 0055 Reserved 0056 Reserved 0057 Reserved 0058 PDS/PDSE Member TTR Info. 6 bytes Big Endian 0059 PDS 1st LMOD Text TTR 3 bytes Big Endian 005A PDS LMOD EP Rec # 4 bytes Big Endian 005B Reserved 005C Max Length of records 2 bytes Big Endian 005D PDSE Flag 1 byte flag 005E Reserved 005F Reserved 0060 Reserved 0061 Reserved 0062 Reserved 0063 Reserved 0064 Reserved 0065 Last Date Referenced 4 bytes Packed Hex "yyyymmdd" 0066 Date Created 4 bytes Packed Hex "yyyymmdd" 0068 GZIP two words 8 bytes 0071 Extended NOTE Location 12 bytes Big Endian 0072 Archive device UNIT 6 bytes EBCDIC 0073 Archive 1st Volume 6 bytes EBCDIC 0074 Archive 1st VOL File Seq# 2 bytes Binary APPENDIX C - Zip64 Extensible Data Sector Mappings (EFS) --------------------------------------------------------- -Z390 Extra Field: 以下は、extended tape operations のための ZIP 64 "extra" block の 属性の一般的な構造です。この extended tape processing 技術の いくつかの部分は、出願中の特許で保護されています。現在の APPNOTE に あるような、なんらかの技術的な点における、製品での使用や実装は、 strong encryption や patching や extended tape operation と みなされるものと併せての使用や実装を含めて、PKWARE からの許諾が 必要です。ライセンスを取得するためには PKWARE に連絡をください。 注: いくつかの field はビッグエンディアンのフォーマットで 保存されます。全てのテキストは、別記ない場合は EBCDIC フォーマットです。 Value Size Description ----- ---- ----------- (Z390) 0x0065 2 bytes この "extra" block のタイプを示すタグ Size 4 bytes 後続の data block のサイズ Tag 4 bytes EBCDIC の "Z390" Length71 2 bytes ビッグエンディアン Subcode71 2 bytes Enote type code FMEPos 1 byte Length72 2 bytes ビッグエンディアン Subcode72 2 bytes Unit type code Unit 1 byte ユニット Length73 2 bytes ビッグエンディアン Subcode73 2 bytes Volume1 type code FirstVol 1 byte ボリューム Length74 2 bytes ビッグエンディアン Subcode74 2 bytes FirstVol file sequence FileSeq 2 bytes Sequence APPENDIX D - Language Encoding (EFS) ------------------------------------ ZIP フォーマットは歴史的に original IBM PC の文字エンコーディングセットのみを サポートしています。これは一般的に IBM Code Page 437 と呼ばれるものです。 これにより、ファイル名の文字は元々の MS-DOS の範囲の値でのみ保存されるという 制限があり、他の文字エンコーディングや言語でのファイル名を 正しくサポートしていません。この制限に取り組むために、この仕様は 以下の変更をサポートするでしょう (will) 。 general purpose bit 11 が設定されていないならば、file name と comment は 元々の ZIP の文字エンコーディングと同じであるべき (should) です。 general purpose bit 11 が設定されているならば、 filename と comment は UTF-8 保存仕様で定義される文字エンコーディング形式を使用した version 4.1.0 以上の The Unicode Standard をサポートしなければ なりません (must) 。The Unicode Standard は The Unicode Consortium (www.unicode.org) から公開されています。 ZIP ファイルに保存される UTF-8 でエンコードされたデータは、 byte order mark (BOM) を含まないことが予想されます。 アプリケーションは、このファイル名を保存するために 0x0008 の Extra Field を 使うようにするでしょう (may) 。このオプションの field を保存する場所については 現在のところ定義されていませんが、それが使われるでしょう (will) し、 そこに source と target のエンコーディングについての拡張情報が 保存されうることで、ファイル名やファイルの内容のエンコーディングを扱う アプリケーションをより補助することになるでしょう (may) 。この field を どのように使うべき (should) かについての、どんな要請でも PKWARE に 送ってください。 0x0008 の Extra Field は、general purpose bit 11 の設定に応じて 使われるでしょう (may) 。この field の意図された使い方の例としては "modified-UTF-8" (JAVA) が使われているか、UTF-8-MAC かといったことを 保存します。同様に、他の一般的に使われる文字エンコーディング (code page) を、 この field によって示すことができます。0x0008 record で使われる公式な値は、 現在のところ未定義のままです。0x0008 field の構造の定義は、 可能になったときに公開されるでしょう (will) 。0x0008 Extra Field を 使うことで、ZIP ファイル内のデータを IBM Code Page 437 や UTF-8 以外の エンコーディングで保存することができます。 general purpose bit 11 がファイルの内容やパスワードのエンコーディングを 暗示することは無いでしょう (will) 。ファイルの内容やパスワードの 文字エンコーディングを定義する値は 0x0008 Extended Language Encoding Extra Field の中に 保存されなければなりません (must) 。 Info-ZIP グループの Ed Gordon は "extra field" のひと組の record を定義して、 そこに UTF-8 のファイル名とファイルのコメントを保存できるようにしました。 これらの record は、標準のファイル名とコメントの field に UTF-8 のデータを 保存するための general purpose bit 11 の方法が望ましくないような場合に 使うことができます。この代替方法は、古いプログラムとの後方互換性が 要求されるような場合に用いられるのが一般的です。 これらの field の record 構造についての定義は、上述した "extra field" record の 3rd party mappings についてのセクションに 含まれています。これらの record は Header ID が 0x6375 (Info-ZIP Unicode Comment Extra Field) や 0x7075 (Info-ZIP Unicode Path Extra Field) であることで識別できます。 ZIP ファイルを書き込む際に、どの保存方法を使うかの選択は、実装に 任されています。開発者は ZIP ファイルがいずれかの方法を 含んでいるだろう (may) ことを想定すべき (should) ですし、 いずれのフォーマットのデータをも読み込めるようなサポートを 提供すべき (should) です。general purpose bit 11 を使えば、 各ファイルに追加の "extra field" データが必要ないので、 ファイル名のデータ用に必要な保存容量を減らせますが、古い ZIP プログラムで ファイルが展開できないという結果になる可能性もあります。 0x6375 と 0x7075 の record を使うことで、古い ZIP プログラムでも いつでも ZIP ファイルを読み込めるべき (should) であるように できるでしょう (will) けれど、ファイルごとにファイル名と、 あるいはファイルのコメントの field を書き込むための容量を余計に必要とします。