تخطَّ إلى المحتوى

تحقق من JSON الخاص بك

ليس مجرد صالح أو غير صالح — بل السطر والعمود والحرف، وما يجب فعله. لا يُخزَّن أي شيء؛ ويجري الفحص هنا مباشرةً.

  • لا يُخزَّن أبدًا
  • لا طابور ولا انتظار
  • دون تسجيل ودون علامة مائية
بعد التنسيق

الصق JSON وسيُفحص أثناء الكتابة.

كيف تعمل الأداة

1

الصق JSON

أو أفلِت الملف. يُقرأ في مكانه؛ ولا يُرسل أي شيء إلى أي مكان.

2

اقرأ النتيجة

صالح، مع إحصاء لما بداخله. أو غير صالح، مع تحديد الموضع بالضبط.

3

أصلح وأعد الفحص

عدّل في المكان نفسه وتتحدّث النتيجة أثناء الكتابة.

ما الذي يمنعه JSON فعلًا

قواعد JSON صغيرة جدًا عن قصد، وتكاد كل حالات فشل التحقق تكون واحدة من بضعة أشياء يستعيرها الناس من JavaScript ولم يعتمدها JSON قط. فاصلة زائدة بعد العنصر الأخير. علامات اقتباس مفردة بدل المزدوجة. مفاتيح غير محاطة بعلامات اقتباس. التعليقات — لا يوجد في JSON أي تعليقات، ولم يكن فيه قط. NaN وInfinity، وهما رقمان صالحان في JavaScript وغير صالحين في JSON. وعلامة ترتيب البايت (BOM) في البداية، غير المرئية في أي محرر، والتي تضيفها بعض أدوات Windows عند الحفظ بترميز UTF-8، فتجعل مستندًا سليمًا تمامًا يفشل عند أول حرف.

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

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

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

عندما تحتاج إلى شيء آخر

للتحقق من المستندات وفق مخطط لا وفق قواعد الصياغة، فإن JSON Schema هو المعيار وajv أسرع تطبيق له — سيخبرك بأن حقلًا مطلوبًا مفقود أو أن قيمة خارج النطاق، وهو السؤال الذي يشغلك عادةً فعلًا. وتُجري check-jsonschema الفحوص نفسها من سطر الأوامر وفي CI.

لأي شيء في سطر الأوامر، jq هي الأداة التي يجب أن تمتلكها: فالأمر jq empty file.json يتحقق ولا يطبع شيئًا عند النجاح، وهذا بالضبط ما يناسب سكربتًا، والأمر jq . ينسّق. وللملفات الأكبر من أن تُحفظ في الذاكرة، يحلل jq --stream وijson في Python بشكل تدريجي، وهذا ما لا تستطيعه أي صفحة تحمّل المستند كاملًا.

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

هل يُخزَّن JSON الخاص بي في أي مكان؟

لا. لا يوجد أي اتصال بخادم ولا أي تسجيل، ولا يُخزَّن أي شيء. يمكنك قطع الاتصال بالإنترنت بعد تحميل الصفحة وستستمر في العمل. وهذا أهم هنا مما يبدو: فما يلصقه الناس في أداة تنسيق عبر الإنترنت هو استجابات API وملفات إعدادات وحمولات أخطاء، وهذه تحمل عادةً رموزًا مميزة (tokens) وسجلات عملاء وأسماء خوادم داخلية.

بماذا تخبرني عندما يكون JSON معطوبًا؟

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

ما الذي يُعدّ صالحًا؟

المعيار RFC 8259، بصرامة. أي مفاتيح بين علامات اقتباس مزدوجة، ولا فواصل زائدة، ولا تعليقات، ولا أصفار بادئة أو أرقام ست عشرية في الأعداد. الصرامة هي الغاية من أداة التحقق: فلو قبلت ما سيرفضه المحلّل لديك، لما أخبرتك بشيء.

هل تتحقق من JSON الخاص بي وفق مخطط (schema)؟

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

لماذا تقول إنه صالح بينما لا يزال API الخاص بي يرفضه؟

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

هل تُفحص الأرقام الكبيرة بشكل صحيح؟

نعم، خانة بخانة — بينما تفسدها معظم أدوات التحقق بصمت. الرقم في JavaScript عدد عشري بـ 64 بت، فلا يستطيع حمل الأعداد الصحيحة بدقة إلا حتى 9,007,199,254,740,991. وأي رقم أكبر — معرّف منشور على Twitter/X، أو معرّف snowflake في Discord، أو رقم حساب بنكي، أو مفتاح قاعدة بيانات بـ 64 بت — يفقد خاناته الأخيرة لحظة مروره عبر `JSON.parse`. ويظل الرقم معقولًا في مظهره، وهذا ما يجعله خطيرًا: يصبح 7205759403792793600 بهدوء 7205759403792793000. تحتفظ هذه الصفحة بالخانات التي لصقتها كما هي تمامًا، وتخبرك بعدد الأرقام التي اضطرت إلى حمايتها.

هل يوجد حد للحجم؟

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

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

أضِف هذه الأداة إلى موقعك

مجانية لأي مدونة أو صفحة فصل دراسي أو مقالة مساعدة. الصق مقتطفًا واحدًا وسيتمكن زوارك من استخدامها مباشرةً على صفحتك.