Recursive.7zアーカイブ：ある種のファイルとRecursive.7zアーカイブ

7-Zipアーカイブの形式は非常に柔軟であり、たとえば、アーカイブ全体をアーカイブ内のファイルの1つとして含めることができます。 例を使用して形式を見てみましょう。「Recursive.7z」という2つのファイルを含むアーカイブをほぼ手動で作成します。



この形式に関する簡単なドキュメントは、 LZMA SDKに含まれています 。 アーカイブは、サイズが32バイトの次の構造で始まります。 アーカイブ内のすべての位置は、この構造の終わりに対するオフセットとしてエンコードされます。

, 6 : { '7', 'z', 0xBC, 0xAF, 0x27, 0x1C };  ,   { Major, Minor }, 7-Zip 9.20   { 0, 3 }; CRC   , 4 ;       , 8 ;   , 8 ; CRC  , 4 .
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この後には、ファイル自体およびデータの境界に関する情報のないファイルデータが続きます。 アーカイブの内容全体を説明するメインヘッダーは、アーカイブの最後にあります。



メインヘッダー自体をパックできます（暗号化もできます）。 構造化されたデータ（ファイル名など）が含まれているため、圧縮率は非常に良好です。 7zのファイルに関するすべての情報が1つのヘッダーに収集され、圧縮されたファイルデータから完全に分離されるのは、このような圧縮の可能性のためです。 パッキングの符号は、メインヘッダーの最初のバイトです。アンパックヘッダーの場合は1、パックの場合は0x17である必要があります。 アーカイブを手動で作成するために、何も圧縮しません。



