محول CSV إلى JSON

كيفية تحويل CSV إلى JSON عبر الإنترنت

CSV هو الصيغة التي تُصدِّر بها جداول البيانات وقواعد البيانات وأنظمة CRM بياناتها افتراضياً، لأنها ببساطة نص عادي: صف عناوين، ثم سطر واحد لكل سجل، تفصل الفواصل بين الأعمدة. أما JSON فهو ما تريده تطبيقات الويب الحديثة وواجهات REST API وجافاسكريبت نفسها لتستهلكه مباشرة: مصفوفة من الكائنات (objects)، كل كائن مفاتيحه هي أسماء الحقول. يقوم هذا المحول بسد الفجوة بين الصيغتين بالكامل داخل متصفحك، فيحوّل صفوف ملف CSV أو TSV المُصدَّر إلى مصفوفة JSON منظمة في الوقت الذي يستغرقه الضغط على زر واحد.

تظهر هذه الفجوة يومياً في العمل العادي. مطوّر backend يستلم من فريق الاختبار جدول بيانات لمستخدمين تجريبيين ويحتاجه كملف JSON fixture لاختبار تكاملي. مطوّر frontend يستلم كتالوج منتجات مُصدَّراً من نظام مخزون ويحتاج مصفوفة من الكائنات لعرضها كبطاقات على الصفحة. محلل بيانات يسحب تقريراً من نظام CRM ويحتاج تغذيته إلى سكربت لا يقرأ سوى JSON. لا أحد من هؤلاء يريد كتابة parser من الصفر، ولا أحد يريد تثبيت أداة سطر أوامر من أجل تحويل لمرة واحدة يستغرق عشر ثوانٍ هنا.

خطوات تحويل CSV إلى JSON بالتفصيل

1. الصق ملف CSV الخاص بك. ضع صفوفك في مربع "إدخال CSV"، سواء كانت منسوخة من Excel أو Google Sheets أو مُصدَّرة من قاعدة بيانات، أو ملف TSV تفصل فيه علامات التبويب بين الأعمدة بدلاً من الفواصل.
2. حدد الفاصل. اترك الخيار على "اكتشاف تلقائي" في أغلب الحالات، أو اختر مباشرة فاصلة أو تبويب أو فاصلة منقوطة أو خط عمودي إذا كنت تعرف مسبقاً الحرف المستخدم في ملفك.
3. اختر خيارات العناوين والأنواع. أبقِ خيار "الصف الأول كعناوين" مفعّلاً لاستخدام صف العناوين كمفاتيح JSON، وفعّل أو ألغِ "تحويل الأرقام" حسب ما إذا كانت الحقول التي تبدو رقمية، مثل الأعمار أو الأسعار، يجب أن تصبح أرقام JSON حقيقية أم تبقى نصاً.
4. اضغط "تحويل إلى JSON". يبني المحلل المصفوفة في أقل من ثانية، بالمسافة البادئة التي اخترتها، ويضعها في مربع "ناتج JSON" أسفل الصفحة.
5. انسخ النتيجة أو نزّلها. احصل عليها بضغطة واحدة على "نسخ"، أو استخدم "تنزيل .json" لحفظها كملف تسلّمه أو ترفقه أو تستورده مباشرة في أداة أخرى.

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

لماذا يهم اختيار الفاصل: الفاصلة والفاصلة المنقوطة والتبويب والخط العمودي

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

أكثر مفاجأة شائعة هي الفاصلة المنقوطة. يربط Windows الفاصل الافتراضي في Excel بإعدادات المنطقة لديك، وفي معظم دول أوروبا القارية تكون الفاصلة نفسها مستخدمة بالفعل كفاصل عشري، فيُكتب السعر 12,50 بدلاً من 12.50. لو استخدم Excel الفاصلة أيضاً كفاصل حقول، لانقسم عمود سعر واحد بصمت إلى عمودين في كل تصدير. لتجنّب هذا التصادم، يُصدِّر Excel في الإعدادات الألمانية والفرنسية والإسبانية والإيطالية وغيرها ملفات CSV بفاصلة منقوطة كفاصل بدلاً من ذلك، رغم أن امتداد الملف يبقى .csv. سطر يشبه Name;Stadt;Gehalt بقيمة 4500,75 هو تصدير عادي تماماً من جدول بيانات ألماني أو فرنسي، وليس ملفاً تالفاً.

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

