Recursive.7z संग्रह: कुछ प्रकार की फ़ाइल और Recursive.7z संग्रह

7-ज़िप अभिलेखागार का प्रारूप काफी लचीला है और उदाहरण के लिए, पूरे संग्रह सहित संग्रह के अंदर की फ़ाइलों में से केवल कुछ गिनती के साथ, अनुमति देता है। आइए एक उदाहरण का उपयोग करके प्रारूप का विश्लेषण करें: हम दो फ़ाइलों वाले "Recursive.7z" नाम के साथ लगभग मैन्युअल रूप से एक आर्काइव बनाएंगे: "हेलो, हैब्राहब!" और "रिकर्सिवेज़" की सामग्री के साथ "कुछ प्रकार की .txt फ़ाइल", स्वयं की एक प्रति।

प्रारूप पर संक्षिप्त प्रलेखन LZMA एसडीके में शामिल है। संग्रह आकार में 32 बाइट्स की निम्न संरचना के साथ शुरू होता है। पुरालेख के भीतर सभी पदों को इस संरचना के अंत के सापेक्ष ऑफसेट के रूप में एन्कोड किया गया है।

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

इसके बाद फाइल डेटा के बारे में बिना किसी फाइल के जानकारी के और डेटा की सीमाओं के बारे में बताया जाता है। मुख्य हेडर, जो संग्रह की संपूर्ण सामग्री का वर्णन करता है, संग्रह के अंत में स्थित है।

मुख्य हैडर को ही पैक किया जा सकता है (साथ ही एन्क्रिप्टेड)। चूंकि इसमें संरचित डेटा (जैसे फ़ाइल नाम) होता है, इसलिए संपीड़न अनुपात बहुत अच्छा होता है। यह इस तरह के संपीड़न की संभावना के लिए है कि 7z में फ़ाइलों के बारे में सभी जानकारी एक हेडर में एकत्र की जाती है और संपीड़ित फ़ाइल डेटा से पूरी तरह से अलग हो जाती है। पैकिंग का संकेत मुख्य हेडर का पहला बाइट है: यह अनपैक्ड हेडर के लिए 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-ज़िप कभी भी उन्हें नहीं बनाता है और चुपचाप पढ़ना छोड़ देता है।

अतिरिक्तस्ट्रीम और मेनस्ट्रीम संपीड़ित डेटा की संरचना का वर्णन करते हैं। अतिरिक्तस्ट्रीम में पहला बाइट 0x03 है, मेनस्ट्रीम में पहला बाइट 0x04 है, अन्यथा उनकी संरचना समरूप है (वैसे, पहली बाइट 0x17 के बाद पैक्ड मुख्य हेडर बिल्कुल एक ही संरचना है)।
MainStream फ़ाइल डेटा का वर्णन करता है। अतिरिक्त आंकड़े आपको कुछ डेटा बाहर निकालने की अनुमति देते हैं (उदाहरण के लिए, फ़ाइल नाम एकत्र) अलग से और मुख्य हेडर की परवाह किए बिना संपीड़ित करें; 7-ज़िप लिखते समय इस सुविधा का उपयोग नहीं करता है (असली अभिलेखागार में कोई अतिरिक्त स्ट्रीम नहीं हैं), लेकिन यह पढ़ते समय उन्हें संसाधित करने में सक्षम है।

हम मेनस्ट्रीम का पहला बाइट लिखते हैं और गहराई तक जाते हैं:

 00000030: 04 

