MarkItDown viene spesso messo nello stesso sacco degli scraper web, ma è un equivoco. Non ha crawler, non ha motore JavaScript e non c’è alcun modo di passargli un URL per fargli ripulire il boilerplate della pagina. Quello che fa è prendere i byte che hai già — un PDF, un documento Word, un foglio di calcolo, una presentazione — e trasformarli in Markdown leggibile da un language model.
Per un paio di settimane ho messo MarkItDown di Microsoft alla prova su documenti reali, su un solo Mac, confrontando ogni tabella con un manifest preparato prima del test e cronometando ogni conversione. In breve: con input puliti è veloce e fedele, il packaging nasconde un runtime di machine learning da 73 MB che non avevi chiesto, e le tabelle si rompono in modi che superano il controllo “il testo è sopravvissuto?” ma falliscono il controllo “i dati sono finiti nella colonna giusta?”. Ecco il quadro completo, numeri inclusi.
Cos’è davvero MarkItDown
MarkItDown è un’utility Python di Microsoft che converte file e documenti Office in Markdown ottimizzato per gli LLM. Gli puoi dare in pasto un PDF, un .docx, un .xlsx, un .pptx, un’immagine, un file HTML o altri formati supportati, e lui restituisce Markdown. Offre tre modi per usarlo: da CLI (markitdown file.pdf -o out.md, oppure tramite stdin), via API Python (MarkItDown().convert(...)) e, in opzione, come server MCP per workflow agentici.
La distinzione più importante è ciò che non fa, perché non lo promette nel README e il test me l’ha confermato: niente crawling, niente rendering JS, niente follow dei link, niente paginazione e niente estrazione del contenuto principale in stile readability. È un convertitore dell’intero documento. Tu porti i byte; lui li standardizza. Questa singola differenza decide se questo strumento ha senso nel tuo stack oppure no, quindi ci tornerò spesso.
Il repository, visto con gli occhi delle vanity metrics di GitHub, è un peso massimo: 165.282 stelle e 11.790 fork a metà luglio 2026, licenza MIT, con l’ultima release (v0.1.6) uscita il 2026-05-26. Però quel numero di stelle riflette soprattutto l’entusiasmo generale attorno agli strumenti per LLM e il fatto che sia un repo dell’org Microsoft, non la maturità del motore di conversione. Ci sono anche 833 issue aperte, e alcune ti interessano prima ancora di installarlo (ci arrivo tra poco).
Da HTML a Markdown: veloce e completo, boilerplate incluso
Dato che il resto della mia serie di recensioni sugli scraper usa gli stessi quattro fixture web, ho passato a MarkItDown gli identici file HTML locali — non per valutarlo come scraper, ma per capire quanto sia buono nel convertire HTML in Markdown. Su pagine ben marcate, è davvero valido.
Tutte e quattro le pagine sono state convertite con l’installazione base, senza extra, e ogni probe sul contenuto principale è stato preservato. L’articolo di Wikipedia “Web scraping” (226 KB) è uscito con l’albero delle intestazioni perfettamente mantenuto — un h1, sette h2 e dodici h3, in linea con la struttura reale della pagina — e con 418 link conservati nel formato corretto [testo](url). La tabella hockey 26×9 nella pagina Scrape This Site forms page è diventata una tabella GFM pulita da 27 righe (intestazione + separatore + 26 righe dati), celle vuote incluse. La velocità non è stata un problema: mediana di 48 ms per la pagina piccola delle citazioni fino a 352 ms per la pagina Wikipedia da 226 KB.
Ma c’è un però, e non è un bug: è una scelta progettuale. MarkItDown non rimuove il boilerplate. Converte l’intero <body>, quindi la chrome della pagina resta dentro — e il residuo cresce in proporzione alla quantità di chrome presente.
| Pagina | Caratteri in output | Intestazioni (h1/h2/h3) | Link | Righe di chrome del sito |
|---|---|---|---|---|
| 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) |
Sulla homepage di Books, quasi priva di chrome, solo lo 0,6% delle righe in output è chrome. Su Wikipedia, invece, siamo al 12,4%: 42 delle 338 righe non vuote sono “salta al contenuto”, “mostra/nascondi indice”, “22 lingue”, “tratto da”, footer di cookie e licenza. Quei banner di manutenzione di Wikipedia (“This article needs additional citations”) vengono persino resi fedelmente in tabelle pipe a due colonne, ed è da lì che arrivano nove righe di tabella in una pagina che non ha una vera tabella dati.
Tutto questo non significa che MarkItDown stia sbagliando qualcosa. È un convertitore dell’intero documento, non un estrattore di readability: una conversione fedele da HTML a Markdown è un compito diverso dall’estrazione pulita dell’articolo. Strumenti come Trafilatura o Firecrawl puntano a restituire solo il contenuto principale; MarkItDown restituisce la pagina. Sotto il cofano, il suo _html_converter.py rimuove <script> e <style>, poi passa l’intero body alla libreria markdownify — senza alcuna euristica per identificare il contenuto principale. Se vuoi solo l’articolo, sei nel livello sbagliato.
Il suo terreno naturale: PDF, DOCX, XLSX, PPTX
I documenti sono il caso d’uso per cui MarkItDown è stato creato. L’ho testato su file pubblici reali: un paper arXiv con layer testuale, il whitepaper di Bitcoin, un PDF scannerizzato solo immagine che ho renderizzato senza alcun testo, e i file DOCX/XLSX/PPTX del test suite di MarkItDown stesso (con UUID inseriti per poter individuare perdite silenziose di contenuto).
| Documento | Input | Caratteri in output | Probe | Tempo mediano | Note |
|---|---|---|---|---|---|
| arXiv 1706.03762 (PDF con layer testuale) | 2.2 MB | 40,174 | 7/7 | 3.7 s (warm) | titolo, "Transformer", "BLEU", "References" tutti presenti |
| Whitepaper di Bitcoin (PDF 9 pagine) | 184 KB | 22,485 | 6/6 | 1.4 s | "Satoshi Nakamoto", "proof-of-work", "Conclusion" presenti |
| PDF scannerizzato (senza layer testuale) | 89 KB | 0 | 0/4 | 15 ms | output vuoto, nessun errore, niente OCR |
| DOCX (test.docx) | 136 KB | 4,651 | — | 70 ms | intestazioni + tabella GFM; UUID incorporati preservati |
| DOCX con equazioni | 15 KB | 240 | — | 101 ms | Office Math mantenuto come LaTeX |
| XLSX (test.xlsx) | 12 KB | 808 | — | 57 ms | ogni sheet → ## NomeFoglio + tabella GFM |
| PPTX (test.pptx) | 278 KB | 2,047 | — | 52 ms | marker del numero di slide, tabelle, grafico → tabella |
Il richiamo del testo nei PDF con layer testuale è stato eccellente — 7 su 7 probe preregistrati sul paper arXiv “Attention Is All You Need”, 6 su 6 sul whitepaper di Bitcoin — e nessuno dei file Office ha perso un solo UUID sentinella, quindi nessuna perdita silenziosa di contenuto sui fixture di regressione dei manutentori. Un bel vantaggio mirato: il percorso DOCX (tramite mammoth) preserva le equazioni Office Math come LaTeX, convertendo equations.docx in veri blocchi matematici $$...$$. Se stai dando a un LLM documenti Word ricchi di matematica, questo è un punto di forza reale, anche se molto specifico, che non ho trovato documentato altrove.
Su questo terreno ci sono due risultati che meritano attenzione separata, perché sono quelli più facili da incassare senza accorgersene.
Il PDF scannerizzato che sparisce
Se dai a MarkItDown un PDF solo immagine, senza layer testuale, lui restituisce una stringa vuota. Zero caratteri, nessuna eccezione, nessun avviso — conversione in circa 15 ms, perché non c’è nulla da estrarre. Il percorso PDF di MarkItDown fa solo estrazione testuale (sotto il cofano usa pdfminer e pdfplumber) e non include OCR né nell’installazione base né in alcun extra pip.
Questo pesa parecchio in batch. Uno sviluppatore che passa a MarkItDown una cartella di PDF in cui alcuni sono scansioni si ritrova con risultati vuoti e nessun segnale che quei file siano stati saltati. Ho verificato che il fixture non fosse rotto eseguendo direttamente extract_text di pdfminer: zero caratteri puliti, conferma dell’assenza di layer testuale; quindi l’output vuoto è davvero il comportamento di MarkItDown su uno scan reale. Questo riproduce una vecchia lacuna aperta legata all’OCR fallback (#1268), già tracciata da tempo upstream. Il percorso documentato prevede l’backend opzionale Azure Document Intelligence o un plugin; nessuno dei due fa parte dell’installazione predefinita.
I PDF escono come testo piatto, non come struttura
Su entrambi i PDF con layer testuale, MarkItDown non ha prodotto nemmeno un marcatore di intestazione Markdown. Un PDF non contiene tag semantici per le intestazioni e MarkItDown non le inferisce dalla dimensione del font, quindi ogni riga finisce a livello di body. Il richiamo del testo è alto; la struttura è piatta.
Non è solo una mia osservazione. Benchmark pubblici di terze parti assegnano a MarkItDown una precisione della gerarchia di intestazioni PDF intorno allo 0.0 e una fedeltà delle tabelle circa 0.27, ben sotto lo 0.88 di Docling supportato da TableFormer (vedi il confronto MarkItDown vs Docling vs Marker e il benchmark READoc). I miei fixture riproducono quei risultati, e questo rafforza le prove: i miei numeri coincidono con una fonte esterna. Lo stesso benchmark segnala però che MarkItDown è circa 100× più veloce di Docling, e la cosa torna con i miei tempi nell’ordine dei secondi, non dei minuti, su documenti che un tool basato su layout model processa per minuti. Conclusione: MarkItDown ti dà testo PDF pulito e veloce; non ti dà la struttura del PDF. Se le intestazioni e le tabelle devono sopravvivere, il livello giusto è uno strumento come Docling o Marker.
Tabelle: il contenuto sopravvive sempre, la struttura a volte no
Le tabelle sono il punto in cui “il testo è sopravvissuto?” e “i dati sono utilizzabili?” si separano davvero, quindi ho costruito una matrice da 13 casi — un <table> per caso, ciascuno valutato rispetto a un manifest scritto prima del test — per capire esattamente quali forme reggono e quali si rompono.
Il risultato principale: MarkItDown non ha mai perso il contenuto di una tabella. Tutti e 13 i casi hanno conservato il 100% dei token preregistrati. La fedeltà strutturale, però, si è divisa in tre categorie. Sette su tredici hanno prodotto una griglia GFM ben formata (tabella semplice, con header-colspan, larga 24 colonne, senza header, con celle vuote, block-in-cell e arabo da destra a sinistra). Quattro sono diventati irregolari, perché Markdown non ha il concetto di cella spanned, quindi rowspan, colspan e sorgenti malformate generano righe corte. E due sono proprio rotti.
Vale la pena nominare i due casi rotti. Una tabella annidata — un <table> dentro un <td> — viene appiattita inline, riversando pipe e riga separatrice della tabella interna nella cella padre e producendo una riga spazzatura da 14 “colonne”. E un carattere | letterale dentro una cella non viene escapato — il testo a | b diventa due colonne, x || y diventa tre — così una tabella a due colonne genera righe da due, tre e quattro colonne, e qualsiasi parser Markdown a valle legge confini sbagliati. Curiosamente, gli asterischi e i backtick dentro le celle vengono escapati; le pipe no. La causa è che il percorso HTML di MarkItDown usa la gestione tabelle di default di markdownify, mentre la sottoclasse personalizzata sovrascrive link, immagini e intestazioni, ma non le celle delle tabelle. La stessa classe di bug legata all’escaping delle pipe è già una issue aperta anche per il converter CSV (#2019), anche se quella correzione non tocca il percorso HTML che ho testato.
Il caso più subdolo — quello che vorrei vedere subito a un data engineer — è il rowspan. Il caso t03 non si limita a diventare irregolare; allinea male i dati senza segnalarlo. Un’etichetta con rowspan=2 (“Fruit”) viene emessa una sola volta, e la riga sotto diventa una riga corta da due colonne (| Banana | 8 |), quindi “Banana” finisce sotto la colonna Group invece che Item. Tutti i token ci sono. Un consumer ingenuo che legge “la seconda colonna” prende il valore sbagliato. È il tipo di bug che passa il controllo sulla sopravvivenza del testo e corrompe silenziosamente un dataset.
Il limite sugli span, del resto, è una restrizione progettuale nota e tracciata (#1211, #1248): una griglia GFM piatta non può davvero rappresentare span o nesting, quindi il convertitore scambia struttura con completezza del contenuto. Ci sono anche comportamenti positivi: le tabelle senza header ricevono una riga header vuota sintetica (così nessun dato viene promosso silenziosamente a intestazione), le celle vuote vengono preservate e <caption> sopravvive come riga di testo sopra la tabella.
Installazione e startup: il costo che un’utility “leggera” non ti avverte di pagare
Qui non c’è nulla che mi abbia sorpreso più di questo, ed è il punto in cui la narrativa della “piccola utility Python” promette più di quanto mantenga.
Per prima cosa, non eseguire pip install 'markitdown[all]'. Su Python 3.14, fa silenziosamente backtracking fino a markitdown 0.0.2, una release di due anni fa, e l’ho riprodotto in diretta in un virtualenv pulito. Il motivo emerge quando si fissa la versione: pip install 'markitdown[all]==0.1.6' va in errore perché l’extra [all] blocca youtube-transcript-api~=1.0.0, e su PyPI attuale ogni build di quell’intervallo è limitata a Python <3.14, mentre le uniche build compatibili con 3.14 stanno fuori dal vincolo. Il resolver quindi torna fino all’ultima release con dipendenze soddisfacibili. La cosa coincide con una issue upstream aperta (#2179). La soluzione è semplice: fissa la versione e installa gli extra singolarmente: pip install 'markitdown==0.1.6', poi pip install 'markitdown[pdf,docx,pptx,xlsx,xls]==0.1.6'. Ognuno di questi si risolve correttamente; solo il bundle [all] contiene il vincolo “avvelenato”. (Attenzione: è una trappola dipendente dalla versione di Python — con Python 3.13 o precedente il blocco potrebbe non scattare, quindi [all] potrebbe risolversi in modo diverso.)
Secondo: l’ingombro. L’installazione core pesa 161 MB (un virtualenv vuoto da 13 MB più 148 MB). Di questi, onnxruntime (73 MB) e numpy (34 MB) insieme fanno 107 MB — il 66% dell’intero footprint base — e vengono trascinati dentro da una sola dipendenza obbligatoria: magika, il rilevatore di tipo file basato su ML di Google. Quindi un convertitore di testo si porta dietro nel base install un runtime ONNX da 73 MB prima ancora di aggiungere un solo extra per i documenti. Con gli extra documentali il virtualenv arriva a 310 MB. Molto più leggero di uno stack con browser headless, certo, ma se ti aspettavi una micro-utility da “pip install e via”, sappi che un runtime ONNX si porta dietro il resto.
Terzo — e questo è l’unico risultato del mio set che supera ogni test di novità che ho fatto — anche dopo un’installazione pulita, import markitdown costa circa 3,35 secondi su questa macchina. Il costo è quasi tutto al momento dell’import: markitdown._markitdown importa subito l’intero registro dei converter (2,56 s cumulativi, il 76% del totale), trascinando dentro pandas (594 ms, via il converter XLSX), python-pptx (427 ms), magika (354 ms) e requests (270 ms) — indipendentemente dal fatto che tu converta davvero quei formati. Per un servizio a lunga esecuzione questo costo si ammortizza e conta poco. Per una CLI o un cold start serverless, invece, è una tassa reale per processo che l’etichetta “utility leggera” non ti fa aspettare. (Caveat corretto: si tratta di un solo run profilato, considerato una singola osservazione e non una distribuzione su più esecuzioni.)
Scalabilità: non va in crash, ma metti in conto CPU per i PDF e RAM per i fogli di calcolo
Ho spinto quattro casi di grandi dimensioni, ognuno in un processo separato così il picco di memoria non fosse influenzato da esecuzioni precedenti. Nulla è andato in crash. Il profilo dei costi, però, è sbilanciato.
| Soggetto | Input | Caratteri in output | Tempo mediano | Δ RSS massimo |
|---|---|---|---|---|
| NIST SP 800-53r5 (PDF da 492 pagine) | 5.9 MB | 1,625,365 | 192.5 s | +40 MB |
| XLSX 50.000 righe × 8 colonne | 2.1 MB | 3,722,955 | 62.1 s | +374 MB |
| arXiv 1706.03762 (~15 pagine PDF) | 2.2 MB | 40,174 | 12.6 s | +25 MB |
| XLSX 200 righe × 64 colonne | 46 KB | 120,129 | 2.9 s | +22 MB |
Il PDF NIST da 492 pagine ha richiesto una mediana di 192,5 secondi — circa 3,2 minuti, ovvero 0,39 s/pagina — perché pdfplumber esegue il rilevamento della struttura delle parole su ogni pagina. Il picco RSS è rimasto a +40 MB, quindi il collo di bottiglia è la CPU, non la memoria. Anche il PDF arXiv da 15 pagine ha impiegato 12,6 secondi nel suo processo isolato, cioè circa 3,4× rispetto ai 3,7 secondi osservati a caldo nello stesso file dentro il mio set documentale. Quel divario è il costo del processo freddo e conferma che il lavoro per pagina è il vero driver, non la dimensione grezza del file. Se vuoi un numero trasferibile per quel PDF, usa i 12,6 s in esecuzione isolata.
Il percorso dei fogli di calcolo ribalta il collo di bottiglia. Un XLSX da 2,1 MB con 50.000 righe è salito a +374 MB di RSS massimo (e 3,7 milioni di caratteri in output) perché il convertitore carica l’intero foglio e costruisce una sola grande stringa Markdown. Il consiglio pratico è quindi diretto: per PDF grandi, mettiti in conto minuti di CPU; per fogli di calcolo grandi, centinaia di MB di RAM. Si tratta di numeri su una singola macchina, macOS arm64 e Python 3.14, quindi le costanti per pagina e per riga dipendono dalla piattaforma — ma la forma del comportamento (i PDF sono lenti e CPU-bound, gli XLSX consumano molta memoria, niente va in crash) è il dato che conta davvero.
Dove entra Thunderbit — e dove no
Prova Thunderbit per l’estrazione di dati web
È il confronto in cui sarebbe facilissimo esagerare, quindi traccio il confine con precisione. MarkItDown e Thunderbit risolvono problemi adiacenti, non lo stesso problema.
MarkItDown converte file che hai già. Thunderbit recupera prima la pagina. L’endpoint /distill di Thunderbit trasforma una pagina web live in Markdown pulito, pronto per gli LLM — gestendo rendering JS, anti-bot e contenuti dinamici che MarkItDown non sa trattare — mentre l’endpoint /extract restituisce JSON strutturato allineato a uno schema, non solo Markdown grezzo. Per gli sviluppatori, tutto questo è esposto tramite API (POST /distill / POST /extract), server MCP e CLI (npx @thunderbit/thunderbit-cli) su un unico motore AI, lo stesso che alimenta l’estensione con oltre 100.000 utenti.
Quindi si sovrappongono in una sola cosa — entrambi possono produrre “Markdown pronto per LLM” — ma il dominio di input è diverso: il distill di Thunderbit prende una URL sul web aperto, MarkItDown prende un file locale. Non sono equivalenti plug-and-play, e non farò finta che lo siano. Lo stack realistico usa entrambi: raccogli e fai crawling del web con Thunderbit (o un servizio stile Firecrawl), poi normalizza anche i documenti locali misti che hai già — PDF, presentazioni e fogli di calcolo — con MarkItDown. Uno gestisce la rete; l’altro la cartella dei file.
Pro e contro
Punti di forza
- Recupero completo del body su HTML pulito (4/4 pagine), con alberi di intestazioni e link conservati fedelmente
- Ottimo recupero del testo da PDF/DOCX (probe arXiv 7/7, Bitcoin 6/6) e nessuna perdita silenziosa di contenuto sui fixture Office dei manutentori
- Le equazioni Office Math vengono preservate come LaTeX — un vero vantaggio di nicchia
- Nessun crash su soggetti di qualsiasi dimensione, fino a un PDF da 492 pagine e un XLSX da 50k righe
- Facilissimo da usare: CLI,
convert(), piping da stdin e server MCP opzionale - Licenza MIT, mantenuto attivamente da Microsoft, issue tracker reattivo
Punti deboli
- Mantiene il boilerplate — fino al 12,4% di righe chrome su Wikipedia; non è un estrattore di articoli
- Le tabelle si rompono con span, nesting e pipe nelle celle (2/13 rotte, 4/13 irregolari) e il rowspan può riallineare i dati nella colonna sbagliata senza avviso
- I PDF scannerizzati/solo immagine restituiscono output vuoto senza OCR e senza errori
- L’output PDF non conserva alcuna struttura di intestazione (coerente con i benchmark pubblici)
- Installazione base da 161 MB con runtime ONNX da 73 MB; circa 3,35 s di import a freddo
- L’extra
[all]fa backtracking silenzioso fino alla vecchia 0.0.2 su Python 3.14
Chi dovrebbe usarlo e chi no
Scegli MarkItDown se devi standardizzare una massa di documenti locali misti — Word, Excel, PowerPoint, PDF con layer testuale — in Markdown per una pipeline LLM, e ti interessa più avere tutto il testo che preservare la struttura. Come convertitore dell’ultimo miglio in un batch job, che passa testo pulito a un modello, è veloce, fedele e gratuito.
Lascialo perdere, o affiancalo a qualcos’altro, se il tuo obiettivo è uno di questi: ti serve solo l’articolo principale da una pagina web (usa uno strumento di readability o stile Firecrawl); devi far sopravvivere intatte intestazioni e tabelle di un PDF (qui servono strumenti come Docling o Marker); oppure i tuoi input includono documenti scannerizzati che richiedono OCR (ti serve l’backend Azure o un tool diverso). E se stavi cercando uno scraper — qualcosa che recupera e fa crawling — questo non lo è affatto.
Il punteggio provvisorio che ho assegnato, usando una griglia pensata per uno scraper, è 60/100, e questo risultato basso è solo l’effetto di giudicare un convertitore con il test di un crawler. Nel suo territorio, i punteggi di fedeltà testuale sono alti; i punti deboli sono strutturali (tabelle, intestazioni PDF) e di packaging (peso, import, trappola [all]), non di qualità del testo. Se lo giudichi per quello che è — un convertitore da file a Markdown — è uno strumento solido, ben mantenuto e con un paio di spigoli vivi che conviene conoscere prima di portarlo in produzione.
Domande frequenti
MarkItDown è uno web scraper?
No. Non ha crawler, non fa rendering JavaScript, non segue i link e non gestisce la paginazione. Converte file e documenti che hai già — PDF, DOCX, XLSX, PPTX, immagini, HTML — in Markdown. Se devi recuperare e fare crawling di pagine web live, ti serve uno strumento di scraping come Thunderbit o Firecrawl; MarkItDown è il passo successivo, quello che trasforma file recuperati o locali in Markdown pulito.
Perché pip install markitdown[all] installa una versione vecchia?
Su Python 3.14, l’extra [all] blocca youtube-transcript-api~=1.0.0, e tutte le build di quell’intervallo sono limitate a versioni di Python inferiori alla 3.14. Il resolver non riesce a soddisfare il vincolo, quindi torna silenziosamente a markitdown 0.0.2, una release di due anni fa. La soluzione è fissare la versione e installare gli extra separatamente: pip install 'markitdown==0.1.6', poi aggiungere 'markitdown[pdf,docx,pptx,xlsx,xls]==0.1.6'. La questione è tracciata come issue #2179.
MarkItDown fa OCR sui PDF scannerizzati?
Non nell’installazione predefinita. Il suo percorso PDF fa solo estrazione testuale, quindi un PDF solo immagine senza layer testuale restituisce una stringa vuota — nessun errore, nessun avviso. L’OCR richiede l’backend opzionale Azure Document Intelligence o un plugin, nessuno dei quali è incluso di default. È una lacuna nota da tempo (issue #1268).
Quanto bene gestisce le tabelle MarkItDown?
Sul contenuto, molto bene: nel mio test da 13 casi ha mantenuto il 100% del contenuto di ogni tabella. Sul piano strutturale, dipende dalla forma: tabelle semplici, larghe, senza header e con celle vuote escono come griglie GFM pulite, ma rowspan e colspan diventano irregolari (e il rowspan può riallineare i dati nella colonna sbagliata senza dirlo), le tabelle annidate vengono appiattite in righe spazzatura e i caratteri pipe letterali dentro le celle non vengono escapati. Il formato tabellare piatto di Markdown semplicemente non può rappresentare span o nesting.
MarkItDown è abbastanza veloce per documenti grandi?
Non va in crash sui file grandi, ma conviene pianificare le risorse in base al tipo. Un PDF da 492 pagine ha richiesto circa 3,2 minuti (circa 0,39 s/pagina) perché esegue il rilevamento della struttura per pagina, quindi è CPU-bound. Un foglio di calcolo da 50.000 righe ha finito in circa un minuto ma ha usato +374 MB di RAM, perché costruisce una grande stringa Markdown in memoria. Per PDF grandi, metti in conto minuti di CPU; per fogli di calcolo grandi, centinaia di MB di RAM.
Prova Thunderbit per l’estrazione di dati web Get Started Free
