محوّلات البيانات

نقل البيانات بين CSV وJSON وYAML وXML

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

تعمل محوّلات Speedor كلياً في متصفحك. تلصق، تنقر، تنسخ النتيجة. لا شيء يُرفع، ولا شيء يُسجَّل، ولا شيء يغادر جهازك. ولكل من تردّد يوماً قبل إسقاط تصدير عملاء في موقع عشوائي، فإن ذلك التصميم المحلي فقط هو المقصود.

فيمَ تجيد كل صيغة فعلاً

يساعد أن تعرف لماذا وُجدت هذه الصيغ قبل أن تبدأ التنقّل بينها، لأن كلاً منها بُني لمهمة مختلفة.

CSV هي الشبكة المسطّحة المفصولة بفواصل التي تعشقها جداول البيانات. إنها جدولية بطبيعتها: صفوف وأعمدة، لا تداخل. افتحها في إكسل أو Google Sheets أو Numbers وتعمل ببساطة. والمأخذ أن CSV لا مفهوم لديها للأنواع. فالقيمة 007 قد تكون نصاً أو رقماً أو رمزاً بريدياً، ولن تخبرك CSV بأيّها.

JSON هي اللغة المشتركة للويب الحديث. وكل API ستستدعيه تقريباً يتحدّثها. تتعامل JSON مع التداخل والمصفوفات وحفنة من الأنواع الحقيقية (نصوص وأرقام وقيم منطقية وnull)، مما يجعلها أكثر تعبيراً بكثير من جدول مسطّح. إنها مدمجة وودودة للآلة ومدعومة في كل مكان.

YAML هي ابنة عمّ JSON الأكثر قابلية للقراءة. تستخدم الإزاحة بدل الأقواس، وتدعم التعليقات، وتميل إلى أن تكون الصيغة المفضّلة لملفات الإعداد وDocker Compose وملفات Kubernetes وخطوط التكامل المستمر. وحين يضطر إنسان إلى تحرير شيء يدوياً، تكون YAML عادةً أرفق بالعينين.

XML هي الشيخ المخضرم. مُسهبة وكثيرة الوسوم وما زالت متجذّرة بعمق في أنظمة المؤسسات وخدمات SOAP والرسائل المالية ومعايير المستندات مثل RSS. ستلتقي بها أقلّ في المشاريع الجديدة، لكن حين تحتاجها فعلاً، تحتاجها بشدة.

أين تحدث التحويلات فعلاً

السيناريوهات ملموسة جداً حالما تبدأ بالنظر. لنقُل إن التسويق سلّمك جدول بيانات بـ 4000 جهة اتصال، وAPI التسجيل لا يقبل سوى مصفوفة JSON. تُصدّر الورقة إلى CSV، تمرّرها عبر CSV إلى JSON، وتحصل على حمولة جاهزة للإرسال بطلب POST. دون سكربت لصق، ولا pandas، ولا انتظار مهندس.

أو تسحب قطعة من JSON من ذلك API نفسه وتريد إسقاطها في ملف إعداد تقرؤه خدمتك عند الإقلاع. حوّلها بـ JSON إلى YAML فتحصل على شيء نظيف وقابل للتعليق يلائم مستودعك. ويعمل الاتجاه الآخر أيضاً حين لا تقبل أداة سوى JSON لكن إعدادك يعيش بـ YAML.

ثم هناك التكامل الذي لا يستمتع به أحد: نظام شريك لا يبتلع سوى XML. تبني حمولتك بـ JSON لأن هكذا يفكّر تطبيقك، ثم تحوّل إلى XML عند الحدّ. يبقى الشكل نفسه، ويتغيّر النحو فقط.

المطبّات التي يجدر معرفتها

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

CSV تنسى الأنواع. لأن كل خانة مجرّد نص، تخرج الأرقام والقيم المنطقية والتواريخ كلها كنصوص ما لم يخمّن المحوّل لك. فإن كان true يجب أن يكون قيمة منطقية لا كلمة «true»، فتحقّق من المُخرَج قبل الإرسال.

YAML تهتمّ بالمسافات البيضاء. الإزاحة ليست تجميلية في YAML، بل بنيوية. ومسافة شاردة واحدة قد تغيّر إلى أي مفتاح تنتمي قيمة، والتبويبات (tabs) ممنوعة تماماً. وبعد أي رحلة ذهاب وإياب من JSON إلى YAML، يُجدي تفحّص سريع، أو أعد تمرير النتيجة عبر منسّق JSON للتأكد من نجاة البنية.

XML وJSON لا تتطابقان بنظافة. فلـ JSON مصفوفات؛ ولـ XML عناصر متكرّرة. ولا سمات في JSON إطلاقاً؛ بينما لـ XML سمات في كل مكان. تختار معظم المحوّلات اتفاقاً معقولاً، لكن إن استخدم XML لديك السمات بكثرة، فإن JSON الناتج سيبدو مختلفاً قليلاً عن JSON المكتوب يدوياً. وهذا متوقّع لا خلل.

عمق التداخل يهمّ. CSV مسطّحة، فلا يمكن دائماً طيّ JSON عميق التداخل إلى أعمدة دون تسطيح المفاتيح (فكّر بـ address.city). وفي الاتجاه الآخر، تصير CSV المسطّحة مصفوفة مسطّحة، لا شجرة أبداً.

لماذا يهمّ هنا أن تكون محلية فقط

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

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