Test et débogage de regex en ligne, gratuits

Testez vos expressions régulières avec mise en évidence en temps réel et groupes de capture.

Aucune donnée ne quitte votre appareil

Correspondances mises en évidence

Détails de la correspondance

0 matches

Référence rapide

.Tout caractère sauf saut de ligne \dChiffre (0-9) \wCaractère de mot (a-z, A-Z, 0-9, _) \sEspace blanc (espace, tabulation, saut de ligne) ^Début de la chaîne (ou début de ligne avec le flag m) $Fin de la chaîne (ou fin de ligne avec le flag m) *0 ou plusieurs occurrences du motif précédent +1 ou plusieurs occurrences du motif précédent ?0 ou 1 occurrence du motif précédent {n,m}Entre n et m occurrences du motif précédent [abc]Classe de caractères : a, b ou c [^abc]Ni a, ni b, ni c (abc)Groupe de capture (?:abc)Groupe non capturant a|ba ou b \bLimite de mot (?=abc)Lookahead positif (?!abc)Lookahead négatif

À propos des expressions régulières

Les expressions régulières (regex) sont des motifs utilisés pour faire correspondre des combinaisons de caractères dans des chaînes. C'est un outil essentiel en programmation, en traitement de texte, en validation de données et en recherche. Tous les grands langages de programmation prennent en charge les regex · JavaScript, Python, Java, PHP, Ruby, Go, et bien d'autres.

Ce testeur utilise le moteur RegExp intégré de JavaScript, qui prend en charge la syntaxe regex ECMAScript, y compris les lookaheads, les classes de caractères, les quantificateurs et les flags g, i, m et s. Les correspondances sont mises en évidence en temps réel à mesure que vous tapez, et les groupes de capture apparaissent dans le panneau des détails.

Usages courants

Questions fréquentes

À quoi servent les flags g, i, m et s ?

g (global) trouve toutes les correspondances au lieu de s'arrêter à la première. i (insensible à la casse) ignore la différence entre majuscules et minuscules. m (multiligne) fait que ^ et $ correspondent au début et à la fin de chaque ligne. s (dotAll) fait que . correspond aussi aux sauts de ligne.

Cette regex fonctionnera-t-elle en Python, Java ou PHP ?

La majeure partie de la syntaxe regex est partagée entre les langages. Il existe toutefois des différences · par exemple, JavaScript ne prend pas en charge les lookbehinds sur tous les navigateurs (les navigateurs modernes, oui), et Python utilise une syntaxe différente pour les groupes nommés. Pour les motifs de base, ce qui fonctionne ici fonctionnera partout.

Mes données de test sont-elles envoyées quelque part ?

Non. Toutes les correspondances regex se font localement dans votre navigateur, via le moteur RegExp natif de JavaScript. Rien n'est envoyé à un serveur.

Qu'est-ce qu'un testeur de regex ?

Un testeur de regex est un éditeur interactif qui exécute une expression régulière contre une chaîne d'exemple et vous montre exactement ce qui a correspondu, ce qui n'a pas correspondu, et ce que contiennent les groupes de capture. Le testeur vous permet d'itérer rapidement : tapez le motif, voyez les surbrillances, ajustez, répétez. Il remplace la boucle lente d'édition du code source, d'exécution d'un script et de lecture de la sortie console.

Les expressions régulières elles-mêmes sont une syntaxe de motif inventée par Stephen Cole Kleene en 1956 pour décrire des ensembles de chaînes. Les implémentations modernes de regex (PCRE, RegExp de JavaScript, re de Python, System.Text.RegularExpressions de .NET, java.util.regex de Java) partagent la plupart de leur syntaxe mais diffèrent dans les cas limites comme les lookbehinds, les groupes nommés, la gestion Unicode et le comportement des quantificateurs.

