ملف CSV ليس مجرد نص عادي ── الممارسة العملية لملفات CSV في تطبيقات C# (ترميز الأحرف وتوافق Excel والحماية من الحقن)

يظل تبادل البيانات عبر CSV اليوم لاعبًا أساسيًا حاضرًا بقوة في عالم تطبيقات الأعمال. ولأنه يبدو للوهلة الأولى مجرد “نص مفصول بفواصل”، فإنه أيضًا مجال تتكرر فيه أعطال من قبيل: انهيار المحلل المخصص (Parser) بسبب وجود فاصلة داخل الحقل نفسه، وتشوّه النصوص عند الفتح في Excel، واختفاء الصفر البادئ من رقم الهاتف.

في هذا المقال، وبافتراض تطبيق أعمال يقرأ ويكتب ملفات CSV بلغة C#، سنستعرض مواصفات CSV (RFC 4180) واللهجات الواقعية لها، وكيفية تحديد ترميز الأحرف، ومشكلات التوافق مع Excel، والحماية من الحقن عبر CSV، ومكامن الخطأ التشغيلية، مرتبة حسب الترتيب الذي يواجه فيه الممارسون صعوبة في اتخاذ القرار.

1. الخلاصة أولًا (جدول القرار)

يُشتق قرار تصميم ملف CSV بالعكس انطلاقًا من “من (أو ما) الذي سيفتح هذا الملف”.

نكتب الخلاصة أولًا:

• تحليل CSV باستخدام String.Split(',') ينهار من الناحية المواصفاتية حتى وإن بدا أنه يعمل. والسبب أنه لا يستطيع معالجة الفاصلة أو السطر الجديد أو علامة الاقتباس عندما توجد داخل الحقل نفسه. إن أردت البقاء ضمن نطاق مكتبات .NET القياسية، استخدم TextFieldParser (الفصل 3).
• أعطال ترميز الأحرف تحدث بسبب طريقة تفسير Excel للملف. الخيار الآمن حاليًا لملفات CSV التي يفتحها الأشخاص في Excel هو UTF-8 مع BOM. وهناك فخ في .NET وهو أن وجود BOM من عدمه يختلف حسب طريقة تحديد Encoding (الفصل 4).
• في .NET (Core) لا يمكن استخدام Shift_JIS دون حزمة إضافية. لا ينجح Encoding.GetEncoding("shift_jis") إلا بعد تسجيل CodePagesEncodingProvider من حزمة System.Text.Encoding.CodePages. وهذه نقطة نموذجية يظهر فيها استثناء لأول مرة في بيئة الإنتاج عند معالجة CSV التي تم ترحيلها من .NET Framework.
• فقدان الصفر البادئ وتحوّل القيم إلى تواريخ لا يمكن منعهما من جهة CSV. والحقيقة المهمة هنا أن إحاطة القيمة بعلامتي اقتباس مزدوجتين لا تمنع ذلك أيضًا (الفصل 5).
• التطبيقات التي تُخرج مدخلات المستخدم إلى CSV تحتاج إلى الحماية من الحقن عبر CSV. فالحقول التي تبدأ بـ = أو + يفسّرها Excel كصيغة حسابية (الفصل 6).

2. “مواصفات” CSV ── RFC 4180 واللهجات الواقعية

يوجد لملف CSV معيار فعلي هو RFC 4180¹. القواعد الأربع التالية فقط هي ما يجب مراعاته عمليًا:

1. الفاصل بين السجلات هو السطر الجديد (CRLF)، والفاصل بين الحقول هو الفاصلة.
2. إذا احتوى الحقل على فاصلة أو سطر جديد أو علامة اقتباس مزدوجة، يجب إحاطة الحقل بأكمله بعلامتي اقتباس مزدوجتين.
3. علامة الاقتباس المزدوجة داخل الحقل نفسه تُهرَّب بتكرارها مرتين على الشكل "".
4. الحقول التي لا تحتاج إلى إحاطة يمكن إحاطتها أو تركها دون إحاطة، حسب الرغبة.

