محوّل JSON إلى YAML (وبالعكس)

ما محوّل JSON إلى YAML؟

محوّل JSON إلى YAML أداة تحوّل بين الصيغتين في الاتجاهين: من JSON إلى YAML، ومن YAML إلى JSON، دون أي خطوة وسيطة ولا حاجة إلى رفع الملف إلى خادم. تلصق النص في حقل الإدخال، فتظهر النتيجة فورًا في اللوحة المقابلة.

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

كيف تستخدم الأداة

1. اختر الاتجاه: بدّل بين «JSON → YAML» و«YAML → JSON» بحسب الصيغة التي تملكها والصيغة التي تريد الوصول إليها.
2. الصق نصك أو جرّب مثالًا جاهزًا: الصق JSON أو YAML في حقل الإدخال، أو اضغط «تحميل مثال» لتجربة الأداة فورًا دون نص جاهز لديك، ثم اختر المسافة البادئة المناسبة.
3. انسخ الناتج وراجع التنبيهات إن ظهرت: اضغط «نسخ» لنقل النتيجة إلى الحافظة، واقرأ لوحة التنبيهات لتعرف بالتحديد ما ضاع أو تغيّر قبل أن تعتمد على الناتج.

ما الذي ينجو من التحويل وما الذي يضيع

كل مستند JSON صالح هو أصلًا YAML صالح، فالتحويل من JSON إلى YAML يحافظ على البنية والقيم كلها، ولا يستثنى من ذلك إلا الأعداد الكبيرة جدًا الموضّحة بعد قليل. أما الاتجاه المعاكس فهو موطن المفاجآت المعروفة في عالم YAML، وأشهرها ما يُعرف بـ«مشكلة النرويج»: في نسخة YAML 1.1 القديمة كانت الكلمة المجردة NO — رمز الدولة — تُقرأ تلقائيًا على أنها القيمة المنطقية false، وهو خطأ تسبب فعليًا في أعطال حقيقية. وهذه الأداة تعتمد مخطط core في YAML 1.2، حيث تبقى NO نصًا عاديًا كما تبقى yes وno وon وoff، ولا يُقرأ منطقيًا إلا true وfalse بأي حالة أحرف. وللسبب نفسه تبقى قيمة مثل 12:30 نصًا بدل أن تتحول إلى الرقم 750 كما كانت تفعل النسخة القديمة، ويبقى 2024-01-15 نصًا لا تاريخًا.

لكن هناك ما يضيع فعلًا، وأولها صورة كتابة الأرقام: يتحول 1.10 إلى 1.1، ويتحول 0123 إلى 123، لأن كل رقم يمر عبر تمثيله العددي المجرد الذي لا يحتفظ بالأصفار الزائدة في البداية أو النهاية. وهذا يضرب بالذات أرقام الإصدارات؛ فإن أردت الحفاظ على الصورة الأصلية، ضع القيمة بين علامتَي اقتباس قبل التحويل. والمشكلة نفسها تتفاقم مع الأعداد الصحيحة الكبيرة جدًا في كلا الاتجاهين: ما يتجاوز نحو 2⁵³ لا يمكن تمثيله بدقة تامة، فيخرج عدد مثل 12345678901234567890 بصورة 12345678901234567000. ومعظم المحوّلات تفعل هذا بصمت دون أن تخبرك، أما هذه الأداة فتكتشف الحالة وتسمّي لك المفتاح الذي وقع فيه التغيير بالتحديد، مثل rows[0].id، وتعرض القيمة الأصلية إلى جانب ما صارت إليه.

وهناك أشياء أخرى تفقدها حين تحوّل من YAML إلى JSON. التعليقات أولًا، لأن JSON لا يملك صيغة تعليق أصلًا، فأي تعليق في ملف YAML يختفي بلا أثر، وتنبّهك الأداة إلى ذلك. وهي تميّز السياق فلا تطلق إنذارًا كاذبًا: علامة # داخل نص بين علامتَي اقتباس ليست تعليقًا، وسطر #!/bin/sh داخل كتلة حرفية هو محتوى سكربت لا تعليق. والمراسي والأسماء البديلة ثانيًا: يتيح YAML تعريف قيمة مرة واحدة بعلامة &اسم وإعادة استخدامها بعلامة *اسم، وهي ميزة لا نظير لها في JSON، فتُفكَّك عند التحويل ويتكرر المحتوى نفسه في كل موضع كان يشير إليها، وتضيع المعرفة بأنها كانت مرتبطة أصلًا.

وثلاث حالات تُرفَض صراحةً بدل التخمين: الملفات متعددة المستندات المفصولة بـ ---، وهي شائعة جدًا في ملفات Kubernetes، إذ لا يملك JSON نظيرًا لتيار من عدة مستندات، فتطلب الأداة تحويل مستند واحد في كل مرة؛ والمفاتيح المكررة، إذ يُذكر رقم سطرها بدل الاكتفاء بآخر قيمة بصمت؛ والمسافة البادئة بـ Tab، فمواصفة YAML لا تجيزها.

متى تحتاج فعلًا إلى هذه الأداة

تحتاج إلى هذا التحويل كل مرة تلتقي فيها الصيغتان: حين يصلك رد JSON من واجهة برمجية وتريد وضعه في ملف إعداد YAML يقرأه تطبيقك، أو حين تريد تحويل ملف YAML إلى JSON لتغذية سكربت أو أداة لا تفهم إلا JSON. فأنظمة التكامل المستمر مثل GitHub Actions وGitLab CI تكتب إعداداتها بصيغة YAML، وكذلك ملفات Kubernetes وDocker Compose، بينما تُخرج كثير من الواجهات البرمجية نتائجها بصيغة JSON فقط. ومواصفات OpenAPI تُكتب أحيانًا بإحدى الصيغتين وتحتاج تحويلها إلى الأخرى لتعمل مع أداة معينة.

لماذا هذه الأداة مجانية؟

تعمل هذه الأداة بالكامل داخل متصفحك، فلا تكلّف أي معالجة على خادم، ولهذا لا حاجة إلى فرض رسوم عليها. لا حساب ولا تسجيل، ولا رفع لأي ملف إلى أي خادم، ولا علامة مائية على الناتج، ولا حد لعدد مرات الاستخدام.