7-जिप में, एन्कोडर डेटा रूपांतरण में शामिल हैं। प्रत्येक एनकोडर में कुछ इनपुट स्ट्रीम, कुछ आउटपुट स्ट्रीम, इसकी अपनी पहचानकर्ता और, संभवतः, कुछ सेटिंग्स होती हैं। अधिकांश एनकोडर एक इनपुट स्ट्रीम को एक आउटपुट स्ट्रीम में परिवर्तित करते हैं: उदाहरण के लिए, कॉपी करने वाला एनकोडर {00} (हमें भी इसकी आवश्यकता है), LZMA पैकर {03, 01, 01}, एईएस एनकोडर {06, 01, x5} , BZip2-आवरण {04, 02, 02} (हाँ, 7z प्रारूप एल्गोरिदम के लिए अनुमति देता है जो परंपरागत रूप से अन्य संग्रह स्वरूपों का उपयोग करता है)। कई आउटपुट स्ट्रीम वाले एनकोडर का एक उदाहरण: BCJ2 {03, 03, 01, 1B}। X86 और x86-64 मशीन कोड को डिज़ाइन किया गया है ताकि प्रक्रिया (E8 xx xx xx xx) को कॉल करने के लिए कमांड्स (E9 xx xx xx xx - लंबी बिना शर्त, 0F 8x xx xx xx xx - लंबी सशर्त) गंतव्य पते को एक ऑफसेट पते के रूप में उसके ऑफसेट सापेक्ष में कूटबद्ध करें। अंत। इस वजह से, संपीड़न बस "नोटिस" नहीं करेगा कि E8 xx xx xx xx की अलग-अलग घटनाएं (ऑफसेट की सापेक्षता के कारण अलग-अलग xx के साथ) वास्तव में एक ही प्रक्रिया के लिए एक कॉल हैं। BCJ2 कॉल और जंप के गंतव्य को पूर्ण रूप में परिवर्तित करता है और 4 आउटपुट स्ट्रीम उत्पन्न करता है: पहला गंतव्य डेटा है, दूसरा कॉल का गंतव्य है, तीसरा जंप का गंतव्य है, चौथा एक बिटस्ट्रीम है जो आपको बताता है कि क्या कोई उपयुक्त E8 / E9 / 0F 8x है एन्कोडेड असाइनमेंट या यह केवल डेटा का एक बाइट है।

7z प्रारूप सबसे सामान्य स्थिति का वर्णन करता है: इनपुट स्ट्रीम कुछ एनकोडर की एक मनमानी संख्या से एन्कोड की जाती है, जिसके आउटपुट बदले में अन्य एन्कोडर के इनपुट हो सकते हैं, और इसी तरह। स्ट्रीम जानकारी में पहला PackInfo ब्लॉक संग्रह में दर्ज सभी अंतिम धाराओं का वर्णन करता है (एन्कोडर के सभी आउटपुट स्ट्रीम किसी अन्य एन्कोडर को आपूर्ति नहीं की जाती है): बाइट 0x06, फ़ाइल में अंतिम धाराओं की एन्कोडेड (पहले हेडर के अंत से एक ऑफसेट के रूप में) धाराएँ एक के बाद एक क्रमिक रूप से), धाराओं की एन्कोडेड संख्या, बाइट 0x09, सभी अंतिम धाराओं के आकार (प्रत्येक अंतिम स्ट्रीम के लिए एक एन्कोडेड संख्या), बाइट 0x00। धाराओं के आकार और संरचना के अंत के बीच अंतिम धाराओं के सीआरसी के बारे में जानकारी हो सकती है, लेकिन आमतौर पर इसका उपयोग नहीं किया जाता है, और सीआरसी को अनपैक्ड डेटा के लिए नियंत्रित किया जाता है।

7z में पूर्णांक निम्नानुसार एन्कोड किए गए हैं: पहले बाइट में अग्रणी इकाइयों की संख्या अतिरिक्त बाइट्स की संख्या निर्धारित करती है, पहली बाइट के अन्य बिट्स संख्या के सबसे महत्वपूर्ण बिट हैं, अतिरिक्त बाइट्स छोटे-एंडियन में संख्या के कम बाइट्स का निर्धारण करते हैं। 0x80 से कम संख्या एक बाइट के साथ ही संख्या के बराबर एन्कोडेड हैं। सभी 8 बाइट्स पर कब्जा करने वाले नंबर बाइट की शुरुआत में 0xFF असाइन करके एन्कोड किए गए हैं।
हमारी दो धाराएँ होंगी। पहला फ़ाइल "किसी प्रकार की .txt फ़ाइल" के लिए है, पहले हेडर के अंत में ऑफसेट 0 के सापेक्ष शुरू होता है। दूसरा संग्रह के लिए है, जो फ़ाइल की शुरुआत में है। चूंकि उत्तराधिकार में धाराएं एक के बाद एक का अनुसरण करती हैं, इसलिए पहली धारा के आकार को 0 - 0x20 = 0xFFFFFFFFFFFFFFFFFFE0 के बराबर बनाना होगा। संग्रह का आकार, हम अभी तक नहीं जानते हैं, हम इसके लिए दो बाइट छोड़ देंगे। तो, हम PackInfo ब्लॉक बनाते हैं:

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

