Strávil jsem absurdní množství nočních hodin laděním skriptů, které měly jen „stáhnout soubor a jít dál“. V devíti z deseti případů byl problém v tom, že cURL dělal přesně to, co jsem mu řekl, ne to, co jsem skutečně chtěl. Ukázalo se, že mezi „curl -O funguje“ a „curl -O funguje spolehlivě v produkci“ je pořádná propast.
Právě tuhle propast tenhle průvodce zaplňuje. cURL je předinstalovaný v macOS, ve většině linuxových distribucí i ve Windows 10 a novějších, takže je dost pravděpodobné, že už ho ve svém počítači dávno máte. Jenže mezi tichým selháním přesměrování, záhadnými 403 chybami a přechodem z „stáhnu jeden soubor“ na „stáhnu 500 souborů a nerozžhavím terminál doběla“ je spousta prostoru, kde se dá zaseknout. Provedu vás přepínači, na kterých opravdu záleží, příkazy, které sám používám, chybami, na které lidé narážejí nejčastěji, i okamžikem, kdy už vám cURL skutečně nepomůže — a co použít místo něj.
Co je cURL a proč by vás měl zajímat?
cURL je bezplatný open-source nástroj z příkazové řádky pro přenos dat na server nebo ze serveru pomocí URL. Umí HTTP, HTTPS, FTP, SFTP a spoustu dalších protokolů, proto se objevuje všude od bash skriptů přes Dockerfile až po CI pipeline. Pod kapotou používá příkaz curl, který zadáte do terminálu, knihovnu libcurl v jazyce C, kterou spousta aplikací a jazykových rozhraní integruje. Jedním příkladem je PHP rozšíření cURL; populární knihovna Requests v Pythonu je naopak samostatný HTTP klient postavený na urllib3, nikoli na libcurl.
Aktuální stabilní verze v době psaní je curl 8.21.0, vydaná v červnu 2026 — nepočítejte ale s tím, že váš operační systém dodává přesně tuhle sestavu. Verze balíčků v distribucích bývají často o měsíce i déle pozadu za upstream projektem, takže se před použitím přepínače jako --parallel vyplatí ověřit curl --version.
Proč stahovat soubory pomocí cURL? Hlavní scénáře použití
Často slýchám otázku, proč se vůbec zabývat nástrojem z příkazové řádky, když prohlížeč soubory stáhne taky. Upřímná odpověď: prohlížeče jsou skvělé, dokud nepotřebujete něco automatizovat.
| Scénář použití | Proč cURL vyniká |
|---|---|
| Stahování binárek v CI/CD pipeline | Dá se skriptovat, není potřeba GUI |
| Načítání API odpovědí nebo datových exportů | Podpora vlastních hlaviček, autentizace a směrování výstupu |
| Obnovení velkých stahování přes SSH | Vestavěná podpora pokračování stahování (-C -) |
| Automatizace opakovaných stahování (cron úlohy) | Lehký, dobře se skládá se shell skripty |
| Stahování souborů chráněných přihlášením | Flexibilní autentizační přepínače (basic, token, cookies, .netrc) |
Stahování v prohlížeči je jednorázové kliknutí. cURL dělá ze stejné akce něco, co můžete naplánovat, řetězit v pipeline, automaticky opakovat při chybě a spustit naprosto stejně na stovce serverů najednou. A právě v tom je jeho síla — není „lepší“ proto, že je okázalý, ale proto, že je opakovatelný.
Základní přepínače cURL pro stahování souborů
Pořád se vracím ke zhruba desítce přepínačů, které mi pokryjí 90 % práce. Tady je tahák, který bych si přál dostat už před lety — rozdělený podle toho, co skutečně dělají.
Přepínače pro výstup a uložení souboru
-O(--remote-name) uloží soubor pod názvem odvozeným z poslední části URL. Je to pohodlné, ale může to tiše přepsat existující soubor stejného jména.-o <název_souboru>(--output) vám dovolí zvolit přesný lokální název:curl -o report.pdf https://example.com/downloads/file.pdf.-J(--remote-header-name) použije název souboru z hlavičky serveruContent-Dispositionmísto názvu z URL. Hodí se pro API stahování, ale názvy od serveru berte jako nedůvěryhodný vstup — stahujte do vyhrazené složky, ne do domovského adresáře, jak doporučuje bezpečnostní dokumentace cURL.
Přepínače chování, které potřebuje každé stahování
-L(--location) říká curlu, aby následoval HTTP přesměrování. Bez něj se odpověď 3xx uloží jako malá HTML stránka s přesměrováním místo skutečného souboru — tohle je zdaleka nejčastější chyba typu „proč je moje stahování rozbité“.-C -(--continue-at -) obnoví přerušené stahování přesně tam, kde skončilo.-s/-Sběží potichu, ale stále vypisují chyby — ideální do skriptů, kde nechcete zahlcovat logy průběhovým ukazatelem.--limit-rate 1Momezí přenosovou rychlost (užitečné na sdíleném připojení nebo když nechcete zbytečně vysávat placenou síť).--connect-timeout 10a--max-time 300zabrání tomu, aby zaseknuté připojení zmrazilo skript navždy.--retry 3a--retry-delay 5automaticky zopakují pokus při dočasných chybách — podle manuálové stránky cURL je vhodné--retry-all-errorspřidávat jen tehdy, když je skutečně bezpečné zopakovat úplně stejný požadavek.
Přepínače pro průběh a ladění
-#zobrazí jednoduchý průběhový pruh místo výchozí tabulky statistik.-vvypíše podrobné informace včetně kompletních hlaviček požadavku a odpovědi — moje první volba, když se něco chová divně.-I(--head) stáhne jen hlavičky odpovědi, což je skvělá rychlá kontrola před tím, než se pustíte do velkého stahování.-wvám umožní vypsat po přenosu vlastní výstup, třebacurl -o /dev/null -s -w "%{http_code}\n" <url>pro pouhou kontrolu stavového kódu.
Než začnete
- Obtížnost: začátečník až mírně pokročilý (část o dávkovém stahování a autentizaci už jde víc do hloubky)
- Časová náročnost: asi 15–20 minut na projití základních příkazů
- Co budete potřebovat: terminál (macOS Terminal, shell v Linuxu nebo Windows PowerShell/WSL), nainstalovaný curl (ověřte pomocí
curl --version) a testovací URL — použiju veřejný asset z GitHub release, protože je stabilní a volně dostupný
Jak stahovat soubory pomocí cURL: krok za krokem
Krok 1: Stažení jednoho souboru
Úplný základ: curl -O <url> uloží soubor pod původním názvem, zatímco curl -o muj-soubor.zip <url> vám dovolí soubor při stahování přejmenovat.
curl -LO https://github.com/curl/curl/releases/download/curl-8_21_0/curl-8.21.0.tar.gz
-L přidávám teď už vždycky bez výjimky — příliš mnohokrát mě zradilo přesměrování, které z „downloadu“ udělalo tichý 400bajtový HTML soubor. V terminálu byste měli vidět, jak roste ukazatel průběhu, a nakonec se soubor objeví v aktuálním adresáři.
Když příkaz uspěje, průběhový ukazatel dosáhne 100 % a v aktuální složce se objeví curl-8.21.0.tar.gz. Než soubor použijete, ověřte ho:
ls -lh curl-8.21.0.tar.gz
Krok 2: Stažení a přejmenování souboru
Použijte -o, když chcete konkrétní lokální název místo toho, co je zrovna na konci URL:
curl -L -o curl-latest.tar.gz -S https://github.com/curl/curl/releases/download/curl-8_21_0/curl-8.21.0.tar.gz
-S znovu zapne vypisování chyb, i když jste jinde ve skriptu použili -s. Tahle kombinace — -L -o <název> -S — je v podstatě můj výchozí příkaz pro stažení jednoho souboru.
Krok 3: Obnovení přerušeného stahování
Když se velké stahování přeruší uprostřed (špatná wifi, výpadek VPN, cokoli), nezačínejte od nuly. Spusťte:
curl -C - -LO https://example.com/large-file.iso
Háček je v tom, že to funguje jen tehdy, když server podporuje požadavky na rozsahy bajtů. Accept-Ranges: bytes je užitečný pozitivní signál, ale jeho absence ještě neprokazuje, že rozsahy nejsou podporované. Spolehlivá kontrola je odpověď serveru na skutečný požadavek o rozsah: pokračovatelné stahování obvykle vrací 206 Partial Content s platným Content-Range. Spusťte příkaz pro obnovení a zkontrolujte stav pomocí -v nebo -D -; pokud server rozsah ignoruje nebo offset odmítne, raději stahování spusťte znovu záměrně, než abyste předpokládali, že částečný soubor je bezpečný.
Krok 4: Stažení s průběhovým pruhem nebo potichu
Pro čistší zobrazení v interaktivním terminálu: curl -# -LO <url>. Pro skripty a cron úlohy, kde chcete jen chyby, ne hluk: curl -sS -LO <url>. Tichou variantu používám skoro všude, kromě situací, kdy ladím ručně.
Krok 5: Omezení rychlosti stahování
Na sdíleném firemním připojení (nebo když nechci být ten člověk, který během hovoru žere celou šířku pásma) rychlost omezím takto:
curl --limit-rate 1M -LO https://example.com/big-dataset.zip
Jednotky jsou K, M a G pro kilobajty, megabajty a gigabajty za sekundu.
Krok 6: Uložení hlaviček odpovědi vedle souboru
Někdy potřebuju přesně vědět, co server poslal zpátky — typ obsahu, cache hlavičky a podobně — aniž bych zahltil terminál:
curl -L -D headers.txt -o file.zip https://example.com/file.zip
Tím se hlavičky odpovědi uloží do headers.txt, zatímco skutečný soubor skončí jako file.zip. Skvělé pro ladění nesouladu v content-type nebo pro ověření, že CDN skutečně cacheuje to, co si myslíte, že cacheuje.
Tipy a časté chyby
- Tip: Vždy používejte jako výchozí
-L. Upřímně si neumím představit nevýhodu toho, když ho přidáte, a už jsem kvůli jeho zapomenutí ztratil hodiny. - Tip: Při skriptování spojte svůj stahovací příkaz s
--fail, aby ne-2xx odpověď skutečně způsobila chybu a skript neskončil tichým uložením chybové stránky jako „souboru“. - Past: Nekombinujte
-C -s--remove-on-error— cURL tyto volby dokumentuje jako nekompatibilní, protože pro obnovení stahování musí částečný soubor zůstat na místě. - Past:
-Omůže soubory přepsat bez varování. Pokud dávkově stahujete do sdílené složky, použijte--output-dir, aby vše zůstalo pohromadě.
Jak stahovat více souborů a dávkové stahování pomocí cURL
Příklady pro jeden soubor jsou ta snadná část. Skutečné workflow, která jsem stavěl — stahování nočních datových exportů, synchronizace binárek mezi build servery — potřebovala souběh, a tady většina návodů prostě... končí. Jsou tři přístupy, které stojí za to znát, každý o něco pokročilejší než ten předchozí.
Přístup 1: Více URL v jednom příkazu cURL
Nejjednodušší možnost je prostě vypsat URL adresy:
curl -LO https://example.com/a.zip -LO https://example.com/b.zip -LO https://example.com/c.zip
Funguje to, ale sekvenčně — curl dokončí jeden soubor, než začne další. Na tři soubory v pohodě, na tři sta bolest.
Přístup 2: Paralelní stahování pomocí --parallel (curl 7.66+)
Od curl 7.66 můžete přidat --parallel (nebo -Z) a stáhnout více URL souběžně:
curl --parallel --parallel-max 5 --remote-name-all \
https://example.com/a.zip https://example.com/b.zip https://example.com/c.zip
Je dobré vědět, že výchozí parallel max je ve skutečnosti 50, což je výrazně víc souběžných spojení, než ocení většina serverů nebo vaše vlastní síť. --parallel-max proto zadávám výslovně a opatrně — obvykle 4 až 8 — místo abych spoléhal na default.
Přístup 3: xargs a Bash smyčky pro souběh nad seznamem URL
Pro velký seznam URL v textovém souboru obvykle sahám po xargs:
cat urls.txt | xargs -n1 -P 8 curl -O -L
Nebo, když chci větší kontrolu nad tím, co se děje s každou úlohou, použiju bash smyčku s procesy na pozadí:
while read -r url; do
curl -O -L "$url" &
done < urls.txt
wait
wait na konci je důležitý — bez něj skript skončí dřív, než doběhnou všechny stahování na pozadí.
Kdy se místo toho hodí wget nebo aria2
Řeknu to na rovinu: cURL není vždy správný nástroj. Pokud potřebujete zrcadlit celý strom adresářů webu, wget -r zvládá rekurzivní procházení hned po instalaci způsobem, na který cURL prostě nebyl stavěný. A pokud potřebujete vícesource nebo segmentované stahování kvůli maximální propustnosti u jednoho obrovského souboru, aria2c je opravdu rychlejší.
| Nástroj | Nejlepší pro |
|---|---|
| cURL | Přesnost, skriptování, stahování jednoho souboru nebo malé dávky, práce s API |
| wget | Rekurzivní a zrcadlené stahování webů, jednodušší hromadné stahování statických souborů |
| aria2 | Vícesource/segmentované stahování, maximum propustnosti u velkých souborů |
Síla cURL byla vždy v přesnosti a skládání do pipeline — piping, skriptování, flexibilita protokolů — ne v brutálním procházení webu.
Jak stahovat chráněné soubory pomocí cURL: autentizační vzory
Většina návodů na cURL skončí u -u uzivatel:heslo a tím to hasne. To je relikt staršího internetu. V roce 2026 stahuju soubory hlavně z REST API, dashboardů založených na session a CI systémů — a každý z nich chce jiný typ přihlašovacích údajů.
Základní autentizace
curl -u username:password -O https://legacy-server.example.com/file.zip
V pořádku pro starší FTP servery nebo jednoduché HTTP endpointy. Jen počítejte s tím, že se heslo objeví v historii shellu a v seznamu procesů, pokud si nedáte pozor — to není něco, co bych používal pro cokoli citlivého.
Autentizace přes Bearer / OAuth token
Tohle je varianta, která bývá v mnoha návodech překvapivě opomíjená, a přitom ji dnes používám nejčastěji:
curl -H "Authorization: Bearer $GITHUB_TOKEN" \
-LO https://api.github.com/repos/curl/curl/releases/assets/12345
To je reálný vzor pro stahování soukromého assetu z GitHub release — stačí vyměnit token a ID assetu. REST API a zdroje chráněné OAuth2 dnes mluví přesně tímhle jazykem.
Autentizace pomocí cookies a session
U webových aplikací, kde přihlášení vytvoří session, si při loginu uložte cookie jar a při stahování ho znovu použijte:
curl -c cookies.txt -d "user=me&pass=secret" https://example.com/login
curl -b cookies.txt -O https://example.com/protected/file.zip
Soubor .netrc pro skriptované a CI prostředí
Můj preferovaný způsob pro vše, co běží bez dozoru. Vytvořte soubor ~/.netrc (na Windows _netrc):
machine example.com
login myusername
password mypassword
Zabezpečte ho přes chmod 600 ~/.netrc a pak ho použijte takto:
curl --netrc -LO https://example.com/protected-file.zip
Výhoda je, že se přihlašovací údaje nikdy nedostanou do historie shellu ani do zdrojáku skriptu — a to je v CI/CD opravdu důležité, protože skripty se tam často logují celé.
| Metoda autentizace | Přepínač / volba | Nejlepší pro |
|---|---|---|
| Základní auth | -u user:pass | Starší FTP, jednoduché HTTP |
| Bearer token | -H "Authorization: Bearer <token>" | REST API, OAuth2 |
| Cookie auth | -b cookies.txt (+ -c pro uložení) | Webové aplikace založené na session |
Soubor .netrc | --netrc nebo --netrc-file | CI/CD, skriptovaná prostředí |
Řešení běžných selhání cURL při stahování
Tohle je část, kterou bych si býval přál najít, když jsem začínal, protože ji skoro nikdo nevysvětluje. „Proč mi nefunguje stahování přes curl“ je reálné, časté a dost frustrující hledání — a opravy bývají po pochopení příčiny často otázkou jediného řádku.
| Příznak | Pravděpodobná příčina | Oprava |
|---|---|---|
curl: (60) SSL certificate problem | Vlastnoručně podepsaný nebo expirovaný certifikát | --cacert <soubor> nebo -k (jen pro vývoj) |
403 Forbidden / prázdný soubor | Server blokuje výchozí user agent curlu | -A "Mozilla/5.0..." nebo -H "User-Agent: ..." |
Stahování s -C - začíná znovu od nuly | Server nepodporuje Range | Zkontrolujte curl -I <url> a hledejte Accept-Ranges: bytes |
| Uložený soubor má 0 bajtů | Nebylo následováno přesměrování | Přidejte přepínač -L |
curl: (28) Operation timed out | Pomalý server nebo potíže s sítí | --connect-timeout 10 --max-time 300 + --retry 3 |
| Místo souboru se uloží HTML stránka | Stránka vyžaduje vykreslení JavaScriptem | curl JS nespustí — viz část níže |
Chyby SSL certifikátu: co znamenají a jak je opravit
Chyba 60 znamená, že curl nedokázal ověřit SSL certifikát serveru — obvykle proto, že je self-signed, expirovaný nebo vydaný certifikační autoritou, které curl nedůvěřuje. Pokud server spravujete, nasměrujte curl na správný CA bundle pomocí --cacert /cesta/k/ca.pem. Přepínač -k (--insecure) přeskočí ověření úplně, což je v pohodě pro lokální vývoj, ale v produkci nebo u reálných uživatelských dat je to opravdu špatný nápad.
403 Forbidden a prázdná stahování
Překvapivě mnoho serverů blokuje požadavky, které se identifikují jako curl/8.21.0 (výchozí User-Agent curlu), protože je považují za boty nebo scrapery. Oprava bývá prostá: předstírat, že jste prohlížeč:
curl -A "Mozilla/5.0 (Windows NT 10.0; Win64; x64)" -LO https://example.com/file.zip
Když si chci ověřit, co se vlastně vrací, ještě než spustím plné stahování, použiju: curl -o /dev/null -s -w "%{http_code}\n" <url>.
Timeouty, opakování pokusů a nespolehlivé připojení
Tohle je příkaz, který bych si nejspíš vytetoval na ruku, kdybych byl odvážnější na tetování.
Můj výchozí stahovací příkaz, ten, který skutečně používám v produkčních skriptech, kombinuje všechny spolehlivé volby dohromady:
curl -L -C - --retry 5 --retry-delay 3 --connect-timeout 10 --max-time 600 --fail -O <url>
To znamená sledování přesměrování, obnovení stahování, pět pokusů s třísekundovou pauzou, 10sekundový timeout připojení, celkový limit 10 minut a tvrdé selhání při špatném HTTP stavu — v podstatě všechno, co jsem se naučil zahrnovat až bolestivou zkušeností.
cURL v reálné automatizaci: CI/CD pipeline, piping a bezpečnost skriptů
Předávání výstupu cURL do dalších nástrojů
curl nemusí vůbec nic ukládat na disk — přímé předání výstupu do jiného příkazu je jedna z jeho nejvíc podceňovaných funkcí:
curl -sL https://example.com/archive.tar.gz | tar xz
curl -s https://api.example.com/data | jq '.results'
Stažení a rozbalení, nebo stažení a parsování, v jediném řádku. Přesně tenhle vzor používám pořád u jednorázových datových pullů.
Použití cURL v GitHub Actions a CI/CD
Minimální krok v GitHub Actions, který stáhne binárku s logikou opakování a při chybě hlasitě selže:
- name: Download binary
run: |
curl -L --fail --retry 3 --retry-delay 5 \
-o app-binary "https://example.com/releases/app-binary"
Všechny tokeny ukládejte jako CI secrets a odkazujte na ně přes proměnné prostředí — nikdy je napevno nepište do skriptu. A používejte --fail (nebo --fail-with-body, pokud potřebujete pro ladění vidět tělo chyby), aby rozbité stahování skutečně rozbilo build místo tichého „úspěchu“ s odpadem.
Bezpečnostní otázka curl | sh
Tohle se objevuje skoro na každém developerském fóru, které jsem četl, a není divu: poslat výstup z curl rovnou do sh znamená spouštět vzdálený kód, který jste nezkontrolovali, a spoléhat výhradně na to, že server nebyl kompromitován a spojení nebylo podvržené. To je skutečné riziko — ne paranoia, ale prostý problém dodavatelského řetězce.
Bezpečnější postup je nejdřív skript stáhnout, podívat se do něj, ověřit checksum nebo GPG podpis, pokud je k dispozici, a teprve potom ho spustit:
curl -sL https://example.com/install.sh -o install.sh
cat install.sh # opravdu si ho přečtěte
sha256sum install.sh # porovnejte s publikovaným checksumem, pokud existuje
bash install.sh
Známé instalační nástroje jako rustup a Homebrew tenhle vzor curl | sh stejně používají a v jejich konkrétních případech je obecně přijímaný, protože autoři i distribuční kanál jsou dlouhodobě důvěryhodní. Já bych ale těch deset sekund navíc na kontrolu skriptu stejně rád obětoval, než později zjistit, že jsem mu neměl věřit.
Když cURL nestačí: stránky renderované přes JS, anti-bot ochrany a strukturovaná data
Tady je režim selhání, na který naráží spousta lidí, a často to ani není jejich chyba: spustíte curl -O na stránku, která vypadá normálně, a místo očekávaného obsahu dostanete prázdnou HTML kostru, challenge od Cloudflare nebo něco, co vypadá jako nesmysl. curl udělal přesně to, k čemu byl vytvořen — stáhl syrovou HTTP odpověď — jen neumí spouštět JavaScript, řešit CAPTCHA ani projít anti-bot fingerprintingem. To nejsou chyby curlu; to je prostě mimo jeho působnost.
Proč cURL selhává na moderních webových stránkách
Moderní single-page aplikace často vracejí téměř prázdnou HTML kostru a skutečný obsah vykreslují na klientovi pomocí JavaScriptu až po načtení stránky — což curl nikdy nespustí. Navíc systémy jako Cloudflare a Akamai aktivně servírují challenge stránky čemukoli, co nevypadá jako skutečný prohlížeč, a opakované požadavky z curlu z jedné IP adresy se velmi rychle mohou dostat do rate limitu nebo být označeny jako bot traffic.
Další krok: AI scraping API pro vývojáře
Řekl bych, že cURL je správný nástroj asi pro 80 % stahování souborů a dat — statická aktiva, API odpovědi, cokoli doručené jako běžný HTTP zdroj. Ten zbylý problémových 20 %, tedy JavaScriptem těžké nebo botem chráněné stránky, je místo, kde jsem viděl vývojáře utrácet hodiny bojem s hlavičkami a user-agent řetězci, než to nakonec vzdali a sáhli po jiné vrstvě.
Právě tuhle mezeru si náš tým v Thunderbit vytkl za cíl vyplnit, spolu s rozšířením do Chromu, které nás většina lidí zná. Pro vývojáře nabízí Thunderbit Open API endpoint POST /distill, který vrací čistý Markdown připravený pro LLM z URL — s vykreslením stránky zajištěným službou — a POST /extract, který vrací strukturovaný JSON odpovídající schématu, když potřebujete skutečná pole místo čitelného textu. K dispozici je i MCP server, takže agenti v Claude nebo Cursor mohou během úkolu volat thunderbit_distill a thunderbit_extract, a také CLI (npx @thunderbit/thunderbit-cli distill <url>), které se v terminálu chová hodně jako curl. JSON výstup můžete poslat do jq, například thunderbit distill <url> --format json | jq -r '.data.markdown'; výstup --format markdown pošlete třeba do textového nástroje nebo do souboru.
Vedle sebe je ten rozdíl markantní. Požadavek curlu na stránku renderovanou přes JavaScript může vrátit převážně prázdné <div id="root"></div>. Odpovídající příkaz thunderbit distill vrátí vykreslený obsah stránky jako čistý Markdown. Distill stojí 1 kredit za URL a Extract 20 kreditů za URL. Aktuální limity pro jednotlivé endpointy se liší: Batch Distill podporuje až 100 URL na jeden job, zatímco Batch Extract přijímá až 50 URL s jedním sdíleným schématem. Před plánováním produkční fronty si vždy zkontrolujte aktuální API dokumentaci.
Pokud je vám koncept obecně ještě trochu nový, náš vlastní článek co vlastně web scraping obnáší je dobrý začátek a průvodce scrapingem bez kódu vysvětluje stejný problém z pohledu lidí, kteří se na terminál vůbec nechystají. Pro širší srovnání nástrojů v tomhle prostoru jsme také dali dohromady přehled nejlepších AI web scraperů, které stojí za pozornost.
Rychlá reference: tahák pro stahování s cURL
| Úkol | Příkaz |
|---|---|
| Základní stažení | curl -LO <url> |
| Vlastní název souboru | curl -L -o muj-soubor.zip <url> |
| Obnovení stahování | curl -C - -LO <url> |
| Tichý režim s vypisováním chyb | curl -sSL -O <url> |
| Paralelní stahování | curl --parallel --parallel-max 5 -O <url1> -O <url2> |
| Autentizace bearer tokenem | curl -H "Authorization: Bearer <token>" -LO <url> |
| Výchozí skriptované stahování | curl -LO --retry 5 --retry-delay 3 --max-time 600 --fail <url> |
| Předání do nástroje pro extrakci | curl -sL <url> | tar xz |
Závěr a hlavní poznatky
Stahování souboru pomocí curlu začíná jednoduše — curl -O a jste skoro hotovi — ale skutečná dovednost je ve vrstvách pod tím: vědět, kdy přidat -L, kdy obnovit stahování místo restartu, který autentizační vzor se skutečně hodí pro váš workflow a co dělat ve chvíli, kdy se místo očekávaného souboru objeví 403 nebo prázdná HTML kostra. Všechna tahle pravidla jsem si v nějaké chvíli osvojil, většinou právě ve chvíli, kdy jsem na vlastní kůži poznal, proč na nich záleží.
curl pro mě pořád zůstává výchozím nástrojem pro jednoduché stahování souborů a skriptovatelnou práci s HTTP — je rychlý, je všude a krásně se skládá se zbytkem shell pipeline. Když ale narazíte na stránku renderovanou přes JavaScript nebo anti-bot bariéru, není to problém, který vyřeší víc přepínačů u curlu; je to signál, že potřebujete jinou vrstvu, a přesně tam nastupuje API jako Thunderbit, aniž by vás nutilo opustit terminál.
Uložte si ten tahák do záložek, vyzkoušejte příkaz pro opakování a obnovení stahování při příštím nespolehlivém downloadu a pokud narazíte na zeď, kde curl vrací jen nesmysly, už víte, jak vypadá další krok — stránka s cenami Thunderbit vám ukáže aktuální rozpad kreditů, pokud chcete vědět, kolik tenhle přesun do jiné vrstvy skutečně stojí, a náš YouTube kanál nabízí videonávody, pokud raději sledujete než čtete.
Často kladené otázky o stahování souborů pomocí cURL
Jak stáhnu soubor pomocí cURL a uložím ho pod konkrétním názvem?
Použijte -o a za něj požadovaný název souboru: curl -L -o vasnazev.ext <url>. Přidejte -L, aby přesměrování nestáhlo celý proces z cesty.
Jak obnovím neúspěšné stahování v cURL?
Spusťte curl -C - -LO <url>. Funguje to jen tehdy, když server podporuje range requests — nejdřív to ověřte příkazem curl -I <url> a ve výstupu hledejte Accept-Ranges: bytes.
Dokáže cURL stahovat soubory vyžadující přihlášení?
Ano, čtyřmi hlavními způsoby: základní autentizace (-u user:pass), bearer tokeny (-H "Authorization: Bearer <token>"), session založené na cookies (-b cookies.txt) nebo soubor .netrc pro skriptovaná prostředí. V sekci o autentizaci výše najdete kompletní rozbor a doporučení, kdy co použít.
Jaký je rozdíl mezi cURL a wget při stahování souborů?
cURL podporuje více protokolů a je obecně lepší pro skriptování, piping a přesné stahování jednoho souboru nebo malé dávky souborů. wget je stavěný na rekurzivní procházení a zrcadlení celých adresářů webu, takže je lepší volbou pro hromadné stahování statických webů.
Proč cURL stáhne HTML stránku místo skutečného souboru?
Dva běžní viníci: zapomněli jste na přepínač -L a server vás přesměroval jinam, nebo stránka vyžaduje JavaScript k vykreslení skutečného obsahu — což curl prostě neumí spustit. V druhém případě budete potřebovat nástroj schopný vykreslování, ne další přepínače cURL.
