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

7Z एक बेहतरीन फ़ॉर्मेट है, पर दूसरी तरफ़ जो मशीनरी बैठी है उसने इसे कभी माना ही नहीं। एक बिल्ड एजेंट tarball ही खोलना जानता है, एक डिप्लॉय स्क्रिप्ट gzip की उम्मीद में लिखी गई थी, और सर्वर एडमिन के पास पहले से कोई archiver लगाने का वक़्त नहीं है।

बात करने में जितना वक़्त लगेगा, बदलने में उससे कम लगता है। जहाँ दोनों सिरे आपके हाथ में हों वहाँ हिसाब अलग है, पर यहाँ आने की सबसे आम वजह यही है कि एक सिरा आपके हाथ में नहीं है।

GZ ठीक एक बाइट-स्ट्रीम को दबाता है और नाम, पथ या permission के लिए इसमें कोई जगह नहीं है। 7Z इसके उलट है — अपनी खुद की डायरेक्टरी, अपने चेकसम और अपनी एन्क्रिप्शन वाला एक कंटेनर। इसलिए बीच में एक कदम चाहिए, और वह है TAR।

सामग्री को पहले tarball के रूप में बिछाया जाता है, फिर उस पूरे tarball को gzip किया जाता है। यही .tar.gz का पुराना मतलब है, और यही वजह है कि दूसरे सिरे पर बैठी tooling इसे बिना कुछ बताए पहचान लेती है।

7Z में LZMA2, 64 MB तक पीछे देखकर दोहराव पकड़ता है; gzip का DEFLATE सिर्फ़ 32 KB पीछे देखता है। नतीजा साफ़ है — फ़ाइल बड़ी होकर लौटती है, ख़ासकर मिलते-जुलते टेक्स्ट फ़ाइलों के संग्रह पर। तस्वीरों या वीडियो के संग्रह पर फ़र्क़ लगभग नहीं रहता, क्योंकि किसी भी कंप्रेसर के हाथ कुछ खास नहीं लगता।

TAR परत एक फ़ायदा बचा लेती है: gzip पूरी tarball को एक लगातार धारा मानकर दबाता है, इसलिए फ़ाइलों की सीमाओं के आर-पार का दोहराव भी उसे दिखता है — ठीक वैसे ही जैसे 7Z को दिखता था।

gzip हमारी रजिस्ट्री में इकलौता archive फ़ॉर्मेट है जिसे streaming का दर्जा मिला है — बाइट्स आते ही उन्हें खोला जा सकता है, फ़ाइल का अंत देखे बिना। यही वजह है कि curl … | tar -xz काम करता है और डाउनलोड होते-होते ही निकाला जा सकता है।

7Z ऐसा नहीं कर सकता — पहले पूरी archive की संरचना पढ़नी पड़ती है, इसलिए फ़ाइल कहीं पूरी बैठनी ज़रूरी है इससे पहले कुछ खुले। पाइपलाइन के लिए यह फ़र्क़ मेगाबाइट से ज़्यादा भारी है।

यह रूपांतरण आपके ब्राउज़र में नहीं, हमारे कन्वर्टर पर चलता है — एक एन्क्रिप्टेड कनेक्शन से 7Z ऊपर जाती है, 7-Zip उसे खोलता है, tar बनकर gzip होती है और लौट आती है। अपलोड, बीच की tarball और आउटपुट — तीनों काम खत्म होते ही मिटा दिए जाते हैं।

मुफ़्त सीमा 25 MB प्रति फ़ाइल है। पासवर्ड वाली archive तुरंत रुककर संदेश दे देती है, और जो archive 2 GB से ज़्यादा फैलती हुई घोषित होती है वह लिखने से पहले ही मना कर दी जाती है।

डाउनलोड मूल नाम पर लक्ष्य का एक्सटेंशन जोड़ता है — build.7z, build.gz बनकर लौटती है, भले भीतर एक gzipped tarball ही क्यों न हो। ज़्यादातर Unix टूल यह बाइट्स से पहचान लेते हैं; कुछ स्क्रिप्ट और सर्वर नहीं पहचानते।

इसे .tar.gz या .tgz नाम दे दीजिए — यह कुछ खर्च नहीं करता और उस भ्रम को जड़ से हटा देता है जो किसी को यह सोचने पर मजबूर करता है कि रूपांतरण ग़लत हुआ।

सॉलिड कंप्रेशन ही 7Z को छोटा बनाता है और यही उसे बदलने में मुश्किल भी करता है। सदस्य एक लगातार धारा हैं, इसलिए किसी एक तक पहुँचने के लिए उससे पहले वाला सब खोलना पड़ता है — पूरी archive खुलती है इससे पहले कि एक भी बाइट tar में लिखा जाए।

यही वजह है कि साठ सेकंड की सीमा और 2 GB की छत इस जोड़ी पर ज़्यादा मायने रखती हैं। कसकर पैक की गई 7Z छोटी दिखती है पर भीतर बहुत काम छुपाए रह सकती है।

अगर tarball पूरी तरह डिस्क पर उतरने के बाद ही खुलनी है, तो gzip की streaming वाली ख़ूबी बेकार है और उसका कमज़ोर अनुपात सीधा नुक़सान। 7Z को XZ में बदलना उसी LZMA परिवार को बनाए रखता है और बहुत छोटी फ़ाइल देता है।

बदले में xz को खोलने के लिए ज़्यादा मेमोरी चाहिए और वह हर छोटे सिस्टम पर मौजूद नहीं होता। पाइपलाइन के लिए gzip, डाउनलोड और रिलीज़ के लिए xz — दोनों एक ही tarball से बनते हैं, फ़र्क़ सिर्फ़ आवरण का है।

TAR परत हर सदस्य के साथ mode, यूज़र और ग्रुप रिकॉर्ड करती है, इसलिए पैकेजिंग टूल tarball ही माँगते हैं। पर जो कभी था ही नहीं वह वापस नहीं आता — ये फ़ील्ड हमारे कन्वर्टर की extraction से भरे जाते हैं, उस मशीन से नहीं जहाँ फ़ाइलें बनी थीं।

बिल्ड आर्टिफ़ैक्ट के लिए यह अक्सर मामूली है; जो चलाना है उसके लिए नहीं। executable bit खो जाना स्क्रिप्ट को रन-टाइम पर तोड़ देता है। अगर पाइपलाइन mode पर निर्भर है, तो उसे extraction के बाद बिल्ड-स्टेप में ख़ुद सेट कीजिए।