بمعنى آخر، السطر التالي هو سجل مكوّن من ثلاثة حقول:

1001,"株式会社サンプル 営業部","住所は""東京都○○区1-2-3""です,と入力された備考"

وبما أن RFC 4180 هو “معيار فعلي” فحسب، فإن لملفات CSV الواقعية لهجات كثيرة: سطر جديد بحرف LF فقط، عدم معالجة علامات الاقتباس، فاصل بعلامة تبويب أو فاصلة منقوطة، ووجود صف العناوين أو غيابه. ولهذا السبب، فإن النص في مستند مواصفات التكامل على عبارة “متوافق مع RFC 4180”، بالإضافة إلى تحديد ترميز الأحرف ووجود BOM ورمز نهاية السطر ووجود صف العناوين من عدمه، هو أكثر الأعمال جدوى من حيث التكلفة مقابل الفائدة في منع المشكلات لاحقًا.

3. لا تبنِ محللًا مخصصًا باستخدام Split(‘,’) ── ممارسة القراءة

بناءً على القواعد المذكورة في الفصل السابق، يتضح سبب انهيار String.Split(','). إذ تنقسم البيانات بشكل زائد بسبب الفاصلة الموجودة داخل الحقل، وينقطع السطر في منتصفه بسبب السطر الجديد الموجود داخل علامتي الاقتباس. وحقيقة أن “الملف الوارد حاليًا لا يحتوي بيانات فيها فواصل، لذا يعمل الكود” لا تعني شيئًا، إذ يمكن أن ينهار في أي وقت حسب البيانات.

إن أردت القراءة الصحيحة ضمن نطاق مكتبات .NET القياسية، يمكن استخدام Microsoft.VisualBasic.FileIO.TextFieldParser. ورغم أن مساحة الاسم (Namespace) تعود إلى Visual Basic، إلا أنه يُستخدم بشكل عادي من C# أيضًا.

using Microsoft.VisualBasic.FileIO; // Microsoft.VisualBasic.Core (مضمّنة في SDK الخاص بتطبيقات سطح مكتب Windows)

using var parser = new TextFieldParser(path, System.Text.Encoding.UTF8)
{
    TextFieldType = FieldType.Delimited,
    HasFieldsEnclosedInQuotes = true, // معالجة الحقول المحاطة بعلامات اقتباس بشكل صحيح
    TrimWhiteSpace = false, // القيمة الافتراضية هي true (تتم إزالة الفراغات في بداية ونهاية القيمة بصمت). عطّل هذا الخيار عندما تحمل الفراغات دلالة في البيانات
};
parser.SetDelimiters(",");

while (!parser.EndOfData)
{
    try
    {
        string[]? fields = parser.ReadFields();
        if (fields is null) break;
        // معالجة fields[0], fields[1], ... إلخ
    }
    catch (MalformedLineException ex)
    {
        // سطر تالف: يمكن تسجيل محتواه ورقمه عبر ErrorLine / ErrorLineNumber
        logger.LogWarning("السطر رقم {Line} في ملف CSV غير صالح الصيغة: {Content}",
            ex.LineNumber, parser.ErrorLine);
    }
}

الميزة العملية لـ TextFieldParser، إلى جانب معالجة علامات الاقتباس (HasFieldsEnclosedInQuotes)، هي القدرة على اكتشاف الأسطر التالفة مع رقم السطر عبر MalformedLineException. ففي استيراد ملفات CSV بتطبيقات الأعمال، غالبًا ما يكون الفيصل في المواصفات هو “هل يُرفض الملف بأكمله عند تلف سطر واحد، أم يُتخطى ذلك السطر فقط مع الإبلاغ عنه؟”، ويمكن نقل تصميم معالجة هذا الاستثناء مباشرة إلى المواصفات.

