|
|
ウェブやソフトウェアに関するサポート＆情報サイトです。サイト構築からソフトウェアの作成、利用まであなたの助けになるかも・・・・しれません。たぶん・・。
|
|
ウェブやソフトウェアに関するサポート＆情報サイトです。サイト構築からソフトウェアの作成、利用まであなたの助けになるかも・・・・しれません。たぶん・・。
--- Google Auto Converted 2009.4.10 ---
ファイル： APPNOTE.TXT - 。 Zipファイル形式の仕様
Version: 6.3.1
Revised: April 11, 2007
Copyright (c) 1989 - 2007 PKWARE Inc., All Rights Reserved.
特定の技術的な面での使用は、現在の開示
セクションには、以下に定めるところにより、権利APPNOTEに入手可能です
"お客様の製品に独自の技術を組み込んだPKWARE " 。
一目的
----------
この仕様はクロスプラットフォームを定義するために、意図しています
相互運用可能ファイルの保存や転送形式です。以来の
1989年に初めて出版、 PKWAREにコミットしている
を通じて形式は、 zip形式ファイルの相互運用性を確保する
出版ており、この仕様の維持。我々は信頼関係は、
すべてのことが互換性のベンダーやアプリケーション開発者の郵便番号
を採択し、このフォーマットからの恩恵を共有することになりますとサポート
相互運用性を約束。
? 。お問い合わせPKWARE
---------------------
PKWARE社
648 nをPlankintonアベニュー、スイート220
ミルウォーキー、無線53203
+1-414-289-9788
+1-414-289-9789ファックス
zipformat@pkware.com
? 。免責事項
---------------
PKWAREは、電流を供給しようとしますと、正確な
情報のファイル形式は、アルゴリズムに関連し、
対象のプログラムは、エラーまたは不作為の可能性をことはできません
排除される。 PKWAREため、明示的に保証を放棄
関連する資料は、情報関連に含まれる
対象のプログラムやファイルを/または形式または作成
対象のプログラムおよび/またはアルゴリズムによって使用されるがアクセス
対象のプログラム、またはその他の問題は、修正するか現在の情報です
配信は、正確な。損傷のため、すべてのリスクの可能性
不正確な情報は、情報の利用者が想定されています。
また、情報は、対象のプログラムに関連する
および/またはそのファイルフォーマットを作成したり、被写体によってアクセス
プログラムおよび/またはそのアルゴリズムは、対象のプログラムで使用されています
予告なく変更すること。
このファイルのバージョン変更のお知らせとしてマークされています
コンテンツは、初期の機能仕様書（ EFS ）を変更する定義
に変更する前に対象となることがあります。 ZIPファイル形式に
最終機能仕様書（ FFS ）の出版をしてください。この
文書は、計画機能の情報が含まれる場合があります
仕様（によってPFS ）を認識、将来の拡張機能を定義する。
? 。変更ログ
--------------
バージョンを変更する説明日付
------- ------------------ ----------
対称暗号化パスワードを5.2 -シングル2003年6月2日
保存
6.1.0 -スマートカードの互換性を2004年1月20日
ドキュメントの証明書の保管
6.2.0 -はじめに2004年4月26日の中央ディレクトリ
暗号化を暗号化するためのメタデータ
-追加のOS / Xのバージョンに値して
6.2.1 -フィールドのプレースホルダの追加エキストラ2005年4月1日
POSZIP番号0x4690を使用して
に明らかにサイズのフィールドに
中央ディレクトリレコードの" zip64エンド"
6.2.2ドキュメントファイナル機能仕様書2006年1月6日
強力な暗号化のため
の明確化や印字
訂正
テープの位置を記憶6.3.0 -追加日2006年9月29日
パラメータ
サポートされているハッシュアルゴリズムの拡張リスト
サポートされている圧縮の拡張リスト
アルゴリズム
サポートされている暗号化の拡張リスト
アルゴリズム
- Unicodeのファイル名のオプションを追加
保存
一貫使用するための明確化
データ記述子レコード
追加"エキストラフィールド"を追加
定義
6.3.1 -修正標準のハッシュ値を2007年4月11日
SHA-256/384/512
6.3.2 -追加圧縮法97 2007年9月28日
ドキュメントInfoZIP "エキストラフィールド"
の値はUTF - 8ファイル名と
コメントをストレージファイル
五、一般的な形式は、 zip形式のファイル
--------------------------------
ファイルを任意の順番で格納されます。大規模なzip形式のファイルをすることができます複数の
ボリュームやユーザー定義サイズのセグメントに分割される。すべての値
特に指定しない限りリトルエンディアンのバイト順序で格納されている。
全体の。 ZIPファイル形式：
[ローカルファイルのヘッダー1 ]
[ファイルのデータを1 ]
[データ記述子1 ]
。
。
。
[ローカルファイルのヘッダーN ]
[ファイルデータn ]
[データディスクリプタn ]
[アーカイブを復号化ヘッダー]
[アーカイブの余分なデータを記録]
[中央ディレクトリ]
[中央ディレクトリレコードのzip64終了]
[中央ディレクトリロケータのzip64終了]
中央ディレクトリレコードの[終了]
a.ローカルファイルのヘッダー：
ローカルファイルのヘッダーの署名は4バイト（ 0x04034b50 ）
バージョン2バイトを抽出するために必要な
一般的な目的のビットフラグを2バイト
圧縮方式は2バイト
最後のモジュールのファイルの時間は2バイト
最後のモジュールファイルの日付は2バイト
のCRC - 32の4バイト
サイズは4バイト圧縮
サイズは4バイトの非圧縮
名の長さは2バイトのファイル
余分なフィールドの長さは2バイト
ファイル名（変数サイズ）
余分なフィールド（変数サイズ）
B.ファイルのデータ
すぐに次のファイルのローカルヘッダ
圧縮されているか、ファイルのデータが格納されます。
のシリーズ[ローカルファイルのヘッダー] [ファイルデータ] [データ
記述子] 。 ZIPアーカイブ内の各ファイルを繰り返します。
C.データの記述：
のCRC - 32の4バイト
サイズは4バイト圧縮
サイズは4バイトの非圧縮
この記述子が存在する場合のみのビット3は、一般的な
目的のビットフラグ（下記参照）に設定されます。バイトに整列され
とすぐに、圧縮データの最後のバイト以下の通りです。
この記述子をすることが可能ではなかった場合にのみ使用されています
は、出力を求める。 ZIPファイルは、例えば、出力。 ZIPファイル
標準出力または非シークデバイスだった。形式ZIP64 （ TM ）で
アーカイブは、圧縮と非圧縮のサイズは8バイトごとされています。
圧縮ファイルの場合、圧縮と非圧縮サイズ
ZIP64フォーマットで保存する必要があります（ 8バイトの値として）ときに
ファイルのサイズは0xFFFFFFFFを超えています。しかしながらZIP64フォーマットされることがあります
使用に関係なく、ファイルのサイズ。際には、抽出する場合、
zip64拡張情報は、余分なフィールドに存在している
このファイルは、圧縮非圧縮サイズを8になります
バイトの値。
署名は、もともとは、値が割り当てられていない
0x08074b50一般に署名値として採用されています
データ記述子を記録。実装する必要があります
ZIP形式のファイルではなく発生することができるか、この認識
署名マーキングのデータ記述子とを考慮すべき
いずれの場合の互換性を確保するためにZIP形式のファイルを読んでいます。
ZIPファイルの書き込み時には、含めることをお勧めします
署名の値は、データ記述子レコードをマーク。いつ
の署名を、フィールドに定義され、現在使用されています
すぐに次のデータ記述子を記録する
署名。
拡張可能なデータ記述子は、将来リリースされる
このAPPNOTEのバージョン。この新記録を目的としているに
このレコードを使用するとの衝突を解決する今後は、
ファイルのストリーミング配信と処理のためのよりよいサポートを提供します。
は、セントラルディレクトリの暗号化の方法、使用されているデータ
記述子の記録は、必須ではありませんが、使用される場合があります。もし、現在の
とビット3は、一般的な目的のビットフィールドを示すために設定されている
その存在は、データ記述子のフィールドの値
レコードのバイナリゼロに設定する必要があります。
アーカイブD.復号ヘッダ：
復号化は、アーカイブヘッダのバージョン6.2で導入されています
はZIP形式の仕様。このレコードのサポートに存在する
中央ディレクトリの暗号化機能の一部として実装さ
強力な暗号化の仕様として、この文書で説明する。
は、セントラルディレクトリ構造は暗号化され、この復号化
ヘッダーには、暗号化されたデータセグメントに先行されます。暗号化された
余分なデータセグメントをアーカイブデータレコードで構成されます（該当する場合
現在）と、暗号化されたデータを中央のディレクトリ構造。
このデータレコードのフォーマットは、復号化と同じです
ヘッダーレコードのデータファイルの圧縮前。場合は、中央
ディレクトリ構造は、スタートの場所を暗号化されて
このデータ記録の開始を使用して決定される中央Directoryの
中央ディレクトリレコードのZip64エンドでフィールド。を参照してください
情報については、強力な暗号化の仕様のセクション
ヘッダーレコードのフィールドは、アーカイブ復号化で使用されている。
E.アーカイブ余分なデータレコード：
余分なデータのアーカイブの署名は4バイト（ 0x08064b50 ）
余分なフィールドの長さは4バイト
余分なフィールドのデータ（変数サイズ）
エキストラは、アーカイブデータレコードのバージョン6.2で導入されています
はZIP形式の仕様。このレコードのサポートに存在する
中央ディレクトリの暗号化機能の一部として実装さ
強力な暗号化の仕様として、この文書で説明する。
が存在する場合、このレコードはすぐに中央の前に
ディレクトリのデータ構造。このデータレコードのサイズとなります
中央ディレクトリのフィールドのサイズに含ま
中央ディレクトリレコードの終わり。中央のディレクトリ構造の場合
が、圧縮されている暗号化されず、スタートの場所
このデータ記録の開始を使用して決定される中央Directoryの
中央ディレクトリレコードのZip64エンドでフィールド。
F.中央ディレクトリ構造：
[ファイルのヘッダー1 ]
。
。
。
[ファイルのヘッダーN ]
[デジタル署名]
ファイルのヘッダー：
中央のファイルのヘッダーの署名は4バイト（ 0x02014b50 ）
バージョン2バイトによって作ら
バージョン2バイトを抽出するために必要な
一般的な目的のビットフラグを2バイト
圧縮方式は2バイト
最後のモジュールのファイルの時間は2バイト
最後のモジュールファイルの日付は2バイト
のCRC - 32の4バイト
サイズは4バイト圧縮
サイズは4バイトの非圧縮
名の長さは2バイトのファイル
余分なフィールドの長さは2バイト
コメントの長さは2バイトのファイル
ディスク番号を開始する2バイト
内部ファイルは2バイトの属性
外部ファイルは4バイトの属性
相対ローカルヘッダのオフセットは4バイト
ファイル名（変数サイズ）
余分なフィールド（変数サイズ）
ファイルのコメント（変数サイズ）
デジタル署名：
ヘッダの署名を4バイト（ 0x05054b50 ）
データを2バイトの大きさ
署名データ（変数サイズ）
中央ディレクトリの暗号化の導入により
この仕様のバージョン6.2の機能を、中央
ディレクトリ構造の両方を圧縮、暗号化保存されることがあります。
必須ではありませんが、それを暗号化する場合を想定しています
中央のディレクトリ構造、それが圧縮されます
効率の高いストレージ。情報は、上
中央ディレクトリの暗号化機能のセクションで見つけることができます
強力な暗号化の仕様を記述する。デジタル
署名や暗号化された記録も圧縮されます。
トジップ中央ディレクトリレコードの64終わり
中央ディレクトリの最後zip64
署名は4バイト（ 0x06064b50 ）
zip64の最後のサイズを中心
ディレクトリレコードの8バイト
バージョン2バイトによって作ら
バージョン2バイトを抽出するために必要な
このディスクの数は4バイト
とは、ディスクの数
中央ディレクトリの開始は4バイト
は、エントリの合計数
このディスク上の中央ディレクトリの8バイト
は、エントリの合計数
中央ディレクトリの8バイト
中央ディレクトリのサイズは8バイト
の開始のオフセット中央
を尊重するとディレクトリ
開始ディスク番号の8バイト
zip64拡張可能なデータの部（変数サイズ）
の価値のzip64エンドの"大きさに格納中央
ディレクトリレコード"の残りのサイズをする必要があります
記録し、主要な12バイトを含めないでください。
サイズ= SizeOfFixedFields + SizeOfVariableData - 12 。
上記のレコード構造のバージョン1を定義しています
中央ディレクトリレコードのzip64終了します。バージョン1だった
前のバージョンでは、この仕様を実装
6.2は、大容量のファイル機能のサポートZIP64 。その
中央ディレクトリの暗号化機能の導入
バージョン6.2での強力な暗号化の一環として実施
このレコード構造のバージョン2の仕様を定義します。
参照するセクションでは、強力な暗号化を記述する
仕様は、バージョン2形式のための詳細については
このレコード。
特別な目的のデータは、 zip64拡張可能なデータに存在する可能性があります
次のフィールドのいずれか、この部門のv1もしくはV2バージョン
記録します。この特別な目的のデータを識別するために
それを識別するヘッダブロックの構成を含める必要があります
以下の通りです：
ヘッダ番号- 2バイト
データサイズ- 4バイト
は、ヘッダーのIDフィールドのデータ型を示すことにある
データは次のようにブロック。
バイトのデータサイズは、このために次のコードを識別
データブロックタイプ。
複数の特別な目的のデータをブロックされることがありますが、現在、各
IDとデータサイズは、ヘッダフィールドが先行されなければなりません。現在の
ヘッダIDのマッピングをこのフィールドでサポートされる値は、
付録Cで定義されて
チジップ中央ディレクトリロケータの64終わり
中央ディレクトリロケータのzip64終了
署名は4バイト（ 0x07064b50 ）
とは、ディスクの数
zip64末に開始
中央ディレクトリ4バイト
相対的にzip64のオフセット
中央ディレクトリレコードの最後の8バイト
ディスクの合計数が4バイト
? 。エンド中央ディレクトリレコード：
中央ディレクトリの署名の最後の4バイト（ 0x06054b50 ）
このディスクの数は2バイト
とは、ディスクの数
中央ディレクトリの開始は2バイト
は、エントリの合計数
このディスク上の中央ディレクトリに2バイト
エントリの合計数で
中央ディレクトリに2バイト
中央ディレクトリのサイズを4バイト
の開始のオフセット中央
を尊重するとディレクトリ
開始ディスク番号の4バイト
zip形式のコメントの長さは2バイトのファイル
。 ZIPファイルのコメント（変数サイズ）
J.フィールドの説明：
バージョン（ 2バイト）によって作ら
の上位バイトは、ファイルの互換性を示す
属性情報。場合は、外部ファイルの属性
のMS - DOSとPKZIPと互換性があるがために読むことができます
DOSバージョン2.04グラムを、この値はゼロになります。これらの場合
属性は、互換性がありませんし、この値が
これは、ホストシステムの属性を識別
互換性があります。ソフトウェアを決定するためにこの情報を使用することができます
テキストファイルなどの現在の行のレコード形式
マッピングされます：
0 -のMS - DOSとOS / 2 （のFAT / VFAT / FAT32ファイルシステム）
1 -アミガ2 -のOpenVMS
3 - UNIXの4 -のVM / CMSは
5 -アタリST 6 - OS / 2のH.P.F.S.
7 - Macintoshの8 - ? -システム
9 - CP /月10 - WindowsのNTFSの
11 - MVSは（ OS/390 - ? / OS ）の12 - VSE
13 -どんぐりRISC用14 - VFAT
15 -代替MVSは16 - BeOSの
17 -タンデム18 -のOS/400
19 -のOS / Xの（ダーウィン） 20 255まで-未使用
下位バイトはZIP形式の仕様バージョンを示す
この文書（のバージョン）は、ソフトウェアでサポートされて
ファイルをエンコードするために使用されます。 value/10を示し、主要な
バージョン番号、およびモジュールの値は10のマイナーバージョンです
数。
バージョン（ 2バイト）を抽出するために必要な
ZIP形式の仕様のバージョンに必要な最小限のサポート
、上記のようにマップされたファイルを解凍します。この値に基づいている
特定の形式にはZIP形式のプログラムの機能をサポートしなければなりません
そのファイルを抽出することができる。複数の機能がある
ファイルに適用されると、最小バージョンを設定する必要があります
機能を持つ最高の値。新機能や機能
公開されたフォーマットの仕様変更に影響される
よりも高いバージョン番号を使用して実装の最後の
公開値の競合を避けるために。
現在のバージョンの最低限の機能は次のように定義されています：
1.0 -デフォルト値
1.1 -ファイルにボリュームラベルです
2.0 -ファイルのフォルダ（ディレクトリ）です
2.0 -ファイルを収縮させるの圧縮を使用して圧縮されている
2.0 -ファイルの暗号化を使用して暗号化され、伝統的PKWARE
2.1 -ファイル（ TM ）のDeflate64を使用して圧縮されている
2.5 -ファイルPKWARE破DCLを使用して圧縮されている
2.7 -ファイルのパッチデータが設定されている
4.5 -ファイル形式の拡張子を使用してZIP64
6月4日- bzip2圧縮ファイルを使用して圧縮されている*
5.0 -ファイルを使用して暗号化されデ
5.0 -ファイル3DESのを使用して暗号化されて
5.0 -ファイルの暗号化を使用して元のRC2が暗号化されて
5.0 -ファイルRC4暗号化を使用して暗号化されて
5.1 -ファイルのAES暗号化を使用して暗号化されて
5.1 -ファイルRC2が暗号化の修正を使用して暗号化されて**
5.2 -ファイルを修正RC2が- 64暗号化を使用して暗号化されて**
6.1 -ファイル以外を使用して暗号化され- OAEPキーラッピング***
6.2 -中央ディレクトリの暗号化
6月3日-ファイルを使用してLZMA圧縮されている
6月3日-ファイルを使用して圧縮されているPPMd +
6.3 -ファイルフグを使用して暗号化されて
6月3日-ファイルを使用して暗号化されてTwofish
*初期の7.0以降（事前PKZIPの7.2 ）のバージョンを誤って設定
バージョンbzip2圧縮されるために抽出するために必要な50
46がされている。
**紹介強力な暗号化の仕様上のセクションに
追加情報については、 RC2が訂正。
*** OAEP鍵証明書を使用して、暗号化以外の折り返しのです
すべてのバージョン6.1で始まるの操作の意図モード。
OAEPキー折り返しをサポートするだけで使用する必要があります
下位互換性がZIPファイルを送信して開くことに
PKZIPのバージョン6.1よりも古い（ 5.0または6.0 ） 。
+ PPMd圧縮ファイルのバージョンを使用して設定する必要があります
6.3フィールドを抽出するために必要な、しかし、すべての郵便
このプログラムを実施すると解凍できないことがあります
この値が設定されているデータを使用してファイルを圧縮PPMd 。
ZIP64の拡張機能を使用するときは、内の対応する値
中央ディレクトリレコードの最後zip64も設定する必要があります。
このフィールドを適切に設定する必要がありますかどうかを示すために
バージョン1またはバージョン2形式を使用しています。
一般的な目的のビットフラグ： （ 2バイト）
設定ビット0の場合：そのファイルが暗号化されています。
方法6 （ - Imploding ）
ビット1 ：圧縮メソッドを使用する場合は、タイプ6だった。
Implodingし、このビットは、設定すると、を示して
辞書を使用されたスライドは8K 。場合には、明確な
4Kスライディングして辞書を使用しています。
ビット2 ：圧縮メソッドを使用する場合は、タイプ6だった。
Implodingし、このビットは、設定すると、を示して
3シャノンファノの木のエンコードに使用された
辞書出力スライディング。もしクリアして2
シャノンファノの木を使用した。
方法8および9 （ -しぼませる）
ビット2ビット1
0 0通常（ -アン）圧縮オプションを使用していた。
0 1最大（ -exx/-ex ）圧縮オプションを使用していた。
1 0高速（ -アルファベットのF ）の圧縮オプションを使用していた。
1月1日超高速（ - ES ）を圧縮オプションを使用していた。
法14 （ - LZMA ）
ビット1 ：圧縮メソッドを使用する場合は、タイプ14 、れた
LZMAし、このビットは、設定すると、を示して
の終わりをストリーム（のEOS ）マーカーに使用されています
圧縮データストリームの終わりを告げる。
もしクリアし、一のEOSマーカーが存在しない場合
と知られているデータサイズを圧縮する必要があります
抽出します。
注：ビット1と2未定義している場合は、圧縮
他の方法です。
ビット3 ：このビットが設定されている場合、フィールドのCRC - 32 、圧縮
大きさやサイズは、非圧縮でゼロに設定されている
ローカルヘッダ。正しい値は、に置かれます
データをすぐに次の記述子は、圧縮
データ。 （注： DOS用のバージョン2.04グラムしかPKZIP
法8圧縮、新しいため、このビットを認識
PKZIPのバージョンのため、このビットを認識する
圧縮方式。 ）
ビット4 ：強化されたメソッドを8で使用するために、ために予約
しぼませる。
このビットが設定されているビット5 ：これはファイルであることを示します
パッチを適用したデータを圧縮。 （注： PKZIPが必要です
バージョン2.70以上）
ビット6 ：強力な暗号化。このビットが設定されている場合は、必要
のバージョンに設定する値を抽出するために必要な最低でも
また50ビットを0に設定する必要があります。 AES暗号化する場合
使用されている、バージョンする必要があります値を抽出するために必要な
少なくとも51である。
ビット7 ：現在使用されていない。
ビット8 ：現在使用されていない。
ビット9 ：現在使用されていない。
ビット10 ：現在使用されていない。
ビット11 ：言語のエンコードフラグ（ EFS ）を。このビットは、設定されている
このファイルのファイル名とコメント欄
はUTF - 8を使ってエンコードする必要があります。 （ ）付録Dを参照してください
ビット12 ：強化された圧縮PKWAREによって予約。
ビット13 ：時を示すために、中央ディレクトリの暗号化使用
ローカルのヘッダで選択したデータの値をマスクしている
実際の値が非表示にします。のセクションを記述を参照してください
詳細については、強力な暗号化規格。
ビット14 ： PKWAREによって予約。
ビット15 ： PKWAREによって予約。
圧縮方式： （ 2バイト）
（アルゴリズムの付属ドキュメントを参照してください
説明）
0 -このファイル（非圧縮）保存されています
1 -このファイルは縮小され
2 -ファイルの圧縮率1に削減され
3 -ファイルの圧縮率2に削減され
4 -ファイルの圧縮率3に低減され
5 -ファイルの圧縮率4に低減され
6 -ファイルImplodedです
7 -トークンの圧縮アルゴリズムのために予約
8 -ファイルしぼんです
9 -拡張しぼませる（ TM ）のDeflate64を使用して
10 - PKWAREデータ圧縮ライブラリImploding （旧IBMの簡潔な）
11 - PKWAREによって予約
12 -ファイルBZIP2アルゴリズムを使用して圧縮されている
13 - PKWAREによって予約
14 - LZMA （ EFS ）を
15 - PKWAREによって予約
16 - PKWAREによって予約
17 - PKWAREによって予約
18 -ファイルを使用してIBMの簡潔な（新）圧縮されている
19 - IBMのLZ77 ?建築（によってPFS ）
97 - WavPackデータ圧縮
98 - PPMdバージョン、改訂1
日付と時刻のフィールド： （ 2バイト毎）
日付と時刻を標準のMS - DOS形式でエンコードされています。
入力は標準入力の場合、日付と時刻から来ている
これらは、このデータ圧縮のために開始されました。
中央ディレクトリと一般的な目的の場合はビットの暗号化
13マスキングを示すフラグが設定され、その値が格納
ローカルヘッダがゼロになります。
のCRC - 32 ： （ 4バイト）
気前のCRC - 32アルゴリズムによって寄贈されました
デビッドSchwadererと自分で見つけることができる優れた
書籍" CプログラマのNetBIOSガイド"が発行
ハワードW.サムス＆カンパニー社の'マジックナンバー'
のCRC 0xdebb20e3されています。適切な事前のCRCとポスト
エアコン、使用されている意味は、 CRCが登録
すべてのもの（条件の出発前の値です。
は0xFFFFFFFF ）の値が投稿されてから条件
のCRCは、自分の残留を補完している。
一般的な目的の場合は、フラグのビット3を設定すると、この
フィールドには、ローカルのヘッダーと適切ではゼロに設定されている
値は、データ記述子に置かれ、中央に
ディレクトリにあります。ときは、中央のディレクトリを暗号化する場合は、
ローカルヘッダZIP64フォーマットと一般的な目的ではない
13ビットのマスクを示すフラグは、設定されている値が格納
ローカルヘッダがゼロになります。
サイズ圧縮： （ 4バイト）
非圧縮サイズ： （ 4バイト）
ファイルの圧縮と非圧縮のサイズ、
読み替えるものとする。復号化する際にヘッダが存在している
ファイルのデータの前に置かれるとの価値
圧縮されたファイルのサイズは、復号化のバイト数が含まれます
ヘッダ。一般的な目的の場合はビットフラグのビット3 、設定されている
これらのフィールドは、ローカルのヘッダーで、ゼロに設定されている
正しい値は、データ記述子に入れている
中央ディレクトリ。 ZIP64フォーマットの場合は、アーカイブされ
このフィールドの値は0xFFFFFFFFです、サイズとなります
ZIP64対応する8バイトの情報を拡張
余分なフィールド。ときは、中央のディレクトリを暗号化する場合は、
ローカルヘッダZIP64フォーマットと一般的な目的のビットではない
13マスキングを示すフラグが設定されていると、値のために保存
ヘッダーには、地元の非圧縮サイズをゼロになります。
ファイル名の長さ： （ 2バイト）
余分なフィールドの長さ： （ 2バイト）
コメントの長さファイル： （ 2バイト）
ファイル名の長さは、余分なフィールド、およびコメント
それぞれのフィールド。任意の長さの合計
ディレクトリを記録し、これらの3つのフィールドは必要ない
一般的に65,535バイトを超える。場合は標準入力から来た
入力は、ファイル名の長さはゼロに設定されています。
起動ディスク番号： （ 2バイト）
は、このファイルを開始し、ディスクの数です。場合は、
ZIP64アーカイブ形式で、このフィールドの値です
0xFFFF 、サイズに対応する4バイトzip64になる
拡張情報余分なフィールド。
内部ファイルの属性： （ 2バイト）
PKWAREのビット1と2で使用するために予約されています。
このフィールドの最下位ビットは、設定すると、を示すものであり
明らかにされ、ファイルをASCIIまたはテキストファイルです。れていない場合は
設定すると、どうやら、そのファイルのバイナリデータが含まれます。
残りのビットのバージョン1.0で使用されていないしている。
場合は、このフィールドの設定0x0002ビットを示しますが、
4バイトのレコード長を制御フィールドでは、各変数の前に
論理レコードは、レコードの長さを示す。その
レコード長制御フィールドリトルエンディアンバイトに格納されている
順番。このフラグがテキストを制御文字に依存せず、
の場合、テキストデータと組み合わせて、使用されるすべてが含まれています
レコードの合計の長さは制御文字。この
値をメインフレームのデータ転送のサポートを提供しています。
外部ファイルの属性： （ 4バイト）
外部属性のマッピングされ
ホストシステムに依存（参照してください'のバージョンによって作ら' ） 。 ?のために
MS - DOSのは、下位バイトは、 MS - DOSのディレクトリです
バイト属性。入力は標準入力の場合は、このから来た
フィールドをゼロに設定されている。
相対ローカルヘッダのオフセット： （ 4バイト）
これは、最初のディスクの開始からのオフセット
このファイルが、そこでは地元のはずのヘッダが表示されます
発見される。 ZIP64アーカイブ形式とする場合の値です
この分野では、サイズが表示されます0xFFFFFFFFです
8バイトの拡張情報zip64余分なフィールドが対応する。
ファイル名： （可変）
オプションの相対パスでファイルの名前は、 。
ドライブまたはパスを含めることはできません格納
デバイスの文字、または、リードを大幅に削減する。すべてのスラッシュ
転送する必要がありますスラッシュ' / 'のように反対する
後方スラッシュ' \アミガとの互換性のために
およびUNIXのファイルシステム等の場合は標準入力から来た
入力、ファイル名がない分野です。もし暗号化
中央ディレクトリとの汎用13ビットフラグが設定されている
マスクを示し、ファイルの名前は地元のヘッダに格納
実際のファイル名をすることはできません。マスクの値を構成
ユニークな16進数の値が格納されます。この値が
アーカイブ内の各ファイルを順番にインクリメントされる。見る
詳細については、強力な暗号化の仕様のセクションを
暗号化されたファイル名を取得する。
余分なフィールド： （可変）
この拡張されています。関連情報を参照する場合
特別なニーズのために保存する必要があるかを特定
プラットフォームは、ここに格納する必要があります。以前のバージョン
のソフトウェアを安全に、そして、このファイルをスキップすることができます
次のファイルやヘッダを検索する。このフィールドは0になります
バージョン1.0での長さ。
ためには、異なる種類の異なるプログラムを許可する
情報の' '余分なフィールドに格納される。郵便
ファイルは、次の構造のすべてを使用する必要があります
この分野でのプログラムを格納するデータ：
header1 + header2 + data1 + data2 。 。 。
各ヘッダとしてください：
ヘッダ番号- 2バイト
データサイズ- 2バイト
注：インテルlow-byte/high-byteすべてのフィールドの順序で格納されます。
は、ヘッダーのIDフィールドのデータ型を示すことにある
以下のデータをブロック。
ヘッダのIDを0から31日までPKWAREで使用するために予約されています。
残りの番号のサードパーティベンダのために使用することができます
独占的使用。
PKWAREは、現在のヘッダIDをマッピングによって定義されます：
0x0001 Zip64拡張情報余分なフィールド
0x0007のAV情報
0x0008拡張言語（によってPFS ）のデータのエンコーディングのために予約
（ ）付録Dを参照してください
0x0009のOS / 2
0x000aのNTFS
0x000cのOpenVMS
0x000dのUNIX
ストリームのファイル記述子のために予約し0x000eフォーク
0x000fパッチディスクリプタ
0x0014のPKCS ＃ 7店、 X.509証明書を
0x0015 X.509証明書IDと署名を
個々のファイル
0x0016 X.509証明書番号中央Directory用
強力な暗号化0x0017ヘッダ
0x0018レコードマネジメントコントロール
0x0019のPKCS ＃ 7暗号化受信者の証明書のリスト
0x0065 IBM社のS/390 （ Z390 ） 、 AS/400の（ I400 ）の属性
-非圧縮
0x0066 IBM社のS/390 （ Z390 ） 、 AS/400の（ I400 ）のために予約
属性-圧縮
0x4690 POSZIP 4690 （予約）
よく使われているサードパーティのマッピングされます：
0x07c8マッキントッシュ
0x2605 ZipItのMacintosh
Macintosh版1.3.5 + 0x2705 ZipIt
Macintosh版1.3.5 + 0x2805 ZipIt
0x334d情報郵便マッキントッシュ
0x4341どんぐり/ SparkFS
0x4453 Windows NTセキュリティ記述子（バイナリのACL ）
0x4704のVM / CMSは
MVSは0x470f
0x4b46 FWKCSはMD5 （下記参照）
0x4c41 OS / 2のアクセス制御リスト（本文のACL ）
0x4d49情報- ZIP形式のOpenVMS
Xceed元の場所0x4f4c余分なフィールド
0x5356 AOS /対（ ACL ）の
0x5455延長タイムスタンプ
0x554e Xceed Unicodeの余分なフィールド
0x5855情報- ZIP形式のUNIX （ 、また元のOS / 2 、 NTでは、等）
0x6375情報- ZIP形式のUnicodeコメントエキストラフィールド
BeOSの0x6542 / BeBox
0x7075情報- ZIP形式のUnicodeパスエキストラフィールド
ASIを0x756eのUNIX
0x7855情報- ZIP形式のUNIX （新）
オープン0xa220マイクロソフト製品の成長のヒント
0xfd4aのSMS / QDOS
余分なフィールドで定義されて3分の1の詳細説明
党のマッピング情報にはドキュメント化される
このようなデータ構造PKWAREに利用可能になります。
PKWAREは公開の精度を保証していません
サードパーティのデータ。
フィールドには、以下のデータサイズの大きさを示して
データブロック。プログラムをスキップして、この値を使用することができます
次のヘッダブロックされている任意のデータをブロックに渡す
興味はない。
注記：同様に、全体をzip形式のファイルのサイズを上記のように
ファイル名、コメントを含むヘッダーは、余分な
フィールドのサイズが64Kを超えてはならない。
2種類のプログラムが同じ場合には適切なはず
ヘッダのID値は、それを強くお勧めしますが、各
少なくとも2つのバイトのプログラムに固有の署名で
サイズ（ 4バイトまたは、できれば大きい）は、開始時に
各データ領域を設定します。すべてのプログラムを確認する必要がありますが、その
独自の署名は、ヘッダーの番号に加えて、存在している
値は、これのブロックであると仮定する前に修正されて
タイプ知られています。
- Zip64拡張情報エキストラフィールド（ 0x0001 ） ：
以下は、 zip64拡張のレイアウトです
情報" "余分なブロック。もし1つのサイズや
は、ローカルまたは中央のディレクトリにオフセットフィールド
レコードでも、必要なデータを保持するために、小さいです
Zip64作成されている情報を記録した。
内のフィールドの順序が、 zip64拡張
情報を記録、が固定されている分野が
のみ表示される場合は、対応するローカルまたは中央
ディレクトリレコードのフィールド0xFFFFまたは0xFFFFFFFFに設定されている。
注：インテルlow-byte/high-byteすべてのフィールドの順序で格納されます。
値のサイズ説明
----- ---- -----------
（ ZIP64 ） 0x0001 2バイトこの"余分な"ブロックタイプのタグ
この" "余分なブロックのサイズは2バイトのサイズ
オリジナル
サイズはオリジナルの8バイトの非圧縮ファイルのサイズ
圧縮
圧縮データのサイズは8バイトのサイズ
相対ヘッダ
オフセット8バイトローカルヘッダレコードのオフセット
ディスクを起動
コードは4バイト数は、ディスクの上の
このファイルを起動する
ローカルのヘッダーにこのエントリは元の両方を含める必要があります
ファイルの圧縮とサイズフィールド。場合は、暗号化
中央ディレクトリとは、一般的な目的のビットのビット13
マスキングを示すフラグが設定され、その値が格納
地元のヘッダーは、元のファイルサイズをゼロになります。
- OS / 2のエキストラフィールド（ 0x0009 ） ：
以下は、 OSのレイアウトは、 / 2の属性" "余分な
ブロック。 （最終改訂09/05/95 ）
注：インテルlow-byte/high-byteすべてのフィールドの順序で格納されます。
値のサイズ説明
----- ---- -----------
（ OS / 2の） 0x0009 2バイトこの"余分な"ブロックタイプのタグ
以下のデータをブロックにTSize 2バイトサイズ
BSize 4バイトの非圧縮ブロックサイズ
CType 2バイト圧縮タイプ
解凍ブロックEACRC 4バイトのCRC値
（予めVar ）可変圧縮ブロック
は、 OS / 2拡張属性構造体（ FEA2LIST ）
と圧縮して全体の中で、この内に格納
構造。までのデータを1つしかない"ブロック"になる
VarFields [ ] 。
- NTFSのエキストラフィールド（ 0x000a ） ：
以下は、 NTFSのレイアウトです属性
"余分な"ブロック。 （注：この時点では、ファイルのmtime 、 atimeが
とCtime値は、 Win32システム上で使用されることがあります。 ）
注：インテルlow-byte/high-byteすべてのフィールドの順序で格納されます。
値のサイズ説明
----- ---- -----------
（ NTFS ）を0x000a 2バイト、この"余分な"ブロックタイプのタグ
総" "ブロックを追加TSize 2バイトのサイズ
予約は4バイト、将来の使用のために予約
2バイトのNTFS Tag1タグの属性値＃ 1
バイト単位での属性＃ 1のSize1 2バイトサイズ、
（ var. ） Size1属性＃ 1データ
。
。
。
2バイトのNTFS TagNタグのvalue属性の値が＃ N
バイトで属性のSizeN 2バイトのサイズが＃ N 、
（ var. ） SizeN属性が＃ Nデータ
NTFSのは、 TagNを通じてTag1の値は以下のとおりである：
属性の（現在は1つしか設定NTFS用）定義されている
タグのサイズ説明
----- ---- -----------
0x0001は2バイトのタグの属性＃ 1
バイト単位での属性＃ 1のSize1 2バイトサイズ、
ファイルのmtime 8バイトファイルの最終更新時間
atimeが8バイトファイルの最終アクセス時間
Ctime 8バイトファイルの作成時
- OpenVMSのエキストラフィールド（ 0x000c ） ：
以下は、 OpenVMSの属性のレイアウトです
"余分な"ブロック。
注：インテルlow-byte/high-byteすべてのフィールドの順序で格納されます。
値のサイズ説明
----- ---- -----------
（ VMS上） 0x000c 2バイトこの"余分な"ブロックタイプのタグ
総" "ブロックを追加TSize 2バイトのサイズ
CRCが4バイト、 32ビットのCRCは、ブロックの残りの
2バイトのOpenVMS Tag1タグの属性値＃ 1
バイト単位での属性＃ 1のSize1 2バイトサイズ、
（ var. ） Size1属性＃ 1データ
。
。
。
2バイトのOpenVMS TagNタグのvalue属性の値が＃ N
バイトで属性のSizeN 2バイトのサイズが＃ N 、
（ var. ） SizeN属性が＃ Nデータ
ルール：
1 。されますが、 1つまたは属性が存在するのは、
それぞれの値TagX ＆ SizeX上記の先行されます。
これらの値は、 ATR $ C_XXXXと同じです
ATR.Hの下で定義されているATR $ S_XXXX定数
OpenVMSのC.これらの値のどちらもゼロになります。
2 。単語の配置やパディングは行われている。
3 。よく生産することはありませんPKZIP / OpenVMSのプログラムの動作
2つ以上のサブTagX値では同じブロック。同様に、
型のことはありませんが、複数の"余分な"ブロック
特定のディレクトリレコードで0x000c 。
- UNIXのエキストラフィールド（ 0x000d ） ：
以下は、 UNIXの" "余分なブロックのレイアウトです。
注記：すべてのフィールドが格納されているインテルのlow-byte/high-byte
順番。
値のサイズ説明
----- ---- -----------
（ UNIXの） 2バイトこの"余分な"ブロックタイプのタグ0x000d
以下のデータをブロックにTSize 2バイトサイズ
atimeが4バイトのファイルの最終アクセス時間
ファイルのmtime 4バイトのファイルの最終更新時間
Uidの2バイトファイルのユーザーID
GIDの2バイトファイルのグループID
（予めVar ）変数の長さのデータフィールド
は、可変長のデータフィールドのタイプのファイルが含まれます
特定のデータ。現在、唯一の値が許可されています
"元のリンク先"のファイル名を象徴するのは難しいか
リンクと、メジャーとマイナーデバイスノード番号について
文字やデバイスノードをブロック。デバイスノード以降
シンボリックまたはハードリンクのいずれか1つだけ設定することはできません
可変長のデータが格納されます。リンクファイルは、必要があります
元のファイル名を格納します。この名前がNOT NULLである
終了しました。そのサイズTSizeを確認して決定することができます-
12 。 8バイトの2つのデバイスのエントリとして保存されているだろう4
バイトのエントリをリトルエンディアン形式（ ） 。最初のエントリ
予定の主要なデバイスの数、および2つ目は、軽微なこと
デバイス番号。
-ディスクリプタエキストラフィールド（ 0x000f ）修正プログラム：
以下は、修正プログラム記述子のレイアウトを"余分な"です
ブロック。
注：インテルlow-byte/high-byteすべてのフィールドの順序で格納されます。
値のサイズ説明
----- ---- -----------
（パッチ） 0x000f 2バイトこの"余分な"ブロックタイプのタグ
総" "ブロックを追加TSize 2バイトのサイズ
バージョン2バイト版は、記述子の
フラグ4バイトの操作と反応（下記参照）
ファイルのOldSize 4バイトのサイズについてのパッチを適用する
OldCRC 4バイト、 32ビットのCRCは、ファイルのパッチを適用する
表示されたファイルのNewSize 4バイトのサイズ
NewCRC 4バイト、 32ビットのCRC結果のファイルの
行動と反応
ビット説明
---- ----------------
自動検出に0を使用
自己として1トリート-パッチ
2-3予約
4-5アクション（下記参照）
6-7予約
8-9反応（下）ファイルを参照してください欠席
10月11日の反応（下）新しいファイルを参照してください
12月13日反応（下記参照）が不明のファイルを参照してください
14-15予約
16-31予約
アクション
アクション値
------ -----
なし0
1追加
2削除
パッチ3
反応
反応値
-------- -----
0尋ねる
1を飛ばして
2無視
3失敗
パッチをサポートPKPatchMaker （ TM ）の技術が提供されている
保留中の米国特許と特許の対象。を使用するか
特定の技術的な側面は、製品の実装を設定
APPNOTE規定は、現在、これらの点を含む
強力な暗号化、パッチ、または拡張テープの操作が必要
PKWAREからライセンス。 PKWAREに関してお問い合わせください
のライセンスを取得。
-ストアのX.509証明書のPKCS ＃ 7 （ 0x0014 ） ：
このフィールドは、それぞれの証明書に関する情報が含まれ
ファイルが署名される可能性があります。は、セントラルディレクトリの暗号化
機能は、 ZIPファイルを有効にすると、このレコードに表示されます
アーカイブ余分なデータレコードが、それは、で表示されます
最初の中央ディレクトリを記録し、任意では無視されます。
他の記録。
注：インテルlow-byte/high-byteすべてのフィールドの順序で格納されます。
値のサイズ説明
----- ---- -----------
（店） 0x0014 2バイトこの"余分な"ブロックタイプのタグ
店のTSize 2バイトのサイズのデータ
TData TSizeのデータの保存について
- X.509証明書IDと署名、個々のファイル（ 0x0015 ） ：
このフィールドの情報は約証明書に含まれて
＃ 7店は、特定のファイルの署名に使用されたのPKCS 。また、
その署名データが含まれます。このフィールドは、複数表示することができます
回、 1回あたりの証明書のみが表示されます。
注：インテルlow-byte/high-byteすべてのフィールドの順序で格納されます。
値のサイズ説明
----- ---- -----------
（ CID ）を0x0015 2バイトこの"余分な"ブロックタイプのタグ
TSize 2バイトのデータサイズは、次のように
TData TSize署名データ
- X.509証明書IDと署名中央ディレクトリ（ 0x0016 ） ：
このフィールドの情報は約証明書に含まれて
＃ 7店の中央のディレクトリ構造の署名に使用されたのPKCS 。
は、セントラルディレクトリの暗号化機能が有効になっている
ZIPファイルは、この記録は、アーカイブに余分なデータレコードが表示されます
そうでなければ、最初の中央ディレクトリレコードに表示されます。
注：インテルlow-byte/high-byteすべてのフィールドの順序で格納されます。
値のサイズ説明
----- ---- -----------
（ CDID ） 0x0016 2バイトこの"余分な"ブロックタイプのタグ
TSize 2バイトのデータサイズは、次のように
TData TSizeデータ
-強力な暗号化ヘッダ（ 0x0017 ） ：
値のサイズ説明
----- ---- -----------
0x0017は2バイト、この"余分な"ブロックタイプのタグ
TSize 2バイトのデータサイズは、次のように
このレコードのフォーマットは2バイト形式の定義
悪感2バイトの暗号化アルゴリズムの識別子
Bitlen 2バイトのビット長の暗号化キー
フラグを2バイトのフラグを処理
CertData TSize - 8証明書の復号余分なフィールドのデータ
（ CertDataのための説明を参照してください
このセクションでは、記述で
証明書の処理方法の下で
強力な暗号化仕様）
レコードマネジメントコントロール（ 0x0018 ） ：
値のサイズ説明
----- ---- -----------
（録音- CTLが） 0x0018 2バイトこの"余分な"ブロックタイプのタグ
余分なブロックの合計サイズCSize 2バイトのデータ
Tag1 2バイトレコードの制御1属性
属性は1バイトでSize1 2バイトのサイズ、
Data1 Size1属性1のデータ
。
。
。
TagN 2バイトレコードの制御N属性
バイトで属性のSizeN 2バイトサイズN 、
DataN SizeN N属性データ
-のPKCS ＃ 7暗号化受信者の証明書のリスト（ 0x0019 ） ：
このフィールドは、それぞれの証明書に関する情報が含まれ
暗号化処理に使用されるが誰なのかを識別するために使用することができます
暗号化されたファイルを復号化できるようになりました。このフィールドにのみ表示されます
アーカイブ内の余分なデータを記録します。このフィールドは必須ではありません
側近のアーカイブの変更のみを保存しております公開
暗号化キーデータ。個々のセキュリティ要件を左右する可能性があります
情報の暴露を抑止するには、このデータを省略すること。
注：インテルlow-byte/high-byteすべてのフィールドの順序で格納されます。
値のサイズ説明
----- ---- -----------
（ CStore ） 0x0019 2バイトこの"余分な"ブロックタイプのタグ
店のTSize 2バイトのサイズのデータ
TData TSizeのデータの保存について
TData ：
値のサイズ説明
----- ---- -----------
バージョン2バイト形式のバージョン番号- 0x0001する必要がありますこの時点で
BLOB型のPKCS ＃ 7データCStore （予めVar ）
- MVSはエキストラフィールド（ 0x0065 ） ：
以下は、 MVSは"余分な"ブロックのレイアウトです。
注：一部のフィールドをビッグエンディアン形式で格納されている。
指定された場合を除き、すべてのテキストをEBCDIC形式になっています。
値のサイズ説明
----- ---- -----------
（ MVSは） 0x0065 2バイトこの"余分な"ブロックタイプのタグ
以下のデータをブロックにTSize 2バイトサイズ
番号は4バイトのEBCDIC " Z390 " 0xE9F3F9F0または
TargetFour " T4MV "
（予めVar ） TSize - 4属性データ（付録Bを参照してください）
エキストラ-OS/400フィールド（ 0x0065 ） ：
以下は、 『 OS/400 "余分なのレイアウトを"ブロックされています。
注：一部のフィールドをビッグエンディアン形式で格納されている。
指定された場合を除き、すべてのテキストをEBCDIC形式になっています。
値のサイズ説明
----- ---- -----------
（ OS400 ） 0x0065 2バイトこの"余分な"ブロックタイプのタグ
以下のデータをブロックにTSize 2バイトサイズ
番号は4バイトのEBCDIC " I400 " 0xC9F4F0F0または
TargetFour " T4MV "
（予めVar ） TSize - 4属性データ（付録Aを参照してください）
サードパーティのマッピング：
- ZipIt Macintoshのエキストラフィールド（長い） （ 0x2605 ） ：
以下は、 ZipIt余分なブロックのレイアウトです
Macintosh用。は、ローカルのヘッダーと中央部にあるヘッダのバージョン
同一です。このブロックの場合は、ファイルが存在する必要があります
MacBinaryとエンコードに使用すべきではない場合は、ファイルを格納
MacBinary保存されていないエンコードされた。
値のサイズ説明
----- ---- -----------
この余分なブロックタイプ（ Mac2 ） 0x2605ショートタグ
このブロックの全データサイズTSizeショート
" ZPIT "属して余分なフィールド署名
ファイル名のFnLenバイトの長さ
Macintoshの変数の完全なファイル名のファイル名
ファイルタイプバイト[ 4 ] 4バイトのMacのファイルの種類を文字列
クリエイターバイト[ 4 ] 4バイトのMacクリエイターの文字列
- ZipIt Macintoshのエキストラフィールド（ファイル用） （ 0x2705 ）ショート：
以下は、その他の短縮のレイアウトです
Macintosh用の余分なブロックZipItフルネーム"エントリ） （ " 。
その他ZipIt 1.3.5以降で、このエントリのために使用されています
ファイル（ディレクトリ）は、 MacBinaryエンコードしていない
ファイル。は、ローカルのヘッダーと中央のヘッダーのバージョンは同じです。
値のサイズ説明
----- ---- -----------
この余分なブロックタイプ（ Mac2b ） 0x2705ショートタグ
このブロック（ 12 ）の合計データサイズTSizeショート
" ZPIT "属して余分なフィールド署名
ファイルタイプバイト[ 4 ] 4バイトのMacのファイルの種類を文字列
クリエイターバイト[ 4 ] 4バイトのMacクリエイターの文字列
fdFlags FInfo.frFlagsから、属性beShort
省略されることがあります
0x0000のbeShort予約、省略されることがあります
- ZipIt Macintoshのエキストラフィールド（ディレクトリの） （ 0x2805 ）ショート：
以下は、その他の短縮のレイアウトです
Macintosh用の余分なブロックZipItディレクトリのみに使用される
エントリ。このその他ZipIt 1.3.5およびそれ以降で使用されて
保存するディレクトリについてのいくつかのオプションのMac固有の情報。
は、ローカルのヘッダーと中央のヘッダーのバージョンは同じです。
値のサイズ説明
----- ---- -----------
この余分なブロックタイプ（ Mac2c ） 0x2805ショートタグ
このブロック（ 12 ）の合計データサイズTSizeショート
" ZPIT "属して余分なフィールド署名
frFlags 、 DInfo.frFlagsから属性beShort可能性があります
省略すること
表示beShort ZipIt表示フラグ、省略されることがあります
[表示フィールドとしてZipItの内部設定を指定します：
は、フラグのビット：
ビット0が設定すると、そのフォルダの拡大（オープン）で表示されます
ZipItでは、アーカイブの内容が表示されます。
ビット1-15予約、ゼロ;
- MD5エキストラFWKCSフィールド（ 0x4b46 ） ：
FWKCS Contents_Signatureのシステムで使用される
自動的に識別するファイルのファイル名に依存しない、
オプションで追加し、余分なフィールドを使用してサポートするために
contents_signatureの急速な拡張の作成：
ヘッダ番号= 0x4b46
データサイズ= 0x0013
序文= ' M 'の、 'エ' 、 '5 '
続いては、 16バイトを含む非圧縮ファイルの
128_bit MD5ハッシュ（ 1 ） 、下位バイト初めて。
FWKCSときはzip形式を追加するには中央のディレクトリにファイルを修正
ファイルを、この余分なフィールドが、それに代わるも
中央ディレクトリエントリは、ファイルを非圧縮のための
長さを測定した値を持つファイルです。
FWKCSこの余分なフィールドは、ストリップするためのオプションを提供する場合
現在、から。郵便中央ディレクトリファイルです。追加で
この余分なフィールドFWKCS保持します。認証のファイルをZIP形式
検証の場合、この余分なフィールドFWKCSストリッピング
PKZIPのバージョン2.04グラムまでのAVのすべてのバージョンを保持します。
FWKCS 、 FWKCS Contents_Signatureシステムです
フレデリックWカンターの商標です。
（ 1 ） rをRivest 、 RFC1321.TXT 、 MITの研究室のコンピュータ用の
科学とはRSA Data Security社は、 1992年4月。
ll.76 - 77 ： " MD5アルゴリズムは、に配置されている
見直しをパブリックドメインとは、養子縁組の可能性
標準的な。 "
マイクロソフトオープン包装成長のヒント（ 0xa220 ） ：
値のサイズ説明
----- ---- -----------
この余分なブロックタイプのショートタグ0xa220
SIGのTSizeショートサイズ+ PadVal +パディング
信号ショート署名検証（ A028 ）
ショート初期値PadValパディング
変数がNULL文字で埋めパディング
ファイルコメント： （可変）
このファイルのコメント。
このディスクの数： （ 2バイト）
このディスクは、中心部が含まれ、数
ディレクトリの最後のレコード。 ZIP64フォーマットの場合は、アーカイブされ
このフィールドの値0xFFFFは、サイズが
zip64最後に対応する4バイトになる中央
ディレクトリフィールド。
中央のスタートでは、ディスクの数
ディレクトリ： （ 2バイト）
ディスクの数は、中央が
ディレクトリを開始します。 ZIP64フォーマットの場合は、アーカイブされ
このフィールドの値0xFFFFは、サイズが
zip64最後に対応する4バイトになる中央
ディレクトリフィールド。
中央ディレクトリ内のエントリの合計数に
このディスク： （ 2バイト）
このディスク上の中央ディレクトリエントリの数。
ZIP64フォーマットでアーカイブする場合、値は
0xFFFF 、このフィールドは、サイズが表示されます
8の最後のバイト対応zip64中央
ディレクトリフィールド。
中央ディレクトリ内のエントリの総数： （ 2バイト）
。 ZIPファイル内のファイルの合計数です。場合は、
ZIP64アーカイブ形式で、このフィールドの値です
、サイズに対応する8バイトになる0xFFFFです
フィールドの中央ディレクトリzip64終了します。
中央ディレクトリの大きさ： （ 4バイト）
のサイズ（バイト数）は、全体の中央ディレクトリの。
ZIP64フォーマットでアーカイブする場合、値は
このフィールドは0xFFFFFFFFです、サイズが表示されます
8の最後のバイト対応zip64中央
ディレクトリフィールド。
中央ディレクトリの開始を尊重することでオフセット
開始ディスク番号： （ 4バイト）
オフセットは、上の中央ディレクトリの開始
ディスクの中央ディレクトリを開始する。場合は、
ZIP64アーカイブ形式で、この内の値です
フィールドは0xFFFFFFFFです、サイズが表示されます
8の最後のバイト対応zip64中央
ディレクトリフィールド。
zip形式ファイルのコメントの長さ： （ 2バイト）
このため、コメントの長さ。 ZIPファイル。
。 ZIPファイルのコメント： （可変）
これはコメント。 ZIPファイル。 ZIP形式のデータファイルのコメント
無担保格納されます。データは暗号化や認証
この時点で、この領域に適用されます。機密情報
このセクションに格納してはいけません。
zip64拡張可能なデータの部（変数サイズ）
（現在はPKWAREが使用できるように）予約
ZIPファイルを分割するとスパンK.
スパンは、 ZIPファイルをセグメント化するプロセスのことです
複数のリムーバブルメディア。このサポートは、通常ている場合にのみ
DOSのフロッピーをフロッピーディスクのフォーマットのために提供されている。
ファイルの分割にまたがるの新しい誘導体です。
分割と同様のプロセスを次のように細分化
スパンが、それぞれの書面を必要としない
ユニークなリムーバブルメディアにセグメントし、代わりに対応しています
ローカルまたは非リムーバブルの場所にすべての作品を配置
ファイルシステムには、ローカルドライブのような、フォルダ等..
スパンキーの間の違いとZIP形式のファイルを分割すると
は、同じ名前のファイルはZIPスパンのすべての作品。
以来、各作品を別のボリュームには、名前を書かれている
衝突が発生元の各セグメントを再利用することができます
アーカイブに与えられた。 ZIPファイル名を入力します。
シーケンスDOS用のアーカイブをDOSを使用して発注スパン
ボリュームラベルのセグメント数を決定します。ボリュームラベル
各セグメントのためのフォームを使って書かれている、 ＃ XXXのPKBACK
xxxは、セグメント数を10進で書かれている
001からの値-はNNN 。
スプリットZIPファイルは通常、同じ場所に書かれています
スパンの場合は、名前の衝突名に加算されます
形式各セグメント上に存在するので、同じ使用されています
運転する。 、分割アーカイブの名前が名前の衝突を回避するには
以下のとおりです。
セグメント1 = filename.z01
1 = filename.zセグメントのn （ n - 1の）
セグメントN = filename.zip
は、 zip形式の拡張子の最後のセグメントをサポートするために使用されています
すぐに中央のディレクトリを読んでいます。セグメント数
nは10進数の値をする必要があります。
ZIPファイルPKSFX自己スパンZIPファイルを解凍することができる。
PKSFXファイルも、ただし、この場合には分割されることがあります
名前の最初のセグメントfilename.exeする必要があります。最初の
アーカイブの分割PKSFXセグメントに十分な大きさが必要
全体の実行可能プログラムが含まれます。
分割アーカイブの容量は以下のとおり。
セグメント= 4294967295の最大数- 1
最大セグメントサイズ= 4294967295バイト郵便
最小セグメントサイズ= 64Kの
PKSFX最大セグメントサイズ= 2,147,483,647バイト
セグメントサイズは大会は、すべてが異なる場合があります
セグメントのサイズを除いては、同じでなければなりません
は、最後に小さくすることができる。地方と中央のディレクトリ
ヘッダーレコードはセグメントの境界で分割することはする必要があります。
場合には、ヘッダーレコードを書く場合、残りのバイト数
セグメント内のヘッダーレコードのサイズよりも小さいことを
現在のセグメントを終了して、開始時には、ヘッダーを書く
次のセグメントの。中央ディレクトリがありますスパンセグメント
境界線が、中央のディレクトリには1つのレコード
セグメントを分割する必要があります。
スパン/スプリットPKZIP for Windowsを使用して作成アーカイブ
（ V2.50以上） 、 PKZIPコマンドライン（ V2.50以上） 、
またはPKZIP Explorerをまたがる特別含まれます
最初のセグメントの最初の4バイトとして署名
アーカイブ。この署名（ 0x08074b50 ）となります
署名には、ローカルのヘッダの後すぐに
アーカイブ内の最初のファイルです。
特別にまたがるマーカーも表示される場合がありますスパン/分割
アーカイブの場合、または分割処理が始まりますが、スパン
1セグメントのみを必要とします。この場合は、 0x08074b50で
署名は、一時的に置き換えられますまたがる
0x30304b50マーカーの署名です。アーカイブを分割することができます
PKZIPの他のバージョンでは唯一の非圧縮される
分割アーカイブを作成する方法を知っている。
この署名値0x08074b50も一部で使われている
データ記述子のためのマーカーとしては、 ZIP形式の実装
記録します。この別の割り当てで競合することができます
は、署名の位置を確保することによって回避
ZIPファイル内の使用を決定するために
意図しています。
L.一般的な注意：
1 ）すべてのフィールドに格納され、特に断りのない限り符号なし
Intelの低バイト： - 、下位バイトの高いワード：高語順。
2 ）文字列フィールドがNULLで終了しないと、以降
長さを明示的に与えられています。
3 ） 5月、中央のディレクトリ内のエントリは必ずしも
同じ順序で、ファイルは、 。 zipファイルに表示される。
4 ） 1つの中央ディレクトリの最後には、フィールドの
必要なデータの記録も、そのフィールドを保持するために小さい
-1 （ 0xFFFFかは0xFFFFFFFF ）と設定する必要があります
ZIP64フォーマットレコードを作成する必要があります。
5 ）を記録し、中央ディレクトリの最後に
中央ディレクトリロケータレコードのZip64終わる必要があります
同じディスク上に存在する時分割またはスパン
アーカイブ。
? 。 UnShrinking -方法1
--------------------------
縮小ダイナミックLempel - Ziv -ウェルチ圧縮アルゴリズムである
部分をクリアする。最初のコードサイズ9ビットであり、
最大コードサイズは13ビットです。縮小とは異なる
従来のダイナミックLempel - Ziv -ウェルチの実装では、いくつかの
点：
1 ）のコードサイズは、圧縮機によって制御される、とされていません
コードよりも大きく増加したときに自動的に現在の
コードサイズ（ただし、必ずしも）を使用していないが作成されます。いつ
伸張のコードシーケンス256遭遇
（ 10進数） 1が続くと、コードサイズを増やす必要があります
入力ストリームから次のビットサイズをお読みください。いいえ
は、コードのブロックなので、次のコードを実行される
の増加のサイズは、入力ストリームから読み込むことが必要
直後には、小型で、前のコード
ビットサイズを読むでした。繰り返しになりますが、解凍するはずですが、
256,1シーケンスのコードサイズは、使用するまで増加している
が発生しました。
2 ）テーブルがいっぱいになると、全クリアしていないこと
を行った。むしろ、ときに圧縮機のコードを排出
シーケンス256,2 （ 10進数）で、解凍をクリアする
は、 Lempel - Zivからすべてのリーフノードツリーを続ける
現在のコードサイズを使用します。がクリアされているノード
Lempel - Zivからは、ツリーを再使用されて、最低で
コード値を最初に再使用し、最高コード値
再使用されている。コンプレッサーは、シーケンス256,2を発することができる
いつでも。
? 。拡大-メソッド2-5
----------------------------
実際には2つの低減アルゴリズムの組み合わせです
異なるアルゴリズム。最初の繰り返しを圧縮アルゴリズム
バイトシーケンスを、 2つ目のアルゴリズムを圧縮
最初のアルゴリズムからのストリームとは、確率論を適用
圧縮方式。
店舗は、確率論的圧縮追従'の配列
セット' （ j ）は、はJ = 0から255までのため、それぞれの可能性に対応
ASCII文字。各設定は0から32の間に含まれて
文字は、秒（ jと）に示される[ 0 ],...,秒（ j ）は[メートル] 、ここでm < 32 。
を設定するためのデータ領域の先頭に格納されている
削減ファイル、逆の順序は、秒（ 255 ）は、まず、およびS （ 0 ）を使用して
最後の。
セット（ N （ j ）は、 、 ） （ jエンコードされ、 [ 0 ],...,秒（ J ）を追加[ n （ j ）は-1 ] ） 、
ここで、 N （ J ）を設定秒（ j ）はのサイズです。 N （ j ）は0になることができ、
は、追従のS （ J ）を設定する場合は空です。各N （ j ）は値です
6ビットで、 N （ j ）は、 8ビットの文字をエンコードされた値
秒（ j ）はに対応する[ 0 ]秒（ j ） [ N （ j ）は-1 ]である。もし
N （ j ）は0 、その後秒（ j ）はない値、および値が格納される
N （ j - 1 ）すぐに以下の通りです。
すぐに追従を設定した後、圧縮データです
流れ。圧縮データストリームのために解釈することができます
減圧確率は以下の通り：
せ最終-キャラクター< - 0 。
ループまで行わ
追従を設定する場合は、 （最後の文字）が空です
入力ストリームから、 8ビットを読んで、これをコピー
は、出力ストリームに値。
それ以外の場合は、追従を設定する（最後の文字）が非を空
入力ストリームから1ビットをお読みください。
このビットをゼロではない
入力ストリームから、 8ビットを読んで、これをコピー
は、出力ストリームに値。
それ以外の場合、このビットをゼロにしている
は、入力からB （ N読む（最終-キャラクター） ）ビット
ストリームは、この値を代入すると? 。
Sの値をコピー（最後の文字） [私]に
出力ストリーム。
最後の値は、出力ストリームへの配置を割り当てる
最後のキャラクター。
エンドループ
B （ N （ j ）は）ビットの最小限のコードを必要に応じて定義されている
エンコードの値N （ j ）は-1 。
上からのストリームを解凍して、拡大することができます
再としては、元のファイルを作成します：
せ州< - 0 。
ループまで行わ
C.には、入力ストリームから8ビットを読む
国の場合
0 ：もしc （ 144 10進数）ではないに等しいしDLE
出力ストリームをCコピーしてください。
それ以外の場合、 cしているに等しいDLE
せ州< - 1 。
1 ：ゼロ以外の場合cしている
せVの< - C.
）レン< - L （ Vのせ
せ州< -金（レン） 。
それ以外の場合、 cゼロにしている
出力ストリームに値を144 （ 10進数）をコピーします。
国家<せ- 0
2 ：せレン< -レン+ Cで
せ州< - 3 。
3 ：移動後方エ（ Vの、 C ）を出力ストリームのバイト
（この位置は前に、出力の開始
ストリームは、当然だと思うし、前にすべてのデータ
出力ストリームの開始ゼロで）いっぱいだ。
この位置からは、出力ストリームにコピーレン3バイトです。
せ州< - 0 。
終了の場合
エンドループ
機能金、 L 、およびDは'圧縮に依存している
4を通じて因子' 、 1 、と定義されている以下の通り：
圧縮率1の場合：
L （ X ）をXの7ビットは、下に等しい
それ以外の場合、 Xの金（ X ）を3に等しい等しい金127 （ X ）を2に等しい。
エの（ x 、 y ） ） * 256 +イ+ 1 Xの（上位1ビットに相当します。
圧縮因子2の場合：
L （ X ）をXの6ビットは、下に等しい
それ以外の場合、 Xの金（ X ）を3に等しい63等しい金（ X ）を2に等しい。
エの（ x 、 y ） ） * 256 +イ+ 1 Xの（上位2ビットに相当します。
圧縮率3の場合：
L （ X ）をXの5ビットは、下に等しい
それ以外の場合、 Xの金（ X ）を3に等しい31等しい金（ X ）を2に等しい。
エの（ x 、 y ） ） * 256 +イ+ 1 Xの（上位3ビットに相当します。
圧縮率4の場合：
L （ X ）をXの下位4ビットに等しい
それ以外の場合、 Xの15金（ X ）を3に等しい等しい金（ X ）を2に等しい。
エの（ x 、 y ） ） * 256 +イ+ 1 Xの（上位4ビットに相当します。
? 。 Imploding -方法6
--------------------------
Implodingアルゴリズムの実際の組み合わせは、 2つの異なる
アルゴリズム。最初のバイトの圧縮アルゴリズムを繰り返す
配列のスライド式の辞書を使用しています。 2番目のアルゴリズムである
スライド式の辞書は、出力のエンコードを圧縮し、使用される
木を使用して複数のシャノンファノ。
Implodingアルゴリズムは、 4Kまたは8K辞書をスライドを使用することができます
寸法。辞書サイズを使用してのビットが1に基づいて決定することができます
一般的な目的のフラグワード; 4K辞書が0のビットを示します
中に1ビットの8Kの辞書を示しています。
木のシャノンファノの開始時点で保存されている圧縮
ファイル。木々の数は、ビット2で定義されている保存
一般的な目的のフラグワード;が0ビットの2つの木、保存を示す
1ビットの3つの木格納されていることを示します。もし3の木、保存されている
ツリーには、最初のシャノンファノのエンコーディングを表します
リテラル文字、 2番目の木のエンコーディングを表します
の長さについては、 3番目のエンコードを表します
距離情報。時2シャノンファノの木、保存されている
最初の長さの木は、木の距離の順に格納されます。
のリテラルシャノンファノツリーが存在する場合に使用されます表す
全体をASCII文字セットに含まれ、 256の値。この
ツリーの任意のデータが圧縮されないの圧縮に使用されているスライド式
辞書アルゴリズム。このツリーは、存在している最小
試合の長さは、スライド式の辞書には3です。この木です
存在しない場合は、最低2試合の長さです。
の長さシャノンファノツリーには、長さの部分の圧縮に使用されています
（長さは、スライド式の辞書からの距離）のペア
出力。木64の長さの値は、範囲が含まれて
最低限の試合の長さは、 63試合の長さに加えて、最小。
距離シャノンファノのツリーには、距離の圧縮に使用されています
（長さの部分は、スライド式の辞書からの距離）のペア
出力。木64は、距離の値を、 0に至るまでが含まれて
63は、距離値の上位6ビットを表す。その
距離の値が0との間になりますスライディング
辞書のサイズ、どちらか4Kまたは8K 。
シャノンファノの木は、それ自体で保存されているには、圧縮
フォーマットです。ツリーのデータの最初のバイトの数を表します
データは、 （圧縮を表すのバイト）シャノンファノツリー
マイナス1 。ツリーには、残りのバイト数を表すシャノンファノ
データとしてエンコード：
高4ビット：このビットの長さの値の数+ 1 。 （ 1から16まで）
低4ビット：ビット長の値を表すために+ 1が必要だった。 （ 1から16まで）
このコードは、ビットの長さシャノンファノから構築することができます
は、次のアルゴリズムを使用する場合：
昇順で1 ）の並べ替えのビット長で、維持
元の長さのファイルに保存の順。
2 ）木がシャノンファノを生成：
コード< - 0
CodeIncrement < - 0
LastBitLength < - 0
シャノンの私< -数ファノコード- 1 （いずれかの255または63 ）
ループの中> = 0
コード=コード+ CodeIncrement
もしBitLength （ 1 ） < > LastBitLengthし
LastBitLength = BitLength （ ? ）
CodeIncrement = 1 （ 16 - LastBitLength ）左シフト
ShannonCode （ ? ） =コード
私< -私は- 1
エンドループ
3 ） ShannonCode上記のすべてのビットの順序を逆に（ ）
ベクトルには、最上位ビットは、最低になる
上位ビット。たとえば、値0x1234 （ 16進数）と
（ 16進数） 0x2C48になっています。
4 ）としてシャノンファノ符号の順序を復元もともと保存
このファイル内に。
例：
この例では、シャノンのエンコーディング-ファノツリーが表示されます
サイズ8 。通知は、実際の木を使用シャノンファノ
Implodingのサイズは64または256のいずれかのエントリがあります。
例：が0x02 、 0x42この、が0x01 、 0x13制限
最初のバイトは、この表の3の値を示しています。は、デコード
バイト：
3ビットの0x42この= 5のコード長
2ビットが0x01 = 1のコード長
4ビットの0x13制限= 2のコード長
これは、元のビット長の配列を生成します：
（ 3 、 3 、 3 、 3 、 3 、 2 、 4 、 4 ）
この値は、 0のため、この表には8のコード7を介している。を使用して
このアルゴリズムは、シャノンファノ取得するコードを生成：
逆にオーダーオリジナル
ヴァル分別建設コード値の復元長
-------- -------- -------- --- ------ ------
0 ： 2 1100000000000000 11 101 3
1 ： 3一〇一〇 〇 〇 〇 〇 〇 〇 〇 〇 〇 〇 〇 〇 101 001 3
2 ： 3一〇 〇 〇 〇 〇 〇 〇 〇 〇 〇 〇 〇 〇 〇 〇 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
はヴァル、注文復元、オリジナルの長さの値の列
現在、シャノンファノのために使用することができますエンコードツリーを表す
デコードはエンコードされたデータシャノンファノ。どのように解析する
可変長のデータストリームからシャノンファノの値を超えている
この文書の範囲。 （以下を参照して末に記載参照してください
詳細については、この文書。 ）しかし、従来のデコード
可変長ハフマン方式のデコード用のような使用
Greenlawアルゴリズムは、正常に適用することができます。
圧縮データストリームの後すぐに開始
データ圧縮シャノンファノ。圧縮データをストリームすることができます
として解釈します：
ループまで行わ
入力ストリームから1ビットをお読みください。
このビットは、それ以外の場合（エンコードされたデータは、リテラルデータ）ゼロ
もしリテラルシャノンファノツリーが存在する
リテラル文字とデコードシャノンファノツリーを使用してお読みください。
そうでなければ
入力ストリームから8ビットをお読みください。
は、出力ストリームにコピーする文字。
その他（エンコードされたデータ）と一致スライディング辞書です
辞書サイズが8K
オフセットのオフセットの距離を読むための7ビット（下位7ビット） 。
そうでなければ
オフセットのオフセットの距離を読むために6ビット（下位6ビット） 。
を読むと、デコードの距離シャノンファノの木を使用して、
の距離値の上位6ビット。
を読んで、デコードシャノンファノの長さの木を使用して、
の長さの値。
長さ< -長さ+最小マッチ長
試合の場合、長さ= 63 +最小長
入力ストリームから、 8ビットを読む
長さにこの値を追加します。
後方移動距離は、出力ストリームに1バイト、
この位置は、出力する長さの文字をコピー
流れ。 （この位置は前に、出力の開始
ストリーム、と仮定しての開始前にすべてのデータ
出力ストリームをゼロで）いっぱいだ。
エンドループ
? 。トークン-方法7
-------------------------
PKZIP 、この方法では使用されません。
Xをしぼませる-方法8
-----------------------
アルゴリズムを使用して、収縮させるアルゴリズムは、破に似ている
最大32K二次圧縮との滑り辞書
ハフマン/シャノンファノコードです。
圧縮データのブロックに格納されているヘッダを記述すると
ハフマン符号は、ブロックとは、データブロックで使用される。ヘッダ
フォーマットは以下の通り：
このビットが1に設定されているビット0 ：最終ビットブロックされている場合、この最後の
データの圧縮ブロック。
ビット1-2 ：ブロックタイプ
00 （ 0 ） -ブロックの格納されている-全ての保存されたデータのバイト配列です。
次のバイトをし、次の単語=ブロックまでスキップビット
長さは、ブロックのものが続くの賛辞
単語の長さ。ブロック内の残りのデータは、保存
データ。
01 （ 1 ） -を固定ハフマン符号を使用し、距離コードリテラル。
点灯コードビット区コードビット
--------- --------- ---- ----
0から143 8 0 - 5月31日
144から255 9
256 ? 279 7
280 ? 287 8
リテラルコードを286から287までの距離を30から31アールのコード
使ったことがないが、ハフマン建設に参加しています。
10 （ 2 ） -動的ハフマン符号。 （ハフマン符号の拡大）をご覧ください
11 （ 3 ） -予約-が見られる"圧縮データでは"エラーフラグ。
拡大ハフマン符号
-----------------------
動的な場合は、データブロックに格納されているハフマン符号は、ハフマン
コードは次の圧縮形式で送信されます：
5ビット： ＃リテラルコードの送信- 256 （ 256から286 ）
他のすべてのコードを送信することはありません。
5ビット： ＃区コードの- 1 （ 1から32まで）
4ビット： ＃ビットの長さコード- 3 （ 3 ? 19 ）
ハフマン符号のビット長として構築されていますし、コードが送信されます
アルゴリズムでは、破。ビットの長さにしている
ハフマン符号で圧縮。は19ビット長のコードです：
0 ? 15 ： 0のビットの長さを表す- 15
16 ：前のビット長3 -コピー6回。
次の2ビットを繰り返して長さ（ 0 = 3 、を示して... 、 3 = 6 ）
例：コード8 、 16 （ 2ビット11 ） 、 16 （ 2ビット10 ）が
8の12ビットの長さ（ 1 + 6 + 5 ）に拡大
17 ：繰り返し3の0のビット長- 10回。長さ（ 3ビット）
18 ：繰り返し11の0のビット長-長さの138倍（ 7ビット）
のビット長コードの長さの値ごとに3ビット満員送信されます
（ 0 ? 7 ）には、次の順序で：
16 、 17 、 18 、 0 、 8 、 7 、 9 、 6 、 10 、 5 、 11 、 4 、 12 、 3 、 13 、 2 、 14 、 1 、 15
破アルゴリズムとしては、ハフマン符号で説明構築する必要があります
を除いてのコードは、短いビット長での開始、すなわち、割り当てられている
短いコードはすべて0ではなく1のすべての必要があります。また、コードを
ゼロのビット長は、ツリーの建設に参加することはありません。その
コードして、文字のビット長をデコードするために使用されている
距離テーブル。
リテラルテーブルのためのビットの長さは最初に番号を送信される
エントリの5ビットで、以前の送信で説明した。そこまでしている
286リテラル文字に、最初の256が8それぞれ表す
ビット文字、コード256は、エンドブロックのコードを表し、残りの
29のコード258を介し3のコピーの長さを表しています。そこを30にしている
距離コード32kを通じて1日からの距離を表すといわ
?の下に。
コードの長さ
------------
エキストラエキストラエキストラエキストラ
コードのビット長コードのビット長コードのビット長コードのビット長さ（秒）
---- ---- ---- ---- ------ ------- ------- ---- ---- ---- - - ---------
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
距離コード
--------------
エキストラエキストラエキストラエキストラ
コードビット区コードビット区コードビット遠隔コードビット距離
---- ---- ---- ---- ---- ------ ---- ---- ---- ---- ---- --------
0 0 1 8 3 17-24 7月16日257から384まで11月24日4097から6144
1 0 2 9 3 25-32 7月17日385から512まで11月25日6145から8192
2 0 3 4月10日33から48まで8月18日513から768まで12月26日8193から1228まで8
3 0 4 11 4 49-64 8月19日769から1024まで12月27日12289から16384
4月1日5,6 5月12日65 ? 96 9月20日一千二十五から千五百三十六28 13 16385から24576
5月1日7,8 5月13日97から128まで9月21日1537から2048 29 13 24577から32768まで
6月2日9月12日6月14日129から192 22 10 2049 ? 3072
7月2日13-16 6月15日193から256まで10月23日3073から4096
圧縮データストリームの後すぐに開始
圧縮ヘッダデータ。圧縮データをストリームすることができます
として解釈します：
する
入力ストリームからのヘッダーを読んでください。
場合、ブロックの保存
バイト配列までスキップビット
とカウント数の1の賛辞を読む
コピーカウントデータブロックバイト
そうでなければ
ブロックの終了コードを送信するまでループ
リテラル文字入力ストリームからデコード
リテラルの場合、 < 256
出力ストリームにコピー文字
そうでなければ
ブロックの場合、リテラル=終わり
ループから抜け出す
そうでなければ
入力ストリームからデコード距離
は、出力ストリーム内の移動距離の下位バイト、
この位置は、出力からのコピーの長さの文字
流れ。
エンドループ
最後は中ブロック
データ記述子が存在する場合
バイト配列までスキップビット
読むのCRCとサイズ
endifの
XIの。強化されたしぼませる-方法9
---------------------------------
しぼませるアルゴリズムを拡張収縮させるに似ている
64Kにはスライド式の辞書を使用しています。 Deflate64 （ TM ）のサポートされています
抽出を収縮させる。
XII 。 BZIP2 -方法12
----------------------
BZIP2はオープンソースのデータ圧縮アルゴリズムが開発されています
Julian Sewardに。情報やソースコードは、このアルゴリズムを
インターネット上で見つけることができます。
XIII 。 LZMA -方法14 （ EFS ）を
----------------------------
LZMAブロック型は、一般的な目的のデータ圧縮アルゴリズムである
を開発し、イゴールパブロフによって維持。これはLZ77の誘導体である
マルコフ連鎖とは、さまざまな符号を利用します。情報と
このアルゴリズムのソースコードがインターネット上で見つけることができます。相談
については、このアルゴリズムの著者の用語やで
使用上の制限。
LZMAはZIP形式でのサポートとして定義されている以下の通り：
地方と中央はZIP内の圧縮方式のフィールド
ヘッダーレコードの値を14にデータを示すために設定されます
LZMA圧縮を使用しています。
現地では、バージョンはZIPとフィールドを抽出するために必要な
中央ヘッダーレコードを6.3に示すために設定されます
最小ZIP形式のバージョン、この機能をサポートしています。
ファイルのデータを配置する必要がありますは、 LZMA圧縮アルゴリズムを使用して
すぐに次のヘッダファイルの現地。場合
標準のZIP形式の暗号化ヘッダ、それに従うが必要です
ヘッダとは、ローカルLZMA圧縮ファイルに先行する
データセグメント。 LZMA圧縮データセグメントの場所
としては、 ZIP形式で表示されます：
[ローカルヘッダ1ファイル]
[暗号化ファイルのヘッダ1 ]
[ LZMAファイル1のデータセグメントを圧縮]
[データ記述子1 ]
[ローカルのヘッダー2ファイル]
ヘッダとデータの暗号化記述子を記録することがあります
条件付きで存在する。は、 LZMA圧縮データセグメント
一LZMAのプロパティで構成されるヘッダが続く
LZMA圧縮データとして表示：
[ファイルのプロパティを1 LZMAヘッダー]
ファイル1 [ LZMA圧縮データ]
は、 LZMA圧縮が提供するデータとして保存されます
LZMA圧縮ライブラリ。圧縮サイズ、圧縮されていない
ファイルの中の大きさや他のファイルの特徴
圧縮標準のZIP形式のストレージ形式で格納する必要があります。
LZMAプロパティは、ヘッダーに必要な特定のデータを格納する
データは、 LZMA圧縮解凍。このデータによって設定されている
LZMA圧縮エンジンは、関数を使用してWriteCoderProperties （ ）
LZMA SDKのように記載。
LZMA内でプロパティの情報は、ストレージ分野
ヘッダのプロパティは以下のとおりである：
LZMAバージョン情報は2バイト
LZMAのプロパティのサイズは2バイト
LZMAのプロパティのデータの変数は、 LZMAのプロパティのサイズ"によって定義される"
LZMAバージョン情報-このフィールドでは、バージョンの識別
LZMA SDKのファイルを圧縮するのに使われた。最初のバイトが
LZMA SDKとは、 2番目のメジャーバージョン番号を保存
バイトがマイナー番号を保存します。
LZMAプロパティサイズ-このフィールドには、残りのサイズを定義しています
プロパティのデータ。通常、このサイズは、に基づいて決定する必要があります
SDKのバージョンです。このサイズフィールドには、利便性として含まれています
その中の場合にはあいまいさを避けるためには、将来の
この圧縮アルゴリズムの変化に。
LZMA物件データ-この変数フィールドのレコードに必要なサイズの
は、 LZMA SDKが定義されている解凍の値。その
このフィールドにデータを使用して取得する必要があります保存
WriteCoderPropertiesは、 SDKによって定義されたバージョン（ ）
" LZMAバージョン情報"フィールドに入力します。
" LZMAプロパティデータ"フィールドのレイアウトはの機能です
LZMA圧縮アルゴリズム。それは、このレイアウトすることができる可能性があります
時間をかけて、作者が変更されました。バージョン4.32でのデータのレイアウト
は、 LZMA SDKの4バイトを格納するために使用する5バイト配列を定義しています
リトルエンディアンの順序では、辞書サイズ。これは前に
に含まれる配列の最初の要素の1つのパックバイト
次のフィールド：
PosStateBits
LiteralPosStateBits
LiteralContextBits
LZMAのマニュアルを参照して、より詳細な説明のための
これらのフィールド。
データ法14 、 LZMAで、エンドの圧縮ストリームを含めることができます
（のEOS ）マーカーは、圧縮データストリームを終了します。このマーカーではない
が、必要な処理を容易にするために非常にその使用をお勧めします
と実装可能な場合は、マーカーのEOS含める必要があります。
マーカーのEOSとき、使用されている一般的な目的のビットが1に設定する必要があります。もし
一般的な目的のビットが1は、マーカーのEOSが存在しない場合は設定されません。
14 。 PPMd -方法98
---------------------
PPMdは、データ圧縮アルゴリズムが開発されShkarinドミトリー
これはcarryless rangecoderドミトリーSubbotinが開発されています。
このアルゴリズムに一致するフレーズを複数の予測に基づいている
注文コンテキスト。情報やソースコードは、このアルゴリズムを
インターネット上で見つけることができます。本の著者との相談
使用の条件や制限の詳細については、アルゴリズム。
PPMdはZIP形式でのサポートは現在にのみ提供されます
バージョンの私は、このアルゴリズムの見直し1 。ストレージ要件
このアルゴリズムを使用しては以下のとおりである：
パラメータは、アルゴリズムを制御する2つの格納されている必要
すぐに圧縮データを上記のバイト。これらのバイトをしている
次のフィールドを格納するために使用：
モデルオーダー- 、デフォルト8 、最大のモデルの注文が可能ですセット
値を2月16日に含まれている
サブアロケータサイズ-サブアロケータメガバイトの大きさに設定し、デフォルトの50ですが、
可能な値は1MBから256MBに含まれている
モデルを復元法-コンテキストを再起動するために使用する方法を設定します
メモリ不足でのモデルでは、値は：
0 -ゼロからの再起動モデル-デフォルト
1 -モデルを断つ-の2倍ほどパフォーマンスが低下
2 -凍結コンテキストツリー-お勧めできません
は、 2バイトのストレージ分野にこれらのフィールドを梱包するための例です。
以下に示す。これらの値が格納されているインテルのlow-byte/high-byte
順番。
wPPMd = （モデルオーダー- 1 ） +
（ （サブアロケータサイズ- 1 ） < < 4 ） +
（モデル復元法< < 12 ）
15 。従来の暗号化PKWARE
---------------------------------
以下の情報は、復号化の手順について説明
従来の暗号化をサポートするために必要PKWARE 。この
暗号化のフォームを、今日の基準で考えられている弱い
とその使用状況でのみお勧めします
低セキュリティの必要性以上の高齢者。 ZIP形式との互換性のために
アプリケーションに最適です。
復号
----------
PKWAREロジャー氏Schlaflyへの専門家の貢献に感謝しています
PKWAREの伝統的な暗号化の開発に向けた。
PKZIP圧縮データストリームを暗号化します。暗号化されたファイルをする必要があります
復号化される前に、抽出することができます。
それぞれの暗号化されたファイルは、余分な12バイトの開始時に保存されている
のデータ領域は、そのファイルの暗号化ヘッダを定義する。その
ヘッダの暗号化はもともとランダムな値にし、設定されている
それ自体は、 32ビットキーの3つを使用して暗号化されます。キー値は
提供されている暗号化パスワードを使用して初期化します。各バイトの後
暗号化され、鍵を使用して更新している擬似乱数
同世代の技術と組み合わせてのCRC - 32アルゴリズム
PKZIPで使用されて、他のこの文書で説明します。
以下は、基本的な手順は、ファイルを復号化するために必要です：
1 ） 3 32 - bit鍵のパスワードを入力して初期化します。
2 ）を読むと、 12バイトの暗号化ヘッダ、さらに復号化
暗号化キーを初期化する。
3 ）を読み、その圧縮データストリームを使用して復号化
暗号化キー。
ステップ1 -は、暗号化キーの初期化
-----------------------------------------
キー（ 0 ） < - 305419896
キー（ 1 ） < - 591751049
キー（ 2 ） < - 878082192
ループのi < - 0に長さ（パスワード） -1
update_keys （パスワード（ 1 ） ）
エンドループ
どこupdate_keys （ ）として定義されています：
update_keys （文字） ：
キー（ 0 ） < - CRC32の（キー（ 0 ） 、文字）
キー（ 1 ） < -キー（ 1 ） + （キー（ 0 ） ＆ 000000ffH ）
キー（ 1 ） < -キー（ 1 ） * 134775813 + 1
キー（ 2 ） < - CRC32の（ （ 2 ） 、キー（ 1 ） > > 24 ）キー
最後update_keys
どこCRC32の（ old_crc 、文字）は、 CRC値を指定するルーチンは、
文字は、 CRCを適用した後に値を返すには、更新のCRC - 32
アルゴリズムの他、この文書で説明した。
ステップ2 -ヘッダ、暗号化復号化
-----------------------------------------
この手順の目的はさらに、暗号化を初期化することです
ランダムなデータに基づいて鍵は、平文攻撃にレンダリングする
データの効果がない。
読んでいる12バイトのバッファに暗号化し、ヘッダーの場所で
バッファ（ 11 ）をバッファ（ 0 ） 。
ループのi < - 0から11まで
c < - （ 1 ）バッファ^ decrypt_byte （ ）
update_keys （連）
バッファ（ 1 ） < - c
エンドループ
どこdecrypt_byte （ ）として定義されています：
署名のない文字decrypt_byte （ ）
ローカル未署名の短い気温
気温< -キー（ 2 ） | 2
decrypt_byte < - （気温* （気温^ 1 ） ） > > 8
最後decrypt_byte
ヘッダの後、復号化され、バッファ内の最後の1または2バイト
すべき高次ワード/バイトのファイルのCRCの中になる
、インテルlow-byte/high-byteの順序で格納さ復号化されます。バージョンの
PKZIP 2.0の前には、 2バイトのCRCチェックを使用;を1バイトのCRCチェックしてください。
2.0以降のバージョンで使用されます。このテストに使用できる場合は、パスワード
供給が正しいかどうかです。
ステップ3 -は、圧縮データストリームを復号化
----------------------------------------------
圧縮データストリームの復号化することができます以下の通り：
ループまで行わ
Cには文字を読む
気温< - c ^ decrypt_byte （ ）
update_keys （気温）
出力温度
エンドループ
16 。強力な暗号化仕様
------------------------------------
強力な暗号化技術は、この仕様で定義されている
保留中の特許出願の対象。を使用するかの実装
前項において、特定の技術的側面の製品では、現在の
これらの強力な暗号化などについてAPPNOTE 、パッチ、
または拡張テープPKWARE業務からのライセンスが必要です。部分
この強力な暗号化技術を使用するためには、無料でご利用いただけます。
おPKWAREライセンス条件。第?章を参照して
この（お問い合わせPKWARE ）の情報をどのようにAPPNOTE
連絡PKWARE 。
バージョン5.x 、この仕様のための強力なサポートを発表
暗号化アルゴリズム。これらのアルゴリズムのいずれかを使用することができます
パスワードまたはX.509v3デジタル証明書をそれぞれのファイルを暗号化する。
このフォーマットの仕様のいずれかのパスワードまたは証明書をサポートしています
ベースの暗号化は、今日のセキュリティを満たすために、有効にする必要がある
両方のPKIとPKIの以外に、ユーザー間での相互
環境では、との間の相互運用性を確保するため、異なる
は、 ZIP形式のプログラムを実行しているコンピューティングのプラットフォーム。
パスワードベースの暗号化、暗号化の中でも最も一般的な方法です
人に慣れている。しかし、固有の弱点で
パスワード（辞書に感受性例えば/ブルートフォース攻撃）
だけでなく、パスワード管理やサポートの問題の証明書を作る
ベースの暗号化は、より安全でスケーラブルなオプションを選択します。業界
努力とサポートを定義していると、より高度な方面へ移動
セキュリティソリューションX.509v3デジタル証明書を中心と
公開鍵基盤（ PKI ）のスケーラビリティが大きいため、
以上の管理者用のオプションは、より堅牢なセキュリティの伝統的な
パスワードベースの暗号化。
これでほとんどの標準的な暗号化アルゴリズムをサポートしています
仕様。これらの多くのためのリファレンス実装
アルゴリズムは、商用、オープンソースのいずれかからご利用いただけます
販売代理店。容易に利用可能な暗号化ツールキットを作る
暗号化機能の実装をまっすぐ進む。
この文書データには、論文を提供するために意図されていません
暗号化の原理や理論。その目的は、文書化しています
データ構造の相互運用を実現するためのデータが必要
。 ZIP形式で暗号化。ことを強くお勧めしますが
を読む前にデータの暗号化をよく理解する
それ以上の。
このアルゴリズムはバージョン5.0でこの仕様の導入
含まれます：
RC2が40ビット、 64ビット、 128ビット
RC4の40ビット、 64ビット、 128ビット
デ
3DESの112ビットと168ビット
バージョン5.1は、次のサポートが追加されます：
AESの128ビット、 192ビット、 256ビット
バージョン6.1をサポートするために、暗号化データの変更を発表しました
スマートカードとUSBトークンの証明書のストレージとの相互運用性
OAEPを強化する方法を標準サポートしていません。
バージョン6.2に圧縮して、メタデータを暗号化するためのサポートを紹介
と中央のディレクトリのデータ構造を暗号化する情報を削減する
漏れ。従来のZIP形式のアプリケーションで情報漏えいが発生すること
ファイルに関する情報の露出を介しているにもかかわらず、そのファイル
暗号化保存されます。ファイルで構成される情報公開
特性を記録し、これによって定義されたフィールドに格納
仕様。これは、ファイル名などのデータが含まれ、元の
サイズ、タイムスタンプとCRC32の値。
バージョン6.3のデータを使用してこのBlowfish暗号化のサポートを紹介
やTwofishアルゴリズム。これらの対称ブロック暗号開発されています
Bruce Schneier氏。フグからは可変長の鍵を使用してサポートしています
32から448ビット。ブロックサイズが64ビットです。実装は16を使用してください
ラウンドし、 ZIP形式のファイルのみのモードでサポートされているCBCのです。 Twofish
鍵長128 、 192 、 256ビットをサポートしています。ブロックサイズが128ビットです。
実装は16ラウンドとは、専用モードでサポートされて使用する必要があります
CBCのZIPファイルです。 Blowfishや情報との両方のためのソースコード
Twofishアルゴリズムは、インターネット上で見つけることができます。相談は、著者と
情報は、これらのアルゴリズムを使用する上での条件や制限を加える。
中央ディレクトリの暗号化の一層の保護を提供しています
中央ディレクトリ構造と暗号化することによって情報漏えい
現地では、暗号化キーの値のマスクで複製されます
ヘッダ。 ZIP形式を解釈することはできませんが、暗号化された互換性のあるプログラム
中央のディレクトリ構造に対応するには、データに頼ることはできない
ローカルヘッダ減圧参照してください。
余分なフィールドのレコードは、ファイルに関する情報が含まれることがあります必要があります
公開されないローカルのヘッダに格納してはならないはずのみ
中央ディレクトリへの書き込みがどこに暗号化することができます。この
デザインは現在、ストリーミングをサポートしていません。情報は、終了の
中央ディレクトリの記録は、セントラルディレクトリ検索のZip64完、
中央ディレクトリレコードのZip64エンド暗号化されていません。アクセス
ファイルをZIPファイルには暗号化された中央Directoryとのデータを表示するに
前に復号化するための適切なパスワードまたは秘密鍵が必要
は、アーカイブ内の任意のファイル、またはファイルについての情報を表示する。
古い郵便対応のプログラムは、中央ディレクトリに慣れていない
暗号化機能は、もはや中央を認識できるようになる
ディレクトリとは、 ZIPファイルが破損していると仮定することがあります。プログラムは、
ストリーミングにアクセスを試みるが表示されますローカルヘッダを使用して無効
各ファイルの情報を。中央ディレクトリの暗号化が必要ではない
すべてのZIPファイルに使用されます。その利用をより安全にお勧めします。
郵便として動作する必要があります中央ディレクトリの暗号化を使用していないファイル
過去インチ
この強力な暗号化機能の仕様を提供すること目的としている
は、クロスプラットフォームのスケーラブルな単純なパスワードの暗号化の範囲が必要
一般の暗号化、認証/秘密鍵を暗号化。
暗号化データの機密性とプライバシーを提供します。それは
は、暗号化とデジタル署名を組み合わせるのX.509推奨
認証および否認防止を追加します。
対称暗号化方式を1つのパスワード：
-------------------------------------------
対称暗号化方式は、単一のパスワードを使用して強力な
同様に、従来の暗号化アルゴリズムで動作
PKWAREの暗号化、この形式で定義されています。追加データ
構造は、必要な処理をサポートするために追加されます
強力なアルゴリズム。
強力な暗号化データ構造をしている：
1 。汎用ビット-ビット0と6ビットの汎用
両方の地方と中央のヘッダーレコードにフラグ。両方のビットを設定する
強力な暗号化を示しています。ビット13は、設定して、中央を示して
ディレクトリは暗号化され、地元のヘッダで選択したフィールド
その実際の値を隠すためにマスクされています。
2 。 0x0017中央ヘッダに余分なフィールドのみ。
このレコードのフィールドを検討しています：
フォーマット-このレコードのデータ形式の識別子。唯一の
値はこの時点で許可は、整数値は2です。
悪感-からの暗号化アルゴリズムの整数の識別子
範囲は次の
0x6601 -デ
0x6602 - RC2が（バージョン< 5.2を抽出するために必要な）
0x6603 - 3DESの168
0x6609 - 3DESの112
0x660E - AESの128
0x660F - AESの192
0x6610 - AESの256
0x6702 - RC2が（バージョンを抽出するために必要な> = 5.2 ）
0x6720 -フグ
0x6721 - Twofish
0x6801 - RC4の
0xFFFF -不明なアルゴリズム
Bitlen -明示的なビット長のキー
32から448ビット
フラグ-フラグを復号化に必要な処理
0x0001 -パスワードを復号化するために必要です
0x0002 -証明書のみ
0x0003 -パスワードまたは証明書を復号化するために必要
値> 0x0003証明書処理のために予約
3 。ヘッダファイルを復号化、圧縮前のデータを記録する。
-復号化ヘッダ：
値のサイズ説明
----- ---- -----------
初期化ベクトル（ IV ）のIVSize 2バイトサイズ
このファイルのIVData IVSize初期化ベクトル
残りの復号化データのサイズは4バイトのヘッダサイズ
このレコードのフォーマットは2バイト形式の定義
悪感2バイトの暗号化アルゴリズムの識別子
Bitlen 2バイトのビット長の暗号化キー
フラグを2バイトのフラグを処理
暗号化されたランダムデータのErdSize 2バイトサイズ
ErdData ErdSize暗号化されたランダムデータ
Reserved1 4バイトの予約証明書処理データ
Reserved2 （予めVar ）証明書処理データのために予約
パスワード検証VSize 2バイトのデータサイズ
VData VSize - 4パスワードの検証データ
VCRC32 4バイトの標準郵便CRC32のパスワード検証データの
は、 IVのIVData -のサイズは、アルゴリズムのブロックサイズが一致する必要があります。
IVData完全にランダムなデータにすることができます。サイズの場合
は、ランダムに生成されたデータは、ブロックサイズと一致しません
それを補完する必要がありますがゼロまたは切り捨てとして
必要。もしIVSize 0し、四= CRC32の+非圧縮
ファイルサイズ（リトルエンディアンの64ビット、符号なし整数値として） 。
フォーマット-このレコードのデータ形式の識別子。唯一の
値はこの時点で許可は、整数値は3です。
悪感-からの暗号化アルゴリズムの整数の識別子
範囲は次の
0x6601 -デ
0x6602 - RC2が（バージョン< 5.2を抽出するために必要な）
0x6603 - 3DESの168
0x6609 - 3DESの112
0x660E - AESの128
0x660F - AESの192
0x6610 - AESの256
0x6702 - RC2が（バージョンを抽出するために必要な> = 5.2 ）
0x6720 -フグ
0x6721 - Twofish
0x6801 - RC4の
0xFFFF -不明なアルゴリズム
Bitlen -明示的なビット長のキー
32から448ビット
フラグ-フラグを復号化に必要な処理
0x0001 -パスワードを復号化するために必要です
0x0002 -証明書のみ
0x0003 -パスワードまたは証明書を復号化するために必要
値> 0x0003証明書処理のために予約
ErdData -暗号化されたランダムなデータをランダムなデータを格納するために使用されること
ファイルを暗号化するためにセッション鍵を生成するために使用されています
各ファイル。 SHA1のハッシュを計算するために使用されているデータを使用
鍵を得る。セッション鍵は、マスターファイルから派生しています
セッション鍵は、ユーザーのパスワードから生成する。
ヘッダにある場合は、復号化フラグフィールドが含まれて
値0x4000 、そのErdDataフィールドする必要があります
3DESのを使って復号化されます。この値が0x4000に設定されていません
悪感ErdDataフィールドを使用して復号化する必要があります。
Reserved1 -証明書処理のために予約、もし値です
ゼロにし、 Reserved2データが存在しない。説明を参照してください
証明書の処理方法の詳細については下
このデータ構造。
Reserved2 -が存在する場合は、データ構造のサイズをReserved2
このフィールドの最初の4バイトのスキップが位置しています
して、残りのサイズで、次の2バイトを使用しています。見る
証明書の処理方法の下の説明
このデータ構造の詳細については。
VSize -このサイズの値はいつもの4バイトが含まれます
VCRC32データと4バイトより大きくなるだろう。
VData -パスワードを検証用にランダムデータ。このデータVSizeです
長さは、 VSize 、暗号化の倍数である必要があります
ブロックサイズ。 VCRC32 VDataのチェックサム値です。
VDataとVCRC32格納されている暗号化して開始
ファイルを暗号化されたデータの流れ。
4 。役に立つヒント
強力な暗号化は常に圧縮後のファイルに適用されます。その
カンパニーマン向けのアルゴリズムのブロックのすべてのブロック連鎖（ CBC ）で動作
モード。 AES暗号化に使用されるブロックサイズは16です。他のすべてのブロック
8アルゴリズムのブロックサイズを使用しています。 2つの番号のRC2が定義されているため
のアカウントには、 RC2が不一致のための実装で発見
Windows XP SP1およびアルゴリズムで暗号化ライブラリのすべての
Windowsの以前のバージョン。これはお勧めですが長さゼロのファイル
暗号化されるのは、しかしそれらを抽出するプログラムを用意する必要があります
場合には、 ZIPファイル内で発見されています。
擬似コードは、暗号化プロセスの表現は次のとおりです：
パスワード= GetUserPassword （ ）
MasterSessionKey = DeriveKey （ SHA1を（パスワード） ）
路= CryptographicStrengthRandomData （ ）
各ファイルに対して
四= CryptographicStrengthRandomData （ ）
VData = CryptographicStrengthRandomData （ ）
VCRC32 = CRC32の（ VData ）
FileSessionKey = DeriveKey （ SHA1を（四+路）
ErdData =暗号化（路MasterSessionKey 、 ? ）
暗号化（ VData + VCRC32 + FileData 、 FileSessionKey 、 ? ）
完了した
関数名とパラメータの要件に依存します
選択した暗号化ツールキットを選択します。ほぼすべての
各ツールキットのリファレンス実装をサポート
アルゴリズムを使用することができます。は、 RSA BSAFE （ R ）のはOpenSSL 、およびMicrosoft
CryptoAPIをライブラリのすべてが順調に仕事を知られています。
1つのパスワード-中央ディレクトリの暗号化：
-----------------------------------------------
中央ディレクトリの暗号化します。 ZIP形式にすることによって達成され
中央のディレクトリ構造を暗号化する。これは、メタデータをカプセル化
最も多くの処理に使用されます。 ZIPファイル。追加のメタデータに格納されている
各ファイルのヘッダには、ローカルの冗長性。隠しのプロセス
内のデータを保護していない中央ディレクトリの暗号化することによって、メタデータ
ローカルヘッダ。メタデータからの情報漏えいに露出を避けるために
ローカルのヘッダーには、ファイルに関する情報を含むフィールドはマスクされています。
ローカルヘッダ：
マスキングは、ローカルでのファイルのフィールドの真のコンテンツを置き換える
偽のヘッダ情報を。マスクが、ローカルのヘッダーではない
とのデータを回復するためのオプションにアクセスストリーミングには適して破損
アーカイブを削減することができる。機密情報を含むデータフィールドを追加することがあります
データは、地元のヘッダに格納してはいけません。の値に設定
バージョンフィールドを抽出するための適切な値を必要とする必要がありますが必要
中央ディレクトリの暗号化に関係なく、ファイルを解凍します。フィールド
ローカルヘッダマスキングをターゲットには、セントラルディレクトリです
暗号化されます：
フィールド名マスク値
------------------ ---------------------------
圧縮方式0
最後のモジュールファイルの時間0
最後のモジュールファイルの日付0
のCRC - 32 0
サイズ0の圧縮
サイズ0の非圧縮
からファイル名（変数サイズ）ベース16の値
範囲は1 - 0xFFFFFFFFFFFFFFFF
その文字列として表さ
サイズは、に設定されます
ファイル名の長さフィールド
基本16値は、マスクファイル名として割り当てられているだけでは、順次
それぞれのファイル1で、最初のファイルを起動するためインクリメント値。
ZIPファイルへの変更、異なる値を格納することがあります
各ファイル。互換性のために、ローカルのヘッダーでファイル名]フィールド
空白のままにしてはいけません。バージョン6.2の仕様の時点で、
の圧縮方法と圧縮サイズフィールドはマスクされていません。
フィールドは、 0xFFFFまたはZIP64フォーマットでは0xFFFFFFFFの値を持つ
マスクしてはいけません。
中央ディレクトリの暗号化：
中央ディレクトリの暗号化の暗号化が含まれていません
中央ディレクトリの署名データを、中央DirectoryのZip64完
記録は、セントラルディレクトリ検索するか、 EndのZip64完
中央ディレクトリを記録した。 ZIPファイルのコメントデータがありません
暗号化されます。
中央ディレクトリを暗号化する前に、オプションで圧縮することがあります。
圧縮、必須ではありませんが、ストレージ効率のために想定される
この構造を暗号化する前に圧縮されます。同様に、この
指定せずに、中央ディレクトリの圧縮をサポートしています
また、暗号化される必要があります。これの早期の実装
機能は、ファイルの暗号化方式に適用すると一致すると仮定
暗号化は、セントラルディレクトリに適用されます。
中央ディレクトリの暗号化は同様の方法で行われます
そのファイルの暗号化。暗号化されたデータは前に
復号ヘッダ。ヘッダーには、復号化アーカイブとして知られています
復号ヘッダ。このレコードのフィールドと同じです
それぞれの暗号化ファイルの復号化ヘッダ前。場所
復号化アーカイブのヘッダーの値によって決定されます
スタートは、中央ディレクトリのフィールドの中央でのZip64完
ディレクトリレコード。は、セントラルディレクトリ、暗号化されている
Zip64完中央ディレクトリレコードのは常に存在することになります。
中央ディレクトリレコードのZip64エンドのレイアウトをすべての
バージョン6.2 、この仕様に従うので開始
バージョン2形式です。は、バージョン2の形式は次のとおりです：
このためには、バージョン1の形式内の主要な固定サイズのフィールド
レコードは変更されません。両方のバージョン1のレコードの署名
およびバージョン2 0x06064b50されます。すぐに次の最後
このフィールドは、オフセットスタートとして知られている中央のバイト
ディレクトリには、起動ディスクの番号につきましては、開始されます
バージョン2では、このレコードの新しいフィールドを定義する。
バージョン2のための新たなフィールド：
注：インテルlow-byte/high-byteすべてのフィールドの順序で格納されます。
値のサイズ説明
----- ---- -----------
圧縮方法2の圧縮に使用されるメソッドのバイト
中央ディレクトリ
圧縮サイズは、圧縮データの8バイトのサイズ
元のサイズは8バイトオリジナルサイズの非圧縮
悪感2バイトの暗号化アルゴリズムIDを
BitLen 2バイトの暗号化キーの長さ
フラグ2バイト暗号化フラグ
HashID 2バイトのハッシュアルゴリズムの識別子
ハッシュ長さは2バイトのハッシュデータの長さ
ハッシュデータ（ ）ハッシュデータを変数
の圧縮方法として、同じ値の範囲を受け入れる
中央ヘッダ内の対応するフィールド。
圧縮サイズと元のサイズの値は、含まれません
中央ディレクトリの署名のデータが圧縮されているか
暗号化されます。
の悪感、 BitLen 、フラグフィールドの値の同じ範囲を受け入れる
レコード内の対応するフィールドは0x0017 。
IDは、ハッシュアルゴリズムは、中央ディレクトリのハッシュを識別するために使用
データ。このデータは、ハッシュする必要はありませんその場合は
長さの両方をHashIDとハッシュ値は0になります。可能性
HashIDの値です：
値アルゴリズム
------ ---------
0x0000をなし
0x0001 CRC32の
0x8003 MD5
0x8004 SHA1を
0x8007 RIPEMD160の
0x800C SHA256
0x800D SHA384
0x800E SHA512
は、セントラルディレクトリのデータが署名され、同一のハッシュアルゴリズム
署名には、中央ディレクトリのハッシュを使用する必要があります。
この処理の効率化にお勧めですが、しかし、それは
上記のアルゴリズムを使用することが独立のための許容
は、署名プロセスの。
のハッシュデータを中央ディレクトリのハッシュデータが含まれます。
このアルゴリズムが使用されるデータに応じて異なりますの長さ。
のバージョンに必要な抽出を62に設定する必要があります。
現在のディスクの合計数のエントリーの値が
0である。これらのレコードは、ランダムアクセスをサポートするとき
中央ディレクトリを暗号化する。
は、セントラルディレクトリおよび/または、暗号化された圧縮されている
中央ディレクトリの最後のレコードの値は0xFFFFFFFFを格納する
中央でのエントリーの合計数の値として
ディレクトリにあります。この値は、エントリーの合計数に格納
このディスクは、中央ディレクトリのフィールドに0になります。実際の
値は、 Zip64に相当するフィールドに格納されます
中央ディレクトリレコードの終わり。
復号化、中央ディレクトリの解凍されています
復号化とファイルの解凍と同じ方法です。
証明書の処理方法：
-----------------------------
証明書の処理方法ZIPファイルの暗号化のため
次の追加のデータフィールドを定義します：
1 。証明書のフラグ値
追加処理のフラグは、両方のFlagsフィールドに存在することができます
中央ディレクトリエキストラ0x0017フィールドとフィールドの復号化
上記の圧縮ファイルのデータヘッダを記録している：
0x0007 -将来の使用のために予約
0x000F -将来の使用のために予約
0x0100 - OAEPキーラップを示す非使用されていた。この場合
このフィールドは、バージョンを抽出するために必要な設定されている必要があります
少なくとも61である。この意味ではないOAEPキーラッピング
を使用して、キーがマスターセッションを生成するときに使用される
ErdData 。
0x4000 - ErdData 3DESのを使って復号化する必要があります- 168が、それを使用する
同じアルゴリズムは、ファイルの内容を暗号化するために使用されます。
は0x8000 -将来の使用のために予約
2 。 CertData -エキストラフィールド0x0017記録証明書のデータ構造
セクション内のデータ構造は、証明書のデータを格納するために使用
フィールドは、エキストラの0x0017のCertDataフィールドによって定義されて
記録として表示されています：
値のサイズ説明
----- ---- -----------
RCount 4バイトの受信者の数。
HashAlg 2バイトのハッシュアルゴリズムの識別子
HSize 2バイトのハッシュサイズ
SRList （予めVar ）の単純なリストの受信者の公開鍵ハッシュ
これは、コードの受信者の意図を定義していますRCount
公開鍵暗号化に使われていた。この識別
のSRListの要素数。
これは、ハッシュアルゴリズムを計算するために使用される定義HashAlg
それぞれの公開鍵の公開鍵のハッシュを使用
暗号化のため。このフィールドは、現在サポートしています
次の値のみではSHA - 1
0x8004 - SHA1を
HSizeこれは、ハッシュ化された公開鍵のサイズを定義しています。
SRListこれは、ハッシュ化されたのは可変長のリストです
各受信者の公開鍵。各々
このリスト内の要素HSizeされています。全体の大きさの
SRList * HSize RCountを使用して決定されます。
3 。 Reserved1 -証明書の復号化ヘッダReserved1データ：
値のサイズ説明
----- ---- -----------
RCount 4バイトの受信者の数。
これは、コードの受信者の意図を定義していますRCount
公開鍵暗号化に使われていた。この定義
REListフィールドの下には、定義された要素の数です。
4 。 Reserved2 -証明書の復号化ヘッダReserved2データ構造：
値のサイズ説明
----- ---- -----------
HashAlg 2バイトのハッシュアルゴリズムの識別子
HSize 2バイトのハッシュサイズ
REList （予めVar ）受信者のデータ要素のリスト
これは、ハッシュアルゴリズムを計算するために使用される定義HashAlg
それぞれの公開鍵の公開鍵のハッシュを使用
暗号化のため。このフィールドは、現在サポートしています
次の値のみではSHA - 1
0x8004 - SHA1を
HSizeこれは、ハッシュ化された公開鍵のサイズを定義しています
REHDataで定義されています。
REListこのデータの受信者リストの変数の長さです。
このリストの各要素は、受信者の構成
要素のデータ構造として以下の通り：
受信者の要素（ REList ）データ構造：
値のサイズ説明
----- ---- -----------
REHDataのサイズは2バイトのサイズ+ REKData
受信者の公開鍵ハッシュREHData HSize
REKData （予めVar ）簡易キー塊
リサイズREListこれは、個々のサイズを定義しています
要素を追加します。この値の合計サイズです
REHDataフィールド+ REKDataフィールド。 REHDataによって定義されている
HSize 。変数ですREKDataと計算することができます
REList各要素のサイズを変更するとHSizeを使用しています。
この受信者の公開鍵ハッシュREHData 。
簡単なキーのBlob REKData 。このデータ構造の形式
は、 Microsoftの定義と同じです
CryptoAPIとはCryptExportKeyを使用して生成（ ）
機能します。のバージョンは、簡単なキーのBlob
として、現時点ではサポートされているが0x02で定義されています
マイクロソフト。
証明書の処理-中央ディレクトリの暗号化：
-------------------------------------------------- ----
中央ディレクトリの暗号化、デジタル証明書を使用する
方法は、シングルパスワードの中央のように動作
ディレクトリの暗号化。このレコードがある場合にのみ存在する
データをそこに配置することです。現在、データは、このに置かれている
記録時に暗号化するために使用されているデジタル証明書のいずれか
または、 ZIPファイル内のファイルに署名します。時のみパスワード
暗号化、暗号化やデジタル証明書がないと使用されています
署名は、この記録は現在、必要とされていません。ときは、このプレゼント
レコードは、実際の中央Directoryの開始前に表示されます
データ構造と配置され、アーカイブ後すぐに
ヘッダーの場合は、中央ディレクトリの暗号化復号化されています。
エキストラは、アーカイブデータレコードは、次の格納に使用される
情報。追加データは将来のバージョンで追加される可能性があります。
余分なデータフィールド：
0x0014 - X.509証明書ストアのためのPKCS ＃ 7
0x0016 - X.509証明書IDと署名の中央ディレクトリの
0x0019 -のPKCS ＃ 7暗号化受信者の証明書のリスト
0x0014 、 0x0016 、余分なデータの記録によりますとそれ以外のだろう
中央Directoryの最初のレコードは、デジタルの位置
証明書処理。暗号化や圧縮時には中央
ディレクトリから、レコードは、 0x0014 、 0x0016に位置する必要があります
アーカイブ余分なデータを記録し、彼らは最初に残ってはならない
中央ディレクトリレコード。アーカイブ余分なデータを記録するも
は0x0019のデータを格納するために使われる。
が存在する場合、アーカイブエキストラデータレコードのサイズとなります
中央Directoryのサイズが含まれています。のデータ
アーカイブを追加データの記録にも圧縮され、暗号化された
中央ディレクトリのデータ構造と一緒に。
証明書の処理の違い：
証明書の暗号化の処理方法が異なる
対称暗号化方式を1つのパスワードを以下のとおりです。代わりに
ユーザ定義のパスワードを使用して、セッション鍵を生成するためのマスター
ランダムなデータを暗号化に使用されます。その後、鍵素材です
標準のキーと包装技術を使用して閉幕した。このキー素材
が必要とする各受信者の公開鍵を使って折り返される
それらに対応する秘密鍵を使用して、ファイルを復号化する。
この仕様に従うが、現在のデジタル証明書を前提としています
1024ビット以上のRSA形式のX.509 V3のフォーマットのデジタル
証明書。実装はこの証明書の処理方法
キーのアクセスと管理をサポートするロジックが必要です。この論理
この仕様の範囲外である。
OAEP処理の証明書ベースの暗号化：
非対称暗号化最適OAEPパディングの略です。それはです
符号化復号化技術などの小さなアイテムに使用される強化
キーを押します。これは一般に、暗号化キーに適用される技術の折り返し
とのPKCS ＃ 1でサポートされています。この仕様のバージョン5.0および6.0
OAEPキーをサポートするために設計された証明書ベースのラッピング
追加のセキュリティのために復号化鍵。
秘密鍵はスマートカードやトークンに格納導入をサポート
このOAEPのロジックとの競合。ほとんどのカードとトークン製品は
追加の強化をサポートしていない- OAEPキーに適用ラップ
データ。ためには、この紛争は、バージョン6.1を解決するために、この上
仕様書を使用して暗号化するときには、もはやOAEPをサポートします
デジタル証明書。
PKZIPは、初期の開発中に利用可能なバージョン
証明書処理の方法は、 61の値に設定
バージョンは、ファイルのフィールドを抽出する必要があった。これを示すこと
OAEPキー以外の包装に使用されます。この証明書の暗号化に影響を与える
のみ、およびパスワードの暗号化機能によって影響を受けてはならない
この値。この暗号化された61のファイルで確認することができる値の意味
で証明書のみ、または両方のファイルをパスワードで暗号化された上で
暗号化と証明書を暗号化。ファイルの両方で暗号化
メソッドを安全にパスワードを使用して復号化の方法を記載することができます。
17 。変更プロセス
--------------------
。 ZIPファイル形式を定義するためには、実行可能な、このままに
オープン仕様として定期的に見直し、を検討する必要があります
改正。もともとは、このフォーマットを使用して設計された
拡張性の特定のレベル、技術ではなく、すべての変更
（現在または将来の）で考慮されるかが、必ずしもその
設計する。もしあなたのアプリケーションに新しい定義が必要
この形式で拡張可能な部分、または場合にしたいと思います
新しいデータ構造を送信すると、お客様のリクエストを転送してください
zipformat@pkware.com 。すべての提出によって審査されます
ZIPファイルに含めることが可能な仕様委員会
この仕様の将来のバージョン。定期的な見直し
この仕様の相互運用性を確保するために公開されます。
我々のコメントとは明確に改善を促すことができるフィードバック
またはコンテンツ。
18世紀。独自の技術を製品に組み込むPKWARE
-------------------------------------------------- ------------------
PKWAREとの相互運用性の向上に努めています
。 ZIP形式。 PKWAREのためのフリーなライセンスを提供し、特定の技術
面上に一定の制限や条件の下で説明する。
ただし、使用するかは、製品に含まれる特定の実装技術
側面APPNOTEは、現在の規定では、これらの点を含む設定
強力な暗号化、パッチ、または拡張テープの操作が必要
PKWAREからライセンス。お問い合わせください買収に関してPKWARE
ライセンス。
19 。謝辞
----------------------
PKZIPとPKUNZIPには、上記の貢献に加えて、
私はロバートマホーニーを示唆するための特別な感謝を延長したいと思います
拡張子。郵便このソフトウェアです。
イグゼクス。参考文献
--------------
フィアラ、エドワードR 、グリーン、ダニエルチ"とデータ圧縮
有限窓" 、通信ACM 、巻32 、数4 、
1989年4月、 490 ? 505ページ。
開催、ギルバートは、 "データ圧縮は、技術と応用、
ハードウェアとソフトウェアの考慮事項" 、ジョンワイリー＆サンズ、 1987 。
ハフマン、ダ"の建設のためのメソッドを最小冗長性
コード" 、議事録は、怒り、巻40 、第9号、 1952年9月、
ページ一千九十八から一千百一。
ネルソン、マークは、 " LZWデータ圧縮" 、博士ドブズ誌、巻14 、
10号、 1989年10月、ページ29-37 。
ネルソン、マークは、 "データ圧縮予約" 、メートル＆ Tの書籍、 1991 。
Storer 、ジェームズは、 "データ圧縮は、方法と理論" 、
コンピュータサイエンスプレス、 1988
ウェルチ、テリー、 "高パフォーマンスのデータ圧縮技術" 、
のIEEEコンピュータ、巻17 、数6 、 1984年6月、 8月19日ページ。
Ziv 、 J. 、 Lempel 、場合a. "連続データのための普遍的アルゴリズム
圧縮" 、通信ACM 、巻30 、数6 、
1987年6月、 520 ? 540ページ。
Ziv 、 J. 、 Lempel 、場合a.を介して、個々のシーケンスの"圧縮
可変レート符号化" 、情報理論のIEEEトランザクション、
巻24 、数5 、 1978年9月、 530 ? 536ページ。
付録A - AS/400のエキストラフィールド（ 0x0065 ）属性の定義
-------------------------------------------------- ------------
フィールドの定義構造：
1つの。長さは2バイトを含むフィールドの長さ
b.フィールドコードは2バイト
c.データをxバイト
フィールドコード説明
4001ソースのタイプつまりCLP等
図書館の4002のテキストの説明
ファイルの4003のテキストの説明
メンバーの4004のテキストの説明
4005 x'F0 'または0 pFのは、 DTAの、 x'F1 'または1 PF_SRCです
4007データベースの種類コードを1バイト
4008データベースファイルとフィールドの定義
4009をgzipファイルの種類を2バイト
400B IFSのコードページの2バイト
400C IFSの創作時間4バイト
400D IFSのアクセス時間は4バイト
400E IFSの修正時刻は4バイト
005Cは、ファイル内のレコードの長さは2バイト
0068 2つの単語をgzip 8バイト
付録B - ? / OSのエキストラフィールド（ 0x0065 ）属性の定義
-------------------------------------------------- ----------
フィールドの定義構造：
1つの。長さは2バイトを含むフィールドの長さ
b.フィールドコードは2バイト
c.データをxバイト
フィールドコード説明
0001ファイルの種類は2バイト
0002 NonVSAMレコードの形式は1バイト
0003予約
0004 NonVSAMブロックサイズの2バイトビッグエンディアン
0005主な領域の割り当て3バイトビッグエンディアン
0006第二次宇宙割当3バイトビッグエンディアン
0007バイトの領域の割り当てがType1フラグ
0008改質日付で退職者PKZIP 5.0 +
0009有効期限日に退職者PKZIP 5.0 +
000AのPDディレクトリブロック割り当てビッグエンディアン3バイトのバイナリ値
000B NonVSAM巻一覧変数
000Cユニットリファレンス退職PKZIP 5.0 +
dfを000D / SMSの管理クラスの8バイトのEBCDICテキスト値
dfを000E / SMSのストレージクラスの8バイトのEBCDICテキスト値
dfを000F / SMSのデータのクラスの8バイトのEBCDICテキスト値
0010のPD / PDSEメンバー情報。 30バイト
サブ0011でVSAMファイル形式は2バイト
0012でVSAM LRECL 13バイトのEBCDIC " （ num_avg num_max ） "
0013でVSAMクラスタ名と退職者PKZIP 5.0 +
0014でVSAM KSDSキー情報の13バイトのEBCDIC " （ num_length num_position ） "
0015でVSAM平均LRECL 5バイトのEBCDIC num_valueブランクが埋め込ま
0016でVSAM最大LRECL 5バイトのEBCDIC num_valueブランクが埋め込ま
0017でVSAM KSDSキーの長さ5バイトのEBCDIC num_valueブランクが埋め込ま
0018でVSAM KSDSキーポジション5バイトのEBCDIC num_valueブランクが埋め込ま
0019でVSAMデータ名1から44バイトのEBCDIC文字列
001AでVSAM KSDSインデックス名1から44バイトのEBCDIC文字列
001BでVSAMカタログ名を1から44バイトのEBCDIC文字列
001CでVSAMデータ空間の種類9バイトのEBCDIC文字列
001DでVSAMデータ宇宙プライマリ9バイトのEBCDIC num_value左詰め
001EでVSAMデータ宇宙セカンダリ9バイトのEBCDIC num_value左詰め
001FでVSAMデータ量一覧6変数のEBCDIC文字のボリュームIDをテキスト一覧
0020でVSAMデータバッファスペースの8バイトのEBCDIC num_value左詰め
0021でVSAMデータCISIZE 5バイトのEBCDIC num_value左詰め
0022でVSAM削除フラグ1バイトフラグ
0023でVSAM無料CIの％ 3バイトのEBCDIC num_value左詰め
0024でVSAM無料カナダ％ 3バイトのEBCDIC num_value左詰め
0025でVSAM索引巻一覧6変数のEBCDIC文字のボリュームIDをテキスト一覧
0026でVSAM取り寄せフラグ1バイトフラグ
0027でVSAMを再利用フラグ1バイトフラグ
0028スパンでVSAMフラグ1バイトフラグ
0029でVSAM回復フラグ1バイトフラグ
002AでVSAM WRITECHKフラグ1バイトフラグ
002BでVSAMクラスタ/データSHROPTS 3バイトのEBCDICに" n 、 y "を
002CでVSAM索引SHROPTS 3バイトのEBCDICに" n 、 y "を
002DでVSAM索引スペースタイプ9バイトのEBCDIC文字列
002EでVSAM索引スペースプライマリ9バイトのEBCDIC num_value左詰め
002FでVSAM索引スペースセカンダリ9バイトのEBCDIC num_value左詰め
0030でVSAM索引CISIZE 5バイトのEBCDIC num_value左詰め
インデックスの1バイトフラグ0031でVSAM IMBED
0032でVSAM索引取り寄せフラグ1バイトフラグ
0033でVSAM複製フラグ1バイトフラグ
0034でVSAMインデックスを再利用フラグ1バイトフラグ
0035でVSAM索引WRITECHKフラグ1バイトフラグPKZIP 5.0で退職+
0036でVSAM所有者の8バイトのEBCDIC文字列
0037でVSAMインデックス所有者の8バイトのEBCDIC文字列
0038予約
0039予約
003A予約
003B予約
003C予約
003D予約
003E予約
003F予約
0040予約
0041予約
0042予約
0043予約
0044予約
0045予約
0046予約
0047予約
0048予約
0049予約
004A予約
004B予約
004C予約
004D予約
004E予約
004F予約
0050予約
0051予約
0052予約
0053予約
0054予約
0055予約
0056予約
0057予約
0058のPD / PDSE会員情報TTR 。 6バイトビッグエンディアン
0059のPD 1 LMODテキストTTR 3バイトビッグエンディアン
005AのPD LMOD EP録音＃ 4バイトビッグエンディアン
005B予約
005C最大長のレコードが2バイトビッグエンディアン
005D PDSEフラグ1バイトフラグ
005E予約
005F予約
0060予約
0061予約
0062予約
0063予約
0064予約
0065最終日引用4バイトパック16進数" " 
がおすすめ！！ ウェブやソフトウェアに関するサポート＆情報サイトです。サイト構築からソフトウェアの作成、利用まであなたの助けになるかも・・・・しれません。たぶん・・。
コメントをどうぞ