CSV أم JSON أم XML: أي صيغة تصدير تختار؟

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

CSV و JSON و XML كلها تستطيع نقل البيانات، لكنها لا تخدم نفس النوع من العمل. CSV ممتاز للجداول المسطحة. JSON ممتاز للبيانات المتداخلة التي تقرأها التطبيقات. XML ممتاز عندما تكون هناك عقود صارمة أو أنظمة قديمة أو مستندات منظمة. المشكلة لا تكون عادة في أن الصيغة سيئة، بل في استخدامها في المكان الخطأ.

هذا الدليل يقارن بينها من زاوية عملية: متى تستخدم كل صيغة، أين تتعبك، وكيف تختار بدون فلسفة زائدة.

نفس البيانات بثلاث صيغ

لنفترض أن لدينا عميلا واحدا:

id,name,email,plan,active
42,Amina Shah,amina@example.com,pro,true

هذه صيغة CSV. صف واحد، أعمدة واضحة، وسهل فتحه في أي برنامج جداول.

نفس البيانات في JSON:

{
  "id": 42,
  "name": "Amina Shah",
  "email": "amina@example.com",
  "plan": "pro",
  "active": true
}

ونفسها في XML:

<customer>
  <id>42</id>
  <name>Amina Shah</name>
  <email>amina@example.com</email>
  <plan>pro</plan>
  <active>true</active>
</customer>

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

CSV: صيغة الجداول التي يفهمها الجميع

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

استخدم CSV عندما تكون البيانات مسطحة: عملاء، منتجات، طلبات، معاملات، مخزون، كلمات مفتاحية، روابط، أو سجلات بسيطة. إذا كان الشخص الذي سيستلم الملف غير تقني، فغالبا CSV هو الطريق الأسهل. يفتحه في Excel أو Google Sheets، يفلتر، يرتب، يعدل، ثم يرفعه إلى CRM أو أداة تسويق أو لوحة تقارير.

قوة CSV أنه اجتماعي أكثر من كونه تقنيا. الجميع تقريبا يعرف كيف يتعامل معه. لا يحتاج أحد إلى شرح ما هو كائن أو مصفوفة. لا توجد أقواس كثيرة. ولا يحتاج المستلم إلى محرر مخصص.

لكن CSV ضعيف في الأنواع. كل شيء يبدأ كنص، ثم تحاول البرامج التخمين. قد يتحول رقم طويل إلى صيغة علمية. قد يختفي الصفر من بداية رقم الهاتف أو الرمز البريدي. قد يتغير التاريخ حسب لغة الجهاز. وقد تقرأ الأداة 00123 كأنه 123، وبعدها تبدأ رسائل "لماذا تغيرت البيانات؟".

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

المشكلة الثالثة هي البيانات المتداخلة. إذا كان لكل عميل عدة اشتراكات، فماذا تفعل؟ هل تكرر صف العميل؟ هل تضع الاشتراكات في أعمدة مثل subscription_1 و subscription_2؟ هل تنشئ ملفين وتربطهما بواسطة customer_id؟ كل حل ممكن، لكنه يحتاج توثيقا واضحا.

CSV مناسب للتقارير والاستيراد الجماعي والجداول البسيطة. لكنه ليس مكانا مريحا للبنى المعقدة.

JSON: الصيغة الطبيعية للتطبيقات

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

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

ميزة JSON أنه يحافظ على المعنى أفضل من CSV. القيمة true منطقية، وليست نصا يشبه المنطق. المصفوفة مصفوفة، وليست قائمة مفصولة بفواصل داخل خلية. الكائن المتداخل واضح، وليس مجموعة أعمدة بأسماء طويلة.

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

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

لهذا تستخدم بعض الأنظمة صيغة JSON Lines، حيث يكون كل سطر كائنا مستقلا:

{"id":1,"event":"signup"}
{"id":2,"event":"purchase"}

