- Home
- Categorie
- Società, Web e Cultura
- GT Fetish Cafè
- Archivio Contest & Esperienze
- Teecno
- il parser html più veloce
-
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