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

कोई भी उस gzipped फ़ाइल को नहीं बदलता जो अभी खोलनी है। यहाँ पाठक ऐसी चीज़ देख रहा है जो जमा हो गई है — साल भर के rotated logs, compliance के लिए रखे nightly database dumps, कोई research dataset जो shelf पर पड़ी रहती है।

यही फ़र्क़ पूरा फ़ैसला है। अगर archive को कोई जल्दी में fetch और unpack करेगा, इसे वैसा ही छोड़ दीजिए। अगर यह cold storage में बैठकर लगभग कभी नहीं पढ़ी जाएगी, यह रूपांतरण लगभग मुफ़्त पैसा है।

रजिस्ट्री का नंबर ही पूरी व्याख्या है। Gzip, RFC 1952 (मई 1996), DEFLATE का इस्तेमाल करता है जिसकी history window 32 KB है। XZ, 2009 से, रजिस्ट्री में 64 MB तक की dictionary दर्ज करता है — दो हज़ार गुना ज़्यादा पहुँच।

यही वजह है कुछ इनपुट पर फ़ायदा भारी है और कुछ पर शून्य। साल भर के log lines में वही चालीस message template बार-बार दोहराए जाते हैं, और gzip हर एक को हज़ारों बार दोबारा खोजता है जबकि XZ इसे एक बार सीख लेता है।

संपीड़न का समय स्पष्ट क़ीमत है और सबसे कम मायने रखने वाली, क्योंकि यह एक बार किसी ऐसी मशीन पर चुकाई जाती है जो आपके इंतज़ार में नहीं है। XZ compress करने में gzip से बहुत धीमा है।

Decompression पर memory वह क़ीमत है जो असल फ़ैसला करती है और जिसे लोग चूक जाते हैं। Gzip को unpack करने के लिए सिर्फ़ 32 KB चाहिए; XZ को dictionary के अनुसार बड़ा buffer चाहिए। किसी router, embedded device या memory-capped container पर यही फ़र्क़ अंतर बनाता है।

दोनों फ़ॉर्मेट ठीक एक धारा संपीड़ित करते हैं, इसलिए न directory पता है। व्यवहार में `.gz` लगभग हमेशा `.tar.gz` है — नाम और paths रखने के लिए TAR के साथ gzip लिपटा हुआ।

देखने लायक़ मामला वह है जहाँ स्रोत tarball नहीं था। एक सादा `access.log.gz` एक साधारण फ़ाइल रखता है, और repack अब भी उसके इर्द-गिर्द TAR बनाता है, इसलिए जो लौटता है वह `access.log` वाली tarball है।

Gzip stream में मूल फ़ाइल नाम रखने का field होता है, इसीलिए `dump.gz` को Unix मशीन पर decompress करने से `dump.sql` वापस मिल सकता है। XZ के पास ऐसा कोई field नहीं है।

इसका दोनों सिरों पर व्यावहारिक नतीजा है — नतीजे को नाम दीजिए `something.tar.xz` और उसका मतलब भी वही रखिए, क्योंकि यह डाउनलोड की गई फ़ाइल जो एकमात्र label कभी रखेगी वही है।

दोनों फ़ॉर्मेट ख़ुद को verify करते हैं। Gzip stream एक CRC-32 और uncompressed length के साथ ख़त्म होता है; XZ stream अपनी check रखती है, डिफ़ॉल्ट रूप से CRC-64। दोनों मामलों में कटी हुई download decompression पर error देती है।

कोई भी यह नहीं बता सकता कि कौन-सी फ़ाइल ख़राब है, क्योंकि इस स्तर पर कोई फ़ाइल है ही नहीं। अगर आपको per-member integrity चाहिए, कोई stream compressor ग़लत आकार का है।

यह रूपांतरण आपके device पर नहीं चलता। फ़ाइल एन्क्रिप्टेड कनेक्शन से एक container में जाती है जो इन्हें चलाता है, और container का कोई outbound internet access नहीं।

हर job को memory-backed filesystem पर एक scratch directory मिलती है, और job ख़त्म होते ही मिटा दी जाती है। मुफ़्त तह 25 MB प्रति अपलोड फ़ाइल स्वीकार करती है।

BZ2 "gzip काफ़ी संपीड़ित नहीं कर रहा" का पारंपरिक जवाब है, और ज़्यादातर टेक्स्ट पर अब यह XZ से दोनों axis पर हारता है। इसकी बची खूबी memory वाली बात का उल्टा है — bzip2 900 KB तक के block में काम करता है।

तो चुनाव अनुपात के बारे में नहीं है। XZ चुनिए जब unpack करने वाली मशीन साधारण कंप्यूटर हो, BZ2 सिर्फ़ तब जब न हो — पुराना appliance, constrained container।

पहले एक फ़ाइल कीजिए और दोनों आकार देखिए। एक representative archive बाक़ी फ़ोल्डर के बारे में किसी rule of thumb से ज़्यादा भरोसेमंद बताता है, क्योंकि जवाब formats से नहीं contents से तय होता है।

फिर सिर्फ़ आकार नहीं, listing भी जाँचिए। `tar tJf` चलाकर entry count और paths GZ के मुक़ाबले तुलना कीजिए।