Ce testeur utilise le moteur RegExp natif JavaScript de votre navigateur, qui implémente la regex ECMAScript 2024 incluant tous les drapeaux standard (g, i, m, s, u, y, d) et les lookbehinds modernes. La sortie est exactement ce que votre code front-end verra à l'exécution, ce qui rend le testeur particulièrement utile pour déboguer la validation côté client, les sélecteurs de scraping ou les transformations replace-with-callback.

Ce qu'il y a dans le testeur

La rangée supérieure contient l'entrée du motif flanquée de barres obliques, suivie des boutons bascule pour les quatre drapeaux les plus utilisés (g, i, m, s). Un bouton Motifs ouvre une bibliothèque de fragments regex courants (email, URL, téléphone, date) que vous pouvez cliquer pour remplir le champ motif. En coulisses, l'entrée est anti-rebondie afin que retaper ne sollicite pas le matcher.

Sous le motif, la zone de texte Chaîne de test est l'endroit où vous collez le texte d'exemple. Les correspondances sont surlignées avec un fond jaune dans le panneau Correspondances surlignées qui se met à jour au fur et à mesure que vous tapez. Le champ Remplacer par accepte une chaîne de remplacement avec des références arrière ($1, $2, etc.) et affiche le texte résultant en direct, parfait pour tester les transformations de remplacement de chaîne avant de les coller dans votre code.

La liste Détails de correspondance affiche chaque correspondance avec son index basé sur zéro dans la source, la sous-chaîne correspondante et chaque groupe de capture. Une carte Référence rapide en bas récapitule la syntaxe des classes de caractères, des quantificateurs, des ancres et des lookarounds, afin que vous n'ayez pas à changer de contexte vers un onglet de documentation pour les bases.

Histoire et contexte

Stephen Cole Kleene définit les événements réguliers (1956)

Le mathématicien Stephen Cole Kleene a publié l'article Representation of Events in Nerve Nets and Finite Automata en 1956, introduisant ce qu'il appelait des événements réguliers : des motifs qui décrivent des ensembles de chaînes acceptés par un automate fini. L'étoile de Kleene (l'opérateur *) porte son nom. Sa notation algébrique est l'ancêtre direct de toute syntaxe regex utilisée aujourd'hui.

Ken Thompson livre grep (1968)

Ken Thompson aux Bell Labs a implémenté un moteur regex en 1968 à l'intérieur de l'éditeur QED et de nouveau dans grep (1973), l'utilitaire Unix dont le nom vient de la commande QED g/regular-expression/p. Le moteur basé NFA de Thompson s'exécutait en temps linéaire par caractère, une garantie que les moteurs de backtracking ont plus tard perdue en ajoutant des fonctionnalités comme les références arrière.

Perl 5 introduit la regex étendue (1994)

Larry Wall a publié Perl 5 en 1994 avec une variante regex qui ajoutait les lookaheads, lookbehinds, captures nommées (plus tard), modificateurs en ligne et références arrière. La regex Perl 5 est devenue si dominante que d'autres langages ont copié sa syntaxe. Philip Hazel a créé PCRE (Perl Compatible Regular Expressions) en 1997 comme bibliothèque C, et PCRE alimente aujourd'hui la regex dans PHP, Apache, NGINX et de nombreux autres outils.

JavaScript livre RegExp (1995, formalisé 1999)

JavaScript 1.0 de Brendan Eich en 1995 livrait un objet RegExp modelé sur Perl 5. L'édition 3 d'ECMAScript (1999) a formalisé la syntaxe. Les éditions ultérieures ont ajouté le drapeau Unicode u (ES2015), le drapeau sticky y (ES2015), les groupes nommés (ES2018), les lookbehinds (ES2018) et le drapeau d'indices d (ES2022). Les navigateurs ont rattrapé au fil du temps, et les moteurs modernes (V8, SpiderMonkey, JavaScriptCore) implémentent la spec ES2024 complète.

ReDoS, déni de service par regex (à partir de 2003)

