غالبًا ما يتم تصنيف MarkItDown جنبًا إلى جنب مع أدوات الزحف على الويب، وهذا التصنيف غير صحيح. فهو لا يحتوي على زاحف، ولا على محرّك JavaScript، ولا على أي طريقة لجلب عنوان URL ثم تنظيف العناصر الزائدة فيه. ما يفعله ببساطة هو أخذ البيانات التي لديك أصلًا — ملف PDF، أو مستند Word، أو جدول بيانات، أو عرض شرائح — وتحويلها بالكامل إلى Markdown يمكن لنموذج لغوي قراءته.
قضيت بضعة أسابيع أشغّل MarkItDown من Microsoft على مجموعة من المستندات الحقيقية على جهاز Mac واحد، مع تقييم كل جدول مقابل قائمة تحقق وضعتها قبل الاختبار وقياس زمن كل عملية تحويل. الخلاصة السريعة: على المدخلات النظيفة هو سريع ودقيق، لكن حزمة التثبيت تخفي خلفها بيئة تشغيل تعلّم آلي بحجم 73 ميغابايت لم تكن ضمن حساباتك، كما أن الجداول فيه قد تتعطل بطرق تنجح في اختبار "هل بقي النص؟" وتفشل في اختبار "هل وُضع كل شيء في العمود الصحيح؟". إليك الصورة الكاملة بالأرقام.
ما هو MarkItDown فعلًا
MarkItDown أداة Python من Microsoft لتحويل الملفات ومستندات Office إلى Markdown مهيأ خصيصًا لـ LLMs. أعطه ملف PDF أو .docx أو .xlsx أو .pptx أو صورة أو ملف HTML أو عددًا من الصيغ الأخرى، وسيعيد لك Markdown. ويمكن تشغيله بثلاث طرق: عبر واجهة سطر الأوامر (markitdown file.pdf -o out.md أو عبر stdin)، أو عبر API في Python (MarkItDown().convert(...))، أو عبر خادم MCP اختياري لسير العمل المعتمد على الوكلاء.
أهم نقطة هنا ليست ما يفعله، بل ما لا يفعله، لأن ملف README لا يدّعي ذلك، وقد تأكدت منه أثناء الاختبار: لا زحف، لا عرض JavaScript، لا تتبع للروابط، لا ترقيم صفحات، ولا استخراج للمحتوى الرئيسي بأسلوب أدوات قابلية القراءة. إنه محوّل للمستندات كاملة. أنت تجلب البيانات الخام، وهو يوحّدها. هذا الفرق وحده هو ما يحدد ما إذا كانت هذه الأداة مناسبة لمجموعة أدواتك أم لا، لذلك سأعود إليه أكثر من مرة.
أما المستودع نفسه فهو ضخم بمعايير GitHub الاستعراضية — 165,282 نجمة و11,790 نسخة Fork حتى منتصف يوليو 2026، بترخيص MIT، وآخر إصدار (v0.1.6) صدر في 2026-05-26. لكن هذا العدد من النجوم يعكس حماس مجتمع أدوات LLM ومكانة Microsoft، لا نضج البنية الداخلية للتحويل. كما توجد 833 مشكلة مفتوحة، وبعضها قد يهمك قبل التثبيت (سأعود إلى ذلك لاحقًا).
من HTML إلى Markdown: سريع ومكتمل، مع بقاء العناصر الزائدة
وبما أن بقية سلسلة مراجعات أدواتي تستوعب أربعة نماذج ويب ثابتة، فقد مرّرت إلى MarkItDown ملفات HTML المحلية نفسها — ليس لتقييمه كأداة زحف، بل لأرى جودة تحويله من HTML إلى Markdown. وعلى الصفحات الجيدة الوسوم هو بالفعل ممتاز.
أربع صفحات كلها تحولت بالإعداد الأساسي من دون إضافات، وكل مؤشرات محتوى الجسم نجت. مقال ويكيبيديا الخاص بـ"Web scraping" (226 كيلوبايت) خرج مع شجرة العناوين كما هي — عنوان h1 واحد، وسبعة h2، واثنا عشر h3، مطابقًا للبنية الفعلية للمقال — كما احتُفظ بـ 418 رابطًا بصيغة [text](url) الصحيحة. وجدول إحصائيات الهوكي 26×9 في صفحة Scrape This Site forms تحوّل إلى جدول GFM نظيف من 27 صفًا (رأس + فاصل + 26 صف بيانات)، مع الخلايا الفارغة وكل شيء. أما السرعة فلم تكن مشكلة: الوسيط من 48 مللي ثانية لصفحة الاقتباسات الصغيرة إلى 352 مللي ثانية لصفحة ويكيبيديا ذات 226 كيلوبايت.
لكن هنا تكمن الملاحظة المهمة، وهي قرار تصميمي أكثر من كونها عيبًا. MarkItDown لا يزيل العناصر الزائدة. فهو يحوّل <body> بالكامل، وبالتالي تنتقل معه عناصر واجهة الموقع — وتزداد هذه البقايا كلما زادت الواجهات والحوامل البصرية في الصفحة.
| الصفحة | عدد الأحرف الناتجة | العناوين (h1/h2/h3) | الروابط | أسطر الواجهة الزائدة |
|---|---|---|---|---|
| Books to Scrape | 10,478 | 1 / 0 / 0 | 94 | 0.6% (1/159) |
| Quotes to Scrape | 2,973 | 1 / 1 / 0 | 55 | 1.2% (1/86) |
| ScrapeThisSite forms | 3,385 | 1 / 0 / 0 | 31 | 6.7% (5/75) |
| Wikipedia Web scraping | 60,159 | 1 / 7 / 12 | 418 | 12.4% (42/338) |
في الصفحة الرئيسية Books القريبة جدًا من خلوّها من العناصر الزائدة، 0.6% فقط من الأسطر الناتجة هي عناصر واجهة. أما في ويكيبيديا فالنسبة 12.4% — أي 42 من أصل 338 سطرًا غير فارغ هي من نوع "الانتقال إلى المحتوى"، و"إظهار/إخفاء جدول المحتويات"، و"22 لغة"، و"تم الاسترجاع من"، وتذييلات ملفات تعريف الارتباط والترخيص. حتى شرائط الصيانة في ويكيبيديا مثل "This article needs additional citations" يتم عرضها بأمانة داخل جداول أنابيب ثنائية الأعمدة، وهذا ما يضيف تسعة صفوف جدول في صفحة لا تحتوي على أي جدول بيانات حقيقي.
ولا يعني ذلك أن MarkItDown يفعل شيئًا خاطئًا. إنه محوّل للمستندات كاملة، لا أداة لاستخراج المحتوى القابل للقراءة: تحويل HTML إلى Markdown بأمانة شيء، واستخراج المقال النظيف شيء آخر. أدوات مثل Trafilatura أو Firecrawl تهدف إلى إرجاع المحتوى الرئيسي فقط؛ أما MarkItDown فيعيد الصفحة كلها. من الداخل، ملف _html_converter.py يزيل <script> و<style> ثم يمرر كامل الـ body إلى مكتبة markdownify — من دون أي heuristic للمحتوى الرئيسي في المسار. إذا كنت تريد المقال فقط، فهذا ليس المستوى المناسب.
أرضه الطبيعية: PDF وDOCX وXLSX وPPTX
المستندات هي ما صُمم MarkItDown من أجله. جرّبته على ملفات عامة حقيقية — ورقة arXiv تحتوي على طبقة نصية، وكتاب Bitcoin الأبيض، وملف PDF ممسوح ضوئيًا فقط من دون نص قمت بتوليده ليكون خاليًا تمامًا من النص، إضافة إلى ملفات DOCX/XLSX/PPTX من مجموعة اختبار MarkItDown نفسها (مع UUIDs مضمّنة عمدًا حتى أتمكن من اكتشاف فقدان المحتوى الصامت).
| المستند | حجم الإدخال | عدد الأحرف الناتجة | مؤشرات الاختبار | الوسيط الزمني | ملاحظات |
|---|---|---|---|---|---|
| arXiv 1706.03762 (PDF بطبقة نصية) | 2.2 MB | 40,174 | 7/7 | 3.7 ث (دافئ) | العنوان، "Transformer"، "BLEU"، "References" كلها موجودة |
| ورقة Bitcoin البيضاء (PDF من 9 صفحات) | 184 KB | 22,485 | 6/6 | 1.4 ث | "Satoshi Nakamoto"، و"proof-of-work"، و"Conclusion" موجودة |
| PDF ممسوح ضوئيًا (من دون طبقة نصية) | 89 KB | 0 | 0/4 | 15 مللي ثانية | مخرجات فارغة، بلا خطأ، بلا OCR |
| DOCX (test.docx) | 136 KB | 4,651 | — | 70 مللي ثانية | عناوين + جدول GFM؛ الـ UUIDs المضمّنة تبقى سليمة |
| DOCX مع معادلات | 15 KB | 240 | — | 101 مللي ثانية | Office Math محفوظ بصيغة LaTeX |
| XLSX (test.xlsx) | 12 KB | 808 | — | 57 مللي ثانية | كل ورقة → ## SheetName + جدول GFM |
| PPTX (test.pptx) | 278 KB | 2,047 | — | 52 مللي ثانية | علامات ترقيم الشرائح، والجداول، والمخطط → جدول |
كان استرجاع النص من ملفات PDF ذات الطبقة النصية ممتازًا — 7 من 7 مؤشرات محددة مسبقًا في ورقة arXiv "Attention Is All You Need"، و6 من 6 في ورقة Bitcoin البيضاء — ولم تفقد أي من ملفات Office أي UUID sentinel، أي لا فقدان صامت للمحتوى في مواد الاختبار المرجعية للمشروع. ومن المكاسب الضيقة الجميلة: مسار DOCX (عبر mammoth) يحافظ على معادلات Office Math بصيغة LaTeX، فيحوّل equations.docx إلى رياضيات فعلية داخل $$...$$. إذا كنت تمرر مستندات Word مليئة بالمعادلات إلى LLM، فهذه ميزة حقيقية وإن كانت متخصصة، ولم أجدها موثقة بوضوح في مكان آخر.
وهناك نتيجتان في هذا المجال تستحقان اهتمامًا خاصًا، لأنهما الأكثر قابلية لأن تضرباك في الإنتاج.
PDF الممسوح ضوئيًا الذي يختفي
إذا مرّرت إلى MarkItDown ملف PDF قائمًا على الصور فقط من دون طبقة نصية، فسيعيد سلسلة فارغة. صفر أحرف، بلا استثناء، بلا تحذير — ويُنجز التحويل في نحو 15 مللي ثانية لأنه لا يوجد شيء يستخرج. مسار PDF في MarkItDown يعتمد على استخراج النص فقط (pdfminer وpdfplumber في الخلفية)، ولا يأتي معه أي OCR ضمن التثبيت الأساسي أو حتى في أي خيار pip إضافي.
هذا مهم جدًا في المعالجة الدفعية. مطوّر يمرر مجلدًا من ملفات PDF، وبعضها عبارة عن مسح ضوئي، سيحصل على نتائج فارغة بصمت لتلك الملفات من دون أي إشارة إلى أنها تخطّت المعالجة. تحققت من أن الملف التجريبي نفسه لم يكن تالفًا عبر تشغيل extract_text الخاص بـ pdfminer عليه مباشرة — النتيجة كانت صفر أحرف، وطبقة النص غير موجودة، أي أن الأمر مؤكد — لذا فالمخرجات الفارغة هي سلوك MarkItDown الحقيقي على ملف ممسوح حقيقي. وهذا يعيد إنتاج فجوة OCR المعروفة منذ مدة طويلة (#1268) والتي لا تزال مفتوحة في المشروع الأساسي. المسار الموثق هو Azure Document Intelligence الاختياري أو إضافة Plugin؛ ولا واحد منهما موجود في التثبيت الافتراضي.
ملفات PDF تخرج كنص مسطّح لا كبنية
في كلا ملفي PDF ذوي الطبقة النصية، أنتج MarkItDown صفر علامات عناوين Markdown. ملف PDF لا يحمل وسومًا دلالية للعناوين، وMarkItDown لا يستنتجها من حجم الخط، لذا تهبط كل سطرية إلى مستوى النص العادي. استرجاع النص مرتفع؛ لكن البنية مسطحة.
وهذا ليس مجرد ملاحظتي وحدي. تقيمات عامة من طرف ثالث تمنح MarkItDown نحو 0.0 في هرمية عناوين PDF، ونحو 0.27 في دقة الجداول، وهو أقل بكثير من 0.88 لدى Docling المدعوم بـ TableFormer (انظر مقارنة MarkItDown مقابل Docling مقابل Marker ومعيار READoc). نتائجي تعيد إنتاج نتائجهم، وهذه نقطة قوة في الدليل — أرقامي تتفق مع مصدر خارجي. أما المفاضلة التي تذكرها هذه المقاييس نفسها فهي أن MarkItDown أسرع بحوالي 100 مرة من Docling، وهو ما ينسجم مع أوقاتي التي كانت بالثواني لا بالدقائق على مستندات تقضي عليها أدوات النماذج التخطيطية بالدقائق. الخلاصة: MarkItDown يمنحك نص PDF نظيفًا وسريعًا؛ لكنه لا يمنحك بنية PDF. إذا كانت العناوين والجداول يجب أن تبقى سليمة، فالمستوى المناسب هو أداة تعتمد على نموذج تخطيط مثل Docling أو Marker.
الجداول: المحتوى ينجو دائمًا، لكن البنية لا تنجو دائمًا
الجداول هي المكان الذي ينفصل فيه سؤال "هل بقي النص؟" عن سؤال "هل أصبحت البيانات قابلة للاستخدام؟"، لذلك بنيت مصفوفة من 13 حالة — جدول <table> لكل حالة، وكل حالة قيّمتها مقابل قائمة تحقق كتبتها قبل التشغيل — لمعرفة بالضبط أي الأشكال تصمد وأيها يتعطل.
الخلاصة الأساسية: MarkItDown لم يفقد محتوى أي جدول. جميع الحالات الـ13 احتفظت بـ 100% من الرموز المحددة مسبقًا. لكن الدقة البنيوية انقسمت إلى ثلاثة أنواع. سبع من أصل 13 أنتجت شبكة GFM سليمة (عادية، ورأس مع colspan، وعرض 24 عمودًا، ومن دون رأس، وخلايا فارغة، ومحتوى داخل كتلة، والعربية من اليمين إلى اليسار). أربع حالات خرجت متعرجة، لأن Markdown لا يملك مفهوم الخلية الممددة، لذلك rowspan وcolspan والمصادر المشوهة تنتج صفوفًا قصيرة. وحالتان كانتا مكسورتين بشكل مباشر.
والحالتان المكسورتان تستحقان تسمية واضحة. الجدول المتداخل (أي <table> داخل <td>) يتم تسطيحه داخل السطر، فيُسكب هو نفسه مع فواصل الأنابيب وصف الفاصل الخاص به داخل الخلية الأم، منتجًا صفًا فاسدًا يضم 14 "عمودًا". كما أن الرمز | الحرفي داخل خلية لا يتم هروبه — فالنص a | b يصبح عمودين، وx || y يصبح ثلاثة — وبالتالي يصدر جدول ذو عمودين صفوفًا من عمودين وثلاثة وأربعة أعمدة، فيقرأ أي محلل Markdown لاحق الحدود بشكل خاطئ. والمثير أن النجوم والـ backticks داخل الخلية يتم هروبهما، أما الأنابيب فلا. السبب الجذري أن مسار HTML في MarkItDown يستخدم التعامل الافتراضي الخاص بـ markdownify مع الجداول، بينما يبدّل الصنف المخصص الروابط والصور والعناوين فقط، لا خلايا الجدول. ونفس فئة خطأ هروب الأنابيب موجودة كمشكلة مفتوحة أيضًا في محول CSV (#2019)، لكن ذلك الإصلاح لا يمس مسار HTML الذي اختبرته هنا.
والأكثر دقة — وهو ما أود أن يراه مهندس بيانات تحديدًا — هو rowspan. الحالة t03 لا تصبح متعرجة فقط؛ بل تُحدث عدم محاذاة صامتًا. الوسم rowspan=2 الخاص بـ "Fruit" يُخرج مرة واحدة، والصف الذي تحته يتحول إلى صف قصير من عمودين (| Banana | 8 |)، وبالتالي يستقر "Banana" تحت عمود Group بدل Item. كل رمز موجود. لكن المستهلك الساذج الذي يقرأ العمود الثاني سيحصل على القيمة الخطأ. هذا هو نوع العيوب الذي ينجح في اختبار بقاء النص ثم يفسد مجموعة بيانات بصمت.
ومحدودية spans نفسها هي قيد تصميمي معروف ومتابَع (#1211، #1248) — شبكة GFM المسطحة فعلًا لا تستطيع تمثيل الامتدادات أو التعشيش، لذلك يضحي المحول بالبنية مقابل اكتمال المحتوى. وهناك أيضًا سلوكيات جيدة في الصورة: الجداول من دون رأس تحصل على صف رأس فارغ مُولّد تلقائيًا (حتى لا تُدفَع أي بيانات إلى الرأس بصمت)، والخلايا الفارغة تُحفظ، ووسم <caption> يبقى كسطر نصي فوق الجدول.
التثبيت والإقلاع: الضريبة التي لا يحذرك منها وصف "أداة خفيفة"
لا شيء فاجأني هنا أكثر من ذلك، وهو أيضًا الموضع الذي يبالغ فيه وصف "الأداة الخفيفة في Python" من دون أن يقول ذلك صراحة.
أولًا، لا تشغّل pip install 'markitdown[all]'. على Python 3.14، سيعود بهدوء إلى markitdown 0.0.2 — إصدار عمره سنتان — وقد كررت ذلك فعليًا داخل virtualenv نظيف. وعند التثبيت المقيّد تظهر الأسباب: pip install 'markitdown[all]==0.1.6' يفشل لأن الإضافة [all] تثبّت youtube-transcript-api~=1.0.0، وعلى PyPI الحالي كل الإصدارات ضمن هذا النطاق مقيّدة بـ Python أقل من 3.14، بينما الإصدارات المتوافقة مع 3.14 تقع خارج هذا القيد. لذلك يحلّ resolver المشكلة بالعودة حتى آخر إصدار يمكنه إرضاء اعتمادياته. وهذا يطابق مشكلة upstream مفتوحة (#2179). والحل بسيط: ثبّت الإصدار بدقة ثم ثبّت الإضافات كلًا على حدة: pip install 'markitdown==0.1.6'، ثم pip install 'markitdown[pdf,docx,pptx,xlsx,xls]==0.1.6'. كل واحد من هذه الأوامر ينجح بشكل نظيف؛ المشكلة فقط في الحزمة الموحدة [all] التي تحمل القيد المسموم. (وهذه الفخاخ تعتمد على إصدار Python — على Python 3.13 أو أقل قد لا يظهر هذا السلوك، لذلك قد يُحل [all] بشكل مختلف.)
ثانيًا، البصمة. التثبيت الأساسي يستهلك 161 ميغابايت (بيئة فارغة 13 ميغابايت + 148 ميغابايت). ومن هذا الحجم، يستهلك onnxruntime وحده 73 ميغابايت وnumpy 34 ميغابايت، أي 107 ميغابايت معًا — 66% من كامل بصمة النسخة الأساسية — وكلاهما يدخل عبر اعتماد واحد فقط: magika، كاشف نوع الملفات المعتمد على التعلم الآلي من Google. بمعنى أن محوّل نصوص يأتي مع بيئة استدلال ONNX بحجم 73 ميغابايت ضمن التثبيت الأساسي قبل أن تضيف أي إضافة خاصة بالمستندات. وإذا أضفت إضافات المستندات، تصل البيئة إلى 310 ميغابايت. هذا أخف بكثير من stack يعتمد على متصفح headless، لكن إن كنت تتوقع أداة صغيرة تثبتها وتنتهي، فاعلم أن معها ONNX runtime مرفقًا.
ثالثًا — وهذه هي النتيجة الوحيدة في مجموعي التي تجاوزت كل اختبارات الندرة التي أجريتها — حتى بعد تثبيت نظيف، فإن import markitdown يكلف نحو 3.35 ثانية على هذا الجهاز. التكلفة تحدث تقريبًا بالكامل عند الاستيراد: markitdown._markitdown يستورد مبكرًا سجل المحولات كله (2.56 ثانية تراكمية، 76% من الإجمالي)، والذي يسحب معه pandas (594 مللي ثانية، عبر محول XLSX)، وpython-pptx (427 مللي ثانية)، وmagika (354 مللي ثانية)، وrequests (270 مللي ثانية) — سواء كنت ستحول هذه الصيغ أم لا. في خدمة طويلة التشغيل، هذه الكلفة تتوزع ولا تهم كثيرًا. لكن في تشغيل CLI أو بداية باردة داخل serverless، فهي ضريبة حقيقية لكل عملية لا يوحي بها وصف "الأداة الخفيفة". (تنبيه منصف: هذا تتبع واحد فقط، ويُعامل كملاحظة واحدة لا كتوزيع متعدد التشغيلات.)
على نطاق أكبر: لا ينهار، لكن احسب CPU للـ PDFs وRAM لجداول البيانات
دفعت أربعة موضوعات كبيرة عبر الأداة، كل واحد في عملية مستقلة حتى لا تختلط ذروة الذاكرة بآثار تشغيل سابق. لم ينهَر شيء. لكن نمط التكلفة غير متوازن.
| الموضوع | الإدخال | عدد الأحرف الناتجة | الوسيط الزمني | التغير في ذروة RSS |
|---|---|---|---|---|
| NIST SP 800-53r5 (PDF من 492 صفحة) | 5.9 MB | 1,625,365 | 192.5 ث | +40 MB |
| XLSX 50,000 صف × 8 أعمدة | 2.1 MB | 3,722,955 | 62.1 ث | +374 MB |
| arXiv 1706.03762 (حوالي 15 صفحة) | 2.2 MB | 40,174 | 12.6 ث | +25 MB |
| XLSX 200 صف × 64 عمودًا | 46 KB | 120,129 | 2.9 ث | +22 MB |
استغرق ملف NIST PDF من 492 صفحة وسيطًا قدره 192.5 ثانية — أي نحو 3.2 دقائق، أو 0.39 ثانية لكل صفحة — لأن pdfplumber يجري كشفًا للشكل/الحقول اعتمادًا على موضع الكلمات في كل صفحة. وظلت ذروة RSS عند +40 MB، ما يعني أن العائق هو CPU لا الذاكرة. وحتى PDF arXiv ذو 15 صفحة احتاج 12.6 ثانية في عملية مستقلة تمامًا، وهو ما يزيد بنحو 3.4 مرات عن 3.7 ثانية التي ظهر بها الملف نفسه في وضع دافئ ضمن مجموعة المستندات الخاصة بي. هذا الفرق هو كلفة العملية الباردة، ويؤكد أن العمل لكل صفحة هو المحرك الأساسي، لا حجم الملف الخام. إذا أردت رقمًا واحدًا قابلًا للنقل لذلك الملف، فاعتمد 12.6 ثانية في العملية المستقلة.
أما مسار جداول البيانات فيقلب موضع الاختناق. ملف XLSX بحجم 2.1 MB وبـ 50,000 صف تضخّم إلى +374 MB ذروة RSS (و3.7 مليون حرف ناتج) لأن المحوّل يحمّل الورقة كاملة ويبني سلسلة Markdown ضخمة واحدة في الذاكرة. لذا فالنصيحة العملية واضحة: للـ PDFs الكبيرة، خصص دقائق CPU؛ ولجداول البيانات الكبيرة، خصص مئات الميغابايت من RAM. هذه أرقام مأخوذة من جهاز واحد على macOS arm64 وPython 3.14، والثوابت لكل صفحة ولكل صف خاصة بالمنصة — لكن الشكل العام (PDF بطيء ويستهلك CPU، وXLSX ثقيل على الذاكرة، ولا شيء ينهار) هو الجزء القابل للنقل.
أين يناسب Thunderbit — وأين لا يناسب
جرّب Thunderbit لاستخراج بيانات الويب
هذه هي المقارنة التي يسهل فيها المبالغة، لذلك سأرسم الحد بدقة. MarkItDown وThunderbit يحلان مشكلتين متجاورتين، لا المشكلة نفسها.
MarkItDown يحوّل الملفات التي لديك أصلًا. Thunderbit يجلب الصفحة أولًا. نقطة النهاية /distill في Thunderbit تحوّل صفحة ويب حية إلى Markdown نظيف جاهز لـ LLM، مع معالجة عرض JavaScript ومقاومة الحظر والمحتوى الديناميكي الذي لا يملك MarkItDown أي آلية له، كما أن نقطة النهاية /extract تُرجع JSON منظمًا يطابق المخطط، لا Markdown خامًا فقط. وللمطورين، يتوفر هذا عبر API (POST /distill / POST /extract)، وخادم MCP، وCLI (npx @thunderbit/thunderbit-cli) فوق محرك AI واحد، وهو نفسه خلف الإضافة التي يستخدمها أكثر من 100,000 مستخدم.
إذًا هناك تداخل في نقطة واحدة فقط — كلاهما يمكنه إخراج Markdown جاهز لـ LLM — لكن مجال الإدخال مختلف: Thunderbit في /distill يأخذ عنوان URL من الويب المفتوح، بينما MarkItDown يأخذ ملفًا محليًا. هما ليسا بديلين مباشرين، ولا أتعامل معهما على هذا الأساس. الاستخدام الواقعي يجمعهما معًا: اجلب وازحف الويب بـ Thunderbit (أو خدمة على نمط Firecrawl)، ثم وحّد المستندات المحلية المختلطة التي لديك — PDFs والعروض والجداول — باستخدام MarkItDown. أحدهما يتعامل مع الشبكة، والآخر يتعامل مع درج الملفات.
الإيجابيات والسلبيات
نقاط القوة
- استرجاع كامل لمحتوى HTML النظيف (4/4 صفحات)، مع الحفاظ الدقيق على شجرة العناوين والروابط
- استرجاع مرتفع لنصوص PDF/DOCX (arXiv 7/7، وBitcoin 6/6) من دون فقدان صامت للمحتوى في ملفات Office المرجعية
- الحفاظ على معادلات Office Math بصيغة LaTeX — مكسب متخصص لكنه حقيقي
- لم ينهَر في أي سيناريو كبير، حتى مع PDF من 492 صفحة وXLSX من 50 ألف صف
- سهل الاستدعاء: CLI، و
convert()، وتمرير عبر stdin، وخادم MCP اختياري - بترخيص MIT، وصيانة نشطة من Microsoft، وتتبع مشاكل متجاوب
نقاط الضعف
- يبقي العناصر الزائدة — حتى 12.4% من الأسطر في ويكيبيديا؛ ليس أداة لاستخراج المقالات
- الجداول تتعطل مع spans والتعشيش والأنابيب داخل الخلية (2/13 مكسورة، و4/13 متعرجة)، وrowspan قد يسبب عدم محاذاة صامتًا
- ملفات PDF الممسوحة/القائمة على الصور تعود بمخرجات فارغة بلا OCR وبلا خطأ
- مخرجات PDF لا تحتوي على أي بنية عناوين (وهو ما تؤكده المقاييس العامة)
- تثبيت أساسي بحجم 161 MB يحمل ONNX runtime بحجم 73 MB؛ واستيراد بارد بنحو 3.35 ث
- الإضافة
[all]تعود بصمت إلى إصدار قديم 0.0.2 على Python 3.14
من ينبغي أن يستخدمه، ومن ينبغي ألا يستخدمه
اختر MarkItDown إذا كنت توحّد كومة من المستندات المحلية المختلطة — Word وExcel وPowerPoint وPDFs ذات طبقة نصية — إلى Markdown لمسار LLM، وكنت تهتم أكثر باكتمال النص من الحفاظ على البنية. كمرحلة نهائية في مهمة دفعية، لتحويل النص النظيف إلى نموذج، فهو سريع، أمين، ومجاني.
تجاوزه، أو استخدمه مع أداة أخرى، إذا كانت مهمتك من هذه الأنواع: تريد فقط المقال الرئيسي من صفحة ويب (استخدم أداة قابلية قراءة أو أداة على نمط Firecrawl)؛ تحتاج أن تبقى عناوين PDF وجداوله سليمة (فهنا Docling أو Marker هو المجال المناسب)؛ أو أن مدخلاتك تشمل مستندات ممسوحة تتطلب OCR (ستحتاج إلى Azure backend أو أداة مختلفة تمامًا). وإذا كنت تظن أنك تبحث عن scraper — أداة تجلب الصفحات وتزحف إليها — فهذا ليس ذلك إطلاقًا.
التقييم الأولي الذي أجريته، على سلم تقييم يشبه أدوات الزحف، وضع MarkItDown عند 60/100، وهذا المجموع المنخفض هو أثر جانبي لتقييم محوّل على اختبار مخصص لزاحف. على أرضه الخاصة، درجات دقة النص عالية؛ أما نقاط ضعفه فهي بنيوية (الجداول، عناوين PDF) ومرتبطة بالحزمة (البصمة، الاستيراد، فخ [all]) لا بجودة النص. إذا حكمت عليه كما هو — محوّل ملفات إلى Markdown — فستجده أداة قوية ومصانة جيدًا، مع بعض الحواف الحادة التي يجب أن تعرفها قبل إدخاله في الإنتاج.
الأسئلة الشائعة
هل MarkItDown أداة زحف ويب؟
لا. فهو لا يملك زاحفًا، ولا عرض JavaScript، ولا تتبعًا للروابط، ولا ترقيم صفحات. إنه يحوّل الملفات والمستندات التي لديك أصلًا — PDF، DOCX، XLSX، PPTX، الصور، HTML — إلى Markdown. إذا كنت بحاجة إلى جلب صفحات الويب الحية والزحف إليها، فستحتاج إلى أداة scraping مثل Thunderbit أو Firecrawl؛ أما MarkItDown فهو الخطوة التي تأتي بعد ذلك لتحويل الملفات المحلية أو المُجلبة إلى Markdown نظيف.
لماذا يثبت pip install markitdown[all] إصدارًا قديمًا؟
على Python 3.14، تثبّت الإضافة [all] youtube-transcript-api~=1.0.0، وجميع الإصدارات ضمن هذا النطاق مقيدة بإصدارات Python أقل من 3.14. لا يستطيع resolver إرضاء هذا القيد، فيعود بصمت إلى markitdown 0.0.2، وهو إصدار عمره سنتان. الحل هو تثبيت الإصدار بدقة ثم تثبيت الإضافات منفصلة: pip install 'markitdown==0.1.6'، ثم إضافة 'markitdown[pdf,docx,pptx,xlsx,xls]==0.1.6'. وهذا موثق كـ issue #2179.
هل يقوم MarkItDown بعمل OCR على ملفات PDF الممسوحة؟
ليس في التثبيت الافتراضي. مسار PDF فيه يعتمد على استخراج النص فقط، لذلك أي PDF قائم على الصور فقط ومن دون طبقة نصية سيعود كسلسلة فارغة — بلا خطأ، بلا تحذير. يتطلب OCR وجود Azure Document Intelligence backend اختياري أو Plugin، ولا شيء منهما يأتي افتراضيًا. وهذه فجوة معروفة ومتابعة منذ مدة (issue #1268).
ما مدى جودة MarkItDown مع الجداول؟
من ناحية المحتوى، جيد جدًا — ففي اختباري المؤلف من 13 حالة احتفظ بنسبة 100% من محتوى الجداول في كل حالة. أما من ناحية البنية، فالأمر يعتمد على الشكل: الجداول البسيطة والواسعة ومن دون رأس أو مع خلايا فارغة تخرج كشبكات GFM نظيفة، لكن rowspan وcolspan يخرجان بشكل متعرج (وrowspan قد يحرك البيانات بصمت إلى عمود خاطئ)، والجداول المتداخلة تُسطح إلى صفوف فاسدة، والأنابيب الحرفية داخل الخلايا لا تُهَرَّب. تنسيق Markdown المسطح ببساطة لا يستطيع تمثيل الامتدادات أو التعشيش.
هل MarkItDown سريع بما يكفي للمستندات الكبيرة؟
هو لا ينهار مع الملفات الكبيرة، لكن خصص الموارد حسب النوع. PDF من 492 صفحة استغرق نحو 3.2 دقائق (حوالي 0.39 ثانية لكل صفحة) لأنه يجري كشف النماذج لكل صفحة، وهو محدود بالـ CPU. أما جدول بيانات من 50,000 صف فأنهى المهمة في نحو دقيقة لكنه استخدم +374 MB من RAM لأنه يبني سلسلة Markdown واحدة كبيرة في الذاكرة. بالنسبة للـ PDFs الكبيرة، احسب دقائق CPU؛ وبالنسبة لجداول البيانات الكبيرة، احسب مئات الميغابايت من RAM.
جرّب Thunderbit لاستخراج بيانات الويب Get Started Free