الحقول المقتبسة والفواصل المضمّنة وأسطر النص الجديدة

المحلل الساذج يقسّم كل سطر عند حرف الفاصل فقط، وهذا ينهار فوراً إذا احتوى حقل ما على الفاصل نفسه. بيانات CSV الواقعية مليئة بهذا النوع بالضبط: عمود "اسم العائلة، الاسم الأول"، عنوان يحتوي فاصلة قبل اسم المدينة، وصف منتج فيه قائمة ميزات مفصولة بفواصل. الحل، الموحّد منذ عقود فيما يُعرف الآن غالباً بـ RFC 4180، هو تطويق أي حقل يحتوي على الفاصل بعلامتي اقتباس مزدوجتين، وهذا المحول ينفّذ هذه القاعدة كآلة حالات (state machine) تقرأ حرفاً بحرف بدلاً من تقسيم بسيط.

عملياً، سطر مثل "Doe, John",42,"New York, NY" يتحول بشكل صحيح إلى حقل اسم قيمته "Doe, John" وحقل مدينة قيمته "New York, NY"، ويبقى كل منهما قيمة واحدة بدلاً من الانقسام إلى أعمدة إضافية. يتتبع المحلل علامة inQuotes أثناء قراءته حرفاً بحرف، ولا يعامل الفاصلة كفاصل حقول إلا عندما تكون هذه العلامة غير مفعّلة.

علامات الاقتباس المهرَّبة والحقول متعددة الأسطر

حالتان متعلقتان تظهران باستمرار في التصديرات الحقيقية. أولاً، علامة اقتباس مزدوجة حرفية داخل حقل مقتبس تُكتب كعلامتي اقتباس متتاليتين، فـ "She said ""hello"" to me" يُفكّ إلى حقل واحد قيمته She said "hello" to me، مع دمج علامتي الاقتباس المضاعفتين إلى واحدة. ثانياً، يُسمح للحقل المقتبس بأن يحتوي سطراً جديداً حقيقياً، وهذا يحدث كلما كان عمود في جدول بيانات يحمل عنواناً متعدد الأسطر أو ملاحظة أو تعليقاً. لا يتوقف المحلل عن قراءة الحقل عند أول حرف سطر جديد، بل يستمر في استهلاك النص، بما فيه الأسطر الجديدة، حتى يصل إلى علامة الاقتباس الختامية، فعنوان عميل مُصدَّر عبر سطرين فعليين يصل في JSON كقيمة نصية واحدة تحتوي \n مضمّنة بدلاً من أن يُقطع نصفين أو يتسرب إلى السطر التالي.

هذا بالضبط ما ينهار عند تحويل جدول بيانات إلى JSON بتعبير نمطي سريع أو split(',') من سطر واحد. وجود هذا المحلل تحديداً يغني عن التعامل مع هذه الحالات يدوياً.

صفوف العناوين وأسماء الأعمدة المكررة

مع تفعيل خيار "الصف الأول كعناوين"، يوفّر السطر الأول من بياناتك الملصقة اسم المفتاح لكل حقل في كل كائن يليه، فعنوان مثل name,email,age يعني أن كل كائن ناتج يملك بالضبط هذه المفاتيح الثلاثة، بنفس الترتيب. ألغِ الخيار لبيانات CSV التي لا تحتوي صف عناوين على الإطلاق، ربما تفريغ قاعدة بيانات خام أو ملف سجل، فتلجأ الأداة إلى مفاتيح عامة بدلاً من ذلك، col1 وcol2 وcol3 وهكذا، مرقّمة حسب موضع العمود حتى لا يُفقد شيء بصمت.