दूसरा CodersInfo ब्लॉक मापदंडों और उनके बीच संबंधों के साथ उपयोग किए गए सभी एनकोडर का वर्णन करता है। एन्कोडर को लिंक समूहों में वर्गीकृत किया जाता है, लेकिन लिंक समूहों के बीच नहीं। उदाहरण के लिए, एक समूह में एक LZMA पैकर शामिल हो सकता है, दूसरा - BCJ2 + (कई अलग-अलग LMAMA) के एक समूह से। CodersInfo ब्लॉक बाइट्स 0x07 0x0B के साथ शुरू होता है, इसके बाद समूहों की एन्कोडेड संख्या, शून्य बाइट (नॉन-जीरो का मतलब होगा कि समूहों के बारे में एक अलग अतिरिक्तस्ट्रीम में जानकारी डालना), प्रति समूह एक फ़ोल्डर संरचना। प्रत्येक समूह समूह में एनकोडर की संख्या के साथ शुरू होता है, इसके बाद प्रत्येक एनकोडर का विवरण होता है। एनकोडर विवरण के पहले बाइट में निचले 4 बिट्स में पहचानकर्ता आकार होता है, अगला बिट केवल तभी सेट होता है जब एनकोडर में इनपुट चैनलों की संख्या होती है या आउटपुट चैनलों की संख्या एक के बराबर नहीं होती है, अगला बिट सेट होता है यदि एनकोडर पैरामीटर होता है। इसके बाद पहचानकर्ता द्वारा पीछा किया जाता है, इसके बाद आउटपुट और इनपुट चैनलों की संख्या (यदि एक या दूसरे को एकता से अलग किया जाता है), तो मापदंडों का आकार (यदि कोई हो) और मापदंडों को बाइट्स के एक सरणी के रूप में। सभी एन्कोडर के बाद लिंक का विवरण है: आउटपुट चैनल की संख्या और कनेक्ट होने के लिए इनपुट चैनल की संख्या। प्रत्येक इनपुट चैनल, एक को छोड़कर, कुछ डिकोडर का आउटपुट होना चाहिए, इसलिए सभी एन्कोडर माइनस में इनपुट चैनलों की कुल संख्या के बराबर लिंक की संख्या 1 है। अंत में, यदि आउटपुट स्ट्रीम की संख्या एक से अधिक है, तो समूह विवरण उस क्रम में अनबाउंड आउटपुट स्ट्रीम के सूचकांकों की सूची के साथ है। जिसमें वे अभिलेख में दर्ज हैं। फ़ोल्डरों के विवरण के बाद एक 0xC बाइट है और सभी इनपुट चैनलों के आकार, लिंक किए गए सहित, सभी फ़ोल्डरों के हैं। PackInfo की तरह, CodersInfo ब्लॉक बाइट 0x00 के साथ समाप्त होता है। धाराओं के आकार और संरचना के अंत के बीच इनपुट सीआरसी जानकारी हो सकती है, जो आमतौर पर केवल पैक हेडर के बारे में स्ट्रीम जानकारी के लिए उपयोग की जाती है (सीआरसी फाइलें अगले ब्लॉक में संग्रहीत होती हैं)। सीआरसी, यदि सभी धाराओं के लिए एक है, तो निम्नानुसार संग्रहीत किया जाता है: पहला एक गैर-शून्य बाइट (एक संकेत जो सीआरसी को सभी धाराओं के लिए परिभाषित किया गया है, अन्यथा, एक बिटमैप आगे संकेत देता है कि सीआरसी धाराएं परिभाषित हैं), फिर प्रति स्ट्रीम सीआरसी के 4 बाइट्स।
हम कोडर्सइन्फो ब्लॉक बनाते हैं, यह देखते हुए कि हमारे पास दो समूहों में से प्रत्येक में दो धाराओं के लिए एक-एक कॉपी एनकोडर है, और अभी भी अज्ञात संग्रह आकार के लिए दो बाइट छोड़ रहा है:

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

