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

يظل تبادل البيانات عبر CSV اليوم لاعباً أساسياً في عالم تطبيقات الأعمال. ولأنه يبدو «مجرد وصل نصوص بفواصل»، فهو أيضاً مجال تتكرر فيه حوادث مثل انهيار المحلل الذاتي بسبب فاصلة داخل الحقل، وتشوه النصوص عند الفتح في Excel، واختفاء الصفر البادئ من رقم الهاتف.

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

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

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

1.1 تحديد ترميز الأحرف انطلاقاً من الاستخدام (جدول القرار)

1.2 مبادئ تسري على الكل

نكتب أولاً الخلاصة المشتركة بغض النظر عن الاستخدام.

• تحليل 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 باستثناء لأول مرة في الإنتاج (4.2).
• سقوط الصفر البادئ والتحويل إلى تاريخ لا يُمنعان من جهة CSV. الحقيقة المهمة أنهما لا يُمنعان حتى بالتحويط بعلامات اقتباس مزدوجة (الفصل 5).
• التطبيق الذي يخرج إدخال مستخدم إلى CSV يحتاج حماية من الحقن عبر CSV. الحقل البادئ بـ = أو + يفسّره Excel كصيغة (الفصل 6).

في المخطّط، يشير الخطّ المتّصل إلى علاقة قائمة دائماً، ويشير الخطّ المتقطّع إلى علاقة مشروطة (شروط قيامها مذكورة في شرح كلّ علاقة في الصفحة التفصيليّة). القائمة الكاملة للعلاقات (المجموع 24، مع الأدلّة ودرجة اليقين) وتعريفات المفاهيم الرئيسة مجمّعة في صفحة تفاصيل خريطة المعرفة (باليابانية). البيانات: JSON-LD / Turtle

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. فضاء الأسماء 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("سطر CSV رقم {Line} بصيغة غير صحيحة: {Content}",
            ex.LineNumber, parser.ErrorLine);
    }
}

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

إن احتجت ربط الأعمدة بالكائنات وتحويل الأنواع وأداء ملايين الصفوف، فانظر إدخال مكتبة CSV ذات سجل. الأكثر استخداماً في .NET هو CsvHelper (اسم حزمة NuGet أيضاً CsvHelper)، يصرّح بالتوافق مع RFC 4180، ورخصته مزدوجة MS-PL وApache 2.0 فيجوز الاستخدام التجاري⁴. الربط إلى فئة، ومقابلة أسماء الأعمدة عبر ClassMap، والقراءة المتأخرة بـ IEnumerable<T> مكتملة، فإن تجاوزت مرحلة «تستلم string[] من TextFieldParser وتحوّل النوع بنفسك» صار الخيار الأول للانتقال.

غير أن الأهم من اختيار أي مكتبة ماذا تتحقق منه عند الاختيار. الجوانب الأربعة: «معالجة اقتباس RFC 4180»، «تحديد ترميز الأحرف»، «التعامل مع السطر المنكسر»، «إمكان القراءة بالتدفق». إن استُوفيت الأربعة لا تخرج كثيراً في العمل. وبالعكس، في موقع تقيّد فيه اللوائح الداخلية إضافة حزمة خارجية، احكم أولاً هل يكفي TextFieldParser.

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

// 書き出し側のエスケープはこの1関数に集約する
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 إن كان الفتح في Excel فـ UTF-8 مع BOM

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

كتبنا «في بعض البيئات» لأن مدى التعرف التلقائي على UTF-8 بلا BOM يتأثر بإصدار Excel والبناء والإعداد الإقليمي لنظام التشغيل، ولا يمكن الجزم بأن إصداراً ما يتعرّف حتماً. ما يصلح مستنداً للحكم أن مقال الدعم الحالي من Microsoft يوجّه بالشكل التالي⁵.

أي أن نجاح النقر المزدوج لـ UTF-8 بلا BOM دائماً غير موجَّه رسمياً. في تطبيق أعمال لا تستطيع فيه التحقق بنفسك من إصدار Excel لدى جهة التوزيع والإعداد الإقليمي، «أرفق BOM واتركه قابلاً للفتح بالنقر المزدوج» يقلل استعلامات الدعم. وبالعكس، إن كانت جهة الاستيراد نظاماً، يصير BOM ثلاث بايتات زائدة تسبب خطأ تحليل، فاجعله بلا BOM.

