من Word إلى Markdown: دليل الهجرة الشامل لعام 2026

عادةً ما يصل الطلب بصيغة تبدو بسيطة: «هل يمكنك نقل مستندات Word هذه إلى ويكي الفريق؟»

تفتح القرص المشترك لتجد ثلاثمئة ملف .docx. عقد كامل من التوثيق الداخلي — سياسات وأدلة تشغيل ومحاضر اجتماعات ومواصفات — مبعثرة في مجلدات بأسماء غير منتظمة. لا شيء منها يمكن مقارنته بسهولة (diff)، ولا شيء منها قابل للبحث بشكل جيد. ثم يقرر أحدهم أن كل ذلك يجب أن يُحفظ في Markdown متتبَّع عبر Git قبل نهاية الربع.

قمتُ بهجرتين من هذا النوع. مرة من أجل أرشيف امتثال (حوالي 200 ملف)، ومرة لقاعدة معرفية هندسية (حوالي 500 ملف). وفي المرتين كان الدرس واحداً: تحويل Word إلى Markdown ليس عملية بضغطة زر واحدة. إنه خط أنابيب — تحويل، ثم فحص، ثم تنظيف — والوقت الحقيقي يُستهلك في خطوة التنظيف.

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

لماذا تنقل مستندات Word إلى Markdown أصلاً؟

قبل الحديث عن «كيف»، لنتحدث سريعاً عن «لماذا». لأن فريقك إن لم يُوضّح السبب، فلن تصمد عملية الهجرة.

• تاريخ قابل للمقارنة (Diffable). ملف .docx في Word عبارة عن حزمة XML مضغوطة. نسختان منه تبدوان لـ Git مثل كتلتين ثنائيتين عشوائيتين. أما Markdown فهو نص عادي — كل تغيير يظهر كـ diff مقروء.
• بحث حقيقي وgrep. الأمر rg "incident response" docs/ يعمل في ميلي ثوانٍ عبر آلاف ملفات Markdown. المكافئ عبر مستندات Word يتطلب أداة بحث مملوكة.
• أتمتة. Markdown قابل للاستهلاك من مولّدات المواقع الساكنة، وأدوات التوثيق (Docusaurus وMkDocs وNextra)، وخطوط ابتلاع LLM، وأنظمة CI، وأدوات التدقيق اللغوي. أما Word، فقابل للاستهلاك في الغالب من قِبل Word فقط.
• طول العمر. ملفات النص العادي تعيش أطول من موردي البرمجيات. صيغة DOCX مستقرة اليوم، لكن أفق التوافق مع .doc (الصيغة الثنائية القديمة) بدأ يغيم بالفعل.

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

ما الذي يبقى بعد التحويل وما الذي يضيع

ضبط التوقعات مسبقاً هو ما يوفّر أكبر قدر من الوقت. إليك ما لاحظته عبر مئات عمليات التحويل:

ميزة Word	هل تبقى؟	ملاحظات
العناوين (أنماط Heading 1–6)	نعم	تُقابَل مباشرةً بـ # حتى ######
الخط العريض والمائل والمسطّر	العريض/المائل نعم	التسطير لا مقابل له في Markdown (يصبح مائلاً أو وسم HTML <u>)
القوائم النقطية والرقمية	غالباً نعم	التداخل العميق يتسطّح أحياناً
الروابط التشعبية	نعم	عنوان URL ونص الرابط محفوظان
الجداول (Tables)	الجداول البسيطة نعم	الخلايا المدمجة وألوان الخلايا والحدود تُفقد
الصور المضمّنة (Inline images)	نعم	تُستخرج إلى مجلد وتُعاد كتابة الروابط
الحواشي السفلية (Footnotes)	نعم (GFM)	تتحول إلى صياغة [^1]
الشيفرة (إذا نُسّقت بنمط Code)	يعتمد	تتسطّح غالباً إلى نص عادي بلا كتلة (fence)
المعادلات الرياضية	جزئي	قد تتحول إلى LaTeX أو تتسطّح أحياناً
تتبع التغييرات (Track Changes)	لا	اقبل أو ارفض كل التغييرات أولاً
التعليقات (Comments)	لا	حلّها أو صدّرها بشكل منفصل قبل التحويل
مربعات النص وSmartArt والأشكال	لا	تُفقد كلياً — استبدلها بصور أو نص عادي أولاً
جدول المحتويات المُولَّد تلقائياً	لا	أعِد توليده عبر أداة التوثيق لديك
حقول Word (التاريخ والإحالات المتقاطعة)	لا	حوّلها إلى نص عادي قبل التصدير

