مصغّر JSON

التصغير تحليل يتبعه إعادة تسلسل بلا إزاحة. ويبدو ذلك طريقًا ملتويًا لإزالة المسافات، والبديل هو سبب فعله هكذا.

ونزع الفراغ بمطابقة نمط يُفسد البيانات. فالتعبير النمطي الذي يزيل المسافات لا يميّز المسافة في { "a": 1 } عن المسافة في {"name": "Sara Haddad"}. أما التحليل فيزيل النوع الأول ولا يستطيع مسّ الثاني، لأن السلسلة عندئذ قيمة لا نصّ.

ويعني ذلك أيضًا أن JSON غير الصالح يُرفض بدل أن يُشوَّه في صمت. فالمصغّر الذي يعمل بمطابقة الأنماط سينتج مخرجات من ملف مكسور براحة بال، ولا يظهر الكسر إلا لاحقًا.

والتوفير عادةً بين 15% و30% في JSON المُزاح، وهو أقلّ ممّا يتوقّعه الناس — لأنه على الشبكة يتبعه ضغط gzip أو brotli، وهما بارعان جدًّا في إزالة الفراغ المتكرّر أصلًا.

تضمّن كائن إعداد في صفحة وتريده أصغر ما يمكن. اضغط حمّل عيّنة: 340 بايت منسَّقًا، و232 مصغَّرًا، أي توفير نحو 32%.

والآن التحفّظ الذي يستحق المعرفة قبل التحسين لأجله. فحين يُقدَّم عبر HTTP مع gzip، يُضغط الملف نفسه إلى الحجم نفسه تقريبًا سواء صُغِّر أم لا — فتتابعات المسافات المتكرّرة هي بالضبط ما تزيله خوارزميات الضغط أولًا. وتصغير JSON الذي سيُضغط بـgzip يوفّر حفنة بايتات لا ثلثًا.

وحيث ينفع فعلًا: JSON مضمَّن في سمة HTML أو في عنوان بيانات، أو مخزَّن في عمود قاعدة بيانات، أو مرسَل عبر اتّصال بلا ضغط، أو محفوظ في localStorage، الذي له حدّ حجم صارم يُقاس بالسلسلة الخام.

ونقطة الأمان عمليًا. الصق {"greeting": "hello world"} بثلاث مسافات داخل السلسلة. تبقى في المخرجات المصغَّرة ثلاث مسافات. فهي بيانات. أما المصغّر القائم على التعابير النمطية فكان سيطويها ويغيّر القيمة.

وللاتجاه الآخر، المنسّق يوسّعه من جديد ويبلّغ عن موضع أي خطأ صياغي بالضبط.