ドキュメントの（アンパックされた）メインヘッダーの概要：

 { ArchiveProperties AdditionalStreams { PackInfo { PackPos NumPackStreams Sizes[NumPackStreams] CRCs[NumPackStreams] } CodersInfo { NumFolders Folders[NumFolders] { NumCoders CodersInfo[NumCoders] { ID NumInStreams; NumOutStreams; PropertiesSize Properties[PropertiesSize] } NumBindPairs BindPairsInfo[NumBindPairs] { InIndex; OutIndex; } PackedIndices } UnPackSize[Folders][Folders.NumOutstreams] CRCs[NumFolders] } SubStreamsInfo { NumUnPackStreamsInFolders[NumFolders]; UnPackSizes[] CRCs[] } } MainStreams { (Same as in AdditionalStreams) } FilesInfo { NumFiles Properties[] { ID Size Data } } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

順番に整理して、必要なタイトルを作成していきましょう。 最後に記入する最後の32バイト（既製のメインヘッダーが必要）、次のバイトは簡単にするために圧縮しないデータです。

 00000020: 48 65 6C 6C 6F 2C 20 48 61 62 72 61 68 61 62 72 | Hello, Habrahabr 00000030: 21 | !
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

メインヘッダーの最初のバイトを書き込みます。

 00000030: 01
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ArchiveProperties-可能性のある拡張子のプロパティは現在使用されていません。7-Zipはそれらを作成せず、静かに読み取りをスキップします。



AdditionalStreamsおよびMainStreamsは、圧縮データの構造を記述します。 AdditionalStreamsの最初のバイトは0x03、MainStreamsの最初のバイトは0x04です。それ以外の場合、構造は同じです（ちなみに、最初のバイト0x17の後のパックされたメインヘッダーはまったく同じ構造です）。

MainStreamsはファイルデータを記述します。 AdditionalStreamsを使用すると、一部のデータ（収集されたファイル名など）を個別に取り出して、メインヘッダーに関係なく圧縮できます。 7-Zipは書き込み時にこの機能を使用しません（実際のアーカイブにはAdditionalStreamsはありません）が、読み取り時にそれらを処理できます。



MainStreamsの最初のバイトを書き、深く掘り下げます。

 00000030: 04
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

7-Zipでは、エンコーダーはデータ変換に関与します。 各エンコーダには、いくつかの入力ストリーム、いくつかの出力ストリーム、独自の識別子、および場合によってはいくつかの設定があります。 ほとんどのエンコーダーは、1つの入力ストリームを1つの出力ストリームに変換します。たとえば、コピーエンコーダー{00}（必要です）、LZMAパッカー{03、01、01}、AESエンコーダー{06、01、xx} 、BZip2-wrapper {04、02、02}（はい、7z形式では、他のアーカイブ形式を従来使用していたアルゴリズムを使用できます）。 複数の出力ストリームを持つエンコーダーの例：BCJ2 {03、03、01、1B}。 x86およびx86-64マシンコードは、プロシージャを呼び出すコマンド（E8 xx xx xx xx）とジャンプ（E9 xx xx xx xx-長い無条件、0F 8y xx xx xx xx-長い条件付き）が宛先アドレスをオフセットとしてエンコードするように設計されています終わり。 このため、圧縮は、E8 xx xx xx xxの異なるオカレンス（オフセットの相対性のために異なるxxを使用）が実際には同じプロシージャの呼び出しであることを「通知」しません。 BCJ2は呼び出しの宛先を変換して絶対形式にジャンプし、4つの出力ストリームを生成します。最初は宛先データ、2番目は呼び出しの宛先、3番目はジャンプの宛先、4番目は適切なE8 / E9 / 0F 8xがあるかどうかを知らせるビットストリームですエンコードされた割り当て、または単なるデータのバイトです。



7z形式は、最も一般的な状況を説明しています。入力ストリームは、任意の数のエンコーダーによってエンコードされ、その出力は、他のエンコーダーの入力になります。 ストリーム情報の最初のPackInfoブロックは、アーカイブに記録されたすべての最終ストリーム（他のエンコーダーに提供されないエンコーダーのすべての出力ストリーム）を記述します：バイト0x06、ファイルの最終ストリームの先頭（最初のヘッダーの終わりからのオフセットとして、ストリームは順番に続きます）、エンコードされたストリームの数、バイト0x09、すべての最終ストリームのサイズ（各最終ストリームに1つのエンコードされた数）、バイト0x00。 ストリームのサイズと構造の終わりの間には、最終ストリームのCRCに関する情報がありますが、通常は使用されず、CRCは展開されたデータに対して制御されます。



7zの整数は次のようにエンコードされます：最初のバイトの先頭ユニットの数は追加バイトの数を決定し、最初のバイトの他のビットは数の最上位ビットであり、追加のバイトはリトルエンディアンの数の下位バイトを決定します。 0x80未満の数値は、数値自体に等しい1バイトでエンコードされます。 8バイトすべてを占める数字は、バイトの先頭に0xFFを割り当てることでエンコードされます。

2つのストリームがあります。 1つ目は、ファイル「Some kind of .txt file」用で、最初のヘッダーの末尾からのオフセット0から始まります。 2番目は、ファイルの先頭から始まるアーカイブ用です。 ストリームは連続して次々と続くため、最初のストリームのサイズは0-0x20 = 0xFFFFFFFFFFFFFFFFE0に等しくする必要があります。 アーカイブのサイズは、まだわかりません。2バイト残します。 そこで、PackInfoブロックを作成します。

 00000030: 06 00 02 09 FF E0 FF FF FF FF FF FF FF 00000040: ?? ?? 00
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

2番目のCodersInfoブロックは、パラメーターで使用されるすべてのエンコーダーと、パラメーター間の関係を記述します。 エンコーダーはリンクグループにグループ化されますが、リンクグループ間ではグループ化されません。 たとえば、1つのグループは1つのLZMAパッカーで構成され、2番目のグループはBCJ2 +（いくつかの異なるLZMA）の束から構成されます。 CodersInfoブロックは、バイト0x07 0x0Bで始まり、エンコードされたグループ数、ゼロバイト（ゼロ以外はグループに関する情報を別のAdditionalStreamに入れることを意味します）、グループごとに1つのフォルダー構造が続きます。 各グループは、グループ内のエンコーダーの数で始まり、その後に各エンコーダーの説明が続きます。 エンコーダー記述の最初のバイトには、下位4ビットに識別子サイズが含まれます。次のビットは、エンコーダーに入力チャンネルの数があるか、出力チャンネルの数が1でない場合にのみ設定されます。エンコーダーにパラメーターがある場合、次のビットが設定されます。 これに識別子が続き、出力チャネルと入力チャネルの数（どちらかがユニティと異なる場合）、パラメータのサイズ（ある場合）、およびバイト配列の形式のパラメータ自体が続きます。 すべてのエンコーダーの後に、リンクの説明があります。出力チャネルの番号と接続される入力チャネルの番号です。 1つを除く各入力チャネルはデコーダーの出力でなければならないため、リンクの数はすべてのエンコーダーの入力チャネルの総数から1を引いた数に等しくなります。最後に、出力ストリームの数が複数の場合、グループ記述はその順序で非バインド出力ストリームのインデックスのリストで終わりますアーカイブに記録されます。 フォルダーの説明の後に、0xCバイトと、すべてのフォルダーのすべての入力チャンネル（リンクされたものを含む）のサイズがあります。 PackInfoと同様に、CodersInfoブロックはバイト0x00で終了します。 ストリームのサイズと構造の終わりの間には、入力CRC情報があります。これは通常、パックヘッダーに関するストリーム情報にのみ使用されます（CRCファイルは次のブロックに保存されます）。 CRCは、すべてのストリームに1つある場合、次のように格納されます：最初にゼロ以外のバイト（すべてのストリームにCRCが定義されていることを示す記号。それ以外の場合、ビットマップはさらに、どのCRCストリームが定義されているかを示します）

CodersInfoブロックを形成します。2つのストリームの2つのグループのそれぞれに1つのコピーエンコーダーがあり、まだ未知のアーカイブサイズ用に2バイトが残っている場合です。

 00000040: 07 0B 02 00 01 01 00 01 01 00 0C 11 ?? 00000050: ?? 00
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

SubStreamsInfoの3番目のブロックはファイルを記述します。 パックされたヘッダーのストリームに関する情報には存在しませんが、ファイルのストリームに関する情報には、おそらくデータがないはずです。 7-Zipは、個々のファイルではなく、複数のファイルのブロックを圧縮します（連続アーカイブ。ブロック内のブロックサイズと1ファイルまでのファイル数の制限を設定できます。これにより、連続アーカイブは実際にオフになりますが、デフォルトでは連続がオンになります）。 上記の説明の入力ストリームは、いくつかのファイルを結合します。 SubStreamsInfoブロックは、1つのブロック内の（空でない）ファイルのサイズを記述します。 バイト0x08で始まります。 さらに、おそらくバイト0x0Dと各グループのファイル数が続くはずです。 そうでない場合は、各グループに1つのファイルがあると見なされます。 次に、おそらくバイト0x09と個々のファイルのサイズが続きます（各グループの最後を除く-グループの入力ストリームのサイズによって計算されます）。 さらに、おそらく、個々のファイルのバイト0x0AとCRCは、CodersInfoブロックと同様に保存する必要があります。 SubStreamsInfoブロックは、他のブロックと同様にバイト0x00で終了します。 アーカイブには、異なるストリームに保存された2つのファイルがあります。 簡単にするために、アーカイブにCRCを記録しません（テキストファイルの場合は簡単です。CRC自体を含むデータから計算されたCRCが収束するようにアーカイブを調整する必要があります。未使用のバイトを選択して調整する必要があります）。 したがって、SubStreamsInfoブロックにはデータが含まれていません。

 00000050: 08 00
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

フロー情報をゼロバイトで完了し、上記のレベルに戻ります。

 00000050: 00
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ご想像のとおり、FilesInfoには、アーカイブ内のファイルに関する情報（名前、作成/変更/アクセス日、ファイル属性）が含まれています。 FilesInfoは、バイト0x05で始まり、その後にファイル数を示すエンコードされた整数が続き、その後に（ある程度の）プロパティが続きます。 各プロパティはゼロ以外の識別子バイトで始まり、その後にプロパティのサイズが続きます（7-Zipが不明なプロパティをスキップできるようにするため）。 ゼロバイトはFilesInfoを終了します。 ファイル名はタイプ0x11のプロパティとしてエンコードされ、コンテンツの最初のバイトはゼロです（ゼロ以外のバイトは、すべてのプロパティコンテンツが個別のAdditionalStreamに配置されることを意味し、一般的な配列のインデックスは以下でエンコードされます）。その後、名前自体は終端ゼロでUTF-16になります。

簡単にするために日付と属性を入力しませんが、名前が必要です。 FilesInfoブロックに入力します。

 00000050: 05 02 11 43 00 1A 04 30 04 3A 04 | .....<<< 00000060: 3E 04 39 04 2D 00 42 04 3E 04 20 00 44 04 30 04 | <<-<<< <<< 00000070: 39 04 3B 04 2E 00 74 00 78 00 74 00 00 00 20 04 | <<.<t<x<t<..< 00000080: 35 04 3A 04 43 04 40 04 41 04 38 04 32 04 3D 04 | <<<<<<<< 00000090: 4B 04 39 04 2E 00 37 00 7A 00 00 00 00 | <<.<7<z<...
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

おなじみのゼロバイトでヘッダー全体を完成させるだけです。

 00000090: 00
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そのため、ファイル全体のサイズは0x9Eバイトになりました。今度は、質問の代わりに数値0x9Eをエンコードして80 9Eバイトに戻ることができます。 最初の見出しを形成するために残ります。 メインヘッダーは、最初のヘッダーの末尾から0x11の位置から始まり、0x9E-0x31 = 0x6Dバイトを占有します。

次に、2つのCRCを計算する必要があります。 0x6DバイトでCRCを手動で読み取るのは非常に面倒なので、ここではプログラムの助けを借ります。 計算する必要がある最初のCRCはメインヘッダーです。0x31から最後までのバイト、CRCは0x3F5E2977です。 2番目のCRCは、最初のCRCを含む最初のヘッダーの最後の3つのフィールドでカウントされます：11 00 00 00 00 00 00 00 00 6D 00 00 00 00 00 00 00 00 77 29 5E 3F。 0x6FA3DEA5と同じです。 最後に、すべてをまとめて、この「 Recursive.7z 」を取得します。

 00000000: 37 7a bc af 27 1c 00 03 a5 de a3 6f 11 00 00 00 |7z..'......o....| 00000010: 00 00 00 00 6d 00 00 00 00 00 00 00 77 29 5e 3f |....m.......w)^?| 00000020: 48 65 6c 6c 6f 2c 20 48 61 62 72 61 68 61 62 72 |Hello, Habrahabr| 00000030: 21 01 04 06 00 02 09 ff e0 ff ff ff ff ff ff ff |!...............| 00000040: 80 9e 00 07 0b 02 00 01 01 00 01 01 00 0c 11 80 |................| 00000050: 9e 00 08 00 00 05 02 11 43 00 1a 04 30 04 3a 04 |........C.<<<| 00000060: 3e 04 39 04 2d 00 42 04 3e 04 20 00 44 04 30 04 |<<-<<< <<<| 00000070: 39 04 3b 04 2e 00 74 00 78 00 74 00 00 00 20 04 |<<.<t<x<t<..<| 00000080: 35 04 3a 04 43 04 40 04 41 04 38 04 32 04 3d 04 |<<<<<<<<| 00000090: 4b 04 39 04 2e 00 37 00 7a 00 00 00 00 00 |<<.<7<z<....|