Des chercheurs ont remarqué que les moteurs regex à backtracking peuvent prendre un temps exponentiel sur certaines entrées, une classe de vulnérabilité appelée ReDoS (Regular expression Denial of Service). Une panne Cloudflare en 2019 a été retracée à une regex avec backtracking catastrophique. Des outils comme rxxr et node-re2 ont émergé pour détecter ou contourner le problème, et les moteurs ont commencé à appliquer des budgets de temps sur les correspondances de longue durée.

Les échappements de propriétés Unicode arrivent dans ECMAScript (2018)

ES2018 a ajouté les échappements de propriétés Unicode tels que \p{Script=Latin} ou \p{Letter}, qui permettent de faire correspondre par catégorie Unicode sans énumérer les points de code. Combinée au drapeau u, la regex peut maintenant distinguer les emoji des lettres, les scripts entre eux et gérer correctement les paires de substitution. Cela rend enfin la regex JavaScript adaptée à la correspondance de texte international, un problème que l'ancienne syntaxe ASCII seule ne pouvait pas résoudre.

Flux de travail pratiques

Validation d'email

Déposez un échantillon d'emails valides et invalides dans la zone de test, tapez votre regex candidate (un point de départ courant est ^[^@\s]+@[^@\s]+\.[^@\s]+$), et ajustez jusqu'à ce que les emails valides soient surlignés et les invalides ne le soient pas. Sachez que la spec complète d'email RFC 5321 est si complexe que la regex d'email parfaite fait des centaines de caractères. Une regex pragmatique attrape les fautes de frappe ; la validation finale devrait faire un aller-retour via SMTP réel.

Analyse et extraction d'URL

Collez une page de HTML ou de texte brut et écrivez une regex pour extraire les URL. Un motif de départ comme https?:\/\/\S+ attrape la plupart des cas. Pour le code de production, préférez le constructeur URL (new URL(string)) qui gère chaque cas limite ; la regex est mieux adaptée pour des extractions ponctuelles ou l'analyse de journaux.

Scraping de fichiers journaux

Les journaux Apache et NGINX suivent un format fixe. Collez quelques lignes de journal, écrivez une regex avec des captures nommées ((?\S+) (?\S+ \S+) "(?[^"]+)" ...), et vous avez un analyseur prêt à alimenter un analyseur de journaux structurés. Testez sur un échantillon de vos journaux réels avant de déployer.

Rechercher et remplacer dans les éditeurs de code

VSCode, Sublime Text, les IDE JetBrains et vim acceptent tous la regex dans leurs dialogues de recherche-remplacement. Itérez d'abord sur le motif ici, avec le surligneur en direct montrant exactement ce qui correspond, puis collez la regex dans le dialogue de l'éditeur. Économisez-vous la douleur des échecs sur une base de code de 5 000 lignes.

Scraping web de noms de classes CSS

Lorsque vous avez besoin d'extraire des données du HTML sans analyseur (un script ponctuel, pas pour la production), une regex comme class="([^"]+)" extrait les attributs class. Pour tout ce qui dépasse une exploration rapide, passez à une bibliothèque DOM appropriée ; HTML n'est pas un langage régulier et la regex rate les cas limites.

Validation de chaînes de version sémantique

Semver suit ^\d+\.\d+\.\d+(-[\w.]+)?(\+[\w.]+)?$. Déposez une liste de versions (1.0.0, 1.2.3-beta.1+build.456) dans la zone de test pour vérifier que la regex attrape correctement les métadonnées de pré-version et de build. C'est utile pour valider les dépendances dans les scripts CI.

Pièges courants

Quantificateurs gourmands vs paresseux

Par défaut *, + et ? sont gourmands : ils correspondent autant que possible, puis font marche arrière si le reste de la regex échoue. Les versions paresseuses *?, +?, ?? correspondent aussi peu que possible. L'exemple classique est <.*> sur texte qui correspond à toute la chaîne, tandis que <.*?> correspond juste à et séparément. Choisissez le bon pour éviter les surprises de sur-correspondance.

Backtracking catastrophique (ReDoS)