تستحق أسماء العناوين المكررة انتباهاً خاصاً لأن نمط الفشل هنا صامت وليس رسالة خطأ. كائن JSON لا يمكنه الاحتفاظ بأكثر من خاصية واحدة بنفس المفتاح، فصف عناوين مثل name,phone,phone، ربما جدول بيانات فيه عمودا "هاتف العمل" و"الهاتف الشخصي" مُسمّيان كلاهما "phone"، ينتج كائناً تُكتب فيه قيمة الهاتف الثانية فوق الأولى أثناء التحويل. ناتج JSON صحيح تماماً من الناحية التركيبية، لكنه يحمل بصمت رقم هاتف واحد بدلاً من اثنين، بلا أي تحذير بأن بيانات فُقدت. الحل بالكامل من جهة الإدخال: أعد تسمية الأعمدة المكررة قبل اللصق، مثلاً إلى phone_work وphone_mobile، بحيث يكون كل مفتاح في صف العناوين فريداً قبل أن يبدأ التحويل أصلاً.

استنتاج الأنواع: الأرقام والقيم المنطقية ومشكلة "007"

لا يملك CSV أي مفهوم لأنواع البيانات. كل خلية، سواء حملت اسماً أو عمراً أو سعراً أو قيمة مربع اختيار، مُخزَّنة كنص عادٍ، وخيار "تحويل الأرقام" هو من يقرر كم من هذا النص يُرقّى إلى نوع JSON حقيقي بدلاً من البقاء نصاً. مع تفعيل الخيار، يُحوَّل أي حقل يجتاز فحصاً رقمياً باستخدام Number() في جافاسكريبت، فتصبح "age": "30" في CSV هي "age": 30 في JSON، جاهزة للعمليات الحسابية أو المقارنة دون خطوة تحليل إضافية في الكود الخاص بك.

لهذه الراحة تكلفة حقيقية بالنسبة للقيم التي تبدو رقمية فقط بالمظهر. رمز منتج مثل "007"، رقم حساب مثل "0042"، أو رمز بريدي مثل "02139"، كلها تجتاز الفحص الرقمي وتتحول إلى 7 و42 و2139 على التوالي، فتفقد بصمت الأصفار البادئة التي كانت تمنحها معناها أصلاً. الرمز البريدي معرّف وليس كمية، وبمجرد أن يصبح الرقم 2139 لا توجد طريقة لتمييزه عن رمز بريدي آخر هو 21390 بخطأ إملائي في رقم زائد. إذا كانت بياناتك تحتوي معرّفات أو رموزاً بريدية مختلطة مع حقول رقمية فعلية، ألغِ تفعيل "تحويل الأرقام" قبل التحويل واحتفظ بكل شيء كنصوص، أو حوّل مرتين وصحّح يدوياً حقول المعرّفات فقط في الناتج.

يسهل إغفال صفّين من هذا الجدول: تحويل القيم المنطقية ومعالجة الخلايا الفارغة يحدثان دون شرط، بغض النظر عن حالة خيار "تحويل الأرقام". خلية تحتوي النص true أو false، بغض النظر عن حالة الأحرف، تتحول دائماً إلى قيمة منطقية JSON حقيقية، وخلية فارغة فعلاً تتحول دائماً إلى null بدلاً من سلسلة نصية فارغة "". هذا مهم إن كان الكود الذي يقرأ الناتج يتحقق من حقل بـ === null تحديداً، أو يتوقع أن تشترك كل قيم مفتاح معين في نفس نوع جافاسكريبت؛ عمود يكون فارغاً أحياناً سينتج مزيجاً من نصوص وقيم null عبر المصفوفة بدلاً من عمود نصوص فارغة طوال الوقت.

UTF-8 مقابل Windows-1252: إصلاح الأحرف المشوّهة القادمة من Excel

