WN

WN (https://www.wn.se/forum/index.php)
-   Serversidans teknologier (https://www.wn.se/forum/forumdisplay.php?f=4)
-   -   Vilken Scraping-teknik är bäst? (https://www.wn.se/forum/showthread.php?t=1047417)

Martin™ 2011-03-30 10:39

Vilken Scraping-teknik är bäst?
 
Vilken eller vilka metoder skulle du säga är bäst för att scrapa information från hemsidor?

1# Regex
2# XPath
3# Vet-ej-vad-den-heter*

Vet-ej-vad-den-heter*=
Citat:

"teknik för o skrapa sidor gjord i PHP5 som baserar sig på Curl samt en CSS selector motor liknande den i jQuery som gör att jag kan hantera buffern från curl anropet som vilken DOM baserad sida jag vill.. Ovanpå det hakar jag på en template motor för varje resturang site som definerar vad skrapen letar efter."

Magnus_A 2011-03-30 10:56

Beror helt på hur sidan ser ut och framförallt hur sidan ändras. Är det uppgifter som smyger in sig i långa textsjok kan regexp vara bättre och mer robust mot ändringar i omkringliggande text.
Handlar det om data strukturerad i tabeller och liknande är dom-baserade upplägg kanske bättre.
Viktigast är att du har bra varningssystem som talar om att sidan ändrats på ett sätt som gör att det är osäkert att du får ut rätt värden med din teknik.

emilv 2011-03-30 11:09

Definiera "bäst". Tänk efter vad som är prioriterat och välj den metod som passar bäst.

* Snabbt att skriva kod för varje sida
* Hastighet
* Minnesanvändning
* Processoranvändning
* Adapterbar, dvs passsar många hemsidor med så få ändringar som möjligt
* Automatiskt adapterbar, dvs letar själv upp vad som är rätt innehåll på sidan
* Många vitt skilda typer av sidor eller flera som liknar varandra?
* Pris (om du hyr in någon, annars tid)
* Inlärningströskel (om du gör det själv och inte har kunskapen)

Det finns säkert flera faktorer som spelar in i valet av teknik.

Bjorne 2011-03-30 12:19

XPath är bättre än att bara använda reguljära uttryck. I nyare versioner av XPath finns dessutom inbyggt stöd för reguljära uttryck så teknikerna står inte i motsatsförhållande till varandra. Teknik #3 som du nämner som använder sig av css-selektorer är sannolikt ett lager ovanpå XPath eftersom det är ganska lätt att konvertera css till xpathuttryck.

pelmered 2011-03-30 16:53

Jag har gjort en likande sak för något år sedan. Jag använde då cURL + regex, men jag vet inte om det är det bästa.

Det bästa och enklaste är väl att du antingen ansluter direkt till deras databas(vilket kanske inte är så troligt att du får) eller att de kan spotta ut informationen du vill i ett XML-dokument eller likande som du kan parsa med t.ex. SimpleXML. Du behöver ju ändå ha tillåtelse för att scrappa så det kanske inte är allt för svårt att fixa XML-lösningen om du kan fixa den åt dem. Det är den enklaste och den bästa lösningen i längden.
Jag har stött på en del problem när jag scrappat direkt ur HTMLen. Vissa sidor ändras ganska ofta och innehållet kan skilja väldigt mycket vilket gör att ditt skript då kommer misslyckas med att hämta datan. Det gör att du måste underhålla skriptet regelbundet vilket gör att du aldrig kan släppa det helt om det är viktigt att det fungerar.

emilv 2011-03-30 17:00

Citat:

Ursprungligen postat av ITisGood.se (Inlägg 20400347)
Du behöver ju ändå ha tillåtelse för att scrappa

Nej. Det är helt tillåtet att läsa av andras sidor. Hur man sedan använder informationen regleras bland annat av ifall den täcks av upphovsrätt, personuppgiftslag eller liknande. Men det finns dels andra användningsområden än att bara återpublicera det man läst in och dels material som inte faller inom upphovsrätten.

En seriös webbskrapare lämnar en identifierbar user-agent och respekterar robots.txt så att sajtägaren kan göra opt-out. Det är inte lag på det, men en god sed.

Clarence 2011-03-30 19:13

Citat:

Ursprungligen postat av Martin™ (Inlägg 20400255)
Vilken eller vilka metoder skulle du säga är bäst för att scrapa information från hemsidor?

1# Regex
2# XPath
3# Vet-ej-vad-den-heter*

Vet-ej-vad-den-heter*=

PHPQuery kan du nog titta på för #3.

Regex är krångligast men flexbilast. PHPQuery är väldigt enkelt att lära sig och de flesta har iallafall lite koll på hur det ska användas, de flesta med någon webberfarenhet har ju använt sig av jquery selektorer.

För andra språk, som t ex Python eller Java, finns rätt bra och mer utbyggda scraping bibliotek - men för PHP har iallafall inte jag hittat något intressant.

dAEk 2011-03-31 19:19

Utan att gå in på vad som är bäst tycker jag att någon form av parser som kan gå igenom DOM-trädet är att föredra. Skriver man en screen-scraper får man vara beredd på att sidorna ändras titt som tätt och då är det verkligen inge kul att sitta med en massa regex.

tartareandesire 2011-03-31 19:34

Citat:

Ursprungligen postat av dAEk (Inlägg 20400530)
Utan att gå in på vad som är bäst tycker jag att någon form av parser som kan gå igenom DOM-trädet är att föredra. Skriver man en screen-scraper får man vara beredd på att sidorna ändras titt som tätt och då är det verkligen inge kul att sitta med en massa regex.

Det bör väl påpekas att det inte är särskilt ovanligt med en inkorrekt html-struktur.

Clarence 2011-03-31 22:55

Citat:

Ursprungligen postat av dAEk (Inlägg 20400530)
Utan att gå in på vad som är bäst tycker jag att någon form av parser som kan gå igenom DOM-trädet är att föredra. Skriver man en screen-scraper får man vara beredd på att sidorna ändras titt som tätt och då är det verkligen inge kul att sitta med en massa regex.

Jag vet inte riktigt hur stor erfarenhet du har av scraping - men utifrån min erfarenhet är det tvärtom. Man blir mycket lättare beroende av korrekt och samma struktur i elementen om man kör en DOM parser snarare än en (lite öppen) regex. Däremot skriver jag mycket hellre en helt straight forward CSS selektor än pillar med bakåtreferenser osv. Däremot finner jag det omständigare än regex med de flesta sätten att traversera dom-trädet.

Det är från att ha haft igång scrapers för diverse funktioner över iallafall 5+ år mot ett bra antal väldigt olika källor. Sajter byter hela systemen oftare än de byter HTML:en lite för mycket i vilket fall, i min erfarenhet.

dAEk 2011-04-01 19:46

Bara en sån till synes enkel sak som att validera en e-postadress kräver att man läser uttrycket noga. Trots att formatet är spikat är uttrycket svårt att läsa och samtidigt lätt att tolka fel. Jag kan bara tänka mig hur en regex-scraper för dåligt Html-kodade sidor ser ut... Dom scrapers jag har skrivit har varit för olika privata projekt och jag har testat lite olika sätt att hämta ut informationen. Iofs är jag inte direkt bra på regex men man märker ganska snabbt om det kommer funka med uppdateringar i långa loppet.

Kanske hade jag otur med sajterna som jag läste av men jag tycker ändå att det gick upp för en att det inte är en fråga om utan när man behöver uppdatera koden. När den dagen är kommen vill man som vanlig dödlig helst inte sitta med avancerad regex.

emilv 2011-04-01 19:49

Citat:

Ursprungligen postat av dAEk (Inlägg 20400682)
Bara en sån till synes enkel sak som att validera en e-postadress kräver att man läser uttrycket noga. Trots att formatet är spikat är uttrycket svårt att läsa och samtidigt lätt att tolka fel. Jag kan bara tänka mig hur en regex-scraper för dåligt Html-kodade sidor ser ut... Dom scrapers jag har skrivit har varit för olika privata projekt och jag har testat lite olika sätt att hämta ut informationen. Iofs är jag inte direkt bra på regex men man märker ganska snabbt om det kommer funka med uppdateringar i långa loppet.

Kanske hade jag otur med sajterna som jag läste av men jag tycker ändå att det gick upp för en att det inte är en fråga om utan när man behöver uppdatera koden. När den dagen är kommen vill man som vanlig dödlig helst inte sitta med avancerad regex.

Min erfarenhet är att det räcker med en eller ett par reguljära uttryck för att tolka en sida. Dagen när man måste uppdatera sin kod kommer nästan oavsett vilken metod man väljer (förutom de mest avancerade automatiska metoderna, som förstår tabeller, rubriker och en massa annat, och som tar månader eller år att skriva). Då ser jag ingen direkt skillnad mellan XPath och reguljära uttryck i svårighetsgrad.

tartareandesire 2011-04-01 19:52

Måste instämma att regex för det mesta är att föredra. Fördelarna uppväger definitivt eventuella nackdelar och är man hyfsat van blir det sällan alltför tidsödande.

Vilken teknik du än väljer så kan du vara säker på en sak nämligen att detta är inte en engångskostnad. Har du ett gäng scrapers igång så kommer du garanterat att behöva uppdatera dessa då och då. Det är tråkigt värre men inte mycket man kan göra åt det.

dAEk 2011-04-01 20:07

Citat:

Ursprungligen postat av tartareandesire (Inlägg 20400684)
Fördelarna uppväger definitivt eventuella nackdelar och är man hyfsat van blir det sällan alltför tidsödande.

Kan du nämna några för- resp. nackdelar?

Jag verkar vara ganska ensam om att ogilla regex för den här typen av uppgifter. :eek: Vad har jag missat?

Bjorne 2011-04-01 20:34

Nej, du är inte ensam och jag tror inte du missat någonting alls. Jag skulle vilja se någon skriva en parser som parsar ut brödtexten ur alla inlägg till en tråd på wn.se. Med xpath är det en baggis.

Bjorne 2011-04-01 20:35

Citat:

Ursprungligen postat av tartareandesire (Inlägg 20400535)
Det bör väl påpekas att det inte är särskilt ovanligt med en inkorrekt html-struktur.

Det är inget som helst problem för de flesta domparserbibliotek.

emilv 2011-04-01 21:43

Citat:

Ursprungligen postat av Bjorne (Inlägg 20400691)
Nej, du är inte ensam och jag tror inte du missat någonting alls. Jag skulle vilja se någon skriva en parser som parsar ut brödtexten ur alla inlägg till en tråd på wn.se. Med xpath är det en baggis.

Det är en baggis med reguljära uttryck också (särskilt eftersom inläggen verkar ha kommentarer i början och slutet, något som är extremt lätt att fånga med reguljära uttryck). Jag har förresten inte tagit ställning för eller emot någon teknik utan hävdar fortfarande att det beror på omständigheterna.

Magnus_A 2011-04-01 22:22

Det svåra är inte att tolka en sida. Utan att få fram en sida efter diverse POST med viewstate, kakhantering och redirect.

tartareandesire 2011-04-01 23:04

Citat:

Ursprungligen postat av Magnus_A (Inlägg 20400700)
Det svåra är inte att tolka en sida. Utan att få fram en sida efter diverse POST med viewstate, kakhantering och redirect.

Jupps, säga vad man vill om Microsofts produkter men de gör det helt klart svårare för snyltgäster. Sharepoint är ingen dålig produkt alls även om jag själv inte arbetar med Microsoft-produkter.

Clarence 2011-04-02 13:11

Citat:

Ursprungligen postat av dAEk (Inlägg 20400682)
Bara en sån till synes enkel sak som att validera en e-postadress kräver att man läser uttrycket noga. Trots att formatet är spikat är uttrycket svårt att läsa och samtidigt lätt att tolka fel.

Kanske hade jag otur med sajterna som jag läste av men jag tycker ändå att det gick upp för en att det inte är en fråga om utan när man behöver uppdatera koden. När den dagen är kommen vill man som vanlig dödlig helst inte sitta med avancerad regex.

Sitter du med Xpath-parser blir inte dina uttryck speciellt mycket roligare om du ska ha in lite valfria element, bakåtreferenser, text-parsers osv. Jag skulle snarare säga att du helt plötsligt får ett 5 gånger längre och mångt mycket krångligare uttryck. Eller så får du 5 ggr mer utomstående kod för sträng-hantering och jämförelse, och sedan ett bra antal xpath-uttryck att underhålla paralellt.

Kompetenta programmerare kan gå igenom regex, men en total röra med xpath blir värre.

Bjorne 2011-04-03 10:58

Citat:

Ursprungligen postat av emilv (Inlägg 20400698)
Det är en baggis med reguljära uttryck också (särskilt eftersom inläggen verkar ha kommentarer i början och slutet, något som är extremt lätt att fånga med reguljära uttryck). Jag har förresten inte tagit ställning för eller emot någon teknik utan hävdar fortfarande att det beror på omständigheterna.

Det du då får fram är ett gäng med html-block. Ur de blocken måste du fortfarande ta fram vad som är brödtexten till inläggen. Tänk på att inläggen kan ha inbäddade citat och kodblock som måste rensas bort. xpathuttrycket för uppgiften blir någonting i stil med:
Kod:

//div[contains(@id, "post_message")]/text()

Clarence 2011-04-03 13:06

Citat:

Ursprungligen postat av Bjorne (Inlägg 20400809)
Det du då får fram är ett gäng med html-block. Ur de blocken måste du fortfarande ta fram vad som är brödtexten till inläggen. Tänk på att inläggen kan ha inbäddade citat och kodblock som måste rensas bort. xpathuttrycket för uppgiften blir någonting i stil med:
Kod:

//div[contains(@id, "post_message")]/text()

Jag kan hålla med dig om att med ett sådant enkelt uppdrag för en scraper så är det smidigare med Xpath. När du börjar få lite jobbigare mönster och mer att ta hänsyn till däremot, det är då jag tycker xpath blir omständigare. När du har lite olika struktur beroende på innehåll, olika element som ska tas hänsyn till beroende på det, och sedan bara ska ha ut en liten del av texten som finns där. Då får du dels använda regex för text-parsingen i efterhand ändå, och sedan antingen skapa ett riktigt långt xpath-uttryck eller underhålla flera parallellt.

dAEk 2011-04-03 23:46

Citat:

Ursprungligen postat av Clarence (Inlägg 20400748)
Jag skulle snarare säga att du helt plötsligt får ett 5 gånger längre och mångt mycket krångligare uttryck. Eller så får du 5 ggr mer utomstående kod för sträng-hantering och jämförelse, och sedan ett bra antal xpath-uttryck att underhålla paralellt.

Jo, men fördelen är att de är lätta att ändra även om det är fler uttryck. Det kanske blir en PITA i långa loppet, jag har inte haft någon scraper i drift som varat så länge. Som sagt, det jag har gjort i det här området är ganska litet och smalt. Det har mer eller mindre handlat om att extrahera statistik eller annan typ av tabelldata och i dom lägena har det varit enklare att använda något annat än regex. Skulle jag skriva en snurra som hämtade ut t.ex. alla e-postadresser på en sida hade jag nog gjort det med regex, så jag antar att det som några redan skrivit stämmer: det beror på fall till fall.

Som tur är finns ju bibliotek som gör livet enklare för utvecklare. För .NET är HtmlAgilityPack och Fizzler två trevliga lösningar. De innebär att man kan använda API:t för det mesta men möjligheten att ställa XPath-frågor mot dokumentet finns fortfarande kvar.

dAEk 2011-04-07 23:29

Citat:

Ursprungligen postat av tartareandesire (Inlägg 20400684)
Fördelarna uppväger definitivt eventuella nackdelar och är man hyfsat van blir det sällan alltför tidsödande.

Citat:

Ursprungligen postat av dAEk
Kan du nämna några för- resp. nackdelar?

Hallå?


Forumbegränsning: meddelandet måste vara minst 10 tecken långt.


Alla tider är GMT +2. Klockan är nu 12:41.

Programvara från: vBulletin® Version 3.8.2
Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
Svensk översättning av: Anders Pettersson