أداة مقارنة JSON (Diff)

الصق مستندَي JSON وشاهد بالضبط ما تغيّر بينهما - كل مفتاح أُضيف أو حُذف أو تغيّر، في أي عمق، محدَّدًا بمساره الدقيق مثل user.address.city أو items[2].price. على عكس مقارنة النص العادية، لا يُحتسب ترتيب المفاتيح أو إعادة تنسيق المسافات كفرق هنا أبدًا - فقط البيانات الفعلية تُحتسب.

4 فروقات+2 أُضيف~2 تغيّر
  • أُضيفdiscontinued

    + false

  • تغيّرprice

    − 19.99

    + 24.99

  • أُضيفtags[2]

    + "sale"

  • تغيّرversion

    − "1.2.0"

    + "1.3.0"

المقارنة تتم حسب البنية، لا حسب السطر - إعادة ترتيب المفاتيح أو إعادة تنسيق المسافات لا تظهر أبدًا كفرق، فقط التغييرات الحقيقية في البيانات تظهر.

الأسئلة الشائعة

كيف يختلف هذا عن مقارنة النص العادية؟

تقارن أداة مقارنة النص (مثل أداة مقارنة الفروق في النص الخاصة بهذا الموقع) كتلتَي نص سطرًا بسطر - فهي لا تعرف ما هو JSON، لذا فإن إعادة تنسيق مستند، أو إعادة ترتيب مفاتيحه، أو تغيير المسافة البادئة، يُظهر جدارًا من الأسطر المتغيرة حتى عندما تكون البيانات الأساسية متطابقة. تُحلّل هذه الأداة أولاً كلا الجانبين كـ JSON حقيقي، ثم تقارن البنى الناتجة - لذا فإن {"a":1,"b":2} ونسخة منسّقة يظهر فيها "b" قبل "a" يُبلَّغ عنهما بشكل صحيح بأنه لا فرق بينهما. تُعرض فقط الإضافات والحذوفات والتغييرات الفعلية في القيم.

ما الفرق بين قيمة "متغيّرة" وقيمة "تغيّر نوعها"؟

"متغيّرة" تعني أن القيمة في ذلك المسار لا تزال من نفس نوع JSON لكن بقيمة مختلفة - رقم انتقل من 5 إلى 6، أو نص انتقل من "مسودة" إلى "منشور". "تغيّر نوعها" يعني أن النوع نفسه مختلف - حقل كان قيمة منطقية (boolean) أصبح الآن نصًا، أو رقم أصبح null. هذا التمييز مهم جدًا عمليًا: تغيير النوع أكثر عرضة بكثير لكسر أي كود يقرأ ذلك الحقل (دالة تتوقع قيمة منطقية ستسيء التصرف إذا تلقت فجأة نصًا)، لذا تُشير إليه هذه الأداة بشكل منفصل بدلاً من خلطه مع تحديث قيمة عادي.

كيف تتم مقارنة المصفوفات؟

عنصرًا بعنصر، بالترتيب: الفهرس 0 مقابل الفهرس 0، الفهرس 1 مقابل الفهرس 1، وهكذا، مع الإبلاغ عن أي عناصر إضافية في نهاية المصفوفة الأطول كمُضافة أو محذوفة. هذا بسيط ويمكن التنبؤ به، لكنه يعني أن إدراج عنصر جديد في منتصف مصفوفة سيجعل كل العناصر التالية تبدو متغيرة، حتى لو كانت في الواقع متطابقة - لأنها جميعًا انزاحت بموضع واحد. هذا قيد حقيقي في مقارنة المصفوفات المعتمدة على الموضع بشكل عام (وليس فقط في هذه الأداة)، لذا بالنسبة للمصفوفات التي قد يتغير ترتيبها، غالبًا ما يفيد التحقق مما إذا كانت العناصر المُبلَّغ عنها كـ "متغيّرة" مختلفة فعلاً أم أنها فقط انزاحت.

ماذا لو كان JSON الخاص بي غير صالح؟