هذه ليست وثيقة JSON واحدة، لكنها عملية جدا للسجلات والتدفق والتحليلات.

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

XML: الصيغة الرسمية للعقود والمستندات

XML أقدم وأكثر كلاما من JSON. لكنه لم يختف لأنه يحل نوعا مختلفا من المشاكل. XML قوي عندما تحتاج مستندا منظما، أو عقدا صارما، أو تكاملا مع نظام قديم، أو معيارا موجودا أصلا.

تجد XML في خرائط المواقع، RSS، SVG، ملفات Office، بعض أنظمة البنوك، بعض بوابات الحكومة، وأنظمة الشركات الكبيرة. أحيانا لا تختاره لأنه أجمل، بل لأن الجهة الأخرى تقول: "أرسل XML بهذه البنية بالضبط".

قوة XML في المخططات والصرامة. يمكن لـ XSD أن يحدد العناصر المطلوبة، ترتيبها، أنواعها، عدد مرات ظهورها، والقيم المقبولة. في بيئات منظمة أو حساسة، هذه الصرامة ميزة.

XML أيضا يتعامل مع النصوص التي تحتوي وسوما داخلية بطريقة طبيعية:

<description>استخدم <strong>ماء باردا</strong> مع القماش الحساس.</description>

هذا سهل في XML، لكنه غير مريح في JSON وغير مناسب إطلاقا لـ CSV.

العيب الواضح هو الطول. XML يكرر الوسوم كثيرا، فيكبر الملف. كما أن التعامل معه يحتاج انتباها للأمان، خصوصا عند قراءة XML من مصادر غير موثوقة. وهناك تفاصيل مثل namespaces والترتيب والعناصر الفارغة قد تسبب أخطاء غريبة في التكاملات.

XML مناسب عندما يطلبه المعيار، أو يكون لديك مستند منظم، أو تحتاج عقدا صارما، أو تتعامل مع نظام قديم يعتمد عليه.

مقارنة سريعة

لا تنظر للجدول كأنه مسابقة جمال. الصيغة الصحيحة هي التي تناسب شكل البيانات وطريقة استخدام المستلم.

أمثلة قرار واقعية

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

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

إذا كنت تبني API، استخدم JSON إلا إذا كان هناك معيار مختلف. هذا هو المتوقع في الويب الحديث.

إذا كنت تنشئ sitemap أو RSS feed، استخدم XML لأن النظام المحيط يتوقع XML.

إذا كانت جهة حكومية أو شركة شريكة أعطتك XSD، استخدم XML كما هو مطلوب. لا تحاول تحويل العقد إلى JSON لأنك تفضله. التكاملات لا تهتم بذوقك كثيرا.

إذا كان الملف موجها لمحلل بيانات يعمل في الجداول، CSV هو الأفضل. إذا كان موجها لمطور، اسأله: هل تريد بيانات مسطحة أم بنية كاملة؟

كيف تختار بدون حيرة

اسأل أولا: هل البيانات جدول؟ إذا نعم، CSV مرشح قوي. هل يوجد تداخل أو قوائم داخل السجل؟ إذا نعم، JSON أفضل. هل يوجد معيار خارجي أو عقد XML؟ إذا نعم، XML.

اسأل ثانيا: من سيفتح الملف أول مرة؟ شخص في Excel؟ CSV. سكربت أو API؟ JSON. مدقق schema أو نظام قديم؟ XML.

اسأل ثالثا: هل الملف سيعيش فترة طويلة؟ إذا نعم، وثق الحقول، الأنواع، التواريخ، المنطقة الزمنية، ومعنى القيم الفارغة. الصيغة وحدها لا تكفي.

نصائح عملية

في CSV، أضف صف عناوين دائما. لا تغير أسماء الأعمدة بلا سبب. لا تعتمد على Excel لفهم الأرقام الحساسة. استخدم مكتبة حقيقية للهروب من الفواصل والاقتباسات.