أكبر مفاجآت الهجرة عادةً: (1) تنسيق يبدو كعنوان لكنه في الحقيقة مجرد «عريض يدوي + خط أكبر» — هذه تتحول إلى نص عريض عادي فيخرج ملفك بلا بنية، و(2) جداول بخلايا مدمجة تنهار بطرق قبيحة المظهر وتتطلب إعادة بناء يدوية.

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

الطريقة الأولى: محوّل عبر الإنترنت

هذه ما أنصح به للملفات المفردة والدفعات الصغيرة (أقل من 50 مستنداً تقريباً). إنها أسرع مسار من .docx إلى Markdown نظيف دون أي إعداد.

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

المخرجات تستخدم GitHub Flavored Markdown (GFM)، لذا تُحفظ الجداول وقوائم المهام والحواشي السفلية. العناوين تُقابَل بمستويات #، والقوائم تحتفظ بتسلسلها الهرمي، والروابط التشعبية تحتفظ بنص الإرساء.

تجدر الإشارة: يحدث التحويل داخل المتصفح للمستندات القياسية. للملفات الكبيرة جداً، أو عند التعامل مع محتوى حساس، إبقاء الملف بعيداً عن خوادم خارجية ميزة حقيقية، لا مجرد كلام تسويقي.

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

الطريقة الثانية: Pandoc (للدفعات والسكريبتات)

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

الأمر الأساسي

pandoc document.docx -o document.md

هذا كل شيء لملف واحد. يعمل بسرعة، ويُنتج مخرجات مقروءة، ويتعامل مع معظم ميزات Word الشائعة فور الإقلاع. لكن القيمة الحقيقية لـ Pandoc تظهر حين تضيف الأعلام (flags).

ثلاثة أعلام تستحق المعرفة

pandoc document.docx \
  -o document.md \
  --extract-media=./images \
  --wrap=none \
  --markdown-headings=atx

• --extract-media=./images — يستخرج الصور المضمّنة داخل DOCX ويضعها في مجلد، مع إعادة كتابة روابط الصور في الملف الناتج. بدون هذا العلم، تُسقَط الصور المضمّنة بصمت.
• --wrap=none — يمنع Pandoc من التفاف الأسطر عند ~80 حرفاً. هذا مهم لأن التفاف الأسطر القسري يكسر قابلية قراءة diff في Git للمستندات الكثيفة بالنص.
• --markdown-headings=atx — يفرض صياغة # Heading بدلاً من صياغة setext الأقدم (أسطر تحتها ====). ATX هو العُرف الحديث.

تحويل دفعي لمجلد كامل

for f in *.docx; do
  pandoc "$f" -o "${f%.docx}.md" --extract-media=./images --wrap=none
done

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

مطبّات واقعية انتبه لها

• علامات النقاط تختلف. يستخدم Pandoc أحياناً - وأحياناً *. إن كانت الاتساقية تهمك، شغّل sed -i 's/^\* /- /g' على المخرجات، أو اضبط مُنسّق Markdown في محرّرك.
• القوائم الرقمية تُعيد الترقيم بشكل غير متوقع. يحوي Word كثيراً توجيهات «متابعة الترقيم» التي لا يستطيع Pandoc تفسيرها. سترى قوائم تعدّ 1, 2, 1, 2, 3 بينما يبدو المصدر متواصلاً. قابل للإصلاح بمراجعة سريعة.
• الجداول ذات الخلايا الطويلة تلتف بصعوبة في القراءة. يبذل Pandoc قصارى جهده، لكن جداول GFM لا تدعم فواصل الأسطر داخل الخلية كما يفعل Word. فكّر في تحويل الجداول المعقدة جداً إلى كتل HTML يدوياً.

لا يملك Pandoc واجهة رسومية، وهذا عيب (لا يستطيع زملاؤك غير التقنيين تشغيله) وفائدة في آن معاً (قابل للبرمجة داخل أي خط أنابيب CI/CD).

الطريقة الثالثة: التحويل البرمجي عبر Mammoth.js

