Comment tester des expressions régulières en ligne

Les expressions régulières sont l'un des outils les plus puissants en programmation, et l'un des plus frustrants à maitriser. Un testeur de regex vous permet de construire et déboguer des motifs de manière interactive au lieu d'exécuter votre code, vérifier la sortie et deviner ce qui a mal tourné. La boucle de rétroaction passe de minutes par itération à secondes.

Pourquoi utiliser un testeur regex

Écrire du regex dans votre éditeur de code signifie que vous ne voyez les erreurs qu'à l'exécution. Un testeur vous montre :

• Mise en évidence en direct des correspondances : voir exactement quelles parties de votre texte correspondent au fur et à mesure que vous tapez le motif
• Groupes de capture : voir ce que chaque groupe capture sans écrire de sortie de débogage
• Détails de correspondance : positions exactes, longueurs et contenu de chaque correspondance
• Aperçu de remplacement : voir le résultat de rechercher-remplacer avant de l'appliquer

Comment tester regex en ligne

1. Entrez votre motif : tapez le regex dans le champ de motif. Activez les drapeaux (g pour global, i pour insensible à la casse, m pour multiligne) selon les besoins.
2. Collez votre texte de test : entrez le texte contre lequel vous souhaitez faire correspondre. Les correspondances sont mises en évidence en temps réel.
3. Voir les résultats : voir toutes les correspondances avec les groupes de capture listés ci-dessous. Utilisez le champ « Remplacer par » pour tester les remplacements.

Une brève histoire des expressions régulières

Les expressions régulières ont été formalisées par le mathématicien Stephen Kleene en 1951 comme une notation pour les « événements réguliers » dans son travail sur les réseaux neuronaux. Elles sont passées de la théorie à l'utilisation pratique lorsque Ken Thompson les a implémentées dans l'éditeur de texte QED chez Bell Labs en 1968, puis dans l'éditeur ed (1969), et finalement dans l'utilitaire grep (1973), dont le nom vient de « global / regular expression / print ».

Perl, introduit par Larry Wall en 1987, a considérablement étendu la syntaxe regex : quantificateurs non gloutons, lookahead, groupes nommés, raccourcis de classes de caractères comme \d et \w. La bibliothèque Perl-Compatible Regular Expressions (PCRE), publiée en 1997, est devenue la norme de facto pour la plupart des langages modernes.

Aujourd'hui, pratiquement tous les langages de programmation ont un support regex intégré, bien que la syntaxe varie légèrement. Le moteur JavaScript (V8 dans Chrome, SpiderMonkey dans Firefox) est hautement optimisé et alimente la plupart des testeurs regex en ligne. PHP, Python (module re) et Java (java.util.regex) utilisent une syntaxe étroitement liée mais non identique. Savoir pour quelle saveur vous écrivez compte pour les fonctionnalités avancées.

Motifs regex courants à connaitre

Adresse e-mail (basique) :

[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}

URL :

https?://[^\s]+

Numéro de téléphone (US) :

\(?\d{3}\)?[-.\s]?\d{3}[-.\s]?\d{4}

Date (AAAA-MM-JJ) :

\d{4}-(?:0[1-9]|1[0-2])-(?:0[1-9]|[12]\d|3[01])

Adresse IP (IPv4) :

\b\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}\b

Code couleur hex :

#(?:[0-9a-fA-F]{3}){1,2}\b

Slug (identifiant compatible URL) :

^[a-z0-9]+(?:-[a-z0-9]+)*$

Chaine avec espaces ajustés :

^\s*(.*?)\s*$

Différences de saveurs entre langages

La syntaxe regex est principalement portable mais comporte des pièges :

• JavaScript : lookbehinds ajoutés dans ES2018 ((?<=...), (?<!...)), pris en charge dans Chrome 62+, Firefox 78+, Safari 16.4+. Groupes nommés via (?<name>...).
• Python : le module re prend en charge presque toutes les fonctionnalités Perl ; le package tiers regex en ajoute encore plus (lookbehind de longueur variable, correspondance floue).
• Java : \b pour limite de mot fonctionne de la meme manière ; les groupes nommés utilisent (?<name>...). Modèle Pattern.compile + matcher.
• PHP : la famille preg_match utilise PCRE sous le capot. Les motifs nécessitent des délimiteurs : /motif/drapeaux.
• Go : utilise la syntaxe RE2 (pas de références arrières, pas de lookaround) pour des performances linéaires garanties. Certains motifs qui fonctionnent en JS/PCRE échouent en Go.
• Rust : le crate regex utilise RE2 par défaut ; le crate fancy-regex ajoute le lookaround.

Lorsque vous écrivez un regex dans un testeur (presque toujours saveur JavaScript), confirmez que le langage cible prend en charge toutes les fonctionnalités que vous avez utilisées avant de vous y engager.

Pièges courants

