@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