إذا احتجت إلى ربط الأعمدة بالكائنات وتحويل الأنواع والأداء مع ملايين الصفوف، فمن الأفضل النظر في اعتماد مكتبة CSV موثوقة (من المكتبات المستخدَمة على نطاق واسع في NuGet). وأيًّا كانت المكتبة المختارة، فالنقاط الأربع الواجب التحقق منها هي: “معالجة علامات الاقتباس وفق RFC 4180”، و”تحديد ترميز الأحرف”، و”التعامل مع الأسطر التالفة”، و”إمكانية القراءة عبر البث (Streaming)”.

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

// يجب تجميع منطق التهريب في جانب الكتابة في هذه الدالة الواحدة فقط
static string ToCsvField(string? value)
{
    value ??= string.Empty;
    bool needsQuoting = value.Contains(',') || value.Contains('"')
        || value.Contains('\r') || value.Contains('\n');
    return needsQuoting ? $"\"{value.Replace("\"", "\"\"")}\"" : value;
}

فحتى وجود موضع واحد فقط يُستخدم فيه string.Join مكتوب يدويًا خصيصًا لعمود المبلغ المالي، كافٍ لأن يتحول ذلك الموضع إلى مصدر عطل مستقبلي.

4. ترميز الأحرف ── سلوك Excel وفخاخ .NET

4.1 استخدم UTF-8 مع BOM عند الفتح في Excel

معظم حالات تشوّه النصوص في ملفات CSV تحدث بسبب خطأ Excel في تحديد ترميز الملف. فعند فتح ملف CSV بترميز UTF-8 بدون BOM (العلامة المكوّنة من عدة بايتات في بداية الملف) بالنقر المزدوج، قد يُفسَّر في بعض البيئات على أنه ANSI (أي Shift_JIS في البيئة اليابانية)، فتُتلف الأحرف اليابانية بالكامل. أما مع وجود BOM في UTF-8، فيُتعرَّف عليه بشكل صحيح كـ UTF-8، ولذا فإن الخيار الآمن حاليًا هو استخدام UTF-8 مع BOM لملفات CSV التي يفتحها الأشخاص بالنقر المزدوج في Excel.

وهنا يضاف إلى ذلك فخ من جهة .NET. يختلف وجود BOM من عدمه حسب طريقة تمرير Encoding.

// UTF-8 بدون BOM: هذا هو الافتراضي عند عدم تحديد الترميز
File.WriteAllText(path, csv);

// UTF-8 مع BOM: الخاصية الثابتة Encoding.UTF8 مضبوطة لإخراج BOM
File.WriteAllText(path, csv, Encoding.UTF8);

// إن أردت توضيح النية بشكل صريح، فالتحديد عبر الباني (Constructor) لا يترك مجالًا لسوء الفهم
File.WriteAllText(path, csv, new UTF8Encoding(encoderShouldEmitUTF8Identifier: true));

اختلاف الملف الناتج عند تمرير Encoding.UTF8 مقارنة بحذفه هو أمر لا يمكن ملاحظته دون معرفة مسبقة به. فإذا قررتَ في المواصفات “بدون BOM للتكامل بين الأنظمة” و”مع BOM لما يُخصص لـ Excel”، يُنصح بتوضيح النية في الكود أيضًا عبر new UTF8Encoding(...).

4.2 استخدام Shift_JIS في .NET (Core) يتطلب تسجيلًا مسبقًا

في التكامل مع الأنظمة القديمة، ما زال ملف CSV بترميز Shift_JIS (صفحة الرموز 932) حاضرًا حتى اليوم. والمهم هنا أن .NET (Core) و.NET 5 وما بعده لا تدعم افتراضيًا سوى مجموعة محدودة جدًا من الترميزات مثل عائلة Unicode وASCII. فـ Encoding.GetEncoding("shift_jis") يُطلِق استثناءً إلى أن تُضاف حزمة System.Text.Encoding.CodePages ويُسجَّل CodePagesEncodingProvider.