أخطاء ترميز النصوص من أصعب الأخطاء تشخيصاً لأن الملف يبدو سليماً تماماً في البرنامج الذي أنشأه، ولا ينكشف العطب إلا في مكان ما لاحقاً. الحالة الكلاسيكية: حقل اسم يحتوي "café" أو "François" يُصدَّر من Excel، يُلصق في هذا المحول أو أي أداة أخرى تتوقع UTF-8، ويخرج مكتوباً café أو François بدلاً من ذلك. لهذا التشويه اسم، mojibake، وسبب محدد: حُفظ الملف باستخدام ترميز Windows بـ 8 بت، غالباً Windows-1252، حيث "é" حرف واحد بايت واحد، لكنه يُقرأ بعد ذلك بواسطة أداة تتوقع UTF-8، حيث نفس الحرف يأخذ بايتين، فيُفسَّر كل من هذين البايتين كحرف منفصل قائم بذاته.

القراء العرب يواجهون نسخة موازية من نفس المشكلة تحديداً مع النص العربي نفسه. ملف CSV مُصدَّر أو محفوظ بترميز Windows-1256 القديم (ترميز عربي بـ 8 بت شائع في نسخ Excel وWindows العربية الأقدم) ثم يُقرأ بافتراض UTF-8، أو العكس، ينتج نصاً عربياً مشوهاً تماماً، سلسلة رموز غير مفهومة بدلاً من كلمات مقروءة، تماماً كما يحدث مع الحروف اللاتينية المميزة. إن كنت تحوّل ملف CSV يحتوي أسماء عملاء أو عناوين مكتوبة بالعربية وظهرت مشوهة بعد اللصق هنا، فالسبب هو نفسه: تعارض في الترميز عند التصدير، وليس خللاً في المحول نفسه.

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

علامة ترتيب البايت والصفوف الفارغة الزائدة

يستحق عاملان أصغر معرفتهما. غالباً ما يضيف Excel علامة ترتيب بايت (byte order mark)، توقيع UTF-8 غير مرئي يظهر أحياناً كأحرف  إذا قُرئ بشكل خاطئ، في بداية ملف CSV بترميز UTF-8، وهي مقصودة لمساعدة برامج أخرى على اكتشاف الترميز تلقائياً لكنها تظهر أحياناً كحرف زائد ملتصق باسم العنوان الأول إذا لم تُزلها أداة ما. وبشكل منفصل، تنتهي تصديرات جداول البيانات عادة بسطر فارغ بعد آخر صف بيانات فعلي. يستبعد هذا المحول أي صف تكون كل خلاياه فارغة قبل بناء مصفوفة JSON، فسطر جديد زائد في نهاية ملفك لا ينتج كائناً فارغاً زائداً في نهاية الناتج.

لماذا يعمل هذا المحول بالكامل داخل متصفحك

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

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

ماذا يعني هذا بالنسبة لتصديرات البيانات السرية

إن كنت تحوّل سجلات موظفين، أو بيانات مالية، أو معلومات منتج غير منشورة، أو أي شيء آخر لا يجب أن يغادر مؤسستك، تزيل أداة تعمل بالكامل من جهة العميل (client-side) هذه المخاطرة من المعادلة كلياً بدلاً من مطالبتك بالثقة بسياسة خصوصية لم تقرأها. المنطق نفسه يدفع المطورين إلى تشغيل منسّق كود محلياً بدلاً من لصق كود مصدري خاص في نموذج ويب عشوائي: الأداة الأكثر أماناً هي الأداة التي لم تُتَح لها الفرصة أصلاً لتسريب أي شيء.

طرق شائعة لاستخدام محول CSV إلى JSON هذا

نفس خطوة التحويل تظهر في أعمال مختلفة تماماً. بعض الأنماط تتكرر باستمرار.

نماذج أولية للواجهة الأمامية بلا خادم فعلي

مطورو الواجهة الأمامية الذين يبنون مكوّناً أو جدولاً أو نموذجاً أولياً للوحة تحكم يحتاجون غالباً بيانات عينة واقعية قبل وجود API فعلية. تصدير جدول بيانات لصفوف عينة وتحويله هنا ينتج مصفوفة JSON جاهزة للاستخدام يمكن وضعها مباشرة في ملف بيانات وهمية أو fixture محلي.

