7Z को XZ में बदलें

यह कन्वर्ज़न अनुकूलता का है, संपीड़न का नहीं। कोई पैकेज बना रहा है, सोर्स रिलीज़ पब्लिश कर रहा है, या किसी बिल्ड स्क्रिप्ट की पाइपलाइन एक कंप्रेस्ड tarball मानकर चलती है — और उसकी जगह 7Z आ गया, अक्सर इसलिए क्योंकि बनाने वाला Windows पर काम करता है जहाँ 7-Zip आम है।

दूसरी तरफ़ की व्यवस्था एक फ़ाइल के लिए नहीं बदलेगी। इसलिए ईमानदार सलाह यही है: बदलिए अगर आगे कोई सिस्टम इस पर अड़ा है, और अगर कोई नहीं अड़ा तो 7Z को वैसे ही रहने दीजिए। आकार को लेकर किसी भी दिशा में जल्दबाज़ी की ज़रूरत नहीं।

7Z 1999 से और XZ 2009 से है, और दोनों LZMA परिवार पर बने हैं — रजिस्ट्री दोनों को 64 MB का डिक्शनरी देती है। यही वह आकार है जो कंप्रेसर को यह देखने देता है कि कोई पंक्ति फ़ाइल तीन में पहले भी आई थी।

इसलिए अनुपात डेटा तय करता है, फ़ॉर्मेट नहीं। सोर्स कोड या लॉग की फ़ाइलों में दोनों को बहुत दोहराव मिलेगा; JPEG या MP4 की फ़ाइलों में किसी को कुछ नहीं मिलेगा, क्योंकि दोहराव पहले ही निकाला जा चुका है। अगर उम्मीद यह थी कि यह बदलाव फ़ाइल छोटी कर देगा, तो कंप्रेसर कभी दिक़्क़त था ही नहीं।

XZ ठीक एक स्ट्रीम को कंप्रेस करता है — इसमें फ़ाइल का नाम रखने की कोई जगह नहीं, फ़ोल्डर की कोई अवधारणा नहीं। यही वजह है कि TAR इसके साथ रहता है।

इसलिए 7Z खोलकर उसका सब कुछ पहले एक TAR में जोड़ा जाता है, फिर उस TAR को xz से कंप्रेस किया जाता है। ध्यान रहे: यह अभी लिखा गया एक नया TAR है, इसलिए अगर 7Z के भीतर पहले से एक साधारण .tar फ़ाइल रखी थी तो वह वैसी ही रहती है, खुलती नहीं।

जो फ़ाइल मिलती है वह .xz में ख़त्म होती है, पर उसका ईमानदार नाम .tar.xz होना चाहिए। xz -d और tar दोनों बाइट देखते हैं, नाम नहीं, इसलिए कुछ टूटता नहीं — पर हर इंसान और आधी ऑटोमेशन पहले एक्सटेंशन ही पढ़ती है।

रिलीज़ करने से पहले नाम बदल दीजिए। tar xf project.tar.xz तब दोनों परतें एक ही कमांड में खोल देता है — जबकि project.xz नाम की फ़ाइल किसी को unxz चलाने पर उकसाती है और हाथ में एक ऐसी फ़ाइल थमा देती है जो असल में आर्काइव है।

7Z आर्काइव को पता होता है उसके भीतर क्या है — नाम, पथ, आकार, हर एंट्री की चेकसम — इसीलिए बिना कुछ खोले 400 MB के 7Z की सूची तुरंत दिख जाती है। XZ को कुछ पता नहीं: xz --list सिर्फ़ ब्लॉक की संख्या और स्ट्रीम का आकार बता सकता है।

tar.xz की सूची देखने के लिए भीतर के TAR तक पहुँचना पड़ता है, यानी पूरी स्ट्रीम खोलनी पड़ती है। छोटी रिलीज़ में यह एक सेकंड का काम है; कई गीगाबाइट के आर्काइव में झाँकने भर के लिए यह लंबा इंतज़ार बन जाता है।

xz हर लिनक्स और BSD की बुनियादी स्थापना में शामिल है, क्योंकि पैकेज मैनेजर ख़ुद इस पर निर्भर करता है। GNU tar ने 1.22 से -J का इस्तेमाल समझना शुरू कर दिया था, इसलिए कोई अलग क़दम नहीं चाहिए।

7-Zip उस जगह नहीं है — इसे अलग से इंस्टॉल करना पड़ता है, और यही रजिस्ट्री में 7Z की सीमित उपलब्धता के तौर पर दर्ज है। एक बिल्ड एजेंट या न्यूनतम कंटेनर पर यह फ़र्क़ पूरा सवाल बन जाता है, संपीड़न नहीं।

7Z में एन्क्रिप्शन हो सकता है, XZ में नहीं — इसलिए सुरक्षित आर्काइव को पार करना संभव ही नहीं। एक्स्ट्रैक्टर को जान-बूझकर ख़ाली पासवर्ड के साथ चलाया जाता है, ताकि एन्क्रिप्टेड फ़ाइल तुरंत साफ़ संदेश के साथ रुक जाए, न कि किसी अटके हुए प्रॉम्प्ट पर इंतज़ार करे।

दूसरी जाँच लिखने से पहले होती है: आर्काइव से पूछा जाता है कि खुलकर कितना बड़ा होगा, और 2 GB से ऊपर बताने वाला आर्काइव पहले ही लौटा दिया जाता है।

यह पेज इस साइट के उन थोड़े रास्तों में है जो ब्राउज़र में नहीं चलते, क्योंकि इसके लिए असली 7-Zip और xz प्रोग्राम चाहिए। फ़ाइल एन्क्रिप्टेड कनेक्शन से एक ऐसे कंटेनर तक जाती है जिसे बाहर के इंटरनेट तक पहुँच ही नहीं है।

हर काम की अपनी अस्थायी जगह होती है जो काम ख़त्म होते ही मिटा दी जाती है, चाहे नतीजा जो भी हो। मुफ़्त सीमा 25 MB प्रति फ़ाइल है, क्योंकि यह जोड़ी सर्वर पर चलती है, ब्राउज़र में नहीं।

tar tJf चलाकर सूची को 7Z की सूची से मिलाइए — गिनती, पथ और आकार बराबर होने चाहिए। सबसे ज़्यादा नुक़सान वाली ग़लती यही है कि हर पथ के आगे एक फ़ोल्डर जुड़ या घट जाए।

फ़ाइलें बाइट-दर-बाइट वैसी ही आती हैं — यह लॉसलेस रीपैक है — पर टाइमस्टैंप और Unix अनुमतियाँ हमेशा नहीं बचतीं, ख़ासकर अगर मूल 7Z Windows पर बना हो। किसी एग्ज़िक्यूटेबल फ़ाइल को चलने लायक़ रहना ज़रूरी हो तो tarball में जाँच लीजिए।