• Retour arrière catastrophique : des motifs comme (a+)+b contre aaaaaaaaaaaaaaaaaaaaaaaac peuvent prendre un temps exponentiel. Le moteur regex essaie chaque regroupement possible. Utilisez des quantificateurs possessifs ((a++)+) ou des groupes atomiques (?>a+)+ pour éviter cela. RE2 et Go regex y sont immunisés par conception.
• Quantificateurs gloutons vs paresseux : a.*b correspond autant que possible (glouton) ; a.*?b correspond aussi peu que possible (paresseux). Confondre les deux est la source n°1 de « mon regex correspond à trop ».
• Ancres en mode multiligne : ^ et $ correspondent au début/fin de chaine par défaut. Avec le drapeau m, ils correspondent au début/fin de chaque ligne. L'oublier donne des résultats incomplets.
• Caractères spéciaux dans les classes de caractères : à l'intérieur de [...], la plupart des caractères spéciaux perdent leur signification. [.] correspond à un point littéral. Mais ], \ et ^ (au début) doivent encore etre échappés.
• Unicode et \w : \w est [A-Za-z0-9_] dans la plupart des saveurs, donc il ne correspond PAS aux lettres accentuées comme é ou aux scripts non latins. Utilisez \p{L} (échappement de propriété Unicode) ou passez le drapeau u en JS.
• Oublier le drapeau global : sans g, des méthodes comme String.matchAll() lancent, et .replace() ne remplace que la première correspondance. Le testeur utilise global par défaut, mais votre vrai code peut ne pas le faire.
• Ancrage de validation d'entrée complète : ^foo$ garantit que l'entrée entière est « foo ». Sans les ancres, foo correspond n'importe où dans la chaine, ce qui est un risque de sécurité dans la validation d'entrée.

Quand ne PAS utiliser regex

Regex est le mauvais outil pour certains travaux :

• Analyser HTML ou XML : les structures imbriquées, les attributs et les espaces arbitraires rendent regex peu pratique. Utilisez un vrai analyseur (DOMParser, BeautifulSoup, lxml).
• Analyser JSON : meme raison. Utilisez JSON.parse() ou équivalent.
• Analyser du code source : les analyseurs AST (Acorn, Esprima, AST-grep) comprennent la syntaxe. Regex ne voit que du texte.
• Validation d'e-mail : le regex d'e-mail valide RFC 5322 fait plus de 6 000 caractères. Pour une vraie validation, envoyez plutot un e-mail de confirmation.
• Règles de force de mot de passe : les motifs regex complexes pour « doit contenir majuscule, minuscule, chiffre, caractère spécial » sont difficiles à maintenir. Composez plusieurs vérifications simples à la place.

Si vous vous retrouvez à écrire un regex de plus de 100 caractères avec plusieurs groupes imbriqués, vous résolvez probablement le mauvais problème.

Conseils pour écrire de meilleurs regex

• Commencez simple : faites fonctionner un motif basique d'abord, puis ajoutez de la complexité. Essayer d'écrire le regex parfait du premier coup fonctionne rarement.
• Utilisez le drapeau global (g) : sans lui, le testeur s'arrete à la première correspondance. Avec g, vous voyez toutes les correspondances dans le texte.
• Testez les cas limites : votre regex peut correspondre aux cas évidents mais échouer sur les chaines vides, les caractères spéciaux ou les conditions limites. Ajoutez-les à votre texte de test.
• Échappez les caractères spéciaux : des caractères comme ., *, +, ?, (, ), [, ], {, }, \, ^, $ et | ont une signification spéciale en regex. Pour les faire correspondre littéralement, préfixez avec une barre oblique inverse.
• Utilisez des groupes non capturants : si vous avez besoin de parenthèses pour le regroupement mais pas de la capture, utilisez (?:...) au lieu de (...). Cela garde vos résultats de correspondance plus propres.
• Commentez les motifs complexes : la plupart des saveurs prennent en charge le drapeau x (mode étendu), qui permet les espaces et les # commentaires à l'intérieur du motif. Utilisez-le pour les regex de plus de 50 caractères.
• Enregistrez vos tests : un regex qui fonctionne sur votre texte de test aujourd'hui devrait fonctionner sur des entrées similaires pour toujours. Enregistrez les cas de test à coté du regex dans votre base de code comme documentation.

Confidentialité et données de test sensibles

Le testeur regex fonctionne entièrement dans votre navigateur en utilisant le moteur RegExp natif de JavaScript. Le motif que vous écrivez, le texte de test que vous collez et les correspondances que vous voyez restent tous sur votre appareil. Rien n'est téléversé, enregistré ou analysé par un serveur.

Cela importe parce que le texte de test regex contient souvent des informations sensibles : échantillons de journaux de production (avec de vrais ID utilisateurs, adresses IP, jetons de session), listes d'e-mails extraites d'un CRM, données client formatées de manière inhabituelle. Les testeurs regex en nuage acheminent tout cela via leurs serveurs, parfois en l'enregistrant à des fins « d'amélioration ». Un testeur basé sur navigateur n'a aucune exposition pour aucune de ces données.