في JSON، حافظ على أسماء حقول ثابتة. لا ترسل رقما كنص إلا لسبب واضح. استخدم null عندما تكون القيمة مفقودة عمدا. وإذا كان الملف كبيرا جدا، فكر في JSON Lines.

في XML، التزم بالترتيب والمخطط المطلوب. لا تضف namespaces غير ضرورية. اقرأ XML بإعدادات آمنة. واختبره بالأداة التي يستخدمها الطرف المستقبل، لا بأداتك أنت فقط.

أخطاء تظهر بعد التسليم

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

في CSV، أكثر خطأ مزعج هو تغيير القيم بواسطة برنامج الجداول. رقم بطاقة أو SKU طويل قد يتحول إلى صيغة علمية. رقم هاتف يبدأ بصفر قد يفقد الصفر. تاريخ مثل 03/04/2026 قد يفسر كالثالث من أبريل أو الرابع من مارس حسب إعدادات المنطقة. الحل هو استخدام صيغ تاريخ واضحة مثل 2026-04-03، وتوثيق الحقول التي يجب معاملتها كنص، وتجربة الملف في نفس الأداة التي سيستخدمها المستلم.

في JSON، الخطأ الشائع هو تغيير النوع بدون قصد. ترسل id كرقم في إصدار، ثم كنص في إصدار آخر. ترسل items كمصفوفة فارغة، ثم ترسلها null. هذه تغييرات صغيرة في الشكل لكنها تكسر الكود الذي يعتمد على عقد ثابت. إذا كان API عاما أو بين فريقين، استخدم أمثلة واضحة ويفضل schema.

في XML، الأخطاء غالبا تكون في التفاصيل: ترتيب العناصر، namespace، عنصر مطلوب لكنه فارغ، أو attribute بدلا من element. بعض الأنظمة تقبل XML يبدو صحيحا في محررك لكنها ترفضه لأنه لا يطابق XSD بالضبط. هنا الاختبار ضد مخطط الجهة المستقبلة ضروري.

قائمة فحص قبل اختيار الصيغة

قبل أن تنشر export جديدا، مر على هذه الأسئلة. هل البيانات مسطحة فعلا، أم أنك تخفي تداخلا داخل أعمدة؟ هل المستلم إنسان أم برنامج؟ هل سيعدل الملف يدويا؟ هل توجد حقول حساسة للتفسير مثل IDs وتواريخ ومبالغ مالية؟ هل تحتاج أكثر من ملف لتمثيل العلاقات؟ هل هناك قيود حجم؟ هل تحتاج streaming؟ هل يوجد عقد خارجي أو معيار مفروض؟

إذا كانت الإجابات كلها تدور حول الجداول والبشر والاستيراد اليدوي، CSV مناسب. إذا كانت حول البنية والأنواع وواجهات API، JSON مناسب. إذا كانت حول التحقق الصارم والمعايير والأنظمة القديمة، XML مناسب.

ولا تنس أن التوثيق جزء من التصدير. ملف بلا شرح قد يعمل اليوم ويفشل بعد ستة أشهر عندما ينسى الجميع معنى عمود status_code أو هل التوقيت UTC أم بتوقيت محلي. أضف ملف README صغيرا أو صفحة توثيق فيها الحقول، الأنواع، أمثلة، ومعنى القيم الفارغة. هذه اللمسة البسيطة توفر رسائل كثيرة لاحقا.

الخلاصة

CSV هو جسر الجداول. JSON هو جسر التطبيقات. XML هو جسر العقود والمستندات والمعايير القديمة. الفريق الناضج لا يفرض صيغة واحدة على كل شيء، بل يستخدم CSV للتقارير، JSON للواجهات والبيانات المتداخلة، و XML عندما يطلبه النظام أو المعيار.

اختر حسب شكل البيانات والمستلم، لا حسب الصيغة التي تحبها. هذا القرار الصغير يوفر ساعات كثيرة من تنظيف البيانات لاحقا.