تحويل XML إلى Markdown عبر الإنترنت مجانًا

تحويل XML إلى Markdown: الوسوم تخرج والبنية الهرمية تبقى

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

تحويل XML إلى Markdown يحتفظ بالشجرة ويُسقط المراسم. تداخل العناصر يصير مستويات عناوين، والأشقاء المتكررون يصيرون قوائم أو جداول، والأقواس الزاويّة تختفي. ارفع ملف .xml أعلاه وستستعيده في ثوانٍ معدودة — مجانًا، بلا تسجيل، بسقف 50 MB، ولا يُحتفظ بشيء.

إلى ماذا تتحوّل شجرة العناصر

يمشي التحويل عبر المستند ويترجم كل تركيب:

• العناصر الحاوية تصير عناوين. العنصر الذي له عناصر أبناء ولا نص خاص به هو قسم. عمقه في الشجرة يحدد مستوى العنوان، فيصلك مخطط مؤسسي بخمسة مستويات تداخل مستندًا حسن التخطيط بعناوينه.
• العناصر الورقية تصير قيمًا موسومة. <author>Ursula Le Guin</author> تُقرأ author: Ursula Le Guin. اسم واحد بدل اثنين، وبلا أقواس.
• الأشقاء المتكررون يصيرون قوائم أو جداول — يأتي تفصيله أدناه، لأن معظم القيمة هناك.
• المحتوى المختلط يُحفظ في سياقه السطري. هذه حالة تداخل النص مع عناصر الأبناء، كما في <para>See the <ref>appendix</ref> for details</para>. المحوِّلات الساذجة تشطرها شظايا فتخسر الجملة. الصواب أن تمرّ سطرًا واحدًا مقروءًا والمرجع في مكانه.
• التعليقات وتعليمات المعالجة وإعلان XML تذهب. لا شيء منها محتوى.

السمات: الجزء الذي يفقده الناس دون انتباه

يخزّن XML البيانات في موضعين — بين الوسوم وداخلها. نص العناصر واضح للعيان. أما السمات فيسهل إغفالها، وكثير من الاستخراج الساذج يُسقطها بصمت. لا بأس بذلك حين تكون بيانات وصفية مثل id="4471". وهو كارثة حين تكون هي الحمولة نفسها.

وهذا شائع. <price currency="GBP">49.99</price> بلا معنى من دون العملة. وصيغ الإعدادات أسوأ — ملفات Maven وAnt وSpring وmanifest في Android وapp.config في ‎.NET تضع غالبًا كل شيء تقريبًا في السمات، فيعيد استخراجُ نص العناصر وحده من أحدها مستندًا صحيح البنية وفارغًا تقريبًا بالكامل. إن حوّلت ملف إعدادات وبدا الناتج قصيرًا على نحو مريب، فهذا هو السبب.

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

الأشقاء المتكررون يصيرون جداول

أفضل أشكال XML أبٌ يضم أبناء كثيرين متطابقين: عناصر <item> في خلاصة RSS، وعناصر <row> في تصدير قاعدة بيانات، وسجلات <employee> في تفريغ موارد بشرية. كل ابن له العناصر الفرعية نفسها بالترتيب نفسه.

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

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

نطاقات الأسماء والأغلفة وضجيج الأنظمة المؤسسية

نادرًا ما يكون XML الواقعي نظيفًا. ثلاثة أشياء تنفخه فوق محتواه المعلوماتي:

• نطاقات الأسماء. إعلانات xmlns وبادئات مثل soap: وxsi: وatom: وdc: وُجدت لمنع تصادم الأسماء بين المفردات المختلفة. وهي لا تعني شيئًا للقارئ. تُنزع البادئات في التحويل فتُقرأ <dc:creator> على أنها creator. الحالة الوحيدة التي تستدعي الانتباه هي أن يستخدم نطاقان الاسمَ المحلي نفسه لشيئين مختلفين — نادرة، لكن تحقق منها إن كنت تدمج مفردات.
• أغلفة SOAP. استجابة خدمة الويب تلفّ الجزء الذي تريده داخل Envelope وBody، ومعهما غالبًا ترويسات مليئة برموز الأمان وبيانات التوجيه. التحويل يعطيك مستندًا تظهر فيه الحمولة أخيرًا بدل أن تكون مدفونة أربعة مستويات تحت حشوٍ عليك تخطّيه ذهنيًا.
• مراجع المخططات. xsi:schemaLocation وإعلانات DTD وسمات التحقق تصف كيف يُفحص الملف لا ما يقوله. ضجيج لكل غرض هنا.

