[Bjorne]

Ursprungligen postat av emilv

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:

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

[Clarence]

Ursprungligen postat av Bjorne

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:

//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]

Ursprungligen postat av Clarence

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]

Ursprungligen postat av tartareandesire

Fördelarna uppväger definitivt eventuella nackdelar och är man hyfsat van blir det sällan alltför tidsödande.

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.