using System.Text;

// يُسجَّل مرة واحدة فقط عند بدء تشغيل التطبيق (مثلًا في Program.cs)
Encoding.RegisterProvider(CodePagesEncodingProvider.Instance);

// وبهذا يمكن الحصول على Shift_JIS (صفحة الرموز 932)
Encoding sjis = Encoding.GetEncoding("shift_jis");

وهذه نقطة عطل نموذجية: تطبيق تم ترحيل معالجة CSV الخاصة به من .NET Framework إلى .NET، ثم يُطلق استثناءً لأول مرة في بيئة الإنتاج عند استلام ملف بترميز Shift_JIS. لخصنا نقاط التحقق عند الترحيل في مقال “ما الذي يجب التحقّق منه قبل ترحيل .NET Framework إلى .NET”.

كذلك، ما دام استخدام Shift_JIS قائمًا، فلا مفر من مواجهة مشكلات الأحرف الخاصة بالجهاز (مثل ① و㈱)، ومشكلة الشرطة المتموجة (波ダッシュ)، وفقدان الأحرف التي لا توجد إلا في Unicode. وقد شرحنا أساسيات ترميز الأحرف بهذا الخصوص بالتفصيل في مقالي “فهم ترميزات النصّ على Windows” و”شرح ترميزات النصّ ونهايات السطور في Windows”.

5. بيانات تتلف عند فتحها في Excel ── فقدان الصفر البادئ، وتحوّل القيم إلى تواريخ، والترميز الأسي

حتى مع ضبط ترميز الأحرف بشكل صحيح، تظل هناك مجموعة أخرى من المشكلات عند المعاينة في Excel، وهي أن Excel “يفسّر” القيم عند فتح ملف CSV.

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

الحلول العملية المتاحة ثلاثة:

1. توجيه المستخدم لفتح الملف عبر الإجراء الصحيح في Excel. فبدلًا من النقر المزدوج، يمكن القراءة دون تلف عبر “استيراد البيانات (من نص/CSV)” في Excel مع تحديد نوع العمود كـ “نص”. ويستحق هذا الأمر أن يُدوَّن في دليل التشغيل.
2. إخراج ملف xlsx إذا كان الهدف الرئيسي هو المعاينة. إذ يتيح ذلك للجهة المُصدِرة التحكم في تنسيق الخلايا، مما يُزيل هذه المجموعة من المشكلات من جذورها. راجع طريقة إنشاء ملفات Excel في مقال “كيف تبني إخراج تقارير Excel”. ويُذكر أن أتمتة Excel عبر COM على الخوادم أو الخدمات غير موصى بها، إذ إنها تُعد أرضًا خصبة لبقاء العمليات عالقة، كما ورد في مقال “مشكلة بقاء EXCEL.EXE في التشغيل الآلي عبر COM في C#“، لذا يُفضَّل اعتماد الإخراج القائم على المكتبات البرمجية.
3. الإخراج بصيغة ="007" هو الملاذ الأخير. فهذه حيلة تجعل القيمة تظهر كنص عند فتحها في Excel، لكن الملف من منظور CSV يتحول إلى “ملف غير قياسي يحتوي صيغًا حسابية”، مما يُتلف أي جهة استيراد أخرى غير Excel. لا تستخدم هذا الأسلوب في الملفات المشتركة بين عدة أنظمة.

6. الحقن عبر CSV ── لا تحوّل مدخلات المستخدم إلى صيغ حسابية

بالنسبة للتطبيقات التي تُخرج قيمًا أدخلها المستخدم (كالاسم والملاحظات والعنوان) إلى ملف CSV يُفتح لاحقًا في Excel، توجد ثغرة هجومية تُعرف باسم الحقن عبر CSV. فالحقول التي تبدأ بـ = أو + أو - أو @ يفسّرها Excel كصيغ حسابية، مما يعني أن مدخلات ضارة (مثل صيغة تستهدف تشغيل عملية خارجية على غرار =cmd|'/C calc'!A0) قد تُنفَّذ في بيئة مستخدم آخر فتح ذلك الملف.