تُعرض رسالة خطأ التحليل الدقيقة التي ينتجها محلل JSON الخاص بمتصفحك تحت مربع النص ذلك، بدلاً من الفشل بصمت أو عرض نتيجة قديمة. الأسباب الشائعة هي فاصلة زائدة بعد آخر عنصر في كائن أو مصفوفة (صالحة في حرفيات كائنات JavaScript، غير صالحة في JSON)، أو علامات اقتباس مفقودة حول اسم مفتاح، أو تعليق شارد - فـ JSON لا يملك أي صياغة للتعليقات على الإطلاق، على عكس JavaScript أو JSON5.

هل يمكنني استخدام هذا لمقارنة استجابات API؟

نعم، وهذا أحد أكثر الاستخدامات فائدة: الصق استجابة تم التقاطها قبل تغيير ما وأخرى بعده، وسيتم تمييز كل حقل أُضيف أو حُذف أو - وهذا الأهم - تغيّر نوعه. حقل يتغيّر بصمت من رقم إلى نص، أو من قيمة منطقية إلى null، هو بالضبط نوع التغيير المُخِلّ الذي يسهل تفويته بالعين المجردة في حمولتين كبيرتين، لكنه يظهر هنا فورًا كإدخال منفصل بعنوان "تغيّر نوعها".

هل يهم ترتيب ظهور المفاتيح؟

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

هل تُرسل بيانات JSON الخاصة بي إلى أي مكان؟

لا. يُحلَّل المستندان ويُقارَنان بالكامل داخل متصفحك باستخدام JavaScript خالص - لا شيء يُرفع إلى أي خادم، لذا يمكنك بأمان لصق استجابات API حقيقية، أو ملفات تكوين، أو بيانات أخرى لا تريدها أن تغادر جهازك.

هل يمكنني مقارنة ملفات JSON كبيرة جدًا؟

تتعامل الأداة بسهولة مع استجابات API وملفات التكوين النموذجية - من بضعة أسطر إلى عدة آلاف - لأن المقارنة بأكملها تعمل بشكل متزامن داخل تبويب متصفحك. بالنسبة للمستندات الضخمة حقًا (عشرات الميغابايتات)، قد يصبح المرور التكراري عبر كل مفتاح وفهرس مصفوفة بطيئًا بشكل ملحوظ؛ وإذا حدث ذلك، عادةً ما يفيد تقليص كلا المستندين إلى القسم الذي يهمك فعلاً قبل المقارنة.

هل يمكن أن يحل هذا محل git diff لملفات تكوين JSON؟

إنهما يجيبان عن سؤالين مختلفين ويعملان معًا بشكل جيد بدلاً من أن يكونا بديلَين لبعضهما. مقارنة نظام التحكم بالإصدار نصية - تُظهر الأسطر الدقيقة التي تغيّرت في الملف، بما في ذلك إعادة التنسيق، أو إعادة المسافة البادئة، أو أداة تدقيق تُعيد ترتيب المفاتيح، وكل ذلك لا تعتبره هذه الأداة فرقًا حقيقيًا. تجيب هذه الأداة عن سؤال أضيق، وغالبًا أكثر فائدة، بعد أن يكون منسِّق أو ملف مُولَّد تلقائيًا قد لمس شيئًا ما: هل تغيّر التكوين فعليًا، أم تغيّر تنسيقه فقط؟ تشغيل الأداتين معًا على commit مشبوه طريقة سريعة للتمييز بين "لا داعي للقلق، مجرد إعادة تنسيق" و"هذا يغيّر السلوك فعلاً".

ماذا لو كان للمستندين نوعان جذريان مختلفان، مثل مصفوفة مقابل كائن؟

يعمل هذا رغم ذلك - إذا اختلف المستوى الأعلى نفسه في الشكل (كائن في جانب، ومصفوفة في الآخر، أو قيمة بدائية مقابل أي منهما)، فيُبلَّغ عن ذلك كفرق واحد على مستوى الجذر بدلاً من أن تفرض الأداة مقارنة لا معنى لها. نفس المنطق الذي يُشير إلى تغيّر نوع حقل متداخل يُطبَّق على الجذر: يُعامَل كأكثر أنواع الاختلاف جوهريةً الذي يمكن أن يحدث بين مستندَي JSON.

هل تتحقق هذه الأداة من صحة JSON أو تنسّقه أيضًا؟

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

أدوات ذات صلة