MarkItDown bývá často řazen mezi web scrapery, ale to je omyl. Nemá crawler, neumí JavaScript a nedokáže si z URL stáhnout stránku a vyčistit z ní balast. Jeho úkolem je vzít už existující soubory — PDF, Word, tabulky, prezentace — a převést je celé do Markdownu, který umí číst jazykový model.
Několik týdnů jsem testoval Microsoft MarkItDown na sadě reálných dokumentů na jednom Macu, u každé tabulky jsem porovnával výstup s předem připraveným manifestem a měřil dobu převodu. Stručně: na čistých datech je rychlý a přesný, v balíčku ale skrývá 73MB machine-learning runtime, který jste si nejspíš neobjednali, a tabulky rozbíjí způsoby, které projdou kontrolou „přežil text?“ a selžou u otázky „je hodnota ve správném sloupci?“. Tady je celý obrázek i s čísly.
Co MarkItDown ve skutečnosti je
MarkItDown je Python nástroj od Microsoftu, který převádí soubory a Office dokumenty do Markdownu optimalizovaného pro LLM. Pošlete mu PDF, .docx, .xlsx, .pptx, obrázek, HTML soubor nebo pár dalších formátů a vrátí Markdown. Umí se spustit třemi způsoby: přes CLI (markitdown file.pdf -o out.md nebo přes stdin), přes Python API (MarkItDown().convert(...)) a volitelně i jako MCP server pro agentní workflow.
Nejdůležitější je ale to, co nedělá — protože to neuvádí ani README a při testování jsem si to potvrdil: žádné procházení webu, žádné renderování JS, žádné následování odkazů, žádná stránkování ani extrakce hlavního obsahu ve stylu readability. Je to převodník celých dokumentů. Vy dodáte obsah v bytech, on ho znormalizuje. Právě tenhle rozdíl rozhoduje o tom, jestli se vám tenhle nástroj do stacku hodí, nebo ne, takže se k němu budu vracet.
Repozitář je podle GitHub metrik pořádný macek — k polovině července 2026 měl 165 282 hvězdiček a 11 790 forků, je pod MIT licencí a poslední release (v0.1.6) vyšel 26. 5. 2026. Ta hvězdičková čísla ale spíš odrážejí obecný zájem o LLM tooling a značku Microsoftu než vyspělost samotného převodního jádra. Na GitHubu je také 833 otevřených issue a část z nich by vás měla zajímat ještě před instalací (k tomu se vrátím níže).
HTML do Markdownu: rychlé a kompletní, včetně boilerplate
Protože zbytek mé série recenzí scraperů používá stejné čtyři webové testovací stránky, poslal jsem MarkItDown stejné lokální HTML soubory — ne abych ho hodnotil jako scraper, ale abych zjistil, jak dobrý je v převodu HTML do Markdownu. Na dobře strukturovaných stránkách je opravdu dobrý.
Všechny čtyři stránky prošly základní instalací bez dalších balíčků a každý test body obsahu přežil. Článek Wikipedia o web scrapingu (226 KB) vrátil věrně strukturu nadpisů — jeden h1, sedm h2 a dvanáct h3, přesně podle skutečné sekce článku — a zachoval 418 odkazů jako správné [text](url). Tabulka se statistikami hokeje 26×9 na stránce Scrape This Site forms se změnila v čistou GFM tabulku o 27 řádcích (hlavička + oddělovač + 26 datových řádků), včetně prázdných buněk. Rychlost u těchto případů nebyla problém: medián 48 ms pro malou stránku s citáty až 352 ms pro 226KB Wikipedii.
Háček je v tom, že to není chyba, ale záměr. MarkItDown boilerplate neodstraňuje. Převádí celý <body>, takže se přenáší i stránkový „chrom“ — a jeho množství roste s tím, kolik navigace a obslužných prvků stránka má.
| Stránka | Počet znaků ve výstupu | Nadpisy (h1/h2/h3) | Odkazy | Řádky se stránkovým chromem |
|---|---|---|---|---|
| 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) |
Na téměř „čisté“ domovské stránce Books tvoří chrom jen 0,6 % řádků výstupu. Na Wikipedii je to 12,4 % — 42 z 338 neprázdných řádků jsou věci jako „skočit na obsah“, „přepnout obsah“, „22 jazyků“, „převzato z“, patičky s cookies a licencí. Tyto údržbové bannery Wikipedie („Tento článek potřebuje další citace“) se navíc poctivě vykreslí i do dvousloupcových pipe tabulek, a právě odtud pochází devět řádků tabulky na stránce, která žádná skutečná data vůbec nemá.
Nic z toho není chyba MarkItDown. Je to převodník celého dokumentu, ne extraktor hlavního obsahu: věrný HTML-to-Markdown je jiný úkol než čistá extrakce článku. Nástroje typu Trafilatura nebo Firecrawl se snaží vracet jen hlavní obsah; MarkItDown vrací celou stránku. Uvnitř _html_converter.py nejdřív odstraní <script> a <style>, pak pošle celý body do knihovny markdownify — bez jakéhokoli heuristického výběru hlavního obsahu. Pokud chcete jen článek, jste na špatné vrstvě.
Jeho doména: PDF, DOCX, XLSX, PPTX
Dokumenty jsou přesně to, pro co je MarkItDown stavěný. Otestoval jsem ho na reálných veřejných souborech — na arXiv článku s textovou vrstvou, Bitcoin whitepaperu, skenovaném PDF jen jako obrázek, které jsem vyrenderoval tak, aby nemělo žádný text, a na souborech DOCX/XLSX/PPTX z testovací sady MarkItDownu (s UUID značkami pro odhalení tichých ztrát obsahu).
| Dokument | Vstup | Počet znaků ve výstupu | Proby | Medián času | Poznámky |
|---|---|---|---|---|---|
| arXiv 1706.03762 (PDF s textovou vrstvou) | 2,2 MB | 40,174 | 7/7 | 3,7 s (warm) | název, „Transformer“, „BLEU“, „References“ vše přítomno |
| Bitcoin whitepaper (PDF, 9 stran) | 184 KB | 22,485 | 6/6 | 1,4 s | „Satoshi Nakamoto“, „proof-of-work“, „Conclusion“ přítomny |
| Skenované PDF (bez textové vrstvy) | 89 KB | 0 | 0/4 | 15 ms | prázdný výstup, bez chyby, bez OCR |
| DOCX (test.docx) | 136 KB | 4,651 | — | 70 ms | nadpisy + GFM tabulka; vložené UUID přežily |
| DOCX s rovnicemi | 15 KB | 240 | — | 101 ms | Office Math zachováno jako LaTeX |
| XLSX (test.xlsx) | 12 KB | 808 | — | 57 ms | každý list → ## SheetName + GFM tabulka |
| PPTX (test.pptx) | 278 KB | 2,047 | — | 52 ms | značky čísel snímků, tabulky, graf → tabulka |
U PDF s textovou vrstvou byl návrat textu výborný — 7 ze 7 předem zadaných probeů u arXiv článku „Attention Is All You Need“, 6 ze 6 u Bitcoin whitepaperu — a žádný z Office souborů neztratil jedinou UUID značku, takže u jejich vlastních regresních fixture nedošlo k tiché ztrátě obsahu. Příjemný úzký úspěch: cesta přes DOCX (přes mammoth) zachovává Office Math rovnice jako LaTeX a převádí equations.docx do skutečného $$...$$ matematického zápisu. Pokud posíláte LLM matematicky náročné Word dokumenty, je to specifická, ale reálná výhoda, kterou jsem jinde zdokumentovanou nenašel.
Na této půdě jsou dva nálezy, které si zaslouží zvláštní pozornost, protože právě ty vás nejspíš potrápí.
Skenované PDF, které zmizí
Když MarkItDown dostane PDF jen jako obrázek bez textové vrstvy, vrátí prázdný řetězec. Nula znaků, žádná výjimka, žádné varování — a převod zabere asi 15 ms, protože není co vytahovat. PDF větev MarkItDownu dělá jen textovou extrakci (uvnitř běží pdfminer a pdfplumber) a žádné OCR v základní instalaci ani v žádném pip extra nenajdete.
V dávkovém zpracování je to problém. Vývojář, který pošle do nástroje složku PDF, kde jsou i skeny, dostane u těchto souborů potichu prázdný výstup, aniž by věděl, že se něco přeskočilo. Ověřil jsem, že fixture není rozbitá, tak že jsem na ni pustil přímo pdfminer extract_text — výsledek byl také nulový, takže prázdný výstup je skutečné chování MarkItDownu na skutečném skenu. To potvrzuje dlouhodobě otevřený problém s chybějícím OCR fallbackem (#1268), který je v upstreamu sledován už delší dobu. Zdokumentovaná cesta vede přes volitelný backend Azure Document Intelligence nebo plugin; ani jedno není součástí výchozí instalace.
PDF vycházejí jako plochý text, ne jako struktura
U obou PDF s textovou vrstvou vytvořil MarkItDown nulový počet Markdown markerů pro nadpisy. PDF samo o sobě nenese sémantické značky nadpisů a MarkItDown je neodvozuje ani z velikosti písma, takže každý řádek skončí na úrovni těla textu. Text je zachován dobře, struktura je ale plochá.
Nejde jen o můj výsledek. Veřejné benchmarky třetích stran hodnotí hierarchii nadpisů v PDF u MarkItDown zhruba na 0,0 a věrnost tabulek kolem 0,27, což je hluboko pod 0,88 u Doclingu s TableFormerem (viz MarkItDown vs Docling vs Marker comparison a READoc benchmark). Moje testy to potvrzují, což je silná stránka důkazů — moje čísla sedí s externím zdrojem. Stejné benchmarky ale uvádějí, že MarkItDown běží zhruba 100× rychleji než Docling, a to odpovídá mým časům v sekundách místo minut u dokumentů, které layout-model nástroj zpracovává minuty. Závěr: MarkItDown vám dá čistý a rychlý PDF text; nedá vám PDF strukturu. Pokud musí přežít nadpisy i tabulky, je správná vrstva nástroj s layout modelem, jako je Docling nebo Marker.
Tabulky: obsah obvykle přežije, struktura ne vždy
U tabulek se rozchází otázka „přežil text?“ a „je výsledek použitelný?“, takže jsem vytvořil matici 13 případů — pro každý případ jedna <table>, hodnocená proti manifestu připravenému ještě před během — abych přesně zmapoval, které tvary fungují a které se lámou.
Hlavní zjištění: MarkItDown nikdy neztratil obsah tabulky. Všech 13 případů zachovalo 100 % předem zadaných tokenů. Strukturální věrnost se ale dělí do tří skupin. Sedm z třinácti dalo dobře formovanou GFM mřížku (prosté tabulky, header-colspan, široké 24sloupcové, bez hlavičky, s prázdnými buňkami, blok v buňce a arabská zprava doleva). Čtyři vyšly rozhozeně, protože Markdown nemá pojem roztažené buňky, takže rowspan, colspan a rozbité zdroje generují krátké řádky. A dva byly úplně rozbité.
Ty dva rozbité případy stojí za pojmenování. Vnořená tabulka (<table> uvnitř <td>) se zploští přímo do buňky, její svislé čáry i oddělovací řádek se vmáčknou do rodičovské buňky a vznikne odpadní řádek se 14 „sloupci“. A literál | uvnitř buňky se neescapuje — text a | b se změní na dva sloupce, x || y na tři — takže dvousloupcová tabulka vrací řádky o dvou, třech i čtyřech sloupcích a jakýkoli downstream Markdown parser pak čte špatné hranice. Zajímavé je, že hvězdičky a backticky uvnitř buněk escapované jsou; svislé čáry ne. Kořenem je to, že HTML cesta MarkItDown používá výchozí zpracování tabulek z markdownify a vlastní subclass přepisuje odkazy, obrázky a nadpisy, ale ne buňky tabulky. Stejný typ chyby s neescapovanou svislicí je otevřený problém i u CSV převodníku (#2019), ale jeho oprava se HTML cesty, kterou jsem testoval, netýká.
Jemnější problém — a nález, který bych nejradši ukázal datovému inženýrovi — je rowspan. Případ t03 není jen rozhozený; potichu špatně zarovnává data. Popisek s rowspan=2 („Fruit“) se vypíše jen jednou a řádek pod ním pak vyjde jako krátký dvousloupcový řádek (| Banana | 8 |), takže „Banana“ skončí ve sloupci Group místo Item. Všechny tokeny jsou přítomné. Naivní čtenář typu „vezmu druhý sloupec“ dostane špatnou hodnotu. Přesně takové chyby projdou testem přežití textu a nenápadně zkazí dataset.
Samotné omezení spanů je známý a sledovaný designový limit (#1211, #1248) — plochá GFM pipe mřížka prostě neumí vyjádřit span ani vnoření, takže převodník volí obsah před strukturou. Jsou tu ale i dobré vlastnosti: tabulky bez hlavičky dostanou synteticky doplněný prázdný header řádek (takže se žádná data potichu nepovyšují na hlavičku), prázdné buňky se zachovají a <caption> projde jako textový řádek nad tabulkou.
Instalace a start: daň, o které vás „lehké utility“ nevarují
Nic mě tu nepřekvapilo víc a právě tady označení „lehký Python utility“ potichu přehání.
Za prvé, neinstalujte pip install 'markitdown[all]'. Na Pythonu 3.14 se to tiše vrátí zpět na markitdown 0.0.2 — vydání staré dva roky — a já to reprodukoval v čistém venv. Když jsem to připnul přesněji, bylo jasné proč: pip install 'markitdown[all]==0.1.6' selže, protože extra [all] připíná youtube-transcript-api~=1.0.0, a na současném PyPI je každá verze v tomto rozsahu omezená na Python <3.14, zatímco jediná sestavení kompatibilní s 3.14 leží mimo tenhle pin. Resolver se tedy vrátí až na poslední verzi, jejíž závislosti umí uspokojit. To odpovídá i otevřenému issue (#2179). Oprava je jednoduchá — připněte verzi a instalujte extra balíčky zvlášť: pip install 'markitdown==0.1.6', a pak pip install 'markitdown[pdf,docx,pptx,xlsx,xls]==0.1.6'. Každý z nich se nainstaluje čistě; problém dělá jen kombinovaný balíček [all]. (Tenhle zádrhel navíc závisí na verzi Pythonu — na Pythonu 3.13 a starším se může resolver chovat jinak.)
Za druhé, velikost instalace. Core instalace má 161 MB (prázdný venv 13 MB + 148 MB navíc). Z toho onnxruntime (73 MB) a numpy (34 MB) dohromady tvoří 107 MB — tedy 66 % celé core stopy — a oba tahá jediná tvrdá závislost: magika, ML detektor typu souboru od Googlu. Takže převodník textu v základní instalaci přibaluje 73MB ONNX inference runtime ještě předtím, než přidáte jediný dokumentový extra balíček. Když přidáte všechny dokumentové extra balíčky, venv naroste na 310 MB. Je to stále mnohem lehčí než headless browser stack, ale pokud jste čekali mikronástroj typu „nainstalovat a jít“, počítejte s tím, že s sebou nese i ONNX runtime.
Za třetí — a to je v celé sadě nálezů jediná věc, která prochází všemi testy novosti, které jsem zkoušel — i po čisté instalaci stojí import markitdown na tomto stroji zhruba 3,35 sekundy. Náklad je skoro celý při importu: markitdown._markitdown eager-importuje celý registr konvertorů (2,56 s kumulativně, tedy 76 % celku), což přitáhne pandas (594 ms přes XLSX konvertor), python-pptx (427 ms), magika (354 ms) a requests (270 ms) — bez ohledu na to, zda tyto formáty vůbec převádíte. Pro dlouhodobě běžící službu je to jednorázový náklad, který se rozmělní a není podstatný. Pro CLI nebo serverless cold start je to ale reálná daň za každý proces, kterou označení „lehké utility“ nenaznačuje. (Férové upozornění: jde o jeden profilovaný běh, tedy jedno pozorování, ne distribuci z více běhů.)
Měřítko: nepadá, ale u PDF počítejte s CPU a u tabulek s RAM
Přes čtyři velké vzorky jsem to pustil po jednom procesu, aby peak memory nebyla ovlivněná předchozím během. Nic nespadlo. Cenový profil je ale dost nerovnoměrný.
| Vzorek | Vstup | Počet znaků ve výstupu | Medián času | Peak RSS Δ |
|---|---|---|---|---|
| NIST SP 800-53r5 (PDF, 492 stran) | 5,9 MB | 1,625,365 | 192,5 s | +40 MB |
| XLSX 50 000 řádků × 8 sloupců | 2,1 MB | 3,722,955 | 62,1 s | +374 MB |
| arXiv 1706.03762 (~15stránkové PDF) | 2,2 MB | 40,174 | 12,6 s | +25 MB |
| XLSX 200 řádků × 64 sloupců | 46 KB | 120,129 | 2,9 s | +22 MB |
492stránkový PDF NIST trval v mediánu 192,5 sekundy — zhruba 3,2 minuty, tedy 0,39 s na stránku — protože pdfplumber na každé stránce dělá detekci formulářových polí a pozic slov. Peak RSS zůstalo na +40 MB, takže jde o CPU-bound, ne memory-bound úlohu. I 15stránkový arXiv PDF trval v izolovaném procesu 12,6 sekundy, tedy asi 3,4× víc než 3,7 sekundy, které stejný soubor ukázal „warm“ v sadě dokumentů. Ten rozdíl je cena za cold start procesu a potvrzuje, že hlavní náklad je práce na stránkách, ne velikost souboru. Pokud chcete jedno přenositelné číslo pro ten PDF, použijte izolovaných 12,6 s.
U spreadsheetů se naopak mění úzké hrdlo. XLSX o velikosti 2,1 MB a 50 000 řádcích vyletěl na +374 MB peak RSS (a 3,7 milionu znaků ve výstupu), protože převodník načte celý list a vytvoří jeden velký Markdown řetězec. Praktické doporučení je tedy přímočaré: u velkých PDF počítejte s minutami CPU; u velkých tabulek s stovkami MB RAM. To jsou čísla z jednoho stroje na macOS arm64 a Pythonu 3.14, takže konstanty na stránku a řádek jsou závislé na platformě — ale tvar chování (PDF je pomalé a CPU-bound, XLSX je paměťově náročný a nic nespadne) je přenositelný.
Kde do toho zapadá Thunderbit — a kde ne
Vyzkoušet Thunderbit pro extrakci webových dat
Tohle je srovnání, u kterého by bylo snadné něco nadhodnotit, takže hranici vymezím přesně. MarkItDown a Thunderbit řeší sousední, ne stejné problémy.
MarkItDown převádí soubory, které už máte. Thunderbit nejdřív stránku stáhne. Endpoint Thunderbitu /distill vezme živou webovou stránku a převede ji do čistého Markdownu připraveného pro LLM — včetně JS renderingu, anti-bot ochrany a dynamického obsahu, se kterým MarkItDown neumí pracovat — a endpoint /extract vrací strukturované JSON podle schématu, ne jen syrový Markdown. Pro vývojáře je to dostupné jako API (POST /distill / POST /extract), MCP server a CLI (npx @thunderbit/thunderbit-cli) nad jedním AI enginem, stejným jako v rozšíření s více než 100 000 uživateli.
Překryv mají jen v jedné věci — oba umí vytvořit „LLM-ready Markdown“ — ale vstupní doména je jiná: Thunderbit distill bere URL z otevřeného webu, MarkItDown bere lokální soubor. Nejsou zaměnitelné a nebudu tvrdit opak. Reálný stack používá oba: web stáhnete a prolezete přes Thunderbit (nebo službu typu Firecrawl) a pak smíšené lokální dokumenty, které máte také k dispozici — PDF, prezentace a tabulky — normalizujete přes MarkItDown. Jeden řeší síť, druhý archiv souborů.
Klady a zápory
Silné stránky
- Úplné zachování body obsahu u čistého HTML (4/4 stránky), včetně stromu nadpisů a odkazů
- Vysoká přesnost při extrakci textu z PDF/DOCX (arXiv 7/7 probeů, Bitcoin 6/6) a žádná tichá ztráta obsahu na vlastních Office fixturech
- Office Math rovnice zachované jako LaTeX — skutečný specializovaný bonus
- Bez pádu i u velkých vzorků, až po 492stránkové PDF a XLSX se 50 tisíci řádky
- Snadné použití: CLI,
convert(), piping přes stdin a volitelný MCP server - MIT licence, aktivní údržba Microsoftem, responzivní issue tracker
Slabé stránky
- Zachovává boilerplate — na Wikipedii až 12,4 % řádků chromu; není to extraktor článků
- Tabulky se lámou na span, vnoření a pipe uvnitř buněk (2/13 rozbité, 4/13 rozhozené) a rowspan může tiše rozhodit sloupce
- Skenovaná PDF / PDF jen jako obrázek vrací prázdný výstup bez OCR a bez chyby
- Výstup z PDF nemá žádnou strukturu nadpisů (potvrzují i veřejné benchmarky)
- Core instalace má 161 MB a přibaluje 73MB ONNX runtime; cold import trvá asi 3,35 s
- Extra
[all]na Pythonu 3.14 tiše spadne zpět na starou verzi 0.0.2 starou dva roky
Pro koho je vhodný a pro koho ne
Po MarkItDown sáhněte, pokud standardizujete hromadu smíšených lokálních dokumentů — Word, Excel, PowerPoint, PDF s textovou vrstvou — do Markdownu pro LLM pipeline a záleží vám víc na kompletním textu než na zachované struktuře. Jako poslední převodník v dávkovém procesu, který modelu předává čistý text, je rychlý, věrný a zdarma.
Vynechte ho, nebo ho zkombinujte s něčím jiným, pokud potřebujete některý z těchto případů: z webové stránky chcete jen hlavní článek (použijte readability nebo nástroj typu Firecrawl); potřebujete, aby z PDF přežily nadpisy a tabulky beze změny (to je doména Doclingu nebo Markeru); nebo vaše vstupy zahrnují naskenované dokumenty a vy potřebujete OCR (budete potřebovat backend Azure nebo úplně jiný nástroj). A pokud jste si mysleli, že kupujete scraper — něco, co stránky stahuje a prochází — tak tohle vůbec není ono.
Předběžné skóre, které jsem spočítal podle rubricy pro scraper, vyšlo MarkItDown na 60/100, ale nízké číslo je jen důsledek toho, že převodník hodnotíte scraperovým testem. Ve své vlastní kategorii má vysoké skóre v textové věrnosti; slabiny jsou strukturální (tabulky, PDF nadpisy) a balíčkové (velikost instalace, import, past [all]), ne kvalita textu. Když ho budete posuzovat podle toho, čím skutečně je — převodníkem souborů do Markdownu — dostanete solidní, dobře udržovaný nástroj s několika ostrými hranami, které byste měli znát, než ho zapojíte do produkce.
Často kladené otázky
Je MarkItDown web scraper?
Ne. Nemá crawler, nerenderuje JavaScript, nenásleduje odkazy a neumí stránkování. Převádí soubory a dokumenty, které už máte — PDF, DOCX, XLSX, PPTX, obrázky, HTML — do Markdownu. Pokud potřebujete stahovat a procházet živé webové stránky, chcete nástroj na scraping jako Thunderbit nebo Firecrawl; MarkItDown je až další krok, který stažené nebo lokální soubory převádí do čistého Markdownu.
Proč pip install markitdown[all] instaluje starou verzi?
Na Pythonu 3.14 extra [all] připíná youtube-transcript-api~=1.0.0 a každé vydání v tomto rozsahu je omezené na Python pod 3.14. Resolver ten pin neumí splnit, takže se potichu vrátí zpět na markitdown 0.0.2, tedy vydání staré dva roky. Oprava: připněte verzi a instalujte extra balíčky zvlášť: pip install 'markitdown==0.1.6' a pak přidejte 'markitdown[pdf,docx,pptx,xlsx,xls]==0.1.6'. Je to sledováno v issue #2179.
Dělá MarkItDown OCR u skenovaných PDF?
Ve výchozí instalaci ne. Jeho PDF větev je jen pro extrakci textu, takže PDF jen jako obrázek bez textové vrstvy vrátí prázdný řetězec — bez chyby a bez varování. OCR vyžaduje volitelný backend Azure Document Intelligence nebo plugin, ani jedno není součástí default instalace. Je to dlouhodobě sledovaná mezera (issue #1268).
Jak si MarkItDown vede s tabulkami?
Z hlediska obsahu velmi dobře — v mém testu 13 případů zachoval 100 % obsahu ve všech tabulkách. Z hlediska struktury záleží na tvaru: jednoduché, široké, bez hlavičky a s prázdnými buňkami vycházejí jako čisté GFM mřížky, ale rowspan a colspan se rozbíjejí (a rowspan může tiše posunout data do špatného sloupce), vnořené tabulky se zplošťují do odpadních řádků a doslovné svislé čáry uvnitř buněk se neescapují. Plochý tabulkový formát Markdownu prostě neumí span ani vnoření.
Je MarkItDown dost rychlý pro velké dokumenty?
Na velkých souborech nepadá, ale počítejte se zdroji podle typu dat. 492stránkové PDF trvalo asi 3,2 minuty (zhruba 0,39 s na stránku), protože dělá detekci formulářových prvků na každé stránce, a je tedy CPU-bound. Spreadsheet s 50 000 řádky skončil asi za minutu, ale se spotřebou +374 MB RAM, protože buduje jeden velký Markdown řetězec v paměti. U velkých PDF plánujte minuty CPU; u velkých tabulek stovky MB RAM.
Vyzkoušet Thunderbit pro extrakci webových dat Get Started Free
