Python Web Scraping 2026-ban: httpx + BeautifulSoup + Playwright – mikor melyiket használja

A legtöbb 2018-as „Python webkaparás” oktatóanyag továbbra is a „requests + BeautifulSoup” kifejezést ajánlja. A „kérések” rész rendben van, de vannak jobb alapértelmezett értékek, és a modern web fele JavaScriptben jeleníti meg a tartalmat, így a klasszikus verem csendben visszaadja az üres oldalakat.

Ez az útmutató bemutatja a 2026-os döntési fát: mikor van igaza a „httpx + BeautifulSoup” (a webhelyek még mindig több mint 90%-a), mikor kell nyúlni a „Playwright”-hoz, hogyan kerüljük el a blokkolást, valamint a két szabályt, amelyek megőrzik a kaparó legális és etikus működését.

A döntési fa egy képen

ennyi. A kaparási feladatok 90 százaléka statikus HTML – a klasszikus (átnevezett) verem a megfelelő eszköz. A többihez JS végrehajtásra van szükség, és a Playwright a modern válasz.

1. lépés: httpx + BeautifulSoup (az eset 90%-ában)

A "httpx" a "requests" beugró helyettesítője. Ugyanaz az API, plusz HTTP/2 támogatás és natív aszinkron. A „BeautifulSoup” változatlan maradt 2015-höz képest – az elemző választása számít (az „lxml” ötször gyorsabb, mint az alapértelmezett).

Főbb választási lehetőségek:

• `headers={"User-Agent": ...}` — mindig valódi UA-t állítson be (a kapcsolattartási cím udvarias). Az alapértelmezett „httpx” UA gyakran le van tiltva.
• `timeout=10` — soha ne küldjön korlátlan kérést; lógott kapcsolatok szivárgási fájlleírók.
• `raise_for_status()` — emel 4xx/5xx-en, így a hibák hangosak, nem némák.
• `"lxml"` elemző – 5-ször gyorsabb, mint az alapértelmezett "html.parser", és elnézőbb a hibás HTML-kóddal.
• `soup.select("css-selector")` – a kaparást úgy kell kezelni, mint "úgy, mintha a JavaScript `document.querySelectorAll"-ját használnád. A CSS-szelektorok általában azt jelentik, amit szeretne, nem a fán járó API-t.

2. lépés: drámaíró (amikor JS rendereli a tartalmat)

Sok modern SPA (React, Vue, Angular) üres <div id="root">-t szállít, és mindent hidratál az ügyféloldalon. A „httpx.get” egy üres shellt kap – a kívánt adatok a „fetch” paranccsal töltődnek be az oldal betöltése után.

Teszt: httpx.get(url).text – keresse meg a kívánt adatokat. Ha nincs ott, a webhelynek JS-végrehajtásra van szüksége.

Telepítés: pip install playwright && playwright install chromium (a böngésző letöltése ~150 MB – egyszer megéri, minden gyorsítótárazás nélküli CI futtatáskor fájdalmas).

Költség: A Playwright 10-50-szer lassabb, mint a „httpx” (oldalbetöltés + JS végrehajtás + böngésző többletköltsége). Csak akkor nyúljon hozzá, ha az adatok nincsenek a statikus HTML-ben.

A blokkolások négy módja

A legtöbb karcolásgátló rendszer ezt a négy ujjlenyomatot figyeli:

1. Hiányzó / nyilvánvaló User-Agent

2. Nincs késés a kérések között

