Newsgroup: it.comp.lang.c++
Titolo: parsen tag html

Mi piacerebbe considerare il funzionamento di un parsen tag_HTML,
qualcuno ha già fatto un lavoro simile?
vorrei provare a tradurre i tag in modo ricorsivo, ma se qualcuno ha
qualche suggerimento sulla stesura del parsen è ben accetto,
gestisco i tag_html in una lista_tag e ciascuno utilizza un
id_riferimento (WORD),
il file html viene scansionato dal principio e quando viene trovato un
tag della lista, viene inserito
l'id_riferimento del tag e l'id_riferimento del tag di chiusura in una
pila per controllare l'apertura e chiusura
del tag...
alla fine dovremmo avere una pila vuota come all'inizio,
in alternativa i tag sono stati mal interpretati o incompleti,
contemporaneamente a questa scansione viene aggiornata una lista
(altrimenti tutta la traduzione risulta inutile)
per ogni tag trovato, l'id_riferimento, la posizione iniziale del tag
nel file e la posizione finale del tag nel
file,
tutto questo per estrarre in maniera configurabile, testo, url e
riferimenti che occorrono alla descrizione del
contenuto,
mi piacerebbe ascoltare qualche opinione sul NG, ma anche riferimenti
possono essere utili, purchè
in italiano ;)
grazie in anticipo

