لماذا تتعطل ملفات CSV المُصدَّرة من جداول البيانات عند تحويلها

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

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

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

كل قيمة منفردة في ملف CSV خام تُخزَّن كنص عادي، دون أي طريقة مدمجة للإشارة إلى ما إذا كانت قيمة معينة رقمًا "حقيقيًا"، أو قيمة منطقية، أو مجرد سلسلة نصية تبدو رقمية بالمصادفة — وهذا يصبح مشكلة حقيقية بمجرد أن تحاول أداة تحويل أن تكون مفيدة باستنتاج الأنواع تلقائيًا. فرمز بريدي مثل "007" أو معرّف مثل "042" له صفر بادئ ذو دلالة معنوية — فهو معرّف بعرض ثابت، و"7" و"007" معرّفان مختلفان رغم أنهما يمثلان الرقم نفسه — لكن أداة تحويل تحلل بحماس السلاسل النصية التي تبدو رقمية إلى أرقام فعلية تُسقط بصمت ذلك الصفر البادئ، لأن الرقم 7 ليس له أي مفهوم لعدد الأصفار التي كانت تسبقه. ورقم هاتف مثل "+966 55 000 0000" يبدو رقميًا جزئيًا لكنه ليس بيانات حسابية على الإطلاق، وتحويله إلى رقم ينتج شيئًا عديم المعنى فعلًا. والخيار الافتراضي الآمن والصحيح هو ترك القيم الغامضة كنص ما لم تكن القيمة رقمية بشكل آمن لا لبس فيه، لأن التخمين الخاطئ هنا يتلف البيانات بصمت بدلًا من إطلاق خطأ ظاهر يمكن رصده.

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