Salve, sono nuovo su questo forum, mi sono iscritto qualche giorno fa e sono molto interessato a questo progetto..
Secondo le mie idee e quelle di phakko sarebbe meglio creare un spider che si divide in due file..

Primo file del spider esplora soltanto il web, cioè passando un link quest'ultimo esaminando tutta la pagina e facendo il parser del html mi restituisce tutti i links contenenti nella pagina.. che poi vengono slavati nel database, alla fine del parser si ricarica la pagina e pesca dal database un altro link da esaminare.. e così a ciclo un tot di numeri che si vuole parsare di pagine alla volta, si potrebbe mettere questo file nel CronTab soltanto di notte per non rallentare il server di giorno..

La seconda pagina invece pesca i link già esaminati dalla prima pagina del spider e recupera le keywords secondo l'algortmo attuale (Tf*IDF) ecc....

In questo modo si ha un spider molto più veloce, almeno credo...

Fatemi sapere cosa ne pensate, cmq se questa idea è ottima ho quasi pronta la prima pagina del spider con diversi controlli sui links, eliminazione di links doppi ecc.... Invece la seconda pagina sarà molto simile al codice scritto in spider attuale...

Cosa ne pensate?

Si potrebbe creare anche una terza pagina dello spider che esamina ogni tanto i links che sono già stati controllati in precedenza per vedere se ci sono delle modifiche...

Ciao Andriy,

benvenuto nel Forum gt e grazie per voler partecipare a questo progetto

secondo me è possibile farlo questo spider anche come dici tu

Facci vedere va

scusate ma per recuperare il title di una pagina non è meglio utilizzare una regular expression?
<title>(.+)</title>

ho letto per bene il codice dello spider, e si usano le regular expression, molto bene

mi piace molto come è stato progettato. volevo sapere se avete adottato qualche strategia information retrieval all'interno della ricerca.

Un consiglio: usatele il meno possibile, le funzioni di PHP basate su espressioni regolari. Sono molto più lente di str_replace() e str_ireplace().

Una domanda (alla quale prima o poi vi troverete a dover rispondere): come vi comportate con una pagina priva di tag <title>? Eheheh.

@Everfluxx said:

Un consiglio: usatele il meno possibile, le funzioni di PHP basate su espressioni regolari. Sono molto più lente di str_replace() e str_ireplace().

dove l'hai appresa questa cosa? posso farvi qualche pagina di test, ho i miei seri dubbi su questa affermazione

@domenico.biancardi said:

dove l'hai appresa questa cosa? posso farvi qualche pagina di test, ho i miei seri dubbi su questa affermazione E' cosa risaputa (mi pare ci sia anche un tip a riguardo nel manuale di PHP)...
Comunque, se non ti fidi della mia affermazione, ti basta una semplice ricerca su Google per verificarla.

no no questione di affezioniamento verso le regular expression. fare operazioni complesse in una istruzione è sempre molto bello, magari a scapito della velocità.

sta di fatto che per certe regex dovresti utilizzare 5-6 istruzioni di str_replace

non so dovrei fare dei test rimango dubbioso

Per le funzioni di parsing perché non vi appogiate al Perl: è dannatamente efficiente nella loro manipolazione...

Io ho un consiglio da darvi in base alla mia esperienza, calcolando che ho spiderizzato qualche milione di pagina web spero che vi possa essere utile.

Fate enorme attenzione agli errori del codice html, non sembra ma incasinano di brutto.

Sembra una boiata come consiglio, ma vi accorgerete che è un problema enorme!

Quoto UMOR. La funzione parser_html da per scontate parecchie cose come ad esempio che la pagina sia conforme ad un DDT. Inoltre, non limitatevi a controllate la sola intestazione HTTP per capire se si tratti o meno di HTML (i campi HTTP HEADER sono manipolabili), ma affidatevi ad analisi spot.

... Colgo la palla la balzo per suggerirvi una chicca: sottoporre le pagine ad un validatore come quello del validator.w3.org.

Tratto da: http://infolab.stanford.edu/~backrub/google.html

Parsing -- Any parser which is designed to run on the entire Web must handle a huge array of possible errors. These range from typos in HTML tags to kilobytes of zeros in the middle of a tag, non-ASCII characters, HTML tags nested hundreds deep, and a great variety of other errors that challenge anyone's imagination to come up with equally creative ones.

Ciao, una curiosità: l'output che deve dare la funzione e che serve a teecno è ancora quello iniziale?

Cosa fare nel caso ci siano due h1, si considera il secondo dato che dovrebbe essere più specifico?

@Fra_T said:

Cosa fare nel caso ci siano due h1, si considera il secondo dato che dovrebbe essere più specifico?

Infatti, lo sviluppo dei parser html è una area di ricerca molto interessante ma anche estremamente complessa. Io mi affiderei in questo caso alla stessa scelta dei motori di ricerca più importanti: mozilla. La piattaforma offre una serie di tool fantastici per l'analisi dei contenuti html attraverso l'interfaccia DOM standardizzata. Ciao

per quanto riguarda la gestione degli errori, proporrei la vecchia teoria delle iptable di linux (scusate se la prendo alla lunga ) ossia e' valido solo quello che dichiariamo e non l'operazione contraria (ossia tutto valido tranne quello che gli diciamo noi) che mi sembra piu' ostica , visto che gli errori sono tanti e tali quasi da non poter essere classificati.

non so le regular expression sono più lente, ma di sicuro sono molto più affidabili, leggibili e robuste proprio perche' vanno nella direzione espressa sopra... ossia verificano esattamente cosa far passare