XZ को BZ2 में बदलें

इस बदलाव की एक ईमानदार वजह है और उसे पहले रखना ज़रूरी है, क्योंकि दोनों फ़ॉर्मेट की हर आम तुलना उल्टा करने को कहती है। XZ खोलने के लिए dictionary-आकार का बफ़र चाहिए — रजिस्ट्री इस फ़ॉर्मेट की dictionary 64 MB तक दर्ज करती है। लैपटॉप पर यह कुछ नहीं। किसी राउटर पर, 32 MB मेमोरी सीमा वाले कंटेनर में, यही अंतर है खुलती आर्काइव और मारे गए extractor के बीच।

इसी समस्या का दूसरा रूप यह है कि xz इंस्टॉल ही नहीं। यह 2009 में आया, जो इतना हाल का है कि कई पुराने सिस्टम — उपकरण, इंस्ट्रूमेंट, औद्योगिक कंट्रोलर — के पास bzip2 और gzip हैं, इससे नया कुछ नहीं। ऐसी मशीन में बाइनरी जोड़ना अक्सर टेक्नोलॉजी से कोई नाता न रखने वाली वजहों से मुमकिन नहीं।

2009 का XZ, LZMA2 है: sliding-window कंप्रेसर जिसकी dictionary रजिस्ट्री 64 MB तक दर्ज करती है। बाइट एक सौ मिलियन कंप्रेस करते समय यह अब भी बाइट छत्तीस मिलियन देख सकता है। डिकंप्रेस करने के लिए, reader को वही विंडो उपलब्ध रखनी पड़ती है।

1996 का BZ2 बिल्कुल नहीं फिसलता। यह इनपुट को 900 KB तक के ब्लॉक में काटता है, हर एक को Burrows–Wheeler transform से क्रमबद्ध करता है, और नतीजा कोड करता है। ब्लॉक स्वयं-निहित है, तो decompressor एक ब्लॉक रखता है, और कुछ नहीं। यही डिज़ाइन फ़ैसला bzip2 को अनुपात में हराता है और उसे खोलने में सस्ता बनाता है — दोनों गुण एक ही तथ्य के दो सिरे हैं।

आकार की क़ीमत असली है और उसका पैमाना पूरी तरह सामग्री पर निर्भर है। किसी सोर्स ट्री, दस्तावेज़ों के संग्रह, लॉग फ़ाइल या कई सदस्यों में दोहराई बनावट वाली किसी और चीज़ पर, XZ ने बहुत कुछ खोजा होगा जो bzip2 नहीं देख सकता, और BZ2 साफ़ बड़ी होगी।

दूसरी आर्काइव पर यह क़ीमत लगभग शून्य पर पहुँच जाती है। अगर XZ में तस्वीरें, वीडियो, ऑडियो या पहले से कंप्रेस्ड डेटाबेस डंप है, मज़बूत कंप्रेसर के पास खोजने को कुछ नहीं था; दोनों फ़ॉर्मेट लगभग सिर्फ़ डेटा लपेटते हैं, और दोनों फ़ाइलें कुछ प्रतिशत के फ़ासले पर उतरती हैं।

यह मान लेना आसान है कमज़ोर फ़ॉर्मेट हर चीज़ में तेज़ है, और ऐसा नहीं होता। XZ compress करने में धीमा है, क्योंकि 64 MB dictionary खोजना महँगा है, और decompress करने में अपेक्षाकृत तेज़, क्योंकि back-reference का पालन करना लगभग मेमोरी कॉपी जैसा है। Bzip2 उल्टा है: Burrows–Wheeler transform पलटना असली गणना है, तो bzip2 धीरे खुलता है।

यह योजना बनाने लायक़ है, क्योंकि यह बदलाव की वजह को आंशिक रूप से कमज़ोर करता है। सीमित डिवाइस को अब कम मेमोरी और ज़्यादा समय चाहिए, और अगर उसका प्रोसेसर भी धीमा है — जो छोटे डिवाइस आम तौर पर होते हैं — extraction XZ से कहीं ज़्यादा समय ले सकता है।

