مقال
التحويل بين CSV وXML وJSON وYAML: دليل عملي
CSV وJSON وXML وYAML هي التنسيقات الأربعة التي يصادفها المطورون أكثر من غيرها في خطوط معالجة البيانات وملفات الإعدادات وواجهات API. التحويل بينها سهل حين تتطابق نماذج البيانات، ومفاجئ في خسارته حين لا تتطابق. يغطي هذا الدليل ما يستطيع كل تنسيق تمثيله وما يعجز عنه، وأين تختفي المعلومات أثناء التحويل، ومزالق الترميز التي تسبب تلفاً صامتاً للبيانات. تتولى أداة data-converter في هذا الموقع التحويل بين ثلاثة من التنسيقات الأربعة (CSV وJSON وYAML) بالكامل داخل المتصفح؛ أما أقسام XML هنا فهي خلفية معرفية لحين نقل البيانات يدوياً أو باستخدام أداة منفصلة.
التنسيقات الأربعة ونماذج بياناتها
يُنظّم CSV البيانات على شكل شبكة مسطحة من الصفوف والأعمدة. يسمّي الصف الأول الأعمدة عادةً، وكل صف لاحق يمثّل سجلاً واحداً. لا يوجد تداخل، ولا معلومات عن الأنواع، ولا معيار يتجاوز النص العادي في الخلايا. كل قيمة سلسلة نصية ما لم يفرض التطبيق المستهلك نوعاً معيناً. يُمثّل JSON البيانات على شكل شجرة من الكائنات (خرائط مفتاح-قيمة) والمصفوفات. يمكن أن تكون القيم سلاسل نصية أو أرقاماً أو قيماً منطقية أو null أو كائنات متداخلة أو مصفوفات بأي عمق. يتيح ذلك لمستند JSON واحد تمثيل سجل عميل مع كائنات عنوان مضمّنة ومصفوفات بنود وإجماليات رقمية ذات نوع محدد. يُمثّل XML البيانات على شكل شجرة من العناصر. يمكن لكل عنصر أن يحمل سمات مسمّاة ويحتوي على عناصر فرعية أو محتوى نصي. لا يوجد نوع رقمي أو منطقي مدمج؛ كل شيء نص. يمكن لمخططات مثل XSD فرض الأنواع عند التحقق، لكن تنسيق الإرسال دائماً بيانات أحرف. يستخدم YAML المسافات البادئة للتعبير عن نفس نموذج الكائنات والمصفوفات الذي يستخدمه JSON، بصياخ أكثر وضوحاً للقراءة البشرية. YAML هو مجموعة شاملة تحتوي JSON: أي مستند JSON صالح يُعدّ أيضاً YAML صالحاً. يضيف YAML سلاسل نصية متعددة الأسطر وتعليقات ومراجع المرساة والاسم المستعار للكتل المتكررة. شائع YAML في ملفات الإعدادات، بينما JSON شائع في استجابات API.

