MarkItDown este adesea pus în aceeași oală cu web scraper-ele, dar eticheta asta e greșită. Nu are crawler, nu are motor JavaScript și nu poate lua un URL ca să-i curețe conținutul de elementele inutile. Ce face, de fapt, este să ia fișierele pe care le ai deja — un PDF, un document Word, un spreadsheet, o prezentare — și să le transforme în Markdown, astfel încât un model lingvistic să-l poată citi.
Timp de câteva săptămâni, am testat MarkItDown de la Microsoft pe un set de documente reale, pe un singur Mac, verificând fiecare tabel față de un manifest pregătit înainte de rulare și măsurând timpul fiecărei conversii. Concluzia pe scurt: pe input curat este rapid și fidel, însă pachetarea ascunde un runtime de machine learning de 73 MB pe care nu l-ai cerut, iar tabelele se strică în moduri care trec testul „a supraviețuit textul?” și îl pică pe cel „datele sunt în coloana corectă?”. Mai jos este imaginea completă, cu cifrele.
Ce este, de fapt, MarkItDown
MarkItDown este un utilitar Python de la Microsoft care convertește fișiere și documente Office în Markdown optimizat pentru LLM-uri. Îi dai un PDF, un .docx, un .xlsx, un .pptx, o imagine, un fișier HTML sau alte câteva formate și îți întoarce Markdown. Poate fi folosit în trei moduri: din CLI (markitdown file.pdf -o out.md sau alimentat prin stdin), prin API-ul Python (MarkItDown().convert(...)) și, opțional, ca server MCP pentru fluxuri de lucru cu agenți.
Cea mai importantă clarificare este ce nu face, pentru că nici README-ul nu pretinde asta, iar eu am confirmat-o în teste: nu face crawling, nu randază JS, nu urmărește linkuri, nu gestionează paginare și nu extrage conținutul principal în stil readability. Este un convertor pentru documente întregi. Tu aduci bytes-ii; el îi standardizează. Diferența asta singură decide dacă merită sau nu în stack-ul tău, așa că o voi repeta de mai multe ori.
Repo-ul în sine arată impresionant în metricile de vanitate de pe GitHub — 165.282 de stele și 11.790 de fork-uri, la mijlocul lui iulie 2026, licență MIT, iar cea mai recentă versiune (v0.1.6) a apărut pe 2026-05-26. Totuși, acel număr de stele spune mai mult despre entuziasmul general pentru unelte LLM și despre faptul că repo-ul aparține Microsoft decât despre maturitatea internă a motorului de conversie. Mai există și 833 de issue-uri deschise, iar câteva dintre ele contează înainte să-l instalezi (revin imediat).
HTML în Markdown: rapid și complet, cu boilerplate inclus
Pentru că restul seriei mele de recenzii pentru scrapers folosește aceleași patru fixture-uri web, i-am dat lui MarkItDown exact aceleași fișiere HTML locale — nu ca să-l notez ca scraper, ci ca să văd cât de bun este la conversia HTML în Markdown. Pe pagini bine structurate, chiar este bun.
Toate cele patru pagini s-au convertit pe instalarea de bază, fără extra-uri, iar fiecare probă de conținut din body a supraviețuit. Articolul Wikipedia despre „Web scraping” (226 KB) a ieșit cu arborele de heading-uri oglindit — un h1, șapte h2-uri, douăsprezece h3-uri, exact ca structura reală a articolului — iar cele 418 linkuri au rămas păstrate corect ca [text](url). Tabelul de statistici hockey 26×9 de pe pagina Scrape This Site forms a devenit un tabel GFM curat, cu 27 de rânduri (antet + separator + 26 de rânduri de date), inclusiv celulele goale. Viteza n-a fost o problemă aici: mediana a fost de 48 ms pentru pagina scurtă cu citate și 352 ms pentru pagina Wikipedia de 226 KB.
Dar există o capcană, și ține de design, nu de bug. MarkItDown nu elimină boilerplate-ul. Convertește întreg <body>-ul, așa că elementele de UI ale site-ului rămân în output — iar acest reziduu crește odată cu cât de mult chrome are pagina.
| Pagină | Caractere output | Heading-uri (h1/h2/h3) | Linkuri | Linii de chrome site |
|---|---|---|---|---|
| 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) |
Pe pagina Books, care e aproape lipsită de chrome, doar 0,6% din liniile outputului sunt chrome. Pe Wikipedia, procentul urcă la 12,4% — 42 din 338 de linii ne-goale sunt de tipul „jump to content”, „toggle the table of contents”, „22 languages”, „retrieved from”, plus footer-ele de cookie și licență. Bannierele de mentenanță Wikipedia („This article needs additional citations”) ajung chiar și ele redate fidel în tabele cu două coloane, iar de aici provin nouă rânduri de tabel într-o pagină fără tabel real de date.
Asta nu înseamnă că MarkItDown face ceva greșit. Este un convertor de documente întregi, nu un extractor de articol: conversia fidelă HTML în Markdown este altă sarcină decât extragerea curată a unui articol. Trafilatura și unelte de tip Firecrawl încearcă să întoarcă doar conținutul principal; MarkItDown întoarce pagina. Sub capotă, _html_converter.py elimină <script> și <style>, apoi trimite întreg body-ul către biblioteca markdownify — nu există niciun heuristic de conținut principal pe traseu. Dacă vrei doar articolul, acesta este nivelul greșit.
Domeniul lui: PDF, DOCX, XLSX, PPTX
Documentele sunt terenul pentru care a fost construit MarkItDown. L-am testat pe fișiere publice reale — o lucrare arXiv cu text layer, whitepaper-ul Bitcoin, un PDF scanat doar-imagine pe care l-am randat fără niciun text și fișierele DOCX/XLSX/PPTX din propriul său set de teste (populate cu UUID-uri ca să pot detecta pierderile silențioase de conținut).
| Document | Input | Caractere output | Probe | Timp median | Observații |
|---|---|---|---|---|---|
| arXiv 1706.03762 (PDF cu text layer) | 2.2 MB | 40,174 | 7/7 | 3.7 s (warm) | titlul, „Transformer”, „BLEU”, „References” prezente |
| Whitepaper Bitcoin (PDF 9 pag.) | 184 KB | 22,485 | 6/6 | 1.4 s | „Satoshi Nakamoto”, „proof-of-work”, „Conclusion” prezente |
| PDF scanat (fără text layer) | 89 KB | 0 | 0/4 | 15 ms | output gol, fără eroare, fără OCR |
| DOCX (test.docx) | 136 KB | 4,651 | — | 70 ms | heading-uri + tabel GFM; UUID-urile încorporate rămân |
| DOCX cu ecuații | 15 KB | 240 | — | 101 ms | Office Math păstrat ca LaTeX |
| XLSX (test.xlsx) | 12 KB | 808 | — | 57 ms | fiecare sheet → ## SheetName + tabel GFM |
| PPTX (test.pptx) | 278 KB | 2,047 | — | 52 ms | markere pentru numărul slide-ului, tabele, chart → tabel |
Reținerea textului în PDF-urile cu text layer a fost excelentă — 7 din 7 probe preînregistrate pentru paper-ul arXiv „Attention Is All You Need”, 6 din 6 pentru whitepaper-ul Bitcoin — iar niciun fișier Office nu a pierdut vreun sentinel UUID, deci nu există pierderi silențioase de conținut în fixture-urile de regresie ale întrețînătorilor. Un câștig foarte bun, dar de nișă: calea DOCX (prin mammoth) păstrează ecuațiile Office Math ca LaTeX, transformând equations.docx în math real de tipul $$...$$. Dacă trimiți către un LLM documente Word pline de formule, aceasta este o forță reală, chiar dacă foarte specifică, pe care n-am găsit-o documentată altundeva.
Două rezultate pe acest teren merită atenție separată, pentru că sunt cele mai probabil să te afecteze.
PDF-ul scanat care dispare
Dacă îi dai lui MarkItDown un PDF doar-imagine, fără text layer, îți întoarce un string gol. Zero caractere, nicio excepție, niciun avertisment — convertit în aproximativ 15 ms pentru că nu are ce extrage. Calea PDF din MarkItDown face doar extragere de text (cu pdfminer și pdfplumber sub capotă) și nu include OCR nici în instalarea de bază, nici prin vreun extra pip.
Asta contează în batch processing. Un dezvoltator care aruncă într-un folder de PDF-uri unele scanate va primi rezultate goale pentru acele fișiere, fără niciun semnal că au fost sărite. Am verificat că fixture-ul nu era corupt rulând direct extract_text din pdfminer — zero caractere eliminate, fără layer de text, confirmat — deci outputul gol este comportamentul real al MarkItDown pe un scan real. Acest lucru reproduce o lipsă OCR de lungă durată, deja raportată (#1268), urmărită de ceva vreme upstream. Calea documentată este backend-ul opțional Azure Document Intelligence sau un plugin; niciunul nu face parte din instalarea implicită.
PDF-urile ies ca text plat, nu ca structură
În ambele PDF-uri cu text layer, MarkItDown a produs zero markeri de heading Markdown. Un PDF nu are tag-uri semantice de heading, iar MarkItDown nu le deduce din dimensiunea fontului, așa că fiecare linie ajunge la nivel de body. Reținerea textului este ridicată; structura este plată.
Nu este doar rezultatul meu. Benchmark-urile publice realizate de terți evaluează ierarhia de heading-uri în PDF a MarkItDown la aproximativ 0.0 și fidelitatea tabelelor în jur de 0.27, mult sub 0.88 obținut de Docling cu TableFormer (vezi comparația MarkItDown vs Docling vs Marker și benchmark-ul READoc). Fixture-urile mele reproduc aceste rezultate, ceea ce întărește dovezile — cifrele mele sunt aliniate cu o sursă externă. Compromisul raportat de aceleași benchmark-uri este că MarkItDown rulează cam de 100 de ori mai repede decât Docling, lucru care se potrivește cu timpii mei de ordinul secundelor, nu minutelor, pe documente pe care un tool bazat pe layout model le procesează în minute. Concluzia: MarkItDown îți oferă text PDF curat și rapid; nu îți oferă structura PDF-ului. Dacă heading-urile și tabelele trebuie păstrate, nivelul potrivit este un tool bazat pe layout model precum Docling sau Marker.
Tabele: conținutul supraviețuiește mereu, structura nu întotdeauna
Tabelele sunt locul în care „a supraviețuit textul?” și „datele mai sunt utilizabile?” se despart, așa că am construit o matrice cu 13 cazuri — câte un <table> pentru fiecare caz, fiecare evaluat față de un manifest scris înainte de rulare — ca să văd exact ce forme rezistă și ce se strică.
Ideea principală: MarkItDown nu a pierdut niciodată conținutul tabelelor. Toate cele 13 cazuri au păstrat 100% din tokenii preînregistrați. Fidelitatea structurală, însă, s-a împărțit în trei. Șapte din treisprezece au produs o grilă GFM bine formată (simplă, header-colspan, lățime 24 de coloane, fără header, cu celule goale, block-in-cell și arabă de la dreapta la stânga). Patru au ieșit „ciufulite”, fiindcă Markdown nu are conceptul de celulă întinsă pe mai multe rânduri sau coloane, așa că rowspan, colspan și sursele malformate produc rânduri scurte. Iar două au fost complet rupte.
Cele două stricăciuni merită numite. Un tabel imbricat (un <table> în interiorul unui <td>) este aplatizat inline, aruncând propriile pipes și separatorul în celula părinte și producând un rând de gunoi cu 14 „coloane”. Iar un caracter literal | dintr-o celulă nu este escap-at — textul a | b devine două coloane, x || y devine trei — astfel încât un tabel cu două coloane generează rânduri cu două, trei și patru coloane, iar orice parser Markdown din aval citește limitele greșit. Interesant este că asteriscurile și backtick-urile din celulă sunt escap-ate; doar pipe-urile nu sunt. Cauza este că ruta HTML din MarkItDown folosește tratarea implicită a tabelelor din markdownify, iar subclass-ul personalizat suprascrie linkurile, imaginile și heading-urile, dar nu și celulele tabelului. Aceeași clasă de bug de escapare a pipe-urilor este prezentă și ca issue deschis pentru convertorul CSV (#2019), deși acel fix nu atinge ruta HTML pe care am testat-o.
Cazul subtil — observația pe care aș vrea cel mai mult să o vadă un data engineer — este rowspan-ul. Cazul t03 nu doar că iese „ciufulit”; aliniază greșit datele fără să anunțe. O etichetă rowspan=2 („Fruit”) este emisă o singură dată, iar rândul de dedesubt devine un rând scurt cu două coloane (| Banana | 8 |), astfel încât „Banana” ajunge sub coloana Group în loc de Item. Toți tokenii sunt acolo. Un consumator naiv care „citește a doua coloană” obține valoarea greșită. Acesta este genul de bug care trece un test de supraviețuire a textului și corupe liniștit un set de date.
Limitarea span-urilor în sine este o constrângere de design cunoscută și urmărită (#1211, #1248) — o grilă GFM plată chiar nu poate reprezenta span-uri sau imbricări, așa că convertorul sacrifică structura pentru completitudinea conținutului. Există și comportamente bune: tabelele fără antet primesc un rând de antet gol generat automat (așa că nicio dată nu este promovată silențios în header), celulele goale sunt păstrate, iar <caption> supraviețuiește ca linie de text deasupra tabelului.
Instalare și startup: taxa despre care un utilitar „ușor” nu te avertizează
Nimic nu m-a surprins mai tare aici, și exact aici formularea de „utilitar Python ușor” promite mai mult decât oferă.
În primul rând, nu rula pip install 'markitdown[all]'. Pe Python 3.14, acesta face backtrack în tăcere către markitdown 0.0.2 — o versiune veche de doi ani — lucru pe care l-am reprodus live într-un venv curat. Motivul apare când încerci să fixezi versiunea: pip install 'markitdown[all]==0.1.6' dă eroare fiindcă extra-ul [all] fixează youtube-transcript-api~=1.0.0, iar pe PyPI-ul actual toate build-urile din acel interval sunt limitate la Python <3.14, în timp ce singurele build-uri compatibile cu 3.14 ies din pin. Așa că resolverul cade până la ultima versiune ale cărei dependențe le poate satisface. Acest lucru corespunde unui issue deschis upstream (#2179). Soluția este simplă: fixezi versiunea și instalezi extra-urile separat: pip install 'markitdown==0.1.6', apoi pip install 'markitdown[pdf,docx,pptx,xlsx,xls]==0.1.6'. Fiecare dintre acestea se rezolvă corect; doar pachetul combinat [all] are pin-ul problematic. (Capcana este dependentă de versiunea de Python — pe Python 3.13 sau mai jos, blocajul poate să nu apară, deci [all] se poate rezolva diferit.)
În al doilea rând, amprenta. Instalarea core ocupă 161 MB (un venv gol de 13 MB plus 148 MB). Din aceasta, onnxruntime (73 MB) și numpy (34 MB) însumează 107 MB — adică 66% din întreaga amprentă core — și ambele sunt aduse de o singură dependență dură: magika, detectorul ML de tip de fișier de la Google. Cu alte cuvinte, un convertor de text livrează un runtime ONNX de 73 MB încă din instalarea de bază, înainte să adaugi vreun extra pentru documente. Dacă adaugi extra-urile pentru documente, venv-ul ajunge la 310 MB. Asta este mult mai ușor decât un stack cu browser headless, dar dacă te așteptai la un micro-utilitar de tipul „pip install și gata”, trebuie să știi că vine la pachet și un runtime ONNX.
În al treilea rând — și acesta este singurul rezultat din tot setul meu care trece toate testele de noutate pe care le-am rulat — chiar și după o instalare curată, import markitdown costă aproximativ 3,35 secunde pe această mașină. Costul apare aproape integral la import: markitdown._markitdown importă agresiv întreg registrul de convertoare (2,56 s cumulativ, adică 76% din total), ceea ce trage după sine pandas (594 ms, prin convertorul XLSX), python-pptx (427 ms), magika (354 ms) și requests (270 ms) — indiferent dacă vei converti vreodată acele formate. Pentru un serviciu de lungă durată, acest cost se amortizează și devine irelevant. Pentru o invocare CLI sau un cold start serverless, este o taxă reală per proces, pe care eticheta de „utilitar ușor” nu te face să o aștepți. (Notă corectă: aceasta este o singură rulare profilată, tratată ca o observație, nu ca o distribuție obținută din mai multe rulări.)
Scalare: nu crapă, dar rezervă CPU pentru PDF-uri și RAM pentru spreadsheets
Am împins prin el patru subiecte mari, fiecare într-un proces separat, ca să nu fie contaminată memoria maximă de o rulare anterioară. Nimic n-a căzut. Profilul costului, însă, este dezechilibrat.
| Subiect | Input | Caractere output | Timp median | Δ RSS maxim |
|---|---|---|---|---|
| NIST SP 800-53r5 (PDF de 492 pagini) | 5.9 MB | 1,625,365 | 192.5 s | +40 MB |
| XLSX 50,000 rânduri × 8 coloane | 2.1 MB | 3,722,955 | 62.1 s | +374 MB |
| arXiv 1706.03762 (~15 pagini PDF) | 2.2 MB | 40,174 | 12.6 s | +25 MB |
| XLSX 200 rânduri × 64 coloane | 46 KB | 120,129 | 2.9 s | +22 MB |
PDF-ul NIST de 492 de pagini a avut o mediană de 192,5 secunde — cam 3,2 minute, adică 0,39 s/pagină — pentru că pdfplumber rulează detecția de formulare pe baza poziției cuvintelor pe fiecare pagină. RSS-ul maxim a rămas la +40 MB, deci e limitat de CPU, nu de memorie. Chiar și PDF-ul arXiv de 15 pagini a avut nevoie de 12,6 secunde într-un proces izolat, adică de circa 3,4 ori mai mult decât cele 3,7 secunde pe care același fișier le-a arătat „warm” în suite-ul meu de documente. Diferența este costul procesului rece și confirmă faptul că munca per pagină este factorul principal, nu mărimea brută a fișierului. Dacă vrei o singură valoare transferabilă pentru acel PDF, folosește cele 12,6 s din rularea izolată.
Calea pentru spreadsheet-uri inversează blocajul. Un XLSX de 2,1 MB, cu 50.000 de rânduri, a explodat la +374 MB RSS maxim (și 3,7 milioane de caractere output) pentru că convertorul încarcă tot sheet-ul și construiește un singur string Markdown mare. Recomandarea practică este clară: pentru PDF-uri mari, alocă minute de CPU; pentru spreadsheet-uri mari, alocă sute de MB de RAM. Acestea sunt cifre obținute pe o singură mașină, pe macOS arm64 și Python 3.14, iar constantele per pagină și per rând depind de platformă — dar forma generală (PDF-ul e lent și consumator de CPU, XLSX-ul e greu pe memorie, nimic nu crapă) este partea care se transferă.
Unde se potrivește Thunderbit — și unde nu
Încearcă Thunderbit pentru extragerea datelor web
Aceasta este comparația pe care ar fi ușor să o exagerezi, așa că trasez linia cu grijă. MarkItDown și Thunderbit rezolvă probleme adiacente, nu aceeași problemă.
MarkItDown convertește fișierele pe care le ai deja. Thunderbit preia mai întâi pagina. Endpoint-ul /distill al Thunderbit transformă o pagină web live în Markdown curat, gata pentru LLM — gestionând randarea JS, anti-bot-urile și conținutul dinamic pentru care MarkItDown nu are mecanisme — iar endpoint-ul /extract întoarce JSON structurat, aliniat la schemă, nu doar Markdown brut. Pentru dezvoltatori, acest lucru este expus prin API (POST /distill / POST /extract), server MCP și CLI (npx @thunderbit/thunderbit-cli), toate pe același motor AI, același care stă și în spatele extensiei cu peste 100.000 de utilizatori.
Așadar, se suprapun într-un singur punct — ambele pot produce „Markdown gata pentru LLM” — dar domeniul de intrare este diferit: distill din Thunderbit ia un URL de pe web-ul public, iar MarkItDown ia un fișier local. Nu sunt echivalente drop-in și nu voi pretinde asta. Stack-ul realist le folosește pe amândouă: extragi și crawl-ezi web-ul cu Thunderbit (sau cu un serviciu de tip Firecrawl), apoi normalizezi documentele locale mixte pe care le ai în plus — PDF-urile, deck-urile și spreadsheet-urile — cu MarkItDown. Unul se ocupă de rețea; celălalt de sertarul cu fișiere.
Avantaje și dezavantaje
Puncte forte
- Reținere completă a corpului pe HTML curat (4/4 pagini), cu arbori de heading și linkuri păstrate fidel
- Reținere foarte bună a textului din PDF/DOCX (arXiv 7/7 probe, Bitcoin 6/6) și nicio pierdere silențioasă de conținut în fixture-urile Office ale întrețînătorilor
- Office Math păstrat ca LaTeX — un câștig real de nișă
- Nu a crăpat la niciun subiect testat, inclusiv un PDF de 492 de pagini și un XLSX cu 50k rânduri
- Foarte simplu de folosit: CLI,
convert(), piping prin stdin și un server MCP opțional - Licență MIT, întreținut activ de Microsoft, tracker de issue-uri receptiv
Puncte slabe
- Păstrează boilerplate-ul — până la 12,4% linii de chrome pe Wikipedia; nu este un extractor de articol
- Tabelele se strică la span-uri, nesting și pipe-uri din celule (2/13 rupte, 4/13 ciufulite), iar rowspan poate alinia greșit datele în tăcere
- PDF-urile scanate/ doar-imagine întorc output gol, fără OCR și fără eroare
- Outputul PDF nu are structură de heading (conform benchmark-urilor publice)
- Instalare core de 161 MB care include un runtime ONNX de 73 MB; ~3,35 s la import rece
- Extra-ul
[all]face rollback în tăcere la versiunea 0.0.2, veche de doi ani, pe Python 3.14
Cine ar trebui să-l folosească și cine nu
Alege MarkItDown dacă standardizezi un teanc de documente locale mixte — Word, Excel, PowerPoint, PDF-uri cu text layer — în Markdown pentru un pipeline LLM și te interesează mai mult completitudinea textului decât păstrarea structurii. Ca convertor de ultim kilometru într-un job batch, care pregătește text curat pentru model, este rapid, fidel și gratuit.
Renunță la el, sau combină-l cu altceva, dacă sarcina ta este una dintre acestea: ai nevoie doar de articolul principal dintr-o pagină web (folosește un tool de tip readability sau Firecrawl); ai nevoie ca heading-urile și tabelele dintr-un PDF să supraviețuiască intacte (acolo intră Docling sau Marker); sau inputurile includ documente scanate care necesită OCR (îți va trebui backend-ul Azure sau un alt tool cu totul). Iar dacă, de fapt, căutai un scraper — ceva care preia și crawl-ează — acesta nu este deloc așa ceva.
Scorul provizoriu pe care l-am calculat, folosind o grilă de evaluare gândită pentru un scraper, îl pune pe MarkItDown la 60/100, iar totalul mic este un artefact al faptului că am evaluat un convertor cu testele unui crawler. Pe terenul lui, scorurile de fidelitate a textului sunt mari; punctele slabe sunt structurale (tabele, heading-uri PDF) și de pachetare (amprenta, importul, capcana [all]), nu de calitate a textului. Judecat pentru ceea ce este — un convertor din fișiere în Markdown — este un tool solid, bine întreținut, cu câteva margini ascuțite pe care e bine să le știi înainte să-l bagi în producție.
Întrebări frecvente
Este MarkItDown un web scraper?
Nu. Nu are crawler, nu randază JavaScript, nu urmărește linkuri și nu face paginare. Convertește fișierele și documentele pe care le ai deja — PDF, DOCX, XLSX, PPTX, imagini, HTML — în Markdown. Dacă ai nevoie să preiei și să crawl-ezi pagini web live, ai nevoie de un tool de scraping precum Thunderbit sau Firecrawl; MarkItDown este pasul de după, care transformă fișierele preluate sau locale în Markdown curat.
De ce pip install markitdown[all] instalează o versiune veche?
Pe Python 3.14, extra-ul [all] fixează youtube-transcript-api~=1.0.0, iar fiecare build din acel interval este limitat la versiuni de Python sub 3.14. Resolverul nu poate satisface pin-ul, așa că revine în tăcere la markitdown 0.0.2, o versiune veche de doi ani. Soluția este să fixezi versiunea și să instalezi extra-urile separat: pip install 'markitdown==0.1.6', apoi adaugi 'markitdown[pdf,docx,pptx,xlsx,xls]==0.1.6'. Problema este urmărită ca issue #2179.
Face MarkItDown OCR pe PDF-uri scanate?
Nu în instalarea implicită. Calea lui PDF face doar extragere de text, deci un PDF doar-imagine, fără text layer, returnează un string gol — fără eroare, fără avertisment. OCR necesită backend-ul opțional Azure Document Intelligence sau un plugin, niciunul nefiind inclus by default. Aceasta este o lipsă urmărită de mult timp (issue #1268).
Cât de bine se descurcă MarkItDown cu tabelele?
Din punctul de vedere al conținutului, foarte bine — în testul meu cu 13 cazuri a păstrat 100% din conținutul fiecărui tabel. Structural, depinde de formă: tabelele simple, late, fără antet și cu celule goale ies ca grile GFM curate, dar rowspan și colspan se destramă (iar rowspan poate alinia greșit datele în coloana greșită), tabelele imbricate sunt aplatizate în rânduri de gunoi, iar pipe-urile literale din celule nu sunt escapate. Formatul plat de tabel din Markdown pur și simplu nu poate reprezenta span-uri sau nesting.
Este MarkItDown suficient de rapid pentru documente mari?
Nu crapă pe fișiere mari, dar trebuie să-ți bugetezi resursele în funcție de tip. Un PDF de 492 de pagini a durat aproximativ 3,2 minute (cam 0,39 s/pagină) pentru că face detecție de formulare pe fiecare pagină și este limitat de CPU. Un spreadsheet cu 50.000 de rânduri s-a terminat în aproximativ un minut, dar a folosit +374 MB de RAM pentru că construiește în memorie un singur string Markdown mare. Pentru PDF-uri mari, planifică minute de CPU; pentru spreadsheet-uri mari, planifică sute de MB de RAM.
Încearcă Thunderbit pentru extragerea datelor web Get Started Free
