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
