تصغير JSON

تتم إزالة المسافات البيضاء فقط

تسمح قواعد JSON بالمسافات وعلامات التبويب والأسطر الجديدة بين أي رمزين، ولا يحمل أي منها معنى. التصغير هو إسقاط كل حرف من تلك الأحرف الاختيارية: {"a": 1, "b": 2} يصبح {"a":1,"b":2}. القيمة التي تم تحليلها متطابقة بايتًا ببايت في الذاكرة، ولهذا فإن هذه العملية آمنة دائمًا للتطبيق على الحمولة قبل إرسالها.

ما لا يفعله التصغير هو ضغط البيانات. أسماء المفاتيح ومحتويات السلاسل والدقة الرقمية كلها محفوظة تمامًا. إذا كان مستندك كبيرًا لأنه يكرر نفس أسماء الحقول العشرين عبر عشرة آلاف سجل، فإن التصغير سيحذف المسافات البادئة لكنه سيترك التكرار دون مساس — فهذه مهمة لـ gzip أو لمخطط مختلف.

عندما يكون التوفير مهمًا حقًا

في استجابة API نموذجية مطبوعة بشكل جميل، تشكل المسافات البيضاء ما بين 10% و30% من الحجم الخام. يبدو ذلك مفيدًا حتى تتذكر أن كل استجابة HTTP تقريبًا مضغوطة بالفعل بـ gzip أو brotli أثناء النقل، وأن خوارزميات الضغط تتعامل مع تتابعات المسافات بكفاءة عالية. بعد gzip، غالبًا ما يكون الفرق بين JSON المصغّر والمُنسّق أقل من 2%.

لا يزال التصغير مفيدًا في ثلاث حالات: البيانات المضمّنة مباشرة في صفحة HTML أو حزمة JavaScript حيث لا تُضغط بشكل منفصل؛ والتخزين في عمود قاعدة بيانات أو ذاكرة تخزين مؤقت حيث تكون السلسلة الخام هي ما يشغل المساحة؛ وأي مكان تحسب فيه الأحرف مقابل حد ثابت، مثل معامل URL أو حقل رسالة بسقف ثابت.

فرز المفاتيح للمقارنة

كائنات JSON غير مرتبة رسميًا، لكن كل أداة تسلسل تكتب المفاتيح بترتيب محدد ما، ونادرًا ما تختار نظامان نفس الترتيب. وهذا يجعل المقارنة النصية لمستندين متطابقين منطقيًا غير مقروءة.

فرز المفاتيح بشكل متكرر قبل الإخراج يعطي المستندين نفس الشكل المعياري، بحيث يُظهر فرق الأسطر أخيرًا التغييرات الحقيقية فقط. إنها نفس الحيلة المستخدمة في البناء القابل للتكرار والتخزين المؤقت الموجه بالمحتوى. ضع في اعتبارك أن الفرز يغير إخراج البايتات، لذا فإن المستند المرتب لم يعد مطابقًا لما أنتجه النظام المصدر — استخدمه للمقارنة، وليس لإعادة توقيع الإخراج.