تغذية قاعدة بيانات مستندية أو NoSQL

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

اختبار الواجهات البرمجية وحمولات وهمية

مهندسو ضمان الجودة ومطورو الواجهة الخلفية الذين يبنون حالات اختبار في أدوات مثل Postman أو Insomnia يبدأون غالباً بجدول بيانات لمدخلات نموذجية، صف واحد لكل حالة اختبار، ويحتاجون نفس البيانات كمصفوفة JSON من أجسام الطلبات. التحويل مرة واحدة هنا يبقي جدول البيانات كمصدر الحقيقة بينما ينتج شكل JSON الدقيق الذي يتوقعه مُشغّل الاختبارات.

ترحيل البيانات والسكربتات لمرة واحدة

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

الإعدادات والمحتوى من جداول البيانات

الزملاء غير التقنيين غالباً ما يكونون أكثر ارتياحاً للاحتفاظ بقائمة في Google Sheets من تحرير ملف JSON مباشرة، سواء كانت قائمة أسئلة شائعة، أو فئات منتجات، أو أعلام ميزات (feature flags). تحويل جدول بياناتهم هنا عند كل تحديث يبقي ملف JSON متزامناً مع آخر ما حرروه، دون أن يحتاجوا لمس محرر نصوص.

نصائح لتحويلات نظيفة وأخطاء شائعة يجب تجنبها

• تحقق من الفاصل المكتشف في الملفات القصيرة. يأخذ الاكتشاف التلقائي عينة من أول خمسة أسطر فقط، فملف بسطر أو سطرين لا يمنحه الكثير للعمل عليه. إذا بدا الناتج خاطئاً في عينة صغيرة، اضبط الفاصل يدوياً بدلاً من الثقة بالاكتشاف التلقائي.
• قرر بشأن "تحويل الأرقام" قبل التحويل، لا بعده. بمجرد أن تفقد معرّفات أو رموز أو رموز بريدية أصفارها البادئة بسبب التحويل الرقمي، تختفي تلك المعلومة من الناتج نهائياً. افحص أعمدتك بحثاً عن حقول تشبه المعرّفات أولاً، واترك الخيار معطلاً إذا بدا أي منها معرضاً للخطر.
• انتبه لأسماء العناوين المكررة. عمودان يتشاركان عنواناً واحداً ينهاران بصمت إلى مفتاح واحد في كل كائن ناتج. أعد تسمية المكرر قبل اللصق، لأن الأداة لا تملك طريقة لتخمين أي نسخة أردت الاحتفاظ بها.
• تذكّر أن الحقول تُشذَّب (trimmed). تُزال المسافات البيضاء البادئة واللاحقة حول كل حقل أثناء التحليل، فقيمة مثل " New York " تخرج كـ "New York". هذا عادة ما تريده، لكنه يعني أن البيانات الحساسة للمسافات، مثل رمز يبدأ عمداً بمسافة، لن تنجو من الرحلة.
• أعد التصدير من Excel بترميز UTF-8 إذا بدت الأحرف مشوهة. يعود سبب mojibake دائماً تقريباً إلى تعارض ترميز وقت التصدير، وليس خللاً في اللصق أو المحلل، والإصلاح الأنظف هو خيار مختلف في "حفظ باسم" في جدول البيانات المصدر بدلاً من التنظيف اليدوي لاحقاً.
• استخدم خيار المسافة البادئة ليناسب خطوتك التالية. اختر مسافتين أو أربع مسافات لناتج تنوي قراءته أو حفظه في نظام تحكم بالإصدارات، أو "مضغوط" عندما يكون JSON متجهاً مباشرة إلى طلب API أو سكربت يهم فيه حجم الملف أكثر من سهولة القراءة.

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

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

أدوات المطورين ذات الصلة

🔒 خصوصية كاملة 100% داخل متصفحك

تتم جميع عمليات تحليل CSV وبناء JSON <strong>بالكامل داخل متصفحك</strong>. لا تُرفع أي بيانات إلى أي خادم مطلقاً. تبقى بياناتك على جهازك في كل وقت.