عند مقارنة مستندي JSON بديف نصي عادي (كما يُستخدم للكود)، تكون النتيجة مضللة غالبًا: يمكن كتابة نفس البيانات بترتيب مفاتيح مختلف، أو مسافات بادئة مختلفة، أو عدد مختلف من المسافات — وسيُظهر الديف النصي «فرقًا» حيث تكون البيانات في الواقع متطابقة.
المقارنة البنيوية
يحلّل JSON Diff البنيوي كلا المستندين إلى شجرة قيم ويقارن البيانات نفسها: هل يوجد حقل، وما القيمة التي يحملها، وهل يتطابق النوع. لا يُؤخذ ترتيب مفاتيح الكائن أو المسافات الزائدة أو نمط المسافات البادئة بعين الاعتبار — فهي ليست جزءًا من البيانات نفسها.
ما يُظهره الديف
تُبرز نتيجة المقارنة البنيوية النموذجية ثلاث فئات من التغييرات: حقول أُضيفت في المستند الثاني، وحقول حُذفت من الأول، وحقول موجودة في كليهما لكن بقيم مختلفة. المقارنة أعقد مع المصفوفات — يجب تقرير ما إذا كانت العناصر تُقارَن حسب الموضع أو تُطابَق الكائنات المتشابهة.
لماذا نحتاج ذلك
- مقارنة استجابة API قبل تغيير في الخلفية وبعده لرؤية التغييرات الفعلية في البيانات.
- التحقق من أن تغييرًا في ملف إعداد لم يمس أي شيء غير مقصود.
- اكتشاف تراجع في الاختبارات حيث يختلف JSON المتوقع عن الفعلي.
لماذا لا يعني اختلاف بنية ar.json عن en.json وجود خطأ
الإنجليزية تميّز بين صيغتين فقط للجمع (one/other)، بينما تعرّف قواعد CLDR للتعدد ست فئات مختلفة للعربية: zero وone وtwo وfew وmany وother — فكلمة واحدة قابلة للعدّ في الإنجليزية قد تحتاج في ar.json إلى ستة مفاتيح ترجمة منفصلة بدل اثنين فقط. عند مقارنة ملفات ترجمة i18next بين اللغتين، يجب أن يميّز الديف البنيوي بين مفتاح ناقص فعلاً (خطأ ترجمة حقيقي) وبين فارق بنيوي متوقع ناتج عن قواعد الجمع نفسها في العربية، وإلا فسيُبلغ عن عشرات «الأخطاء» الوهمية في كل ملف ترجمة.
مقارنة المصفوفات: حسب الموضع أم حسب المفتاح
أبسط نهج هو مقارنة عناصر المصفوفة فهرسًا بفهرس، لكن إذا أُدرج عنصر جديد في منتصف المصفوفة، «تنزاح» كل المواضع التالية ويُظهر الديف تغييرًا في كل عنصر بعد نقطة الإدراج، رغم أن عنصرًا واحدًا فقط تغيّر فعليًا. الأدوات الأذكى تحاول مطابقة العناصر بحقل فريد (مثل id) لتُظهر الإدراج أو الحذف الفعلي بدلاً من سلسلة تغييرات وهمية.