gzip / deflate / zlib संपीड़न और विसंपीड़न

gzip कम्प्रेशन क्या है?#

gzip वेब भर में उपयोग होने वाला सामान्य-प्रयोजन लॉसलेस टेक्स्ट और बाइट कम्प्रेसर है — HTTP के Content-Encoding: gzip, सर्वरों से लाई गई .gz फ़ाइलों, और अनगिनत लॉग शिपर्स के वायर फ़ॉर्मेट का सहारा। यह दोहराए गए बाइट पैटर्न ढूँढकर उन्हें छोटे संदर्भों से बदलकर काम करता है, इसलिए पुनरावृत्ति वाला टेक्स्ट (सोर्स कोड, JSON, CSV, लॉग पंक्तियाँ) नाटकीय रूप से सिकुड़ता है, जबकि पहले से संकुचित या यादृच्छिक डेटा (JPEG, एन्क्रिप्टेड बाइट्स) मुश्किल से हिलता है।

यह पेज उन तीन संबंधित एल्गोरिदम को देता है जो आम बोलचाल में “gzip” के नीचे एक साथ रख दिए जाते हैं, और वे केवल उसी DEFLATE कोर के इर्द-गिर्द रैपर में भिन्न होते हैं:

• gzip (RFC 1952) — पूरा पैकेज: एक मैजिक बाइट वाला हेडर, संकुचित पेलोड, और एक CRC32 + साइज़ ट्रेलर। यही .gz फ़ाइलें और HTTP gzip उपयोग करते हैं।
• deflate (RFC 1951) — बिना रैपर वाला कच्चा संकुचित स्ट्रीम। सबसे छोटा आउटपुट, पर कोई अखंडता जाँच नहीं; कुछ API (पुराने Content-Encoding: deflate) ठीक यही अपेक्षा करते हैं।
• zlib (RFC 1950) — एक हल्का 2-बाइट हेडर और एक Adler-32 चेकसम, बाकी दोनों के बीच।

चूंकि संकुचित आउटपुट बाइनरी होता है, औज़ार इसे Base64 या Hex टेक्स्ट के रूप में रेंडर करता है ताकि आप इसे कॉपी कर सकें, JSON में चिपका सकें, या कहीं और पाइप कर सकें। डिकम्प्रेस उल्टा करता है: यह Base64 या Hex पढ़ता है और मूल UTF-8 टेक्स्ट लौटाता है।

इसका उपयोग कैसे करें#

1. टूलबार में एल्गोरिदम चुनें: gzip, deflate, या zlib।
2. दिशा चुनें: संकुचित करें (टेक्स्ट इन → Base64/Hex आउट) या विसंकुचित करें (Base64/Hex इन → टेक्स्ट आउट)।
3. आउटपुट एन्कोडिंग चुनें: Base64 या Hex (विसंकुचित मोड में यह चयनक लॉक रहता है, क्योंकि औज़ार एन्कोडिंग स्वतः पहचानता है)।
4. बाईं ओर इनपुट पैनल में चिपकाएँ; इनपुट आकार उसके हेडर में दिखता है। परिणाम आउटपुट पैनल भरता है, उसका आकार भी हेडर में।
5. एक संकुचित करने के बाद, पहले/बाद की पट्टी दिखती है, जो बताती है कि पेलोड कितना बढ़ा या घटा। परिणाम लेने के लिए कॉपी, या उसे .gz फ़ाइल के रूप में सहेजने के लिए डाउनलोड का उपयोग करें। नमूना एक आम लॉग पंक्ति लोड करता है; साफ़ करें सब कुछ रीसेट करता है।

प्रमुख विशेषताएँ#

• तीन एल्गोरिदम, एक नियंत्रण। gzip, deflate, और zlib के बीच स्विच करें और ठीक देखें कि रैपर ओवरहेड उसी इनपुट के लिए आउटपुट आकार कैसे बदलता है।
• ईमानदार आकार तुलना। पहले/बाद की पट्टी वास्तविक बाइट गणना और चिह्नित प्रतिशत बदलाव दिखाती है — उस मामले सहित जहाँ कम्प्रेशन पेलोड को बड़ा बना देता है, जो gzip के बारे में जानने योग्य सबसे उपयोगी बात है।
• विसंकुचित पर स्वतः एन्कोडिंग पहचान। Base64 या Hex चिपकाएँ और औज़ार समझ जाता है कि कौन सा है, इसलिए आपको याद रखना नहीं पड़ता।
• वापसी पर सख्त UTF-8। यदि विसंकुचित बाइट्स वैध UTF-8 नहीं हैं (ग़लत एल्गोरिदम चुना, कटा हुआ पेलोड), तो औज़ार ऐसा कहता है बजाय प्रतिस्थापन कैरेक्टर्स निकालने के जो गलती छिपाएँ।
• आपके ब्राउज़र में चलता है। कम्प्रेशन स्थानीय रूप से एक छोटी, आलसी से लोड होने वाली लाइब्रेरी द्वारा चलता है; आप जो चिपकाते हैं वह पेज से बाहर नहीं जाता।

