You can’t parse [X]HTML with regex. Just don’t. Bad things will happen. You don’t want to know : ►http://stackoverflow.com/questions/1732348/regex-match-open-tags-except-xhtml-self-contained-tags/1732454#1732454 - Stackoverflow now features a computational demonology section, brought to you by Capital Laundry Services...
regex parsers for HTML will instantly transport a programmer’s consciousness into a world of ceaseless screaming, he comes, the pestilent slithy regex-infection will devour your HTML parser, application and existence for all time like Visual Basic only worse he comes he comes do not fight he com̡e̶s, ̕h̵is un̨ho͞ly radiańcé destro҉ying all enli̍̈́̂̈́ghtenment, HTML tags lea͠ki̧n͘g fr̶ǫm ̡yo͟ur eye͢s̸ ̛l̕ik͏e liquid pain, the song of re̸gular expression parsing will extinguish the voices of mortal man from the sphere I can see it can you see ̲͚̖͔̙î̩́t̲͎̩̱͔́̋̀ it is beautiful the final snuffing of the lies of Man ALL IS LOŚ͖̩͇̗̪̏̈́T ALL IS LOST the pon̷y he comes he c̶̮omes he comes the ichor permeates all MY FACE MY FACE ᵒh god no NO NOO̼OO NΘ stop the an*̶͑̾̾̅ͫ͏̙̤g͇̫͛͆̾ͫ̑͆l͖͉̗̩̳̟̍ͫͥͨe̠̅s ͎a̧͈͖r̽̾̈́͒͑e not rè̑ͧ̌aͨl̘̝̙̃ͤ͂̾̆ ZA̡͊͠͝LGΌ ISͮ̂҉̯͈͕̹̘̱ TO͇̹̺ͅƝ̴ȳ̳ TH̘Ë͖́̉ ͠P̯͍̭O̚N̐Y̡ H̸̡̪̯ͨ͊̽̅̾̎Ȩ̬̩̾͛ͪ̈́̀́͘ ̶̧̨̱̹̭̯ͧ̾ͬC̷̙̲̝͖ͭ̏ͥͮ͟Oͮ͏̮̪̝͍M̲̖͊̒ͪͩͬ̚̚͜Ȇ̴̟̟͙̞ͩ͌͝S̨̥̫͎̭ͯ̿̔̀ͅ
LOL pourtant :
This is the regex I use (!) to match HTML tags:
<(?:"[^"]"[’"]|’[^’]’[’"]|[^’">])+>
It may not be perfect, but I ran this code through a lot of HTML. Note that it even catches strange things like <a name="badgenerator"">, which show up on the web.
I guess to make it not match self contained tags, you’d either want to use Kobi’s negative look-behind:
<(?:"[^"]"[’"]|’[^’]’[’"]|[^’">])+(?<!/\s*)>
or just combine if and if not.
To downvoters: This is working code from an actual product. I doubt anyone reading this page will get the impression that it is socially acceptable to use regexes on HTML.
Caveat: I should note that this regex still breaks down in the presence of CDATA blocks, comments, and script and style elements. Good news is, you can get rid of those using a regex...
#lol #HTML #développement #web
Dédicace à @spip un peu quand même. :D
Non, vraiment, analyser du HTML avec des expressions rationnelles, c’est le mal absolu :
html - RegEx match open tags except XHTML self-contained tags - Stack Overflow
►http://stackoverflow.com/questions/1732348/regex-match-open-tags-except-xhtml-self-contained-tags#1732454
You can’t parse [X]HTML with regex. [...] Every time you attempt to parse HTML with regular expressions, the unholy child weeps the blood of virgins, and Russian hackers pwn your webapp. Parsing HTML with regex summons tainted souls into the realm of the living. HTML and regex go together like love, marriage, and ritual infanticide.
Plus sérieusement, c’est une vraie plaie, que cette approche. Je veux dire : pour y arriver, il faut carrément y aller, d’autant que la plupart des implémentations d’expressions rationnelles ne gèrent pas les références arrières, ou encore les « lookbehind » de longueur indéfinie. Sans oublier que relire une telle expression rationnelle et tente de la comprendre, c’est frôler un AVC.
Personnellement, je me suis rabattu sur XPath pour analyser le HTML, mais d’autres lui préfèrent le CSS. Les expressions XPath sont plus intéressantes d’un point de vue de leurs possibilités, mais réclament un apprentissage plus long. Le CSS est déjà connu des développeurs web, et largement popularisé, y compris en JavaScript avec des frameworks tels que jQuery. En outre, l’implémentation du CSS paraît plus optimisée dans les navigateurs :
Why CSS Locators are the way to go vs XPath
►http://saucelabs.com/blog/index.php/2011/05/why-css-locators-are-the-way-to-go-vs-xpath
The first batch of clicks uses CSS Locators and completes in under 30 seconds. The second batch, the XPath one, continues on for another eight minutes. Eight minutes!
Bref, ce ne sont pas des remplaçants efficaces qui manquent aux expressions rationnelles.
#informatique-développement-expressions_rationnelles #informatique-développement-css #informatique-développement-xpath #informatique-développement-html #informatique-humour
Intéressant. Tu as des indications sur la tolérance des différents systèmes au XHTML non conforme ? (Parce que le recours au regexp, souvent, c’est pour pas se faire planter la moulinette au milieu de 5000 imports parce qu’on tombe sur un seul caractère pas reconnu dans le charset, ou un ampersand pas échappé.)
En PHP, depuis peu, et avec un relatif succès, j’expérimente :
et plus particulièrement ses méthodes :
►http://www.php.net/manual/fr/domdocument.loadhtml.php
►http://www.php.net/manual/fr/domdocument.loadhtmlfile.php
qui, toutes deux, indiquent bien que :
Contrairement au XML, le HTML n’a pas besoin d’être bien formé pour être chargé.
Ensuite, soit le parcours se fait via les méthodes DOM associées — mais alors il faut vraiment que ce soit évident à parcourir, sinon, autant revenir aux expressions rationnelles —, soit via :
Cette classe ne semble pas supporter exhaustivement toutes les possibilités du XPath en matière de syntaxe (j’ai rencontré des soucis avec les vérifications de valeurs de champs, genre « depuis ce tableau <table>, donne-moi la liste des titres de livres dont le prix est supérieur à 10 € »), mais je n’ai pas été spécialement gêné jusqu’ici par rapport à mes besoins.
Pour ce qui est de l’élaboration des expressions XPath, j’utilise Firefox et Firebug auxquels j’ajoute les extensions FirePath et XPather. Au niveau de la syntaxe de base, cette introduction est tout à fait intéressante :
On y trouve même quelques exemples plus avancés, permettant l’élaboration de recherches tout à fait sympathiques sans prise de tête. Et voici d’autres exemples de XPath représentatifs de quelques cas d’utilisation fréquents résolus facilement :
►http://www.exampledepot.com/egs/org.w3c.dom/xpath_GetElemByText.html
Enfin, pour nettoyer du HTML, j’avais récemment regardé HTML Purifier :
sans toutefois être convaincu de son intérêt pour mes besoins. Mais ça peut éventuellement te dépanner si tu as à faire à du HTML.
Hello, pour nettoyer le xhtml, de manière légère, je conseille ma propre lib qui s’appelle justement garbage2xhtml : ►http://svn.kd2.org/svn/misc/libs/garbage2xhtml/lib.garbage2xhtml.php
Ça n’est pas dis que ça fera des miracles sur du html 2.0 mais normalement ça devrait plutôt bien : virer toutes tentatives de XSS, ne pas donner du HTML pourri avec des tags non fermés, et filtrer et ne garder que les tags qu’on autorise.
Vous y verrez que ça utilise des regexps et qu’on peut donc tout à fait bien et même très bien parser du xhtml avec des regexps, MAIS pas à coup de preg_match ou de preg_replace (en PHP), car ça ne donnera jamais un arbre DOM exhaustif, mais avec preg_split et un traitement récursif.
Cette lib comprends aussi une fonctionnalité qui permet de transformer un texte brut (comme entré dans ce textarea) en quelque chose de fonctionnel et sémantique en xHTML, exemple :
« Coucou
Ça va
Bien ? »
(bon Seenthis fait aussi de la magie donc on vois pas qu’entre "Ça va" et bien il y a un saut de ligne simple, et entre "Coucou" et "Ça va" il est double)
Deviendra :
« <p>Coucou</p>
<p>Ça va<br />
Bien ?</p> »
Ce qui est très utile quand on veux un traitement un peu plus évolué que nl2br. Enfin, cette lib est actuellement utilisée sur plusieurs sites afin de permettre aux utilisateurs d’entrer directement du xhtml dans les formulaires, sans se préoccuper d’avoir peur pour les injections ni qu’un tag mal fermé se retrouve à péter le layout du site.
Une page de démo : ►http://dev.kd2.org/garbage2xhtml/demo.php