• 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 :

      http://www.php.net/manual/fr/domdocument.loadhtml.php

      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 :

      http://www.php.net/manual/fr/class.domxpath.php

      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 :

      http://www.w3schools.com/xpath

      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 :

      http://htmlpurifier.org

      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