MarkItDown se často hází do stejného pytle jako web scrapers — a to je chyba. Nemá crawler, JavaScript engine ani možnost stáhnout URL a vyčistit z ní balast. Dělá něco jiného: převádí už existující data — PDF, Word dokumenty, tabulky, prezentace — do Markdownu, který umí jazykový model snadno přečíst.
Několik týdnů jsem testoval Microsoftí MarkItDown na reálných dokumentech na jednom Macu. U každé tabulky jsem výsledek porovnával s manifestem, který jsem si připravil dopředu, a zároveň jsem měřil čas každého převodu. Stručně řečeno: na čistých vstupech je rychlý a spolehlivý, jeho balíček ale skrývá 73MB strojově‑učící runtime, o který jste možná vůbec nestáli, a tabulky umí rozbít způsobem, který projde testem „přežil text?“ a propadne v testu „je datový sloupec správně?“. Tady je celý obraz i s čísly.
Co MarkItDown vlastně je
MarkItDown je Python nástroj od Microsoftu, který převádí soubory a Office dokumenty do Markdownu optimalizovaného pro LLM. Nasměrujete ho na PDF, .docx, .xlsx, .pptx, obrázek, HTML soubor nebo několik dalších formátů a vrátí Markdown. Nabízí tři způsoby použití: CLI (markitdown file.pdf -o out.md nebo přes stdin), Python API (MarkItDown().convert(...)) a volitelně i MCP server pro agentní workflow.
Nejdůležitější je ale to, co nedělá — a README to také netvrdí, což jsem si v testech ověřil: žádné procházení webu, žádné vykreslová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ů. Přinesete bytes, on je znormalizuje. Právě tenhle rozdíl rozhoduje, jestli do vašeho stacku patří, nebo ne — proto se k němu budu vracet.
Samotné repo vypadá podle GitHub vanity metrik jako těžká váha — k polovině července 2026 má 165 282 hvězdiček a 11 790 forků, je pod MIT licencí a poslední release (v0.1.6) vyšel 2026-05-26. Jenže ten počet hvězdiček je spíš odraz obecného nadšení kolem LLM toolingů a Microsoftího repa, ne ukazatel vyspělosti konverzního jádra. Navíc je tam 833 otevřených issues a několik z nich vás může zajímat ještě před instalací (víc níže).
HTML do Markdownu: rychlé a kompletní, včetně balastu
Protože zbytek mé série recenzí scraperů pracuje se stejnými čtyřmi webovými fixture, nakrmil jsem MarkItDown stejnými lokálními HTML soubory — ne proto, abych ho hodnotil jako scraper, ale abych zjistil, jak dobrý je v převodu HTML do Markdownu. Na dobře označkovaných stránkách je opravdu dobrý.
Všechny čtyři stránky prošly na základní instalaci bez jakýchkoli doplňků a žádný z bodů kontrolující obsah nezmizel. Článek Wikipedia „Web scraping“ (226 KB) vyšel s věrně zachovanou strukturou nadpisů — jeden h1, sedm h2 a dvanáct h3, přesně podle skutečné struktury stránky — a 418 odkazy byly zachované jako správné [text](url). Tabulka hokejových statistik 25×9 na stránce Scrape This Site forms se změnila na čistou GFM pipe tabulku o 27 řádcích (hlavička + oddělovač + 26 datových řádků), včetně prázdných buněk. Rychlost tady nebyla problém: medián 48 ms pro malou stránku s citáty až po 352 ms pro 226KB Wikipedii.
Háček je v tom, a je to spíš designové rozhodnutí než chyba: MarkItDown neodstraňuje boilerplate. Převádí celý <body>, takže se veze i site chrome — a množství balastu roste podle toho, kolik ho na stránce je.
| Stránka | Počet znaků ve výstupu | Nadpisy (h1/h2/h3) | Odkazy | Řádky s prvky webu |
|---|---|---|---|---|
| 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ěř bezbalastové homepage Books tvoří chrome jen 0,6 % řádků výstupu. Na Wikipedii je to 12,4 % — 42 z 338 neprázdných řádků jsou „jump to content“, přepínač obsahu, „22 languages“, „retrieved from“, cookies a licenční patičky. Ty wikipedické udržovací bannery („This article needs additional citations“) se navíc poctivě vykreslí i do dvousloupcových pipe tabulek, což je důvod, proč na stránce bez skutečné datové tabulky vznikne devět řádků tabulky.
To ale není chyba MarkItDown. Je to převodník celých dokumentů, ne extractor čistého článku: věrný HTML→Markdown je jiný úkol než čistá extrakce obsahu. Nástroje typu Trafilatura nebo Firecrawl míří na to, aby vrátily jen hlavní obsah; MarkItDown vrací celou stránku. Uvnitř jeho _html_converter.py se zahodí <script> a <style>, pak se celé tělo předá knihovně markdownify — žádná heuristika na hlavní obsah nikde v cestě není. Pokud chcete jen článek, je to špatná vrstva.
Jeho domácí hřiště: PDF, DOCX, XLSX, PPTX
Dokumenty jsou přesně to, pro co je MarkItDown určený. Testoval jsem ho na skutečných veřejných souborech — arXiv paper s textovou vrstvou, Bitcoin whitepaper, naskenované PDF pouze jako obrázek, které jsem sám vyrenderoval tak, aby neobsahovalo žádný text, a na DOCX/XLSX/PPTX souborech z vlastního testovacího balíčku MarkItDownu (osazených UUID, abych poznal tichou ztrátu obsahu).
| Dokument | Vstup | Znaky ve výstupu | Probes | Medián času | Poznámka |
|---|---|---|---|---|---|
| arXiv 1706.03762 (PDF s textovou vrstvou) | 2.2 MB | 40,174 | 7/7 | 3.7 s (warm) | title, "Transformer", "BLEU", "References" všechny přítomné |
| Bitcoin whitepaper (9 stran PDF) | 184 KB | 22,485 | 6/6 | 1.4 s | "Satoshi Nakamoto", "proof-of-work", "Conclusion" přítomné |
| Naskenované 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 zachované jako LaTeX |
| XLSX (test.xlsx) | 12 KB | 808 | — | 57 ms | každý sheet → ## SheetName + GFM tabulka |
| PPTX (test.pptx) | 278 KB | 2,047 | — | 52 ms | značky čísla slajdu, tabulky, graf → tabulka |
Textová návratnost u PDF s textovou vrstvou byla výborná — 7 z 7 předem registrovaných probe na arXiv paperu „Attention Is All You Need“, 6 z 6 na Bitcoin whitepaperu — a žádný z Office souborů neztratil jediné UUID sentinel, takže na vlastních regresních fixture maintainers nedošlo k tiché ztrátě obsahu. Pěkný úzký plus: cesta pro 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 Word dokumenty plné matematiky do LLM, je to reálná, i když specifická síla, kterou jsem nikde jinde nenašel popsanou.
Dva poznatky z tohoto teritoria si zaslouží vlastní pozornost, protože právě ty vás nejspíš potrápí.
Naskenované 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í — zpracování trvá asi 15 ms, protože není co extrahovat. PDF větev MarkItDownu dělá jen textovou extrakci (pod kapotou pdfminer a pdfplumber) a v základní instalaci ani v žádném pip extra není OCR.
V batchi je to zásadní. Vývojář, který mu předá složku PDF, z nichž část jsou skeny, dostane u těchto souborů tiše prázdný výsledek bez jakéhokoli signálu, že něco bylo přeskočeno. Ověřil jsem, že fixture není rozbitá, tím, že jsem na něj pustil přímo pdfminerův extract_text — nulové stripped znaky, žádná textová vrstva, potvrzeno — takže prázdný výstup je skutečné chování MarkItDownu na skutečném skenu. To reprodukuje dlouho otevřený gap v OCR fallbacku (#1268), který je upstream vedený už delší dobu. Dokumentovaná cesta je volitelný Azure Document Intelligence backend nebo plugin; žádná z těchto možností není v default instalaci.
PDF vycházejí jako plochý text, ne jako struktura
Na obou PDF s textovou vrstvou MarkItDown nevygeneroval ani jeden Markdown značkovač nadpisu. PDF nemá žádné sémantické tagy nadpisů a MarkItDown je neodvozuje z velikosti písma, takže každý řádek skončí na úrovni těla dokumentu. Textová návratnost je vysoká; struktura je plochá.
To není jen můj výsledek. Ve veřejných benchmarcích třetích stran vychází hierarchie nadpisů u PDF v MarkItDown zhruba na 0,0 a věrnost tabulek kolem 0,27, což je výrazně pod Doclingem s TableFormerem, který dosahuje 0,88 (viz srovnání MarkItDown vs Docling vs Marker a READoc benchmark). Moje fixture reprodukují stejné výsledky, což posiluje důvěryhodnost — moje čísla sedí s externím zdrojem. Stejný trade-off tyto benchmarky zároveň ukazují i obráceně: MarkItDown běží zhruba 100× rychleji než Docling, což odpovídá mým časům v sekundách, zatímco layout‑model nástroje se s podobnými dokumenty perou minuty. Pointa: MarkItDown vám dá čistý a rychlý PDF text, ale ne PDF strukturu. Pokud musí přežít nadpisy a tabulky, je správná vrstva layout‑model nástroj jako Docling nebo Marker.
Tabulky: obsah přežije vždy, struktura ne vždy
U tabulek se oddělí „přežil text?“ od „je to použitelné?“, a proto jsem postavil matici 13 případů — jedna <table> na případ, každý vyhodnocený proti manifestu připravenému předem — abych přesně určil, které tvary drží a které se lámou.
Hlavní závěr: MarkItDown nikdy neztratil obsah tabulek. Ve všech 13 případech zůstalo zachováno 100 % předem registrovaných tokenů. Strukturální věrnost ale vyšla ve třech různých režimech. Sedm z třinácti případů vytvořilo dobře formovaný GFM grid (běžná tabulka, header-colspan, tabulka široká 24 sloupců, bez hlavičky, s prázdnými buňkami, block-in-cell a zprava doleva v arabštině). Čtyři vyšly kostrbatě, protože Markdown nemá pojem pro sloučenou buňku, takže rowspan, colspan a špatně tvarované zdroje produkují krátké řádky. A dvě byly úplně rozbité.
Ty dvě rozbité stojí za pojmenování. Vnořená tabulka (<table> uvnitř <td>) se zploští inline, takže do rodičovské buňky vysype vlastní pipes i separator row a vznikne 14„sloupcový“ nesmyslný řádek. A doslovný znak | uvnitř buňky se neescapuje — text a | b se změní na dva sloupce, x || y na tři — takže dvousloupcová tabulka vytváří řádky o dvou, třech i čtyřech sloupcích a jakýkoli downstream Markdown parser pak čte hranice špatně. Zajímavě, hvězdičky a backticky uvnitř buněk escapované jsou; pipes ne. Příčina je v tom, že HTML cesta MarkItDownu používá defaultní zpracování tabulek z markdownify a jeho vlastní subclass přepisuje odkazy, obrázky a nadpisy, ale ne buňky tabulky. Stejný typ chyby s escape pipe je otevřený issue i pro CSV converter (#2019), ale tenhle fix se netýká HTML cesty, kterou jsem testoval.
Jemnější, a pro datového inženýra možná nejdůležitější, je rowspan. Případ t03 nejenže vyjde kostrbatě; tiše posune data. Popisek s rowspan=2 („Fruit“) se vypíše jen jednou a řádek pod ním se změní na krátký dvousloupcový řádek (| Banana | 8 |), takže „Banana“ skončí pod sloupcem Group místo Item. Všechny tokeny přitom zůstanou na místě. Naivní consumer, který čte druhý sloupec, dostane špatnou hodnotu. To je přesně ten typ chyby, který projde testem zachování textu a potichu poškodí dataset.
Samotné omezení spanů je známé a evidované designové omezení (#1211, #1248) — plochý GFM pipe grid prostě neumí reprezentovat spany ani vnoření, takže převodník obětuje strukturu ve prospěch úplnosti obsahu. Jsou tu ale i dobré vlastnosti: tabulky bez hlavičky dostanou vygenerovaný prázdný header row (takže se data tiše nepovýší na hlavičku), prázdné buňky zůstávají zachované a <caption> přežije jako textový řádek nad tabulkou.
Instalace a start: daň, o které vás „lehký nástroj“ nevaruje
Nic mě nepřekvapilo víc a právě tady rámování jako „lehký Python utility“ nenápadně slibuje víc, než dodá.
Za prvé, nespouštějte pip install 'markitdown[all]'. Na Pythonu 3.14 se tiše vrátí zpátky na markitdown 0.0.2 — dva roky starý release — a já jsem to reprodukoval v čistém venv naživo. Proč? Když to připnete, dojde na problém: pip install 'markitdown[all]==0.1.6' selže, protože extra [all] připíná youtube-transcript-api~=1.0.0, a na aktuálním PyPI má každá verze v tom rozsahu omezení na Python <3.14, zatímco jediné buildy kompatibilní s 3.14 leží mimo ten pin. Resolver proto couvne až na poslední release, jehož závislosti ještě umí uspokojit. To odpovídá otevřenému upstream issue (#2179). Oprava je jednoduchá — připněte verzi a instalujte extra zvlášť: pip install 'markitdown==0.1.6', pak pip install 'markitdown[pdf,docx,pptx,xlsx,xls]==0.1.6'. Každý z těchto balíčků projde čistě; problémový je jen kombinovaný balík [all]. (Tenhle pastička závisí na verzi Pythonu — na Pythonu 3.13 nebo starším nemusí problém nastat, takže [all] se může vyřešit jinak.)
Za druhé, footprint. Jádrová instalace zabírá 161 MB (prázdný venv o 13 MB plus 148 MB). Z toho samotné onnxruntime (73 MB) a numpy (34 MB) dohromady tvoří 107 MB — tedy 66 % celého jádra — a obojí je přitažené jednou tvrdou závislostí: magika, Googlovým ML detektorem typu souboru. Takže textový převodník si už v základní instalaci nese 73MB ONNX inference runtime, ještě než přidáte jediný dokumentový extra balíček. Když přidáte dokumentové extra, venv doroste na 310 MB. Ve srovnání s headless browser stackem je to pořád lehčí, ale pokud jste čekali mikro‑utility typu pip install a hotovo, vězte, že s tím jede i ONNX runtime.
Za třetí — a to je v celé sadě jediné zjištění, které v mých testech prošlo úplně všemi novelty checks — i po čisté instalaci stojí import markitdown na tomto stroji asi 3,35 sekundy. Náklad vzniká téměř celý při importu: markitdown._markitdown natahuje celý registr konvertorů najednou (kumulativně 2,56 s, tedy 76 % celku), což přitahuje pandas (1,21 s přes XLSX konvertor), python-pptx (427 ms), magika (354 ms) a requests (270 ms) — a to bez ohledu na to, jestli dané formáty vůbec převádíte. U dlouho běžící služby se ten náklad amortizuje a nevadí. U CLI volání nebo serverless cold startu je to reálná daň za proces, kterou nálepka „lehký nástroj“ nečekaně neprozradí. (Poctivě: jde o jediný profilovaný běh, braný jako jedno pozorování, ne jako vícenásobná distribuce.)
Škálování: nepadá, ale na PDF si vyhraďte CPU a na tabulky RAM
Pustil jsem přes něj čtyři velké testy, každý v samostatném procesu, aby peak memory nebyla poznamenaná předchozím během. Nic nespadlo. Nákladový profil je ale nevyrovnaný.
| Téma | Vstup | Znaky ve výstupu | Medián času | Peak RSS Δ |
|---|---|---|---|---|
| NIST SP 800-53r5 (PDF o 492 stranách) | 6.07 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 trvalo medián 192,5 sekundy — zhruba 3,2 minuty, tedy 0,39 s/stranu — protože pdfplumber na každé stránce dělá detekci formulářů podle pozice slov. Peak RSS zůstal jen na +40 MB, takže je to CPU-bound, ne memory-bound. I 15stránkové arXiv PDF trvalo ve vlastním izolovaném procesu 12,6 sekundy, tedy asi 3,4× víc než 3,7 sekundy, které stejný soubor ukázal „warm“ v mém dokumentovém balíčku. Ten rozdíl je cena za cold process a potvrzuje, že hlavním driverem je práce na stránkách, ne velikost souboru. Pokud chcete jeden přenositelný údaj pro to PDF, berte izolovaných 12,6 s.
Cesta pro tabulky obrací bottleneck. XLSX o velikosti 2,1 MB a 50 000 řádcích nafouklo peak RSS na +374 MB (a na 3,7 milionu znaků výstupu), protože konvertor načte celý sheet a složí jeden velký Markdown string. Praktická rada je tedy jednoduchá: u velkých PDF počítejte s minutami CPU; u velkých tabulek počítejte se stovkami MB RAM. Tohle jsou čísla z jednoho stroje na macOS arm64 a Pythonu 3.14, a konstanty na stránku a řádek jsou platformně závislé — ale tvar problému (PDF je pomalé a CPU-bound, XLSX je paměťově náročný, nic nepadá) je to, co se přenáší.
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é přestřelit, proto hranici vymezím opatrně. MarkItDown a Thunderbit řeší sousední problémy, ne ten samý.
MarkItDown převádí soubory, které už máte. Thunderbit stránku nejdřív stáhne. Endpoint Thunderbitu /distill vezme živou webovou stránku a převede ji do čistého Markdownu připraveného pro LLM — zvládá JS rendering, anti-bot ochrany i dynamický obsah, na který MarkItDown nemá žádné mechanismy — a endpoint /extract vrací strukturované JSON odpovědi odpovídající 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, který stojí za rozšířením s více než 100 000 uživateli.
Překryv je tedy jen v jedné věci — oba umí vrátit „LLM-ready Markdown“ — ale vstupní doména je jiná: Thunderbit distill bere URL z otevřeného webu, MarkItDown bere lokální soubor. Nejsou to zástupy, které se dají zaměňovat, a nebudu tvrdit opak. Reálný stack používá obojí: web stáhnete a projdete přes Thunderbit (nebo Firecrawl-style službu) a pak normalizujete i další lokální dokumenty, které máte — PDF, prezentace a tabulky — pomocí MarkItDownu. Jeden řeší síť, druhý souborovou skříň.
Klady a zápory
Silné stránky
- Plně zachová obsah na čistém HTML (4/4 stránky), se zachovanou strukturou nadpisů i odkazy
- Vysoká textová návratnost u PDF/DOCX (arXiv 7/7 probe, Bitcoin 6/6) a žádná tichá ztráta obsahu na vlastních Office fixturech maintainerů
- Office Math rovnice zachované jako LaTeX — skutečný úzký, ale cenný plus
- Na žádném testovaném objektu nespadl, ani u 492stránkového PDF a XLSX se 50 tisíci řádky
- Jednoduché použití: CLI,
convert(), piping přes stdin a volitelný MCP server - MIT licence, aktivní údržba od Microsoftu, reagující issue tracker
Slabiny
- Zachovává boilerplate — na Wikipedii až 12,4 % řádků s chromem; není to extractor článků
- Tabulky se lámou na spanech, vnoření a pipe uvnitř buněk (2/13 rozbité, 4/13 kostrbaté) a rowspan tiše posouvá data do špatného sloupce
- Naskenovaná / obrázková PDF vrací prázdný výstup bez OCR i bez chyby
- PDF výstup nemá žádnou strukturu nadpisů (což odpovídá veřejným benchmarkům)
- 161MB základní instalace se 73MB ONNX runtime; studený import ~3,35 s
- Extra
[all]na Pythonu 3.14 tiše spadne zpět na dva roky starou verzi 0.0.2
Kdo by ho měl používat a kdo ne
Sáhněte po MarkItDownu, pokud standardizujete hromadu smíšených lokálních dokumentů — Word, Excel, PowerPoint, PDF s textovou vrstvou — do Markdownu pro LLM pipeline a víc než na strukturu vám záleží na úplnosti textu. Jako poslední převodník v batch jobu, který modelu dodá čistý text, je rychlý, spolehlivý a zdarma.
Nechte ho být, nebo ho kombinujte s něčím jiným, pokud děláte některou z těchto věcí: potřebujete z webové stránky jen hlavní článek (použijte readability nebo Firecrawl-style nástroj); potřebujete, aby z PDF přežily nadpisy i tabulky beze ztrát (tam patří Docling nebo Marker); nebo vaše vstupy obsahují skeny, které vyžadují OCR (budete potřebovat Azure backend nebo úplně jiný nástroj). A pokud jste hledali scraper — něco, co fetchuje a crawluje — tohle to vůbec není.
Moje orientační skóre na „scraper-shaped“ rubric vychází pro MarkItDown na 60/100, ale ten nízký výsledek je artefakt toho, že převodník hodnotím podle testu pro crawler. Na vlastní půdě má vysoké skóre v textové věrnosti; jeho slabiny jsou strukturální (tabulky, PDF nadpisy) a balíčkovací (footprint, import, past s [all]), ne kvalita textu. Posuzujte ho tak, jaký je — file-to-Markdown převodník — a dostanete solidní, dobře udržovaný nástroj s několika ostrými hranami, o kterých je dobré vědět dřív, než ho nasadíte do produkce.
Často kladené otázky
Je MarkItDown web scraper?
Ne. Nemá crawler, JavaScript rendering, následování odkazů ani 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 je 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, ale každý build v tom rozsahu je omezen na Python pod 3.14. Resolver ten pin neumí splnit, a tak tiše couvne na markitdown 0.0.2, tedy dva roky starý release. Oprava je připnout verzi a instalovat extra zvlášť: pip install 'markitdown==0.1.6', pak přidat 'markitdown[pdf,docx,pptx,xlsx,xls]==0.1.6'. Je to vedené jako issue #2179.
Dělá MarkItDown OCR na naskenovaných PDF?
Ne v defaultní instalaci. Jeho PDF větev dělá jen textovou extrakci, takže PDF pouze jako obrázek bez textové vrstvy vrátí prázdný řetězec — bez chyby, bez varování. OCR vyžaduje volitelný Azure Document Intelligence backend nebo plugin, ani jeden se standardně nedodává. Je to dlouhodobě sledovaný problém (issue #1268).
Jak dobře si MarkItDown poradí s tabulkami?
Po stránce obsahu velmi dobře — v mém testu 13 případů zachoval ve všech případech 100 % obsahu tabulek. Strukturálně záleží na tvaru: jednoduché, široké, bezhlavičkové i tabulky s prázdnými buňkami vycházejí jako čisté GFM gridy, ale rowspan a colspan se lámou (a rowspan může tiše posunout data do špatného sloupce), vnořené tabulky se zploští do nesmyslných řádků a doslovné pipe znaky uvnitř buněk se neescapují. Plošný tabulkový formát Markdownu prostě neumí reprezentovat spany ani vnoření.
Je MarkItDown dost rychlý na velké dokumenty?
Na velkých souborech nepadá, ale je potřeba počítat se zdroji podle typu. PDF o 492 stranách trvalo asi 3,2 minuty (zhruba 0,39 s/stranu), protože dělá detekci formulářů na každé stránce, a je CPU-bound. XLSX s 50 000 řádky skončil asi za minutu, ale vzal si +374 MB RAM, protože v paměti skládá jeden velký Markdown string. U velkých PDF počítejte s minutami CPU; u velkých tabulek s stovkami MB RAM.
Vyzkoušet Thunderbit pro extrakci webových dat Get Started Free