दोनों सिंगल-स्ट्रीम कंप्रेसर हैं और किसी को नहीं पता फ़ाइल क्या है। रजिस्ट्री डायरेक्ट्री बनावट की कमी दोनों की जानी-पहचानी समस्या के तौर पर दर्ज करती है, यही वजह है दोनों लगभग हमेशा भीतर TAR के साथ मिलते हैं। यह बदलाव XZ के भीतर की tarball खोलकर नई बनाता है और उसे bzip2 से कंप्रेस करता है।

कोई भी फ़ॉर्मेट मूल फ़ाइलनाम दर्ज नहीं करता — gzip करता है, ये दोनों नहीं — तो जो एक्सटेंशन आप डाउनलोड पर लगाते हैं वही इकलौता लेबल है। इसे `.tar.bz2` कहिए।

सीमित मेमोरी ही मुख्य बात है, और एक दूसरा नतीजा भी उसी पाठक के लिए काम का है। क्योंकि bzip2 के ब्लॉक स्वतंत्र रूप से कंप्रेस होते हैं, ख़राब फ़ाइल ज़रूरी नहीं ख़राबी के बाद सब कुछ खोए — recovery टूल बरक़रार ब्लॉक सीमाएँ खोजकर जो बचा है वह बचा सकते हैं। कटी या ख़राब xz स्ट्रीम आम तौर पर वहीं ख़त्म हो जाती है।

यह उन वातावरणों से मेल खाता है जिनके लिए यह पेज लिखा गया, जहाँ storage अनिश्चित क्वालिटी की सस्ती flash है और बिना चेतावनी बिजली कट जाती है। यह बैकअप रणनीति नहीं और उसके तौर पर नहीं बेची जानी चाहिए।

अगर XZ छोड़ने की वजह मेमोरी या ग़ायब बाइनरी है, gzip दोनों को कम से कम उतना ही अच्छे से सुलझाता है और कम समय लेता है। इसे 32 KB विंडो चाहिए — लगभग कुछ नहीं — यह लगभग हर सिस्टम पर मौजूद है जिसमें कोई भी कंप्रेसर है, और यह इन डिवाइस के धीमे प्रोसेसर पर bzip2 से कहीं तेज़ खुलता है।

तो ख़ास तौर पर bzip2 का मामला संकरा है: gzip और bzip2 के बीच आकार का फ़र्क़ सच में आपके ट्रांसफ़र या flash बजट के लिए मायने रखता है, और अतिरिक्त decompress समय झेला जा सकता है। न मायने रखे तो gzip बेहतर लक्ष्य है।

हमारे सर्वर पर, आपके ब्राउज़र में नहीं। यहाँ ज़्यादातर टूल आपके अपने डिवाइस पर चलते हैं और साफ़ कहते हैं; archive दोबारा-पैक करना अपवादों में से है, क्योंकि इसे 7-Zip और bzip2 असली प्रोग्राम के तौर पर चाहिए। फ़ाइल एन्क्रिप्टेड कनेक्शन से उन्हें चलाने वाले कंटेनर तक जाती है।

हर काम को memory-backed फ़ाइलसिस्टम पर scratch डायरेक्ट्री मिलती है, जो काम ख़त्म होते ही मिटा दी जाती है, नतीजा कुछ भी हो। मुफ़्त स्तर प्रति अपलोड फ़ाइल 25 MB स्वीकारता है, और 2 GB से ज़्यादा फैलने की घोषणा करने वाली आर्काइव को extraction से पहले ही नकार दिया जाता है।

यहाँ इकलौता मायने रखने वाला सत्यापन लक्ष्य मशीन पर होता है। BZ2 को उस डिवाइस, उपकरण या कंटेनर पर कॉपी कीजिए जो xz फ़ाइल पर फ़ेल हुआ था और वहीं extract कीजिए — अपने वर्कस्टेशन पर नहीं, जहाँ दोनों फ़ॉर्मेट काम करते और आप कुछ नहीं सीखते।

फिर मूल के ख़िलाफ़ सूची मिलाइए: XZ पर `tar tJf` और BZ2 पर `tar tjf` एक जैसी गिनती और पथ दिखाने चाहिए। यह लॉसलेस दोबारा-पैकिंग है, तो फ़र्क़ कभी ख़राब फ़ाइल नहीं — यह बनावट का फ़र्क़ है, आम तौर पर कोई अगुआ डायरेक्ट्री जो एक में है, दूसरे में नहीं।