Les quantificateurs imbriqués comme (a+)+ ou (.*)* sur une longue entrée non-correspondante peuvent prendre un temps exponentiel alors que le moteur essaie chaque combinaison. L'onglet du navigateur peut geler ou planter. Évitez les groupes de quantificateurs qui se chevauchent, préférez les groupes atomiques (?>...) où ils sont pris en charge, ou pré-validez la longueur d'entrée. La bibliothèque npm safe-regex signale automatiquement les motifs risqués.

Les caractères spéciaux ont besoin d'échappement

Les caractères avec une signification spéciale en regex (. * + ? ^ $ ( ) [ ] { } | \) doivent être échappés avec une barre oblique inverse pour correspondre littéralement. Donc \. correspond à un point, tandis que . correspond à n'importe quel caractère. Oublier d'échapper est la cause la plus courante de faux positifs lors de la validation d'IP, d'extensions de fichiers ou de numéros de version pointés.

Ancres et drapeau multiligne

Sans le drapeau m, ^ et $ correspondent seulement au début et à la fin de toute la chaîne. Avec m, ils correspondent au début et à la fin de chaque ligne. Si votre regex fonctionne sur des lignes uniques mais échoue sur une entrée multi-lignes, activez m. Inversement, si elle correspond à trop sur une entrée multi-lignes, retirez m.

Différences de syntaxe entre moteurs

Ce testeur utilise la regex JavaScript. Le re de Python utilise (?P) pour les captures nommées au lieu de (?), .NET permet les références arrière \k différemment, et PCRE a des fonctionnalités comme les sous-motifs récursifs (?R) que JavaScript n'a pas. Si votre cible finale est Python ou Java, validez aussi sur ces moteurs avant de livrer.

Unicode sans le drapeau u

Sans le drapeau u, la regex JavaScript traite les paires de substitution (emoji, supplément CJK) comme deux unités de code séparées. \u{1F600} (emoji visage souriant) ne fonctionne pas sans u. Avec le drapeau u, la regex devient consciente d'Unicode, les échappements de propriété comme \p{Letter} deviennent disponibles, et la gestion des paires de substitution est correcte. Définissez toujours u lors de la correspondance de texte international.

Confidentialité et gestion des données

Chaque regex est compilée et exécutée par le moteur RegExp de votre navigateur. Nous n'envoyons pas votre motif, votre chaîne de test ou votre modèle de remplacement à un serveur. Le matcher s'exécute localement, les surbrillances sont rendues localement, et la liste des détails de correspondance est calculée localement. Il n'y a pas d'analyses liées au contenu de vos entrées.

Une fois la page chargée, le testeur fonctionne hors ligne. Vous pouvez vous déconnecter du réseau, coller des lignes de journal sensibles ou des PII, et exécuter des motifs contre eux sans qu'aucune donnée ne quitte votre appareil. Cela rend l'outil sûr pour tester des regex contre des données de production sans les envoyer via un service tiers.

Quand ne pas utiliser une regex

Analyser HTML ou XML

HTML n'est pas un langage régulier. Vous ne pouvez pas analyser de manière fiable des balises imbriquées avec regex ; la fameuse réponse Stack Overflow sur Zalgo et Cthulhu fait ce point de façon colorée. Utilisez DOMParser ou une bibliothèque comme cheerio (Node.js) ou BeautifulSoup (Python) à la place. La regex convient pour des extractions ponctuelles mais se brise sur les cas limites comme les balises auto-fermantes, les commentaires, CDATA et les entrées malformées.

Tout ce qui est vraiment récursif (JSON, code source, expressions mathématiques)

Les accolades équilibrées, les parenthèses équilibrées, les appels de fonction imbriqués, la précédence arithmétique, tous nécessitent une grammaire hors contexte, pas une régulière. Utilisez un combinateur d'analyseurs (Parsimmon, nom) ou un générateur (pegjs, antlr). La regex peut faire correspondre les jetons d'ouverture ou de fermeture mais ne peut pas suivre l'équilibre.