SubStreamsInfo के तीसरे ब्लॉक फाइलों का वर्णन करता है। यह एक पैक हेडर की धाराओं के बारे में जानकारी में मौजूद नहीं है, लेकिन फ़ाइलों की धाराओं के बारे में जानकारी में, संभवतः, डेटा के बिना होना चाहिए। 7-ज़िप व्यक्तिगत फ़ाइलों को संपीड़ित नहीं करता है, लेकिन कई फ़ाइलों के ब्लॉक (निरंतर अभिलेखागार; आप एक फ़ाइल तक एक ब्लॉक में ब्लॉक आकार और फ़ाइलों की संख्या निर्धारित कर सकते हैं, जो वास्तव में निरंतर अभिलेखागार को बंद कर देता है, लेकिन डिफ़ॉल्ट निरंतरता चालू है)। ऊपर वर्णित विवरण में इनपुट धाराएँ कई फ़ाइलों को जोड़ती हैं। SubStreamsInfo ब्लॉक एक ब्लॉक में (गैर-रिक्त) फ़ाइलों के आकार का वर्णन करता है। इसकी शुरुआत बाइट 0x08 से होती है। इसके अलावा, शायद बाइट 0x0D और प्रत्येक समूह में फ़ाइलों की संख्या का पालन करना चाहिए; यदि वे नहीं हैं, तो यह माना जाता है कि प्रत्येक समूह में एक फ़ाइल। फिर, शायद, बाइट 0x09 और व्यक्तिगत फ़ाइलों के आकार का पालन करते हैं (प्रत्येक समूह में अंतिम को छोड़कर - यह समूह के इनपुट स्ट्रीम के आकार से गणना की जाती है)। इसके अलावा, शायद, बाइट 0x0A और सीआरसी की अलग-अलग फाइलों को कोडर्सइन्फो ब्लॉक के समान संग्रहित किया जाना चाहिए। SubStreamsInfo ब्लॉक अन्य की तरह, बाइट 0x00 समाप्त होता है। हमारे पास संग्रह में दो फाइलें हैं जो विभिन्न धाराओं में संग्रहीत हैं। सादगी के लिए, हम अपने संग्रह में सीआरसी को रिकॉर्ड नहीं करेंगे (यह एक पाठ फ़ाइल के लिए करना आसान है, संग्रह के लिए आपको इसे समायोजित करने की आवश्यकता है ताकि सीआरसी सहित डेटा से गणना की गई सीआरसी स्वयं में कनवर्ट हो जाए - आपको अप्रयुक्त बाइट्स का चयन करना होगा और उन्हें समायोजित करना होगा)। इसलिए, SubStreamsInfo ब्लॉक में डेटा नहीं है:

 00000050: 08 00 

हम एक शून्य बाइट के साथ प्रवाह जानकारी को पूरा करते हैं और ऊपर के स्तर पर लौटते हैं:

 00000050: 00 

FilesInfo, जैसा कि आप अनुमान लगा सकते हैं, संग्रह के अंदर फ़ाइलों के बारे में जानकारी शामिल है: नाम, निर्माण / परिवर्तन / एक्सेस दिनांक, फ़ाइल विशेषताएँ। FilesInfo बाइट 0x05 से शुरू होता है, इसके बाद एक एनकोडेड पूर्णांक द्वारा फाइलों की संख्या का संकेत मिलता है, इसके बाद एक संपत्ति (कुछ मात्रा में)। प्रत्येक गुण एक गैर-शून्य पहचानकर्ता बाइट के साथ शुरू होता है, उसके बाद संपत्ति का आकार (ताकि 7-ज़िप अज्ञात गुणों को छोड़ सके)। शून्य बाइट FilesInfo समाप्त होता है। फ़ाइल नाम टाइप 0x11 के साथ एक संपत्ति के रूप में एन्कोडेड हैं, सामग्री का पहला बाइट शून्य है (एक गैर-शून्य बाइट का मतलब है कि सभी आगे की संपत्ति सामग्री को एक अलग अतिरिक्तस्ट्रीम में रखा गया है, जिसका सूचकांक सामान्य सरणी में नीचे एन्कोडेड है, फिर नाम स्वयं एक समाप्ति शून्य के साथ 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 बाइट्स रखता है।
अब हमें दो सीआरसी की गणना करने की आवश्यकता है। मैन्युअल रूप से 0x6D बाइट्स द्वारा सीआरसी पढ़ना काफी परेशानी भरा है, इसलिए यहां हम कार्यक्रमों की सहायता का सहारा लेते हैं। पहला सीआरसी जिसे हमें गणना करने की आवश्यकता है, मुख्य हेडर है: 0x31 से अंत तक बाइट्स, इसका सीआरसी 0x3F5E2977 है। दूसरे CRC की गिनती पहले हेडर के अंतिम तीन क्षेत्रों में की जाती है, जिसमें पहला CRC शामिल है: 11 00 00 00 00 00 00 00 00 00 6 00 00 00 00 00 00 00 77 77 29E 5F 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<....|