إن كنت تبني خط أنابيب — سكريبت هجرة يسحب ملفات DOCX من SharePoint ويُحوّل ثم يُلزم (commit) إلى Git مثلاً — فقد لا تناسب واجهة ويب ولا استدعاء عملية فرعية لـ Pandoc بيئتك التقنية. Mammoth.js مكتبة JavaScript تُحوّل DOCX إلى HTML نظيف أو إلى Markdown مباشرة داخل Node.js.

const mammoth = require("mammoth");

mammoth.convertToMarkdown({ path: "document.docx" })
  .then(result => {
    console.log(result.value); // مخرجات Markdown
    console.log(result.messages); // تحذيرات بشأن الميزات غير المدعومة
  });

ما يجعل Mammoth مفيداً هو فلسفته الصريحة: يتجاهل التنسيق البصري لـ Word كلياً ويُركّز على البنية الدلالية (العناوين والقوائم والجداول). المخرجات أنظف من Pandoc افتراضياً، على حساب قدر أقل من التحكم. لهجرة أرشيف قديم حيث معظم المستندات ذات بنية متسقة، سألجأ إلى Mammoth. أما للمستندات المتفرّدة ذات التنسيقات الثقيلة، فتفوز مرونة Pandoc.

لدى مستخدمي Python خيار مشابه في python-docx مع كاتب Markdown، وإن كان ذلك أقرب إلى مسار «اصنعه بنفسك» منه إلى أداة جاهزة.

خطوة التنظيف التي لا يُحذّرك منها أحد

التحويل يوصلك إلى ملف .md. لا يوصلك إلى ملف .md تودّ إلزامه (commit) إلى المستودع.

إليك قائمة التحقق القياسية التي أتّبعها بعد التحويل. تأخذ نحو خمس دقائق لكل مستند بعد أن تتمرّن عليها:

1. ابحث عن عناوين بنيوية مفقودة. ابحث في المخرجات عن أسطر تبدو كعناوين لكنها في الحقيقة **نص عريض** على سطر مستقل. أحدهم نسّقها يدوياً في Word بدلاً من استخدام أنماط العناوين. ارفعها إلى عناوين ## فعلية.
2. افحص أول جدول. إن بدا الجدول صحيحاً هنا، فسيبدو كذلك في الغالب في كل مكان. إن كان الأول مكسوراً، فالكل مكسور.
3. احذف الأسطر الفارغة داخل عناصر القائمة. يُدرج Pandoc أحياناً أسطراً فارغة تكسر تسلسل القائمة.
4. تحقق من روابط الصور. افتح الملف في معاينة Markdown (المضمّنة في VS Code تفي بالغرض) وتأكّد من تحميل الصور.
5. ابحث عن بقايا شاذة. بقايا شائعة: \ في نهاية الأسطر (فواصل أسطر قسرية يُخفيها Word لكن يُظهرها Markdown)، وخصائص نمط {.underline}، ووسوم <span> تسلّلت من غير قصد.
6. افحص أول وآخر 10 أسطر. رؤوس وتذييلات الصفحات وأرقامها في Word تتسرّب كثيراً إلى المخرجات كمحتوى فارغ أو قطع شاذة.

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

هجرة واقعية: أرشيف امتثال من 200 ملف

إليك سير العمل الذي استخدمته لهجرة أرشيف الامتثال. من البداية إلى النهاية كان العمل يومين على أرشيف من 200 ملف.

صباح اليوم الأول: فرز المصدر

كتبتُ سكريبت Python يفتح كل DOCX، ويحصي العناوين والصور والجداول، ويُشير إلى كل ملف لا يزال تتبع التغييرات نشطاً فيه أو تحتوي على تعليقات. كان الناتج ملف CSV بالملفات مُرتّبةً حسب التعقيد. الهدف لم يكن إصلاح أي شيء بعد — فقط معرفة ما أنا مُقدِم عليه.

بعد ظهر اليوم الأول: تحويل دفعي للملفات البسيطة

حوالي 140 من أصل 200 ملف كانت مستقيمة: بدون صور، جداول بسيطة، بنية عناوين نظيفة. مرّرتها عبر Pandoc في حلقة مع --extract-media و--wrap=none. فحصتُ 20 عينة عشوائية بالعين. كل شيء سليم.

صباح اليوم الثاني: معالجة الملفات المعقدة فردياً

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

