Diantre.
Et le pire c’est qu’il y aura toujours un couillon pour trouver un nouveau truc débile à utiliser et qui va planter le parseur.
Ça me fait penser à quand j’ai refait les regex dans OranjeProxy. Les regex qui servent à parser du HTML (balises, attributs, valeur).
Les balises, c’est assez simple, mais faut faire gaffe à la casse et aux espaces :
<p> : OK
< p > : OK
</p> : OK
<h1> : OK (balise avec chiffres)
<img/> : OK (autofermante)
<li> : OK (Balise sans balise fermante (HTML4))
Les Attributs c’est chiant avec les quotes/double quotes/pas de quote, et surtout quand il s’agit de les échapper dans la Regex elle-même :
<p id="paragraphe"> : OK
<p id=paragraphe> : OK
<p id='paragraphe'> : OK
<p id = "paragraphe" > : OK
La difficulté c’est de faire savoir à la Regex que si on trouve un quote ouvrant, alors le quote fermant ser du même type, donc un simple (['"](.*)["']) ne marche pas, car il fonctionnerait avec « id="bla' ».
N’oublions pas que les attributs peuvent avoir des tirets (data-id) êtres en capitales (HTML4, généralement) et les valeurs peuvent être n’importe quoi : nombres, lettres, phrases, url, du html lui-même, du JS, et même des quotes échappées :
<p data-nawak="lorem ipsum \"quotes\" sit \\amet lol">
Maintenant, fais un parseur pour trouver les attributs dont les valeurs sont des URL (absolues entières (
http://example.com/dossier/fichier.html), absolues relatives au site ((/dossier/fichier.html) relatives (../dossier/fichier.html) ou absolues sans le protocole : (//example.com/dossier/fichier.html).
Oh et l’URL peut se trouver dans :
– une valeur (value, href, src, post…)
– dans du CSS (background: url(image.jpg))
– dans du JS…
Le cas du CSS est particulier car les URL sont relatives au fichier CSS et non au document HTML qui inclut le fichier CSS.
Ah oui, et parfois le code n’est pas valide W3C dont on trouve des attributs ou des valeurs en vrac, des balises qui n’existent pas ou des URL mal échappées.
— (
permalink)