التحويلات الخسرانة: التسطيح وغموض XML
أكثر التحويلات الخسرانة شيوعاً هو تسطيح JSON أو XML المتداخل إلى CSV. لا يمكن تعيين كائن JSON يحتوي على حقل عنوان متداخل بشكل نظيف إلى صف CSV. الحل الشائع هو أسماء أعمدة بصيغة النقطة: يصبح customer.address.city عموداً مستقلاً. يعمل هذا مع مستوى واحد من التداخل، لكنه يفشل تماماً حين تظهر مصفوفة. عميل لديه ثلاثة أرقام هاتف يتطلب إما ثلاثة أعمدة منفصلة (تثبيت العدد الأقصى مسبقاً) أو تقسيم البيانات إلى ملف CSV ثانٍ أو ترميز المصفوفة كسلسلة محدودة داخل خلية واحدة. لا يُعيد أيٌّ من هذه الخيارات البيانات بدقة إلى JSON الأصلي دون بيانات وصفية إضافية. يُدخل XML غموضاً منفصلاً: الاختيار بين السمة والعنصر الفرعي. يمكن تخزين القيمة Paris كسمة (<city name="Paris">) أو كعنصر فرعي (<city><name>Paris</name></city>). حين يقرأ محوّل XML وينتج JSON، يجب أن يقرر كيف يعيّن السمات. تشمل الاصطلاحات الشائعة إضافة البادئة @ لمفاتيح السمات أو وضعها تحت مفتاح "_attributes". الاختيار غير موحّد، مما يعني أن محوّلَين يقرآن نفس XML قد ينتجان JSON مختلف هيكلياً. إذا كنت تخطط للتنقل ذهاباً وإياباً بين XML وJSON، حدّد اصطلاحاً قبل البدء.
مزالق CSV: المحددات والاقتباس والترميز
لا يوجد لـ CSV معيار رسمي واحد، بل RFC 4180 فقط كمرجع واسع الاستشهاد. أشيع محدد هو الفاصلة، لكن الفاصلة المنقوطة (شائعة في اللغات الأوروبية حيث تُستخدم الفواصل كفواصل عشرية) والتبويبات (TSV) والأنابيب تظهر جميعها في الممارسة العملية. ملف يُسمّى .csv قد يستخدم أياً من هذه دون إشارة. حين تحتوي قيمة حقل على المحدد نفسه، يتطلب RFC 4180 تغليف الحقل بعلامتي اقتباس مزدوجتين: "San Francisco, CA". يجب مضاعفة علامة الاقتباس المزدوجة داخل حقل مقتبس للتهريب: "He said ""hello""". يجب أيضاً اقتباس حقل يحتوي على سطر جديد حرفي. المحللون الذين يتخطون هذه الخطوة ينتجون أخطاء في عدد الصفوف يصعب تتبعها. الترميز مزلق منفصل. غالباً ما تحمل ملفات CSV من أدوات Windows علامة ترتيب بايت UTF-8 BOM (ثلاثة بايتات EF BB BF في بداية الملف). تساعد BOM برنامج Excel على تحديد الترميز، لكن كثيراً من محللي لغات البرمجة يعاملون BOM كجزء من اسم العمود الأول، منتجين عموداً مسمى "id" بدلاً من "id". يكسر هذا أي كود لاحق يبحث عن الأعمدة بالاسم. عند قراءة ملف CSV برمجياً، احذف BOM قبل التحليل، أو استخدم مكتبة تتعامل معها صراحةً.

