يقلّل Gzip وDeflate حجم البيانات، لكن الناتج ثنائي وليس نصيًا. إذا احتاجت هذه البيانات المضغوطة إلى المرور عبر قناة مخصصة للنص (عنوان URL، ملف تعريف ارتباط، حقل JSON)، فإنها تُرمَّز إضافيًا بـ Base64 — ومن هنا يأتي الثنائي "Gzip/Deflate ↔ Base64"، الذي تستخدمه أدوات كثيرة لتعبئة حالة تطبيق كاملة داخل رابط قابل للمشاركة.
لماذا يضغط النص العربي بكفاءة رغم أن كل حرف يأخذ بايتين
كل حرف عربي يشغل بايتين في UTF-8 مقارنة ببايت واحد للحرف اللاتيني، وهو ما يوحي بأن النص العربي يجب أن يُضغط بشكل أسوأ. لكن الواقع مختلف: العربية غنية بالتكرار على مستوى الكلمات — أداة التعريف "الـ" تتكرر في بداية كلمات كثيرة، والحروف والصيغ الصرفية تتكرر بانتظام — وهذا التكرار هو بالضبط ما يستغله Gzip لاستبدال الأنماط المتكررة بمراجع أقصر، ما يعوّض التكلفة الإضافية للترميز الثنائي البايت.
الترتيب المعتاد للعمليات
- يُضغط النص الأصلي بـ Gzip أو Deflate — يقل الحجم.
- يُرمَّز الناتج الثنائي المضغوط بـ Base64 — يزداد الحجم قليلاً مرة أخرى، لكن البيانات تصبح نصًا.
- تُنقل السلسلة الناتجة بأمان عبر قناة نصية.
يحدث فك الترميز بالترتيب المعاكس: أولاً Base64 ← بيانات ثنائية، ثم فك ضغط Gzip/Deflate ← النص الأصلي.
حالات الاستخدام الشائعة
- تعبئة حالة تطبيق كاملة داخل عنوان URL بحيث يمكن مشاركة الرابط وإعادة فتحه كما تُرك تمامًا.
- تخزين بيانات مضغوطة في ملف تعريف ارتباط أو حقل نصي بقاعدة بيانات.
- التصحيح: فك ضغط وقراءة محتوى مُرمَّز بهذه الطريقة من قِبل نظام خارجي أو واجهة برمجية.
Gzip مقابل Deflate "الخام"
Gzip هو فعليًا صيغة غلاف حول خوارزمية Deflate: يضيف ترويسة خاصة به ومجموع تحقق (CRC32) فوق البيانات المضغوطة. لا يحتوي Deflate "الخام" على هذه البايتات الإضافية، لذا فالنتيجة أصغر قليلًا، لكن لا يمكن فك ضغطها بأداة gzip دون تحديد صراحةً أنها بصيغة raw. الخلط بين هذين البديلين سبب شائع لخطأ "invalid header" عند محاولة فك ضغط البيانات.