كيف تتحقق من JSON قبل استخدامه

فاصلة في غير مكانها أو قوس إغلاق مفقود أو مفتاح غير مقتبس قد يتسبب في فشل طلب API كامل أو نشر إعدادات أو استيراد بيانات بصمت أو بخطأ غامض. يتحقق المطورون ومهندسو DevOps ووكلاء الدعم وفرق التكامل من صلاحية حمولات JSON كخطوة أولى لتصحيح الأخطاء لأن أخطاء الصيغة هي الأكثر شيوعاً والأسهل في الإصلاح.

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

تجيب صلاحية JSON عن سؤال واحد: هل يمكن تحليل هذه السلسلة كـ JSON؟ يمرر المدقق المدخل إلى محلل JSON. إذا نجح التحليل فالبنية صالحة. وإذا فشل، يشير الخطأ غالباً إلى أول موضع توقفت فيه الصيغة عن مطابقة قواعد JSON.

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

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

النص {"name":"Ada"} صالح لأن المفتاح مقتبس والقيمة النصية مقتبسة. أما {"name":"Ada",} فهو غير صالح لأن JSON لا يسمح بفاصلة زائدة بعد الخاصية الأخيرة.

مجموعة القواعد: JSON صالح = يقبل المحلل المدخل كله. JSON غير صالح = يرمي المحلل خطأ قبل الوصول إلى قيمة JSON مكتملة. مثال التحقق مما إذا كانت صياغة JSON صحيحة صغير عمداً حتى يمكن فحص الحساب أو التحويل يدوياً قبل الاعتماد على نتيجة آلية أسرع.

قد يحتوي مستند JSON صالح على بيانات عمل خاطئة. يفحص التحقق الصيغة لا المخطط ولا الحقول المطلوبة ولا القيم المسموحة ولا عقود API الخاصة. استخدم تحقق المخطط عندما تهم قواعد الحقول.

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

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

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

الصق JSON في مدقق JSON من TOOLFINA قبل إرساله إلى API أو حفظ إعدادات أو مشاركة حمولة في الدعم. اقرأ حالة صالح/غير صالح وانسخ النص المنسق فقط بعد نجاح الصيغة.

المدخلات: نص JSON. المخرجات: حالة الصلاحية مع JSON منسق، أو حالة عدم الصلاحية مع رسالة خطأ. لا يتصل المدقق بالـ API الذي سيستهلك الحمولة لاحقاً.

يعمل التحقق داخل المتصفح دون رفع الحمولة. يطبق الفحص عبر الموقع هذه العملية داخل المتصفح: يتم تحليل النص كـ JSON لاكتشاف الفواصل أو علامات الاقتباس أو الأقواس أو القيم غير الصحيحة. استخدم النتيجة كنقطة فحص واضحة، ثم قارنها بالقاعدة أو المنصة أو المستند أو السياسة التي تتحكم في مهمتك الفعلية.

ولنتائج أقوى، نسّق JSON الصحيح بعد ذلك لتسهيل فحص البيانات المتداخلة. وأخيراً، احتفظ برسالة الخطأ ونسخة الحمولة عند تصحيح مشكلة تكامل متكررة. الخطوة التالية بسيطة: افتح أداة TOOLFINA المرتبطة، وأدخل المدخلات المجهزة، وراجع تسميات المخرجات، واحتفظ بالقيمة النهائية مع ملاحظاتك إذا كانت النتيجة ستستخدم لاحقاً.

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