الأساس في الحماية هو تحييد الحرف الأول الخطر عند الإخراج.

// إضافة علامة اقتباس أحادية في بداية الحقول التي قد تُفسَّر كصيغة حسابية.
// في البيئة اليابانية، قد تُفسَّر الرموز ＝＋－＠ (بعرض كامل) أيضًا كبداية صيغة حسابية، لذا يجب إدراجها ضمن القائمة
static string SanitizeForExcel(string value)
{
    if (value.Length > 0 && value[0]
        is '=' or '+' or '-' or '@' or '\t' or '\r' or '\n'
        or '＝' or '＋' or '－' or '＠')
    {
        return "'" + value;
    }
    return value;
}

علامة الاقتباس الأحادية في البداية تُعد إشارة لـ Excel لمعاملة القيمة “كنص”. ويُلاحظ أن قائمة الأحرف الأولى الخطرة قد تختلف حسب تطبيق أو إصدار برنامج جداول البيانات المستخدَم، لذا فإن تصميم عملية التحييد هذه على أساس “السماح بالمرور مباشرة فقط إذا كان الحرف الأول ضمن قائمة سماح محددة (كالأحرف الأبجدية الرقمية مثلًا)” يجعلها أكثر مقاومة لأي حالة غير متوقعة. غير أنه يجب الانتباه إلى أن علامة الاقتباس الأحادية ستبقى ضمن البيانات إذا استوردت أنظمة أخرى هذا الملف نفسه، ولذا قد يكون من المنطقي أحيانًا فصل الملف إلى نسخة “للفتح في Excel” وأخرى “للاستيراد إلى الأنظمة”. وفيما يخص إمكانية الجمع بين هذا الإجراء وبين التحقق من صحة المدخلات (مثل عدم السماح أساسًا بأن يبدأ الإدخال بعلامة =)، راجع تصميم الأمان الشامل للتطبيق في مقال “قائمة تحقّق للحدّ الأدنى من الأمان في تطوير تطبيقات Windows”.

7. مكامن الخطأ التشغيلية ── أعطال تحدث خارج نطاق تنسيق الملف نفسه

أخيرًا، نلخّص النقاط التي تحدث فيها الأعطال العملية خارج نطاق بنية CSV نفسها.

