Bonjour, j'aimerais supprimer toutes les balises HTML d'un texte (cad les
chaines du type <xxx>) mais il me supprime trop... c assez bizare et pourtant
l'expression reguilere que j'utilise me semble juste... la voici:
j'ai l'impression que si on a qqch du type "<TAG1> hello <TAG2>"... il prend
tout alors qu'il devrai seulement prendre <TAG1> et <TAG2>... je ne comprend
pas pq... qqn pourrait me donner la bonne expression a utiliser pour
supprimer SEULEMENT les balise (et donc, qu'il ne reste plus que le "hello")
Merci d'avance
peut on avoir un exemple d'ambiguité perturbant cette regex ?
<tag1 onclick="if (x>1) then DoThat();" attr2=val2>
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
Patrick Philippot
laurent courbez wrote:
peut on avoir un exemple d'ambiguité perturbant cette regex ?
Ne vous faites aucune illusion, il est impossible de parser correctement un texte HTML avec des expressions régulières uniquement. Même un parseur complet a du mal.
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
laurent courbez wrote:
peut on avoir un exemple d'ambiguité perturbant cette regex ?
Ne vous faites aucune illusion, il est impossible de parser correctement
un texte HTML avec des expressions régulières uniquement. Même un
parseur complet a du mal.
--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr
peut on avoir un exemple d'ambiguité perturbant cette regex ?
Ne vous faites aucune illusion, il est impossible de parser correctement un texte HTML avec des expressions régulières uniquement. Même un parseur complet a du mal.
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
Faust
hum, y'a pourtant 2 règles simples: - une balise s'ouvre avec < et se ferme avec > - tout symbole < ou > devant être mis dans les paramètres de la balise doivent être encadrés par des " ou '
/_Patrick Philippot_ avait prétendu/ :
laurent courbez wrote:
peut on avoir un exemple d'ambiguité perturbant cette regex ?
Ne vous faites aucune illusion, il est impossible de parser correctement un texte HTML avec des expressions régulières uniquement. Même un parseur complet a du mal.
-- Mephitiquement votre, Faust ICQ #161252577
hum, y'a pourtant 2 règles simples:
- une balise s'ouvre avec < et se ferme avec >
- tout symbole < ou > devant être mis dans les paramètres de la balise
doivent être encadrés par des " ou '
/_Patrick Philippot_ avait prétendu/ :
laurent courbez wrote:
peut on avoir un exemple d'ambiguité perturbant cette regex ?
Ne vous faites aucune illusion, il est impossible de parser correctement un
texte HTML avec des expressions régulières uniquement. Même un parseur
complet a du mal.
hum, y'a pourtant 2 règles simples: - une balise s'ouvre avec < et se ferme avec > - tout symbole < ou > devant être mis dans les paramètres de la balise doivent être encadrés par des " ou '
/_Patrick Philippot_ avait prétendu/ :
laurent courbez wrote:
peut on avoir un exemple d'ambiguité perturbant cette regex ?
Ne vous faites aucune illusion, il est impossible de parser correctement un texte HTML avec des expressions régulières uniquement. Même un parseur complet a du mal.
-- Mephitiquement votre, Faust ICQ #161252577
laurent courbez
c'est pas vraiment un argument !
Du html "bien formé" (au sens w3c du terme) est immanquablement "parsable" sans l'être pour autant trivialement.
Pour le reste, c'est une autre affaire. Mais dans ce cas là, c'est plus vraiment du html, on peut néanmoins s'en sortir avec une heuristique bien pensée, c'est ce que font ie, firefox, opera, konqueror, etc ...
S'ils le font, c'est donc possible, même si on rencontre des différences d'interprétation. Malgré cela, 90% des pages html sont interprétées quasi identiquement par ces browsers.
LC.
Patrick Philippot a écrit :
laurent courbez wrote:
peut on avoir un exemple d'ambiguité perturbant cette regex ?
Ne vous faites aucune illusion, il est impossible de parser correctement un texte HTML avec des expressions régulières uniquement. Même un parseur complet a du mal.
c'est pas vraiment un argument !
Du html "bien formé" (au sens w3c du terme) est immanquablement
"parsable" sans l'être pour autant trivialement.
Pour le reste, c'est une autre affaire. Mais dans ce cas là, c'est plus
vraiment du html, on peut néanmoins s'en sortir avec une heuristique
bien pensée, c'est ce que font ie, firefox, opera, konqueror, etc ...
S'ils le font, c'est donc possible, même si on rencontre des différences
d'interprétation. Malgré cela, 90% des pages html sont interprétées
quasi identiquement par ces browsers.
LC.
Patrick Philippot a écrit :
laurent courbez wrote:
peut on avoir un exemple d'ambiguité perturbant cette regex ?
Ne vous faites aucune illusion, il est impossible de parser correctement
un texte HTML avec des expressions régulières uniquement. Même un
parseur complet a du mal.
Du html "bien formé" (au sens w3c du terme) est immanquablement "parsable" sans l'être pour autant trivialement.
Pour le reste, c'est une autre affaire. Mais dans ce cas là, c'est plus vraiment du html, on peut néanmoins s'en sortir avec une heuristique bien pensée, c'est ce que font ie, firefox, opera, konqueror, etc ...
S'ils le font, c'est donc possible, même si on rencontre des différences d'interprétation. Malgré cela, 90% des pages html sont interprétées quasi identiquement par ces browsers.
LC.
Patrick Philippot a écrit :
laurent courbez wrote:
peut on avoir un exemple d'ambiguité perturbant cette regex ?
Ne vous faites aucune illusion, il est impossible de parser correctement un texte HTML avec des expressions régulières uniquement. Même un parseur complet a du mal.
Patrick Philippot
laurent courbez wrote:
c'est pas vraiment un argument !
Du html "bien formé" (au sens w3c du terme) est immanquablement "parsable" sans l'être pour autant trivialement.
Je ne dis pas que l'HTML n'est pas parsable - heureusement, il l'est :-) - , je dis qu'il ne l'est pas en utilisant uniquement des expressions régulières. En tous cas, l'exemple que j'ai donné est correctement formé (sauf erreur de ma part) et il semble difficile de trouver une expression régulière qui s'en accomode. Ou plutôt non, on peut trouver une expression qui traitera ce cas mais qui sera mise aisément en défaut par une variante du même source.
AMHA, je ne conçois pas une opération de parsing efficace d'un source HTML à partir de code qui utiliserait uniquement des expressions régulières. HTML est défini à partir d'une grammaire et c'est cela qu'il faut exploiter pour le parser.
La question est par ailleurs de savoir si on écrit un parseur qui est censé recevoir un flux HTML conforme à la spec ou un flux HTML provenant du mondé réel (écrit à la main ou généré par des éditeurs plus ou moins fiables). Il suffit d'afficher au hasard le source des pages que l'on affiche dans son browser pour se rendre compte qu'il y a une marge, que dis-je, un abîme, entre les specs du W3C et la réalité quotidienne. C'est bien pour cela que les browsers ont du mal à fournir des résultats cohérents: ils ne peuvent pas se mettre en erreur comme un parseur XML à la moindre faute de syntaxe. Ils sont donc obligés de choisir des compromis, des solutions de repli, variant avec le contexte, le développeur, le langage utilisé, le type d'outil de parsing utilisé, etc... Pas étonnant que le résultat manque souvent de cohérence.
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
laurent courbez wrote:
c'est pas vraiment un argument !
Du html "bien formé" (au sens w3c du terme) est immanquablement
"parsable" sans l'être pour autant trivialement.
Je ne dis pas que l'HTML n'est pas parsable - heureusement, il l'est
:-) - , je dis qu'il ne l'est pas en utilisant uniquement des
expressions régulières. En tous cas, l'exemple que j'ai donné est
correctement formé (sauf erreur de ma part) et il semble difficile de
trouver une expression régulière qui s'en accomode. Ou plutôt non, on
peut trouver une expression qui traitera ce cas mais qui sera mise
aisément en défaut par une variante du même source.
AMHA, je ne conçois pas une opération de parsing efficace d'un source
HTML à partir de code qui utiliserait uniquement des expressions
régulières. HTML est défini à partir d'une grammaire et c'est cela qu'il
faut exploiter pour le parser.
La question est par ailleurs de savoir si on écrit un parseur qui est
censé recevoir un flux HTML conforme à la spec ou un flux HTML provenant
du mondé réel (écrit à la main ou généré par des éditeurs plus ou moins
fiables). Il suffit d'afficher au hasard le source des pages que l'on
affiche dans son browser pour se rendre compte qu'il y a une marge, que
dis-je, un abîme, entre les specs du W3C et la réalité quotidienne.
C'est bien pour cela que les browsers ont du mal à fournir des résultats
cohérents: ils ne peuvent pas se mettre en erreur comme un parseur XML à
la moindre faute de syntaxe. Ils sont donc obligés de choisir des
compromis, des solutions de repli, variant avec le contexte, le
développeur, le langage utilisé, le type d'outil de parsing utilisé,
etc... Pas étonnant que le résultat manque souvent de cohérence.
--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr
Du html "bien formé" (au sens w3c du terme) est immanquablement "parsable" sans l'être pour autant trivialement.
Je ne dis pas que l'HTML n'est pas parsable - heureusement, il l'est :-) - , je dis qu'il ne l'est pas en utilisant uniquement des expressions régulières. En tous cas, l'exemple que j'ai donné est correctement formé (sauf erreur de ma part) et il semble difficile de trouver une expression régulière qui s'en accomode. Ou plutôt non, on peut trouver une expression qui traitera ce cas mais qui sera mise aisément en défaut par une variante du même source.
AMHA, je ne conçois pas une opération de parsing efficace d'un source HTML à partir de code qui utiliserait uniquement des expressions régulières. HTML est défini à partir d'une grammaire et c'est cela qu'il faut exploiter pour le parser.
La question est par ailleurs de savoir si on écrit un parseur qui est censé recevoir un flux HTML conforme à la spec ou un flux HTML provenant du mondé réel (écrit à la main ou généré par des éditeurs plus ou moins fiables). Il suffit d'afficher au hasard le source des pages que l'on affiche dans son browser pour se rendre compte qu'il y a une marge, que dis-je, un abîme, entre les specs du W3C et la réalité quotidienne. C'est bien pour cela que les browsers ont du mal à fournir des résultats cohérents: ils ne peuvent pas se mettre en erreur comme un parseur XML à la moindre faute de syntaxe. Ils sont donc obligés de choisir des compromis, des solutions de repli, variant avec le contexte, le développeur, le langage utilisé, le type d'outil de parsing utilisé, etc... Pas étonnant que le résultat manque souvent de cohérence.
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
laurent courbez
Patrick Philippot a écrit :
...
AMHA, je ne conçois pas une opération de parsing efficace d'un source HTML à partir de code qui utiliserait uniquement des expressions régulières. HTML est défini à partir d'une grammaire et c'est cela qu'il faut exploiter pour le parser.
...
l'approche grammaticale, oui, mais comment ? avec quelque chose comme lex et yacc (ou flex/bison) ?
il faut maintenant en dire davantage, fournir au moins quelques pistes ;-)
LC.
Patrick Philippot a écrit :
...
AMHA, je ne conçois pas une opération de parsing efficace d'un source
HTML à partir de code qui utiliserait uniquement des expressions
régulières. HTML est défini à partir d'une grammaire et c'est cela qu'il
faut exploiter pour le parser.
...
l'approche grammaticale, oui, mais comment ?
avec quelque chose comme lex et yacc (ou flex/bison) ?
il faut maintenant en dire davantage, fournir au moins quelques pistes ;-)
AMHA, je ne conçois pas une opération de parsing efficace d'un source HTML à partir de code qui utiliserait uniquement des expressions régulières. HTML est défini à partir d'une grammaire et c'est cela qu'il faut exploiter pour le parser.
...
l'approche grammaticale, oui, mais comment ? avec quelque chose comme lex et yacc (ou flex/bison) ?
il faut maintenant en dire davantage, fournir au moins quelques pistes ;-)
LC.
Patrick Philippot
laurent courbez wrote:
Patrick Philippot a écrit :
...
AMHA, je ne conçois pas une opération de parsing efficace d'un source HTML à partir de code qui utiliserait uniquement des expressions régulières. HTML est défini à partir d'une grammaire et c'est cela qu'il faut exploiter pour le parser.
...
l'approche grammaticale, oui, mais comment ? avec quelque chose comme lex et yacc (ou flex/bison) ?
il faut maintenant en dire davantage, fournir au moins quelques pistes ;-)
Oui, bien sûr un "vrai" outil de parsing. Lex & Yacc (pas dispo pour .Net - sauf l'outil CSTools mais qui est encore copieusement bogué), Flex / Bison, Visual Parse++ (quoique je ne recommande plus ce magnifique produit pour cause de défaillance chronique de Sandstone Tech.), Programmar, AntLR, The Grammar Forge,...
En ce qui concerne le parsing de HTML plus précisément:
The HTML Agility Pack http://weblogs.asp.net/smourier/archive/2003/06/04/8265.aspx
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
laurent courbez wrote:
Patrick Philippot a écrit :
...
AMHA, je ne conçois pas une opération de parsing efficace d'un source
HTML à partir de code qui utiliserait uniquement des expressions
régulières. HTML est défini à partir d'une grammaire et c'est cela
qu'il faut exploiter pour le parser.
...
l'approche grammaticale, oui, mais comment ?
avec quelque chose comme lex et yacc (ou flex/bison) ?
il faut maintenant en dire davantage, fournir au moins quelques
pistes ;-)
Oui, bien sûr un "vrai" outil de parsing. Lex & Yacc (pas dispo pour
.Net - sauf l'outil CSTools mais qui est encore copieusement bogué),
Flex / Bison, Visual Parse++ (quoique je ne recommande plus ce
magnifique produit pour cause de défaillance chronique de Sandstone
Tech.), Programmar, AntLR, The Grammar Forge,...
En ce qui concerne le parsing de HTML plus précisément:
The HTML Agility Pack
http://weblogs.asp.net/smourier/archive/2003/06/04/8265.aspx
AMHA, je ne conçois pas une opération de parsing efficace d'un source HTML à partir de code qui utiliserait uniquement des expressions régulières. HTML est défini à partir d'une grammaire et c'est cela qu'il faut exploiter pour le parser.
...
l'approche grammaticale, oui, mais comment ? avec quelque chose comme lex et yacc (ou flex/bison) ?
il faut maintenant en dire davantage, fournir au moins quelques pistes ;-)
Oui, bien sûr un "vrai" outil de parsing. Lex & Yacc (pas dispo pour .Net - sauf l'outil CSTools mais qui est encore copieusement bogué), Flex / Bison, Visual Parse++ (quoique je ne recommande plus ce magnifique produit pour cause de défaillance chronique de Sandstone Tech.), Programmar, AntLR, The Grammar Forge,...
En ce qui concerne le parsing de HTML plus précisément:
The HTML Agility Pack http://weblogs.asp.net/smourier/archive/2003/06/04/8265.aspx
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
laurent courbez
merci pour les tuyaux
LC.
Patrick Philippot a écrit :
laurent courbez wrote:
Patrick Philippot a écrit :
...
AMHA, je ne conçois pas une opération de parsing efficace d'un source HTML à partir de code qui utiliserait uniquement des expressions régulières. HTML est défini à partir d'une grammaire et c'est cela qu'il faut exploiter pour le parser.
...
l'approche grammaticale, oui, mais comment ? avec quelque chose comme lex et yacc (ou flex/bison) ?
il faut maintenant en dire davantage, fournir au moins quelques pistes ;-)
Oui, bien sûr un "vrai" outil de parsing. Lex & Yacc (pas dispo pour .Net - sauf l'outil CSTools mais qui est encore copieusement bogué), Flex / Bison, Visual Parse++ (quoique je ne recommande plus ce magnifique produit pour cause de défaillance chronique de Sandstone Tech.), Programmar, AntLR, The Grammar Forge,...
En ce qui concerne le parsing de HTML plus précisément:
The HTML Agility Pack http://weblogs.asp.net/smourier/archive/2003/06/04/8265.aspx
AMHA, je ne conçois pas une opération de parsing efficace d'un source
HTML à partir de code qui utiliserait uniquement des expressions
régulières. HTML est défini à partir d'une grammaire et c'est cela
qu'il faut exploiter pour le parser.
...
l'approche grammaticale, oui, mais comment ?
avec quelque chose comme lex et yacc (ou flex/bison) ?
il faut maintenant en dire davantage, fournir au moins quelques
pistes ;-)
Oui, bien sûr un "vrai" outil de parsing. Lex & Yacc (pas dispo pour
.Net - sauf l'outil CSTools mais qui est encore copieusement bogué),
Flex / Bison, Visual Parse++ (quoique je ne recommande plus ce
magnifique produit pour cause de défaillance chronique de Sandstone
Tech.), Programmar, AntLR, The Grammar Forge,...
En ce qui concerne le parsing de HTML plus précisément:
The HTML Agility Pack
http://weblogs.asp.net/smourier/archive/2003/06/04/8265.aspx
AMHA, je ne conçois pas une opération de parsing efficace d'un source HTML à partir de code qui utiliserait uniquement des expressions régulières. HTML est défini à partir d'une grammaire et c'est cela qu'il faut exploiter pour le parser.
...
l'approche grammaticale, oui, mais comment ? avec quelque chose comme lex et yacc (ou flex/bison) ?
il faut maintenant en dire davantage, fournir au moins quelques pistes ;-)
Oui, bien sûr un "vrai" outil de parsing. Lex & Yacc (pas dispo pour .Net - sauf l'outil CSTools mais qui est encore copieusement bogué), Flex / Bison, Visual Parse++ (quoique je ne recommande plus ce magnifique produit pour cause de défaillance chronique de Sandstone Tech.), Programmar, AntLR, The Grammar Forge,...
En ce qui concerne le parsing de HTML plus précisément:
The HTML Agility Pack http://weblogs.asp.net/smourier/archive/2003/06/04/8265.aspx