anzitutto è un parseR e non un parseN...
l'idea della pila è la scelta più giusta per un file simile, anche se
attenzione, bisogna decidere quale tipo di file si vuole parsare,
l'html canonico permette tag aperti e non chiusi (<li>, <br>, <img>),
mentre è l'XHTML che necessita di chiusure ad ogni apertura (e in
ordine inverso, cosa che nell'HTML non è richiesto)
quindi col tuo rigido metodo il parser sarebbe per XHTML e non per le
pagine HTML normali... è vero che la rete va verso l'XHTML, ma prima
che tutte le pagine seguiranno questo standard saranno passati anni
più che mettere un id_riferimento, che se non ho capito male indica
quale tag è stato aperto, forse converrebbe mettere proprio una
stringa che indica il tag... anche perché, sempre tornando all'XHTML,
potrebbero esserci nuovi tag non standard
più che una lista, forse, dovresti avere un albero, data la struttura
dell'HTML e funzioni che ti permettano di scendere a nodi figli e a
foglie (testo, ad esempio)
ti stavo per dare vari riferimenti... ma in italiano non ho nulla :-D
forse qualcun altro potrà esserti utile in questo
-- 
]\/[ad]\/[age (
www.mindreamz.net
)
"Un Maestro insegue semplicemente la sua visione di Eccellenza in
qualunque cosa sta facendo e lascia agli altri decidere se sta 
lavorando o giocando. A lui sembra sempre di fare entrambe." - Anonimo

 pagine HTML normali...
XHTML è un'applicazione XML.
Quindi per fare il parsing di XHTML ci vuole un parser XML.
a duidols:
Effettuare il parsing di un file del genere a cosa ti serve?
Vuoi rappresentarlo in qualche modo?
Vuoi farne il rendering? 
Se la risposta è si scaricati i sorgenti di Mozilla e divertiti: sono
abbastanza comprensibili e ben documentati.
-- 
Domenico Testa - Studente

Quindi per fare il parsing di XHTML ci vuole un parser XML.
e questo chi l'ha detto? uno può costruire tranquillamente un parser
XHTML che non sia parser XML... è vero, ovviamente, che ogni parser
XML è anche un parser XHTML


XML è anche un parser XHTML
ho detto una scemenza


premetto che il parser più complesso che ho scritto è di qualche
decina di comandi per di più non modificabili, tutto facile insomma,
la traduzione di un file diventa molto più complessa e prima di
scrivere un rigo vorrei capire ciò che è meglio fare, per questo ti
ringrazio dei consigli,
-
l'idea della pila è la scelta più giusta per un file simile, anche se
attenzione, bisogna decidere quale tipo di file si vuole parsare,
l'html canonico permette tag aperti e non chiusi (<li>, <br>, <img>),
mentre è l'XHTML che necessita di chiusure ad ogni apertura (e in
ordine inverso, cosa che nell'HTML non è richiesto)
l'inserimento del tag di chiusura non dovrebbe essere obbligatoria in
un pila,
si potrebbero tradurre anche tag "aperti", addirittura "multipli",
questi verrebbero eliminati dalla medesima soltanto se il tag lo
permette
-
quindi col tuo rigido metodo il parser sarebbe per XHTML e non per le
pagine HTML normali... è vero che la rete va verso l'XHTML, ma prima
che tutte le pagine seguiranno questo standard saranno passati anni
sintetizzando, un tag configurabile deve avere possibilità variabile,
apertura (anche una serie di tag multipli),
apertura e chiusura contemporaneamente,
-
più che mettere un id_riferimento, che se non ho capito male indica
quale tag è stato aperto, forse converrebbe mettere proprio una
stringa che indica il tag... anche perché, sempre tornando all'XHTML,
potrebbero esserci nuovi tag non standard
la dinamicità del parser non l'ho considerata, credo basti gestire
determinati caratteri di apertura\chiusura per i file xhtml ma la cosa
si complicherebbe, comunque realizzabile,
la rigidità di traduzione a favore della semplicità d'implementazione
e velocità d'analisi,
il tag dovrebbe già essere inserito nella lista per riconoscerlo,
i nuovi tag probabilmente verrebbero estratti come testo
-
più che una lista, forse, dovresti avere un albero, data la struttura
dell'HTML e funzioni che ti permettano di scendere a nodi figli e a
foglie (testo, ad esempio)
questa soluzione struca-struca è fulcro di tutta l'implementazione,
la strutturazione ad albero si avvicina molto di più al linguaggio
html,
ma non riesco a concluderne una gestione semplice e veloce,
sicuramente è la mia ignoranza sull'argomento e per questo volevo
discuterne,
sto cercando di gestire la traduzione tag con il risultato di 3
elementi,
la lista dei tag
il file da tradurre,
il risultato del parser.
// fin qui sarebbe un gran aiuto sapere
// se sono sulla strada giusta
Dal momento in cui ho avuto la traduzione per qualsiasi manipolazione
(visuale\gestionale), devo sempre considerare 2 elementi,
il file e il risultato parser
personalmente la lista sembra più veloce e gestibile,
in un file html non credo siano presenti più di un migliaio di tag da
tradurre, pertanto anche una ricerca lineare non dovrebbe comportare
troppi controlli,
ma forse mi sbaglio, dovrei sapere se i diversi browser hanno
preferito la rappresentazione ad albero o meno,
mi sto forse spingendo verso un'implementazione poco dinamica?

a duidols:
Effettuare il parsing di un file del genere a cosa ti serve?
esercizio didattico,
Vuoi rappresentarlo in qualche modo?
si, mi basterebbe creare semplici elenchi per vedere se il parser
funziona
Vuoi farne il rendering?
non lo so, bisognerebbe prima che capissi come implementare il parser
grazie per il riferimento, mozilla non lo conosco, ma approfondirņ
chiedendo nel NG appropriato

non è che sei molto chiaro: in soldoni che cosa vuoi che faccia il tuo
parser? perché finché continuiamo a parlare di cose generiche e parser
xml, alberi, liste, ecc., sfugge lo scopo e quindi tutti i dettagli di
implementazione sono inutili
il fatto della pila, ad esempio, non è chiaro... pensavo tu volessi
inserire un tag nella pila quando ne incontri l'apertura e toglierlo
dalla pila quando ne incontri la chiusura... per questo hai problemi
coi tag non chiusi o, peggio, con quelli chiusi non nell'ordine giusto
non mi è chiaro cosa ci vuoi mettere nella lista e, soprattutto,
perché
cmq, i browser parsano il file html creando un albero, il che è dovuto
anche (ma non solo) al fatto che senza DOM (cioè proprio l'albero), il
JavaScript non ha senso


non è che sei molto chiaro: in soldoni che cosa vuoi che faccia il tuo
parser? perché finché continuiamo a parlare di cose generiche e parser
xml, alberi, liste, ecc., sfugge lo scopo e quindi tutti i dettagli di
implementazione sono inutili
estrarre i tag html e gestirne la manipolazione,
se voglio vedere solo le url,
se voglio vedere solo le immagini,
se voglio vedere solo i riferimenti a file
se voglio solo il contenuto testuale nudo e crudo senza collegamenti
-
pensavo tu volessi inserire un tag nella pila quando ne incontri
l'apertura e toglierlo
dalla pila quando ne incontri la chiusura...
infatti è così,
la pila viene creata all'estrazione di un tag dal file,
ma non dovrebbero esserci problemi con i tag aperti, questi potrebbero
non produrre l'inserimento nella pila perchè abbiamo già trovato la
chiusura,
-
non mi è chiaro cosa ci vuoi mettere nella lista e, soprattutto,
perché
il perchè è solo per interpretare un linguaggio che ti permette di
interagire con internet,
fare un parser per html mi sembra un buon obbiettivo ;)
sulla lista c'è da discutere, è il fulcro dell'interpretazione,
sto ancora pensando a come gestire il risultato degli id_riferimento
-
cmq, i browser parsano il file html creando un albero, il che è dovuto
anche (ma non solo) al fatto che senza DOM (cioè proprio l'albero), il
JavaScript non ha senso
il fatto che utilizzino un albero già mi ha indirizzato,
un punto in cui sono ancora un po' titubante è il fatto della ricerca
nella lista tag,
questa infatti deve essere eseguita completamente ad ogni singolo
carattere del file html se non abbiamo trovato un tag appropriato che
ci permette di saltare la lunghezza del tag,
è un metodo che utilizzano tutti parser oppure mi sto nuovamente
insabbiando?
naturalmente la lista lineare è già declassata,
al suo posto è entrato un b-tree che mi permette di incanalare la
ricerca con pochi movimenti,
grazie ancora.

insabbiando?
questa non l'ho proprio capita!! perché mai dovresti rileggere tutta
la lista AD OGNI CARATTERE?!?