• لا تجعل تنسيق الأرقام والتواريخ يعتمد على إعدادات ثقافة نظام التشغيل. فـ value.ToString() يتأثر بإعدادات المنطقة الجغرافية لنظام التشغيل. ففي إعدادات المنطقة التي تستخدم الفاصلة كفاصل عشري، يُخرَج الرقم على شكل 1,5، مما يتعارض مع فاصل CSV نفسه. حدّد CultureInfo.InvariantCulture صراحةً في عمليات التحويل الخاصة بتكامل الملفات، واستخدم تنسيقًا ثابتًا للتاريخ مثل yyyy-MM-dd. وقد تناولنا تصميم التاريخ بالتفصيل في مقال “التاريخ والوقت والمناطق الزمنية في تطبيقات الأعمال”.
• عالج كميات البيانات الكبيرة عبر البث (Streaming) ── لكن يبقى “سطرًا بسطر” مرهونًا بالمواصفات. فـ File.ReadAllLines يُحمّل كل الأسطر كمصفوفة في الذاكرة دفعة واحدة، وهو ما لا يناسب الملفات الكبيرة. والاستبدال بـ File.ReadLines (التعداد المؤجَّل) أو بقراءة StreamReader سطرًا سطرًا لا يجوز إلا للملفات التي تنص مواصفاتها صراحة على عدم السماح بسطر جديد داخل الحقل نفسه. أما ملفات CSV المتوافقة مع RFC 4180 والتي تسمح بسطر جديد داخل علامتي الاقتباس، فإن التقسيم على مستوى السطر يُقطّع السجل الواحد في منتصفه. في تلك الحالة، استخدم TextFieldParser الذي يقرأ مباشرة من مسار الملف (ويمكنه المعالجة دون تحميل الملف بأكمله في الذاكرة)، أو استخدم القراءة عبر البث المتوفرة في مكتبات CSV.
• لا تقرأ ملفًا لم تكتمل كتابته بعد، ولا تسمح بقراءته. الشكل الأساسي لهذا التكامل هو أن تكتب الجهة المُصدِرة الملف تحت اسم مؤقت ثم تعيد تسميته، وأن تتحقق الجهة المستوردة من التزامن قبل القراءة. لخصنا هذا في مقال “التحكّم الآمن في تزامن تكامل الملفّات“، أما الاحتياطات الخاصة بالاستيراد عبر مراقبة المجلدات فقد لخصناها في مقال “كيفيّة استخدام FileSystemWatcher بأمان”.
• استعد لزيادة أو نقصان عدد الأعمدة. يجب النص في المواصفات صراحة على أحد أمرين: “الربط حسب اسم العمود في صف العناوين” أو “ترتيب أعمدة ثابت مع رفض الملف عند عدم تطابق عدد الأعمدة”. فالإشارة الضمنية إلى رقم عمود ثابت مثل fields[7] تنهار بصمت عند أي إضافة طفيفة لعمود من جانب الجهة المقابلة.
• حدّد مسبقًا كيفية التعامل مع السطر الجديد الختامي والأسطر الفارغة. فوجود سطر جديد بعد السطر الأخير من عدمه، وتخطي الأسطر الفارغة أو رفضها، من الأمور التي يختلف فيها السلوك حسب تنفيذ المحلل (Parser). وTextFieldParser يتخطى الأسطر الفارغة.

الخلاصة

ملف CSV يبدو للوهلة الأولى وكأنه مجرد “فصل بالفواصل”، لكنه في الحقيقة تنسيق تكامل مليء باللهجات المختلفة. النقاط الجوهرية العملية أربع ── استخدم أداة قادرة على معالجة علامات الاقتباس عند القراءة (لا تبنِ حلًا مخصصًا باستخدام Split)، وحدّد ترميز الأحرف بالعكس انطلاقًا من الجهة التي ستفتح الملف (خصوصًا Excel) مع النص على وجود BOM من عدمه في المواصفات، وتذكّر أن تفسير Excel للقيم (فقدان الصفر، وتحوّل القيم إلى تواريخ) لا يمكن منعه من جهة CSV، وأضِف الحماية من الحقن إذا كان التطبيق يُخرج مدخلات المستخدم ── وبهذه النقاط وحدها يمكن تفادي معظم أعطال تكامل CSV منذ مرحلة التصميم.

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

مقالات ذات صلة

• فهم ترميزات النصّ على Windows
• شرح ترميزات النصّ ونهايات السطور في Windows
• كيف تبني إخراج تقارير Excel
• مشكلة بقاء EXCEL.EXE في التشغيل الآلي عبر COM في C#
• التحكّم الآمن في تزامن تكامل الملفّات
• كيفيّة استخدام FileSystemWatcher بأمان
• التاريخ والوقت والمناطق الزمنية في تطبيقات الأعمال
• ما الذي يجب التحقّق منه قبل ترحيل .NET Framework إلى .NET
• قائمة تحقّق للحدّ الأدنى من الأمان في تطوير تطبيقات Windows

مجالات الاستشارة ذات الصلة

