Gzip और Deflate संपीड़न एल्गोरिद्म हैं जो डेटा का आकार घटाते हैं, लेकिन नतीजा बाइनरी होता है, टेक्स्ट नहीं। अगर इस संपीड़ित डेटा को टेक्स्ट के लिए बने चैनल (URL, कुकी, JSON फ़ील्ड) से गुज़रना हो, तो इसे अतिरिक्त रूप से Base64 में एन्कोड किया जाता है — इसीलिए "Gzip/Deflate ↔ Base64" जोड़ी बनती है, जिसका इस्तेमाल कई ऐप्स पूरे स्टेट को शेयर करने लायक लिंक में पैक करने के लिए करते हैं।
देवनागरी टेक्स्ट संपीड़न में क्यों अलग व्यवहार करती है
देवनागरी में कई अक्षर असल में एक साथ जुड़े हुए व्यंजन-समूह (conjuncts) होते हैं, जो यूनिकोड में कई कोडपॉइंट्स से मिलकर बनते हैं — जैसे "क्ष" या "त्र"। नतीजतन एक दिखने वाला अक्षर UTF-8 में कई बाइट्स ले सकता है, और सीधा टेक्स्ट लंबा दिखता है। लेकिन यही जुड़े हुए समूह अक्सर बार-बार दोहराए जाते हैं, तो Gzip इस दोहराव को पहचानकर आकार को काफ़ी हद तक वापस समेट देता है।
ऑपरेशनों का सामान्य क्रम
- मूल टेक्स्ट को Gzip या Deflate से संपीड़ित किया जाता है — आकार घटता है।
- संपीड़ित बाइनरी नतीजे को Base64 में एन्कोड किया जाता है — आकार थोड़ा वापस बढ़ता है, लेकिन डेटा टेक्स्ट बन जाता है।
- परिणामी स्ट्रिंग को टेक्स्ट चैनल के ज़रिए सुरक्षित रूप से भेजा जाता है।
डिकोड करना उल्टे क्रम में होता है: पहले Base64 → बाइनरी डेटा, फिर Gzip/Deflate डीकंप्रेशन → मूल टेक्स्ट।
सामान्य उपयोग
- किसी ऐप के पूरे स्टेट को URL में पैक करना ताकि लिंक शेयर करने पर वह वैसे ही दोबारा खुले।
- कुकी या डेटाबेस के टेक्स्ट फ़ील्ड में संपीड़ित डेटा स्टोर करना।
- डिबगिंग: किसी थर्ड-पार्टी सिस्टम या API द्वारा इस तरह एन्कोड की गई सामग्री को अनपैक करके पढ़ना।
Gzip बनाम "रॉ" Deflate
Gzip असल में Deflate एल्गोरिद्म के ऊपर एक रैपर फ़ॉर्मेट है: यह संपीड़ित डेटा के ऊपर अपना हेडर और एक चेकसम (CRC-32) जोड़ता है। "रॉ" Deflate में ये अतिरिक्त बाइट्स नहीं होते, इसलिए नतीजा थोड़ा छोटा होता है, लेकिन बिना यह साफ़ बताए कि यह रॉ फ़ॉर्मेट है, इसे कोई gzip यूटिलिटी अनपैक नहीं कर सकती। इन दोनों वेरिएंट में उलझ जाना, डेटा अनपैक करते वक़्त "invalid header" एरर की एक आम वजह है।