Quand une opération de chaîne simple suffit

Si vous avez besoin de vérifier si une chaîne commence par prefix-, utilisez str.startsWith("prefix-"), pas /^prefix-/. Les méthodes de chaîne sont plus rapides, plus claires et impossibles à se tromper avec des quantificateurs. Réservez la regex pour des motifs que les méthodes de chaîne ne peuvent pas exprimer.

Validation de schéma complexe

Valider qu'un document JSON a une forme spécifique (champs requis, types imbriqués, plages de valeurs) est bien mieux fait avec un validateur de JSON Schema (ajv, zod, joi) qu'une regex. La regex peut vérifier le format mais pas la structure, et une regex qui essaie de valider un document JSON est un cauchemar de maintenance.

Plus de questions

Quand devrais-je utiliser lookahead vs lookbehind ?

Lookahead (?=...) affirme que ce qui suit correspond sans le consommer ; lookbehind (?<=...) fait la même chose pour ce qui précède. Utilisez lookahead lorsque le contexte de fin détermine s'il faut correspondre, lookbehind lorsque le contexte de début le fait. JavaScript prend en charge les deux depuis 2018 (ES2018), et tous les navigateurs modernes le font. Les versions plus anciennes de Safari avant 16.4 manquaient de support lookbehind.

Le lookbehind est-il pris en charge dans tous les navigateurs ?

Le lookbehind (positif et négatif) est pris en charge dans Chrome depuis la version 62 (2017), Firefox depuis 78 (2020), Edge depuis 79 (2020), et Safari depuis 16.4 (2023). Si votre audience peut utiliser un Safari plus ancien, évitez lookbehind ou polyfillez avec un motif alternatif. Pour Node.js, lookbehind est pris en charge depuis 10.0.

Que fait le drapeau Unicode (u) ?

Le drapeau u active le mode Unicode : les paires de substitution sont traitées comme un seul caractère, les échappements \u{...} fonctionnent, et les échappements de propriété \p{...} deviennent disponibles. Sans u, un emoji comme le visage souriant compte comme deux unités de code et . correspond seulement à la première moitié. Définissez toujours u lorsque vous travaillez avec du texte au-delà de l'ASCII.

Quelle est la vitesse du moteur regex ?

Le moteur RegExp de V8 utilise une implémentation Irregexp qui se compile en code natif. Pour des motifs simples, il fait correspondre des millions de caractères par seconde. Les motifs pathologiques (quantificateurs imbriqués sur une entrée adversariale) peuvent exploser en temps exponentiel, c'est pourquoi ReDoS est un véritable vecteur d'attaque. Les moteurs modernes appliquent des heuristiques pour détecter et abandonner les correspondances qui s'emballent, mais vous devriez quand même éviter les motifs risqués.

En quoi les regex de JavaScript et de Python diffèrent-elles ?

Les groupes nommés utilisent une syntaxe différente (? en JS, ?P en Python). Python manque du drapeau y (sticky) ; JavaScript manque du mode verbeux de Python. Python prend en charge la récursion via le module tiers regex mais pas le re intégré. Le raccourci de classe de caractères diffère légèrement (\d signifie [0-9] dans les deux, mais \w en Python inclut les soulignements en mode Unicode tandis que JS nécessite le drapeau u pour le même comportement).

Puis-je utiliser l'IA pour générer la regex à la place ?

Les LLM sont bons pour proposer des motifs regex initiaux mais produisent régulièrement des sorties subtilement incorrectes (gourmand où le paresseux était nécessaire, échappements manquants, mauvais drapeaux). Utilisez l'IA pour les premiers brouillons, puis validez en exécutant la regex contre des échantillons réels dans ce testeur. Itérez jusqu'à ce que les surbrillances correspondent exactement à ce que vous attendez. La boucle de rétroaction interactive attrape les erreurs des LLM avant qu'elles ne soient livrées en production.

Outils associés