تتعامل شركة Komura Soft المحدودة (合同会社小村ソフト) مع الاستشارات التقنية المتعلقة بتطوير تطبيقات الأعمال بما فيها تكامل CSV والملفات، والتحقيق في أسباب تشوّه النصوص وتلف البيانات في عمليات التكامل القائمة، وتنظيم مواصفات التكامل مع الأنظمة القديمة.

• تطوير تطبيقات Windows
• الاستشارة التقنية ومراجعة التصميم
• تواصل معنا

المراجع

مقالات ذات صلة

أحدث المقالات التي تشترك في نفس الوسوم. عمّق فهمك بمواضيع مرتبطة.

أين يتصل هذا الموضوع

ترتبط هذه المقالة بشكل طبيعي بصفحات الخدمات التالية.

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

أسئلة شائعة حول موضوع هذه المقالة.

ما ترميز الأحرف الذي ينبغي اعتماده لملفات CSV؟

المبدأ الأساسي هو مطابقة مواصفات الجهة المستقبِلة إن كانت محددة سلفًا. أما إذا كان بالإمكان تحديد الترميز من الصفر، فالبداية الآمنة هي أن تنص المواصفات على استخدام UTF-8 مع BOM للملفات التي يفتحها الأشخاص عبر Excel، وUTF-8 بدون BOM للتكامل بين الأنظمة. وإذا طُلب استخدام Shift_JIS للتكامل مع نظام قديم، فمن الضروري الاتفاق مسبقًا على كيفية التعامل مع الأحرف الخاصة بالجهاز والرموز غير القياسية، وإلا تحوّل الأمر لاحقًا إلى نزاع حول مسؤولية تشوّه النصوص.

هل ينبغي استخدام مكتبة جاهزة لمعالجة CSV، أم يكفي بناء حل مخصص؟

بالنسبة للقراءة، فإن الحل المخصص باستخدام String.Split لا يعالج بشكل صحيح حسب المواصفات بعض الحالات (وجود فاصلة أو سطر جديد أو علامة اقتباس داخل الحقل نفسه)، لذا ينبغي استخدام أداة جاهزة. ففي نطاق مكتبات .NET القياسية، توفّر TextFieldParser معالجة لعلامات الاقتباس مكافئة لـ RFC 4180. أما إذا احتجت إلى ربط الأعمدة بالكائنات، وتحويل الأنواع، والأداء مع كميات كبيرة من البيانات، فمن الأفضل اعتماد مكتبة CSV موثوقة. وبالنسبة للكتابة، فبما أن المواصفات أبسط، يظل الحل المخصص خيارًا واقعيًا، لكن ينبغي تجميع منطق تهريب علامات الاقتباس في دالة واحدة مشتركة يمر عبرها كل الإخراج.

هل ينبغي استخدام الفاصلة أم علامة التبويب (TSV) كفاصل؟

إذا كانت البيانات تحتوي على فواصل بكثرة (مثل العناوين والأسماء وصيغ المبالغ المالية)، فإن استخدام TSV يقلّل من الحاجة المتكررة لمعالجة علامات الاقتباس ويسهّل المراجعة البصرية. مع ذلك، يظل احتمال وجود علامة تبويب أو سطر جديد داخل البيانات قائمًا كما هو، أي أن الحاجة إلى معالجة علامات الاقتباس لا تزول. انتبه إلى أن كونه TSV لا يعني أن اعتبارات الفاصل غير ضرورية. وإن أمكن الاتفاق مع الجهة المقابلة، فإن النص على 'ترميز الأحرف وعلامات الاقتباس ورمز نهاية السطر ووجود صف العناوين من عدمه' في المواصفات أكثر فاعلية في منع الأعطال من اختيار نوع الفاصل نفسه.

إذا كان الهدف هو فتح الملف في Excel، أفلا ينبغي إخراج ملف Excel بدلًا من CSV؟

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

الملف الشخصي للمؤلف

صفحة الملف الشخصي لمؤلف المقالة.

غو كومورا

مؤسّس شركة كومورا سوفت ذ.م.م.

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