اختيار التنسيق: الإعدادات والتبادل وجداول البيانات
يتحدد اختيار التنسيق عادةً بالسياق لا بالتفضيل الشخصي. JSON هو الافتراضي لواجهات REST API وتبادل البيانات بين المتصفح والخادم. إنه مضغوط، يُحلَّل بشكل أصلي في كل لغة برمجة، ويحمل معلومات النوع للأرقام والقيم المنطقية. ضعفه هو غياب التعليقات، مما يجعله غير مناسب للملفات التي يقرأها المطورون ويحررونها يدوياً. يُفضَّل YAML لملفات الإعدادات (مانيفستات Kubernetes وتعريفات خطوط CI وكتب تشغيل Ansible) لأنه يتيح تعليقات مضمّنة وأسهل قراءة من JSON مع مستويات كثيرة من التداخل. خطره الرئيسي هو أن أخطاء المسافات البادئة صامتة: مفتاح بمسافة بادئة خاطئة ينتقل إلى نطاق مختلف دون أي خطأ في التحليل. لا يزال XML معياراً في أنظمة المؤسسات القديمة وخدمات SOAP وتنسيقات المستندات (DOCX وSVG وRSS) والسياقات التي تتطلب التحقق من المخطط أو توضيح مساحة الأسماء. إنه مطوّل، لكن أدوات XPath وXSLT ناضجة. CSV هو الخيار الصحيح حين تكون البيانات مسطحة فعلاً والمستهلك تطبيق جداول بيانات أو محلل بيانات. غير مناسب للإعدادات أو تبادل API لأنه لا يحتوي نظام أنواع ولا تداخل.
التحويل محلياً باستخدام data-converter
تُحلّل أداة data-converter على هذا الموقع وتحوّل بين CSV وJSON وYAML بالكامل داخل المتصفح؛ ولا تقرأ XML أو تكتبه. لا تُرسل أي بيانات إلى خادم في أي وقت. يعمل التحويل في بيئة تشغيل JavaScript المحلية، والمخرجات متاحة للتنزيل أو النسخ دون أن يغادر شيء جهازك. يهم هذا للبيانات التي لا تملك حق مشاركتها: استجابات API تحتوي على معلومات شخصية، ملفات إعدادات بأسماء مضيفين داخلية، أو صادرات CSV من قواعد بيانات داخلية. لصق تلك البيانات في محوّل قائم على الويب يعمل على خادم يعني إرسال المحتوى عبر الشبكة ومعالجته على أجهزة لا تتحكم فيها. مع data-converter، علامة تبويب المتصفح هي بيئة المعالجة. تطبّق الأداة اقتباس RFC 4180 عند قراءة CSV أو كتابته، وتتوقع مصفوفة مسطّحة من الكائنات عند تحويل JSON أو YAML إلى CSV: قيمة كائن أو مصفوفة متداخلة تحت مفتاح ما لا تخضع لتسطيح تلقائي بصيغة النقطة، فسطِّح تلك الحقول بنفسك قبل التحويل إذا احتجت إليها كأعمدة منفصلة. وإذا احتجت إلى نقل بيانات من XML أو إليه، حوّلها إلى JSON أو YAML بأداة XML متخصصة أولاً، ثم استورد النتيجة إلى هنا.
الأدوات المذكورة في هذا المقال
الأسئلة الشائعة
هل يمكنني تحويل JSON عبر CSV والحصول على الأصل مجدداً؟
فقط إذا كان JSON مصفوفة مسطحة من الكائنات بلا حقول متداخلة ولا مصفوفات كقيم. بمجرد وجود كائن متداخل أو قيمة مصفوفة، يتطلب تمثيل CSV قراراً هيكلياً (أعمدة بصيغة النقطة أو صفوف متعددة أو سلاسل مشفرة) لا يمكن عكسه تلقائياً. إذا كانت بياناتك متداخلة، فإن JSON وXML وYAML تدور ذهاباً وإياباً بشكل نظيف؛ أما CSV فلا.
لماذا يبدو ملف CSV خاطئاً في Excel بعد التصدير من تطبيق أوروبي؟
غالباً ما تستخدم اللغات الأوروبية الفاصلة المنقوطة كمحدد CSV لأن الفواصل محجوزة للترميز العشري. يتوقع Excel في اللغات الأوروبية الفاصلات المنقوطة. إذا استخدم الملف فواصل، يعامل Excel الصف بأكمله كعمود واحد. الحل إما تغيير المحدد في إعدادات التصدير، أو استخدام معالج استيراد البيانات في Excel الذي يتيح تحديد المحدد يدوياً. مشكلة UTF-8 BOM منفصلة: بدون BOM، قد يقرأ Excel أيضاً الأحرف ذات التشكيل الخاطئ كنص مشوه.
ما الفرق العملي بين YAML وJSON؟
كلاهما يمثّل نفس نموذج البيانات الأساسي: كائنات ومصفوفات وسلاسل نصية وأرقام وقيم منطقية وnull. يضيف YAML تعليقات (أسطر تبدأ بـ #) وحرفيات سلاسل متعددة الأسطر ومراجع المرساة للكتل المتكررة. JSON هو مجموعة فرعية صارمة من YAML الصالح، لكن محللي JSON لا يقرأون YAML. القاعدة العملية: استخدم JSON لحمولات API وتخزين البيانات؛ استخدم YAML لملفات الإعدادات التي يحررها البشر والتي تستفيد من التعليقات المضمّنة.