لماذا ضغط JSON؟
يسهل قراءة JSON المُنسَّق للبشر لكنه مُكلف في الإرسال. كل مسافة وسطر جديد وجدولة بايت إضافي. لاستجابة API عميقة التداخل قد تبلغ 4 كيلوبايت منسّقة، يُقلّص الضغط حجمها عادةً إلى 1–2 كيلوبايت — تخفيض بنسبة 50–75 % — دون أي تغيير في المعنى أو البنية.
يهم هذا التوفير في البيئات عالية الإنتاجية: واجهة API تخدم 10,000 طلب في الثانية توفر غيغابايتات من النطاق الترددي يومياً بمجرد حذف المسافات البيضاء. تتحسن تكاليف خروج CDN وميزانيات بيانات الجوال والوقت حتى أول بايت.
الضغط مفيد أيضاً عند تضمين JSON في HTML (داخل وسم script أو سمة data)، أو تخزينه في عمود قاعدة بيانات محدود الحجم، أو إدراجه في متغير بيئة. JSON المضغوط سطر واحد سهل النسخ واللصق بلا خطر أخطاء صياغية ناجمة عن كسر الأسطر.
ما الذي يغيّره الضاغط (وما لا يغيّره)
يُزيل الضاغط جميع المسافات البيضاء التي ليست جزءاً من قيمة سلسلة نصية: المسافات والجداول وفواصل الأسطر بين الرموز المميزة. لا يمس المسافات البيضاء داخل قيم السلاسل — سلسلة مثل "مرحبا بالعالم" تحتفظ بمسافتها الداخلية. لا يُعيد ترتيب المفاتيح ولا يُغير القيم.
المخرجات دائماً JSON صحيح وفق ECMA-404. يُحلّل الضاغط المدخلات أولاً للتأكد من أنها مُكوَّنة بشكل صحيح قبل إزالة المسافات؛ إن احتوت المدخلات على أخطاء صياغية ستظهر رسالة خطأ تحليل بدلاً من مخرجات تالفة.
مفهوم خاطئ شائع: الضغط قابل للعكس. تمرير المخرجات المضغوطة عبر مُنسّق JSON يُعيد نسخة مقروءة ومعقّدة. البيانات نفسها تُحفظ دائماً كاملة.
الضغط مقابل الانضغاط مقابل التشفير
يُزيل الضغط المسافات البيضاء المقروءة لكنه يترك بنية JSON مرئية بالكامل. الانضغاط (gzip وBrotli) يُطبّق خوارزمية إنتروبيا لتصغير تدفق البايتات أكثر، يُحقق عادةً تخفيضاً إضافياً بنسبة 70–90 %، لكن الناتج ثنائي وغير مقروء مباشرةً. التشفير يُحوّل البيانات إلى نص مشفر لا يُقرأ بدون مفتاح.
عملياً، أفضل استراتيجية هي الضغط أولاً ثم ترك خادم الويب أو CDN يُطبّق ضغط gzip/Brotli تلقائياً عبر رأس Content-Encoding. يُمكن أن يُقلّل الجمع بين الاثنين الحجم بنسبة 85–95 % مقارنةً بـ JSON منسّق غير مضغوط.
لا تخلط بين الضغط والتعتيم. JSON المضغوط يحتوي على أسماء المفاتيح والقيم الأصلية ويمكن قراءته بسهولة. إن كانت بياناتك حساسة استخدم HTTPS وفكّر في تشفير القيم نفسها.