कार्य उदाहरण#

एकल छोटी लॉग पंक्ति संकुचित करना — नमूना इनपुट 2026-08-06 INFO request handled path=/api/stats status=200 (58 बाइट्स) — gzip और Base64 आउटपुट के साथ देता है:

H4sIAHcNdmoAAzMyMDLTNbDQNTBT8PRz81coSi0sTS0uUchIzEvJSU1RKEgsybDVTyzI1C8uSSwpVgCRpcW2RgYGACs/7EA6AAAA

पहले/बाद की पट्टी प्रति-अंतर्ज्ञानी हिस्से को उजागर करती है: सादे टेक्स्ट के वे 58 बाइट्स gzipped और Base64-एन्कोड होने के बाद 75 बाइट्स बन जाते हैं। इनपुट DEFLATE के संकुचित करने के लिए कुछ ढूँढने हेतु बहुत छोटा और बहुत यादृच्छिक था, इसलिए gzip हेडर, ट्रेलर, और Base64 ओवरहेड (लगभग 33%) बस ऊपर जमा हो जाते हैं। यही कारण है कि छोटे पेलोड gzip करना व्यर्थ है।

पुनरावृत्त टेक्स्ट के विरुद्ध इसकी तुलना करें। पंक्ति transaction_id=txn_00001 status=paid amount=100 currency=usd\n की आठ प्रतियाँ कुल 488 बाइट्स हैं, और gzip उन्हें 84 बाइट्स तक लाता है — मूल का लगभग 17%। यहीं कम्प्रेशन अपनी कमाई कमाता है: जितनी ज़्यादा पुनरावृत्ति, उतना गहरा सिकुड़ना।

उसी छोटी लॉग पंक्ति को deflate पर स्विच करने से आउटपुट 57 बाइट्स (कोई हेडर/ट्रेलर नहीं) और zlib 63 बाइट्स पर आता है — काम का जब आप किसी विशिष्ट वायर फ़ॉर्मेट को लक्षित कर रहे हों और दूसरे सिरे से बिलकुल मेल खाना हो।

अक्सर पूछे जाने वाले प्रश्न#

gzip, deflate, या zlib — मुझे क्या चुनना चाहिए?#

दूसरी ओर से मिलान करें। .gz फ़ाइलों, HTTP Content-Encoding: gzip, और लगभग हर “संकुचित” API पेलोड के लिए gzip उपयोग करें। deflate केवल तभी उपयोग करें जब कोई API स्पष्ट रूप से कच्चा DEFLATE दस्तावेज़ीकृत करता हो (कुछ लीगेसी Content-Encoding: deflate सर्वर)। zlib जब कोई लाइब्रेरी या प्रोटोकॉल इसे स्पष्ट रूप से नाम दे। संदेह हो तो gzip सुरक्षित डिफ़ॉल्ट है।

मेरा आउटपुट इनपुट से बड़ा है। क्या वह कोई बग है?#

नहीं — यही छोटे या उच्च-एन्ट्रॉपी इनपुट पर लॉसलेस कम्प्रेशन काम करता है। प्रति स्ट्रीम एक नियत ओवरहेड (हेडर, ट्रेलर, डिक्शनरी वार्म-अप) होता है, और यदि सामग्री में थोड़ी पुनरावृत्ति हो तो DEFLATE उसे पुनर्प्राप्त नहीं कर सकता। एक व्यावहारिक नियम: gzip कुछ सौ बाइट्स या अधिक के पेलोड पर भरोसेमंद ढंग से जीत शुरू करता है, विशेष रूप से पुनरावृत्ति वाले टेक्स्ट पर। छोटे वैल्यूज़ के लिए कम्प्रेशन छोड़ दें।

विसंकुचित मुझे बताता है कि डेटा वैध UTF-8 नहीं है। क्या गलत हुआ?#

आमतौर पर तीन में से एक: आपने ग़लत एल्गोरिदम चुना (डेटा zlib-संकुचित था पर आपने gzip चुना, या इसका उल्टा), Base64/Hex कट गया या उसके बीच में फुटकर व्हाइटस्पेस है, या मूल टेक्स्ट नहीं बल्कि बाइनरी था। क्रम में दूसरे एल्गोरिदम आज़माएँ, और जाँचें कि चिपकाए गए पेलोड को कुछ छोटा नहीं गया।

क्या यह छवियों, वीडियो, या पहले से ज़िप की गई फ़ाइलों को संकुचित कर सकता है?#

आप कुछ भी चिपका सकते हैं, पर आपको शायद ही कुछ मिलेगा। JPEG, PNG, MP4, और .zip/.gz जैसे फ़ॉर्मेट पहले से संकुचित हैं, इसलिए DEFLATE के पास निचोड़ने के लिए कुछ बचता ही नहीं — आउटपुट लगभग उतना ही आकार या थोड़ा बड़ा होगा। gzip टेक्स्ट और संरचनात्मक डेटा का औज़ार है, बाइनरी मीडिया पर दूसरी पास का नहीं।