بعد ظهر اليوم الثاني: التنظيف والإلزام

شغّلتُ سكريبت تنظيف على كل الـ 200 ملف المحوّل (إزالة قطع {.underline}، وتوحيد علامات النقاط، وإصلاح التفاف الأسطر في مخرجات Pandoc). راجعتُ الـ diff، وأَلزَمت على دفعات من 50، ودفعتُ إلى فرع الهجرة.

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

مشاكل شائعة وحلولها

الجداول تبدو خاطئة في معاينة Markdown

تسعون بالمئة من الوقت، كان المصدر يحوي خلايا مدمجة أو محتوى خلية طويلاً جداً. جداول GFM لا تدعم أياً منهما بأناقة. خياراتك: إعادة بناء الجدول يدوياً بصياغة GFM، أو استخدام كتلة <table> بـ HTML داخل Markdown (تدعمها معظم المُصيّرات)، أو تقسيم الجدول إلى جداول أبسط متعددة.

الصور لا تظهر

تحقّق مما إذا كان المحوّل قد استخرجها. لن يفعل Pandoc ذلك إلا إذا استخدمت --extract-media. المحوّلات عبر الإنترنت تُنزّل عادةً ملف zip يحوي ملف Markdown ومجلد images/ — تأكّد أن كليهما انتهى في المكان الصحيح وأن مسارات الصور داخل Markdown مطابقة.

المخرجات تحوي شرطات مائلة غريبة في نهايات الأسطر

هذه فواصل أسطر قسرية من Word يُصيّرها Markdown كفواصل إجبارية. إن كان مستند Word المصدر مليئاً بتباعد فقرات ضيّق يستخدم فواصل أسطر بدل فواصل فقرات، فإن Pandoc يُبقي عليها. عملية بحث واستبدال سريعة لـ \\$ (نهاية السطر) تُنظّفها عادةً.

مستويات العناوين خاطئة بعد التحويل

مستندات Word كثيراً ما تبدأ من Heading 2 أو Heading 3 (لأن Heading 1 كان محجوزاً لصفحة العنوان). العُرف في Markdown هو البدء من # (H1). وفق كيفية عرض نظام التوثيق لديك للعناوين، قد تحتاج إلى رفع كل المستويات بدرجة. sed يقوم بذلك: sed -i 's/^## /# /; s/^### /## /; ...' file.md.

Markdown لا يشبه مستند Word بصرياً على الإطلاق

هذا متوقّع. Markdown يصف البنية، لا المظهر. التنسيق يأتي من أي نظام يُصيّر Markdown (GitHub، أو موقع التوثيق لديك، أو سمة MkDocs، إلخ). إن كانت الأمانة البصرية حرجة، فـ PDF هدف أفضل — انظر دليلنا لتحويل Markdown إلى PDF لسير عمل يحفظ التصميم البصري.

الرحلة المعاكسة: من Markdown عودةً إلى Word

سؤال طبيعي بعد الهجرة: «ماذا لو احتجت إرسال مستند Markdown عودةً إلى صاحب مصلحة لا يفتح سوى Word؟» هذا هو التحويل العكسي — وهو عملية أنظف بكثير، لأن قيود Markdown تعني أن ما يحتاج إلى ترجمة أقل. يغطّي دليل Markdown إلى Word هذا السير.

للفرق التي تتنقّل بين الصيغتين باستمرار، سير العمل الذي رأيته ناجحاً هو: Markdown مصدر الحقيقة في Git، وتصديرات Word تحدث عند الطلب عندما يحتاج أحدهم إلى مراجعة أو شرح. لا شيء يُحرَّر في Word ثم يُدمج عودةً — بهذه الطريقة لا تتفكّك الهجرة ببطء.

الخلاصة

تحويل Word إلى Markdown هجرة، لا ضغطة زر. الأدوات تؤدّي العمل الثقيل — محوّلنا عبر الإنترنت للملفات الفردية، وPandoc للدفعات، وMammoth.js لخطوط الأنابيب — لكن العمل الحقيقي هو الفحص قبل التحويل والتنظيف بعده.

النمطان اللذان يوفّران أكبر قدر من الوقت:

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

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

وإن كانت هجرتك تخرج من Obsidian بدلاً من Word، فإن دليل تصدير Obsidian يُعالج ذلك المسار من البداية إلى النهاية.