Testeur et Débogueur de Regex
Testez des expressions régulières JavaScript en direct avec surlignage des correspondances, groupes de capture et aperçu du remplacement.
Chargement de Testeur et Débogueur de Regex… Si rien ne se passe, activez JavaScript.
Les expressions régulières (regex ou regexp) sont un langage formel permettant de décrire des motifs dans du texte. La théorie remonte au mathématicien Stephen Cole Kleene, qui a formalisé l'algèbre des langages réguliers en 1956, et à Ken Thompson, qui a implémenté les regex dans l'éditeur QED et dans les outils Unix d'origine grep, sed et awk dans les années 1960 et 1970. Les moteurs de regex modernes étendent ce fondement théorique avec des fonctionnalités pratiques comme les anticipations (lookaheads), les références arrière (backreferences) et les groupes de capture nommés, ce qui en fait l'un des outils de traitement de texte les plus puissants disponibles dans n'importe quel langage de programmation.
Exemples
\b\w+@\w+\.\w+\b on "a@b.com x@y.org"
2 matches: a@b.com, x@y.org
Les groupes de capture et les drapeaux (g, i, m) s'affichent en direct à mesure que vous tapez.
Questions fréquentes
Ma saisie est-elle envoyée à un serveur ?
Quelle variante de regex cet outil utilise-t-il ?
Quand devrais-je utiliser une regex plutôt que des méthodes de chaîne simples ?
En quoi la regex JavaScript diffère-t-elle de PCRE (Python, PHP, Perl) ?
Quels sont les drapeaux disponibles et que font-ils ?
Y a-t-il une limite de longueur pour la chaîne de test ou le motif ?
Puis-je l'utiliser pour tester un motif de remplacement ?
Qu'est-ce que le retour sur trace catastrophique et comment l'éviter ?
Quelle est la différence entre un groupe capturant et un groupe non capturant ?
Quelle est une erreur fréquente de débutant avec les expressions régulières ?
À propos de Testeur et Débogueur de Regex
Les expressions régulières sont indispensables pour un large éventail de tâches du monde réel. La validation de formulaires, vérifier qu'une adresse e-mail, un numéro de téléphone ou un code postal correspond au format attendu, utilise presque universellement les regex. Les analyseurs de logs extraient des champs structurés de lignes de log non structurées à l'aide de groupes de capture. Les éditeurs de code et les IDE utilisent les regex pour rechercher et remplacer dans de grandes bases de code. Les outils de sécurité utilisent les regex pour détecter les motifs d'injection et les fuites de données sensibles. Les pipelines de transformation de données utilisent les regex pour normaliser des formats incohérents. Les configurations des équipements réseau sont auditées avec des regex. Comprendre et déboguer un motif de regex de manière interactive est bien plus rapide que d'exécuter un script à répétition.
Ce testeur évalue les expressions régulières JavaScript par rapport à votre saisie en temps réel, en surlignant chaque correspondance à mesure que vous tapez. Il liste tous les groupes de capture (numérotés et nommés) de chaque correspondance afin que vous puissiez voir immédiatement ce que chaque groupe a capturé. Un mode de remplacement vous permet de saisir un modèle de remplacement et de prévisualiser le résultat de String.prototype.replace ou replaceAll, avec la prise en charge des références arrière $1, $2 et $<name>. Tout s'exécute entièrement dans le moteur JavaScript de votre navigateur ; vos motifs et votre texte de saisie ne sont jamais envoyés à un serveur.
Il est notoirement facile de se tromper subtilement avec une regex. Un point seul (.) correspond à n'importe quel caractère, y compris les sauts de ligne dans certains modes, et pas seulement à un point littéral. Les quantificateurs gourmands (*, +) correspondent au maximum possible, capturant souvent plus que prévu ; utilisez les versions paresseuses (*?, +?) pour correspondre au minimum possible. Les ancres ^ et $ correspondent au début et à la fin de toute la chaîne par défaut ; ajoutez le drapeau multiligne (m) si vous voulez qu'elles correspondent aux limites de ligne. Le retour sur trace catastrophique (catastrophic backtracking), où une regex mal écrite provoque un temps de correspondance exponentiel sur une entrée adverse, est un risque réel de déni de service dans les applications web qui appliquent des motifs fournis par l'utilisateur à du texte fourni par l'utilisateur.
De la théorie des langages formels à grep
Le concept d'expressions régulières trouve son origine dans l'informatique théorique. En 1956, le mathématicien Stephen Cole Kleene a publié un article décrivant les « événements réguliers », des ensembles de chaînes pouvant être décrits par un automate fini, et a introduit la notation algébrique qui allait devenir la syntaxe des regex. L'opérateur étoile (*), appelé l'étoile de Kleene, porte son nom. À ce stade, les expressions régulières n'étaient qu'une abstraction mathématique sans lien avec la pratique informatique.
Le passage de la théorie à l'outil est intervenu en 1968, lorsque Ken Thompson a implémenté la recherche par regex dans l'éditeur de texte QED, puis dans l'outil Unix grep (dont le nom signifie 'globally search a regular expression and print'). L'innovation clé de Thompson a été un algorithme efficace qui convertissait une expression régulière en un automate fini non déterministe (NFA) et le simulait, garantissant une correspondance en temps linéaire sans retour sur trace catastrophique. De nombreux moteurs de regex modernes ont abandonné l'approche NFA de Thompson au profit de moteurs à retour sur trace qui prennent en charge plus de fonctionnalités (comme les références arrière) mais peuvent présenter un comportement exponentiel dans le pire des cas.
Aujourd'hui, les expressions régulières sont prises en charge nativement dans pratiquement tous les langages de programmation et éditeurs de texte. Pourtant, la syntaxe s'est fragmentée en des dizaines de variantes incompatibles, POSIX BRE, POSIX ERE, PCRE, .NET, Java, Python, JavaScript, Ruby, chacune avec de subtiles différences de syntaxe et de sémantique. Une regex écrite pour un langage fonctionnera souvent dans un autre, mais les cas limites abondent. Cette fragmentation explique pourquoi il est toujours recommandé de tester un motif dans le moteur précis que vous allez réellement utiliser avant de le déployer en production.