خلاصات RSS وAtom تقع في الطرف الودود من هذا كله. فهي منتظمة وضحلة التداخل وتتحول إلى قائمة نظيفة من مدخلات مؤرَّخة — طريقة معقولة لتسليم نموذجٍ شهرًا من تدوينات مدونة. لاحظ أن أوصاف الخلاصات تحوي عادة HTML مهرّبًا داخل XML يصل ترميزًا في ناتجك؛ مرّره عبر محوِّل HTML إلى Markdown إن أردته نظيفًا، أو استخدم Web2Txt لجلب الصفحات على نحو سليم.

متى تُبقي على XML الخام

جواب صريح، لأن كثيرًا من الصفحات التي تبيع المحوِّلات لن تعطيك واحدًا: النماذج تقرأ XML جيدًا. هو مُسهب، لكنه قاطع الدلالة وممثَّل في بيانات التدريب تمثيلًا وافرًا جدًا. التحويل اختيار، لا شرط.

أبقِه خامًا حين تطلب تعبيرات XPath، أو ورقة أنماط XSLT، أو مُحللًا، أو مخططًا — أي شيء يجب أن يستنسخ فيه النموذج أسماء العناصر الدقيقة وبادئات نطاقات الأسماء والتمييز بين السمة والعنصر. Markdown يطمس هذه التفاصيل بالذات عن قصد. الصق مقتطفًا ممثِّلًا من الملف الحقيقي بدلًا من ذلك.

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

ملفات XML التي لم تعلم أنها XML

عدد لا بأس به من الصيغ التي تحسبها ثنائية هي XML مضغوط في جوهرها. أعد تسمية ملف .docx إلى .zip وفكّ ضغطه وستجد document.xml مع كومة ملفات علاقات. وEPUB القصة نفسها: مستندات محتوى XHTML وبيان حزمة XML داخل ملف zip. وكذلك .pptx، وكذلك .xlsx.

بوسعك فكّ ضغط أحدها وتحويل XML يدويًا. لا تفعل — الترميز الداخلي مليء بمقاطع التنسيق وتتبّع المراجعات وتعليمات التخطيط التي تُغرق النص. استخدم تحويل Word إلى Markdown أو تحويل EPUB إلى Markdown، فهما يعرفان أي أجزاء ذلك الـ XML محتوى وأيها تعليمات تنسيق. هذه الصفحة لملفات XML التي سُلّمت إليك بوصفها XML: خلاصات، وتصديرات، واستجابات API، وإعدادات، وتبادل بيانات.

أسئلة شائعة

كيف أحوّل XML إلى Markdown؟

ارفع ملف .xml أعلاه وستُسقَط بنية المستند على Markdown — البنية الهرمية للعناصر تصير مستويات عناوين، والعناصر الشقيقة المتكررة تصير قوائم أو جداول. مجانًا، بحد 50 MB للملف، بلا تسجيل. إنه يحفظ شكل المستند، وهذا هو الفرق عن تسطيحه إلى نص.

هل تتحول البنية الهرمية للعناصر إلى مستويات عناوين؟

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

ماذا يحدث لبادئات نطاقات الأسماء؟

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

هل هذا مفيد لتحويل DocBook أو DITA؟

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

أيهما أختار لمجموعة XML ضخمة؟

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

النص العادي بدلًا من ذلك، وبقية المجموعة

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

إن كان XML ملفًا واحدًا في مشروع — إعدادات، أو واصف بناء، أو بيانات اختبار — فتحويله وحده يعطي النموذج البيانات بلا الشيفرة المحيطة بها. يتيح لك محوِّل مستودعات GitHub إلى نص و محوِّل المجلدات المحلية أخذ ملف XML ومستهلكيه معًا، وهي في العادة الوحدة الأنفع. File2Txt يتعامل مع كل الصيغ المدعومة في مكان واحد، و دليل تجهيز الملفات لنماذج اللغة الكبيرة يغطي المبادئ العامة.

Repo2Txt من بناء وصيانة v12hero، مطوّر مستقل يبني تطبيقات أصلية وويب تضع الخصوصية أولًا.