هوية ذلك BOM ثلاث بايتات في صدر الملف: EF BB BF. إن نظرت الصدر بمحرر ثنائي أو Format-Hex في PowerShell ميّزت فوراً بأي منهما أُخرج.

BOM付きUTF-8:  EF BB BF 44 61 74 65 2C ...   ← 先頭3バイトがEF BB BF、その後に "Date," が続く
BOMなしUTF-8:  44 61 74 65 2C ...            ← いきなり "Date," から始まる

«الملف المفترض مع BOM لا يبدأ بـ EF BB BF» و«جهة الاستيراد لا يتطابق فيها اسم العمود الأول فقط (ثلاث بايتات غير مرئية معلّقة في رأس اسم العمود)» كلاهما يُحكم عليه في خمس ثوانٍ بالنظر إلى هذه البايتات الثلاث.

هنا يتراكب فخ جانب .NET. إرفاق BOM من عدمه يتغيّر حسب طريقة تمرير Encoding.

// BOMなしUTF-8: エンコーディング指定を省略した場合の既定
File.WriteAllText(path, csv);

// BOM付きUTF-8: Encoding.UTF8(静的プロパティ)はBOMを出力する設定になっている
File.WriteAllText(path, csv, Encoding.UTF8);

// 意図を明示したいなら、コンストラクタで指定するのが誤解がない
File.WriteAllText(path, csv, new UTF8Encoding(encoderShouldEmitUTF8Identifier: true));

أن الملف الناتج يتغيّر بين تمرير Encoding.UTF8 وحذفه مواصفات لا تُلاحظ إن لم تُعرف⁶. إن قررت مواصفات «التكامل بين الأنظمة بلا BOM» و«لـ Excel مع BOM»، يُنصح بإظهار القصد في الشيفرة أيضاً بـ 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;

// アプリ起動時に1回だけ登録する(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، فاختر إخراجاً قائماً على مكتبة.
3. الإخراج بصيغة ="007" آخر الوسائل. حيلة تعرض كنص عند الفتح في Excel، لكن كـ CSV يصير «ملفاً غير قياسي فيه صيغ»، فيكسر جهة استيراد غير Excel. لا تستخدمه في ملف مشترك مع نظام آخر.

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

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

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

// 数式として解釈されうるフィールドの先頭にシングルクォートを付ける。
// 日本語環境では全角の＝＋－＠も数式の開始として解釈されうるため対象に含める
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 لـ «عامل كنص». لاحظ أن قائمة الأحرف البادئة الخطرة قد تتغيّر حسب تنفيذ برنامج الجداول وإصداره، لذلك يصير مثل هذا التحييد أقوى أمام الثغرات المتوقعة إن صُمّم باتجاه «لا يمر كما هو إلا إن طابق الصدر قائمة السماح هذه (أبجدية وأرقام وغيرها)». غير أن جهة نظام آخر تستورد ذلك CSV ستبقى فيها علامة الاقتباس المفردة كبيانات، فوارد الحكم بفصل ملف «لفتح Excel» عن ملف «لاستيراد النظام». بما فيه الجمع مع التحقق من قيمة الإدخال (عدم السماح بـ = في الصدر أصلاً وغيرها)، تصميم أمن التطبيق كله في قائمة التحقق الدنيا لأمن تطبيقات Windows.

7. مطبّات التشغيل ── أين يقع الحادث خارج التنسيق

أخيراً نلخص نقاط يقع فيها حادث العمل خارج نحو CSV نفسه.

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

الخلاصة

CSV تنسيق تكامل مليء باللهجات، بوجه «مجرد فصل بفواصل». نقاط العمل أربع — القراءة تستخدم مكوّناً يعالج الاقتباس (لا تبنِ بـ Split)، وترميز الأحرف يُقرَّر عكسياً من جهة الفتح (خصوصاً Excel) ويُكتب في المواصفات حتى وجود BOM من عدمه، وتفسير Excel للقيمة (سقوط الصفر والتحويل إلى تاريخ) يُعلم أنه لا يُمنع من جهة CSV، وإن أخرجت إدخال مستخدم فأدخل حماية من الحقن — بهذا وحده تُسحق غالب حوادث تكامل CSV في مرحلة التصميم.

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

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

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

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

تتعامل شركة كومورا سوفت ذ.م.م. مع تطوير تطبيقات الأعمال بما فيه تكامل 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 مع توجيه «إجراء الاستيراد (باستخدام ميزة استيراد البيانات)» كخطوة تشغيل.

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

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

غو كومورا

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

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