Utiliser des expressions régulières pour analyser le HTML : pourquoi pas ?

Question

Il semble que chaque question sur stackoverflow où l'auteur de la question utilise une expression rationnelle pour extraire des informations du HTML aura inévitablement une "réponse" qui dit de ne pas utiliser d'expression rationnelle pour analyser le HTML.

Pourquoi pas ? Je suis conscient qu'il existe des analyseurs HTML "réels", entre guillemets. Une belle soupe Je suis sûr qu'elles sont puissantes et utiles, mais si vous faites quelque chose de simple, rapide ou sale, pourquoi vous embêter à utiliser quelque chose de si compliqué alors que quelques instructions regex suffisent ?

De plus, y a-t-il quelque chose de fondamental que je ne comprends pas à propos des regex et qui en fait un mauvais choix pour l'analyse syntaxique en général ?

Answer 1

L'analyse complète du HTML n'est pas possible avec les expressions régulières, car elle dépend de la correspondance entre les balises d'ouverture et de fermeture, ce qui n'est pas possible avec les regexps.

Les expressions régulières ne peuvent correspondre qu'à langues régulières mais le HTML est un langage sans contexte et no un langage régulier (comme @StefanPochmann l'a fait remarquer, les langages réguliers sont également sans contexte, donc sans contexte ne signifie pas nécessairement non régulier). La seule chose que vous pouvez faire avec les regexps sur le HTML est une heuristique, mais cela ne fonctionnera pas pour toutes les conditions. Il devrait être possible de présenter un fichier HTML qui ne sera pas reconnu par n'importe quelle expression régulière.

Answer 2

Pour une utilisation rapide, un regexp fera l'affaire. Mais la chose fondamentale à savoir est qu'il est impossible pour construire un regexp qui correctement analyser le HTML.

La raison en est que les regexps ne peuvent pas gérer les expressions arbitrairement imbriquées. Voir Les expressions régulières peuvent-elles être utilisées pour faire correspondre des motifs imbriqués ?

Answer 3

(De http://htmlparsing.com/regexes )

Say you've got a file of HTML where you're trying to extract URLs from <img> tags.

<img src="http://example.com/whatever.jpg">

Donc vous écrivez une regex comme ceci en Perl :

if ( $html =~ /<img src="(.+)"/ ) {
    $url = $1;
}

Dans ce cas, $url contiendra en effet http://example.com/whatever.jpg . Mais que se passe-t-il quand vous commencez à avoir du HTML comme ça :

<img src='http://example.com/whatever.jpg'>

ou

<img src=http://example.com/whatever.jpg>

ou

<img border=0 src="http://example.com/whatever.jpg">

ou

<img
    src="http://example.com/whatever.jpg">

ou vous commencez à obtenir des faux positifs de

<!-- // commented out
<img src="http://example.com/outdated.png">
-->

Cela semble si simple, et cela peut l'être pour un fichier unique et immuable, mais pour tout ce que vous allez faire sur des données HTML arbitraires, les regex ne sont qu'une recette pour de futurs maux de tête.

Answer 4

Deux raisons rapides :

• écrire une regex qui peut résister à une entrée malveillante est difficile ; bien plus difficile que d'utiliser un outil préconstruit
• écrire une regex qui peut fonctionner avec le balisage ridicule avec lequel vous serez inévitablement coincé est difficile ; bien plus difficile que d'utiliser un outil pré-construit

En ce qui concerne l'adéquation des regex pour l'analyse syntaxique en général : elles ne sont pas adaptées. Avez-vous déjà vu les types de regex dont vous auriez besoin pour analyser la plupart des langues ?

Answer 5

En ce qui concerne l'analyse syntaxique, les expressions régulières peuvent être utiles dans l'étape d'"analyse lexicale" (lexer), où l'entrée est décomposée en tokens. Elles sont moins utiles dans la phase de "construction d'un arbre d'analyse".

Pour un analyseur HTML, je m'attendrais à ce qu'il n'accepte que du HTML bien formé, ce qui exige des capacités autres que celles d'une expression régulière (elle ne peut pas "compter" et s'assurer qu'un nombre donné d'éléments d'ouverture est équilibré par le même nombre d'éléments de fermeture).