A nyers szekvenciális kérelmek kalapálják a szervert. Adjon hozzá a válaszidejükkel arányos késleltetést – ha egy oldal 500 ms-ig tart, várjon 500-2000 ms-ot a kérések között. `asyncio.sleep(random.uniform(0.5; 2.0))".

3. A /robots.txt nem engedélyezett elérési utak kérése

Egyes webhelyek a "robots.txt" fájlt használják legális sebességjelekhez – ellenőrizze lekaparás előtt:

4. TLS/böngésző ujjlenyomat eltérés

Fejlett karcolásgátló (Cloudflare, DataDome) ujjlenyomat a TLS kézfogás és JS környezet. A „httpx” nem hasonlít a Chrome-hoz a TLS rétegben. Opciók:

• "curl_cffi" – egy curl-megszemélyesítésen alapuló könyvtár, amely a valódi böngésző TLS-jét utánozza.
• Dramaturg – valódi böngésző TLS definíció szerint.
• Lakossági proxyk forgatása – a nukleáris lehetőség.

A használati esetek 99%-ánál (nem ellenséges oldalak, mérsékelt hangerő, nem szükséges bejelentkezés) elegendő a httpx + valós UA + késleltetés + robots.txt tisztelet. Ha a Cloudflare által védett webhelyeket nagy mennyiségben kaparja össze, valódi böngészőkre vagy fizetős feloldó szolgáltatásokra van szüksége.

A sebesség korlátozása (a szemafor + alvásminta)

Tömeges lekaparáshoz kombinálja az "asyncio.Semaphore" (maximum egyidejű) és az "asyncio.sleep" (kérésenkénti késleltetés) paramétert:

Az 5-10 egyidejű + 500 ms-2 s kérésenkénti késleltetés határértéke jóval az alatt tart, ami a legtöbb webhelyen sebességkorlát riasztást vált ki.

Jogi + etikai szabályok

1. Olvassa el a webhely szolgáltatási feltételeit. Sokan tiltják a lekaparást – továbbra is megteheti (a szerződési jog a legtöbb joghatóságban nem büntetőjog), de jogi kockázatot vállal. A LinkedIn v. hiQ (2022) megállapította, hogy a nyilvánosan látható adatok kaparása nem jelenti a CFAA megsértését az Egyesült Államokban, de a kapucnis pulcsi viselése nem tesz láthatatlanná.

2. Ne kaparjon ki személyes adatokat. A GDPR / CCPA / minden más bünteti a személyes adatok hozzájárulás nélküli gyűjtését. Ha „X vállalat alkalmazottai” adatkészletet készít, hagyja abba.

Etikai kiegészítések, amelyeket mindenki elfelejt:

• Küldj valódi kapcsolattartási címet az UA-ban. Ha a robot problémát okoz, a webhely tulajdonosának e-mailt kell küldenie.
• Ha gyorsítótárba helyezi a webhely adatait, akkor agresszívan gyorsítótárazzon – ne érje el minden futáskor a szervereiket.
• Előnyben részesítse a nyilvános API-kat, még akkor is, ha fizetősek. Olcsóbb, mint a jogi kockázat.

A 2026-os szerszámok összefoglalója

| Feladat | Nyújtsa a |

|---|---|

| Statikus HTML oldalak | httpx + BeautifulSoup(html, "lxml") |

| JS-renderelt SPA | "Drámaíró" (fej nélküli Chromium) |

| Cloudflare / anti-bot | curl_cffi vagy Playwright + lakossági proxy |

| Nagy mennyiségű kaparás | httpx.AsyncClient + szemafor + alvás |

| Strukturált API adatok | httpx.get + .json() — nincs szükség levesre |

A webkaparás 2026-ban 90%-ban továbbra is „httpx + BeautifulSoup”, valamint azt is tudni, hogy mikor kell valódi böngészővé válnia. Sajátítsd el az udvarias kaparási szokásokat (valódi UA, szemafor, alvás, robots.txt), és tartós adatfolyamokat építhetsz ki anélkül, hogy blokkolnák vagy beperelnék.

Következő lépés: a Data Science track 15 leckét tartalmaz a kaparásról, az ETL-ről és a pandákról – valódi végpontok közötti folyamatot építhet a HTTP lekéréstől a DataFrame-en át a CSV-exportálásig.