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

XZ बस वही है जो ओपन-सोर्स दुनिया प्रकाशित करती है। स्रोत-रिलीज़, वितरण-पैकेज, कर्नेल tree लगभग हमेशा .tar.xz बनकर आते हैं, क्योंकि फ़ाइल हज़ारों बार लाई जाती है और एक ही बार बनाई जाती है।

यह परंपरा उन लोगों ने बनाई जिनके पास shell है, जहाँ tar -xJf एक कमान में दोनों परतें खोल देता है। उससे बाहर यह मददगार नहीं — Windows अनजान फ़ाइल-प्रकार दिखाता है, macOS कुछ काम का नहीं देता।

XZ एक धारा दबाता है और कुछ नहीं। इसमें किसी नाम, पथ या अनुमति-बिट के लिए कोई खाना नहीं। नाम नीचे बैठी TAR में रहते हैं — हर फ़ाइल के लिए एक हेडर ब्लॉक, उसकी सामग्री, बिना कोई अपना दबाव।

आपका फ़ोल्डर वापस पाने के लिए दो अलग चीज़ों को पलटना पड़ता है, और सिर्फ़ पहला करना एक .tar छोड़ जाता है जो Windows पर उतनी ही न-खुलने-वाली है जितनी शुरू की फ़ाइल थी।

LZMA2 किसी दोहराव को धारा में 64 मेगाबाइट पीछे तक किसी संदर्भ के रूप में एनकोड करता है, ZIP की 32 किलोबाइट खिड़की के मुक़ाबले लगभग दो हज़ार गुना पहुँच।

स्रोत-tree पर असर नाटकीय है, क्योंकि दोहराव हर जगह फैला होता है — दो सौ फ़ाइलों में खुलने वाला वही लाइसेंस-हेडर, वही import-लाइनें। इसीलिए किसी प्रोजेक्ट की रिलीज़-टारबॉल खुलकर जो बनती है उससे इतनी छोटी होती है।

कुछ भी निकालने से पहले, आर्काइव से पूछा जाता है वह क्या रखने का दावा करती है, और 2 गीगाबाइट से ऊपर का घोषित योग सीधे मना कर दिया जाता है। ज़्यादातर आर्काइव जोड़ी पर यह सुरक्षा दुर्भावनापूर्ण फ़ाइलों के लिए है।

यह जोड़ी अपवाद है। एक मज़बूत compressor किसी बड़े tree को इतनी छोटी फ़ाइल में बदल सकता है कि आराम से अपलोड हो जाए — तो एक बिलकुल ईमानदार स्रोत-आर्काइव भी लौटा दी जा सकती है।

काफ़ी, अनुपात में। ZIP हर सदस्य को अलग-अलग 32 किलोबाइट खिड़की के ख़िलाफ़ दबाता है, इसलिए फ़ाइल-सीमा के पार तो क्या, 64 मेगाबाइट पीछे भी नहीं देख सकता।

भीतर झाँकने वाले पाठक के लिए यह उचित सौदा है — ZIP बिना किसी सॉफ़्टवेयर के खुलती है। स्टोर या आगे भेजी जाने वाली चीज़ के लिए यह ख़राब सौदा है, और बेहतर जवाब है .tar.xz को जैसे प्रकाशित हुई वैसे ही रखना।

LZMA2 खोलने का मतलब है वह dictionary याद रखना जिससे फ़ाइल पैक हुई थी, इसलिए ज़रूरी मेमोरी फ़ाइल के आकार से ज़्यादा उस dictionary को देखती है।

किसी लैपटॉप या सर्वर पर यह मामूली बात है। यह असली मुद्दा बनती है सीमित हार्डवेयर पर — कोई router, कोई embedded बोर्ड — जहाँ gzip की सामान्य 32 किलोबाइट खिड़की फ़ायदा बन जाती है।

हर xz फ़ाइल टारबॉल नहीं होती। किसी एक दबे डिस्क-इमेज, एक बड़े log या एक डेटाबेस डंप पर xz लगाना बिना किसी TAR के इस फ़ॉर्मेट का ठीक वैसा ही इस्तेमाल है जैसे बना था।

यह converter xz परत से जो निकलता है उसे TAR मानकर पार्स करने की कोशिश करता है; नाकाम होने पर उसे वही एक फ़ाइल मानकर ZIP में रखता है। xz कोई असली नाम नहीं रखता, इसलिए एंट्री को कोई मतलब वाला नाम आगे दे दीजिए।

यह बदलाव हमारे सर्वर पर होता है, पेज में नहीं। फ़ाइल एन्क्रिप्टेड कनेक्शन से जाती है, decompressed होती है, खुलती है, अंदर से ZIP बनकर पैक होकर वापस आती है — अपलोड, बीच की tar और आउटपुट, तीनों काम पूरा होते ही मिटा दिए जाते हैं।

मुफ़्त अपलोड 25 मेगाबाइट पर रुकते हैं, हर काम साठ सेकंड पर रोक दिया जाता है, और पासवर्ड-सुरक्षित आर्काइव किसी संदेश के साथ नाकाम होती हैं, बिना किसी prompt का इंतज़ार किए।

अगर आर्काइव किसी Linux मशीन, build agent या container image की तरफ़ जा रही है, तो बदलना हर मापदंड पर एक क़दम पीछे है — मंज़िल के पास xz पहले से इंस्टॉल है, ZIP ढोने में कहीं ज़्यादा भारी है, और TAR की मोड-अनुमतियाँ ZIP में सफ़र में नहीं बचतीं।

बदलिए जब किसी डेस्कटॉप पर किसी इंसान को भीतर देखना है, जब कोई अपलोड फ़ॉर्म ZIP पर अड़ा है, या जब आप उस किसी को भेज रहे हैं जो कभी कोई archiver इंस्टॉल नहीं करेगा।

स्रोत-रिलीज़ आमतौर पर checksum फ़ाइल और अक्सर अलग हस्ताक्षर के साथ प्रकाशित होती हैं, और दोनों उसी .tar.xz को बताते हैं जो upstream ने लिखी। असली डाउनलोड के ख़िलाफ़ इन्हें पहले जाँच लीजिए, बदलने से पहले — दोबारा पैक की गई ZIP दोनों में से किसी से मेल नहीं खाएगी।

यह बदलाव की ख़ामी नहीं; यही सत्यापन का मक़सद है। सही क्रम है पहले हस्ताक्षर जाँचना, फिर ज़रूरत पड़ने पर आगे बदलना।