Testeur de regex
Testez un regex JavaScript sur du vrai texte, avec named groups, aperçu du remplacement et patterns sauvegardés.
Ce testeur de regex fait tourner un regex JavaScript sur du vrai texte directement dans votre navigateur et vous montre ce que le pattern a vraiment fait. Vous récupérez les matches avec leurs indexes de début et de fin, les groups numérotés, les named groups, un aperçu du remplacement avant de valider, plus des lignes de test positives et négatives qui attrapent les bugs que votre exemple bien propre cache. Sept patterns de départ couvrent email, URL, IPv4, UUID, date ISO, slug et niveaux de log, et vous sauvegardez les vôtres dans le stockage du navigateur. Il écrit des snippets prêts à copier pour JavaScript, PCRE façon PHP et Python, et signale les wildcards gourmands, les quantifiers imbriqués et les boulots à confier plutôt à un parser. Rien ne quitte votre machine.
100% dans votre navigateur. Rien de ce que vous tapez ne quitte cette page.
Testeur de regex, named groups, aperçu du remplacement et patterns sauvegardés
Collez un regex JavaScript, balancez-lui du vrai texte, et regardez ce qui se passe réellement. Vous récupérez les matches, où ils commencent et où ils finissent, les groups numérotés, les named groups, un aperçu du remplacement. Sauvegardez un pattern dans votre navigateur pour plus tard. Il y a aussi un bouton pour copier le snippet. Franchement, la partie que tout le monde zappe, c'est le contrôle de sûreté, et c'est justement celle que je relirais deux fois avant que ce regex s'approche de la production.
Tout ça tourne dans votre navigateur, sur le moteur JavaScript. Les autres langages gèrent la syntaxe et l'échappement un peu différemment, et certaines features n'existent tout simplement pas ailleurs, donc ne partez pas du principe qu'un test réussi ici veut dire un test réussi partout.
Un testeur de regex devrait montrer ce que le pattern a vraiment fait
Un bon testeur de regex montre les indexes, les groups capturés, les named groups, la sortie du remplacement et les flags actifs, pas seulement un voyant vert qui dit "matché". Le regex, c'est compact. C'est tout l'intérêt, et c'est aussi exactement là que ça vous mord. Un pattern peut viser pile votre petit exemple bien propre, puis s'effondrer en silence sur un log multiligne, sur du texte Unicode, sur le presque-match qui aurait dû être rejeté mais qui est passé entre les mailles. Du coup, vous voulez voir tout ça, avant que quoi que ce soit ne soit copié quelque part.
C'est en gros ce que fait ce truc. Tout tourne en local. Il surligne les hits dans votre échantillon, vous dit où chacun commence et s'arrête, détaille les captures numérotées et nommées, vous montre le remplacement avant que vous ne validiez. Il y a des patterns de départ si vous n'avez pas envie d'en écrire un de zéro. Les patterns que vous sauvegardez restent dans le stockage du navigateur. Et il vous sort un snippet pour JavaScript, pour du PCRE façon PHP, pour Python (avec des notes sur la façon dont les named groups changent de forme en passant vers Python, parce que oui, ils changent).
Comment tester une expression régulière sans se faire avoir
Commencez avec du texte bordélique, pas l'exemple bien propre que vous aviez en tête. Glissez-y des lignes qui doivent matcher. Glissez-en aussi quelques-unes qui doivent échouer, ce sont celles-là qui attrapent les vrais bugs. Ensuite, posez-vous une seule question : est-ce que vous repêchez des valeurs dans un pavé de texte, ou est-ce que vous validez un champ entier ? Deux boulots différents. Et les flags comptent plus qu'on ne le croit. Global change le nombre de résultats qui reviennent. Multiline réécrit le sens des anchors. DotAll laisse un point avaler les retours à la ligne. Le case-insensitive peut masquer une hypothèse que vous ne saviez même pas avoir faite.
- Matches vous donnent la valeur plus exactement où elle se trouve, du start index jusqu'à la fin.
- Groups extraient les captures numérotées, et les nommées aussi, à condition que le moteur joue le jeu.
- L'aperçu de Replace, c'est le filet de sécurité. Il montre les dégâts avant qu'un mauvais nettoyage ne frappe un fichier ou une base de données.
- Les patterns sauvegardés restent simplement dans le navigateur pour que vous puissiez revenir à un brouillon.
- Les notes de sûreté signalent les suspects habituels : les wildcards gourmands, les quantifiers imbriqués, et les boulots que vous devriez vraiment confier à un parser à la place.
Exemples courants de debug de regex
Un nettoyage de logs qui bouffe trop de texte ? Neuf fois sur dix c'est un wildcard gourmand quelque part, donc allez le trouver et balancez-lui plusieurs lignes différentes. Vous utilisez un pattern email pour les inscriptions ? D'accord, mais traitez le regex comme le portier, pas comme le videur, vous confirmez quand même l'adresse autrement. Un match d'URL qui traîne une virgule ou un point à la fin ? Resserrez la boundary, ou contentez-vous de couper la ponctuation dans le code ensuite, selon ce qui fait le moins mal. Et le JSON, le HTML, un vrai langage de programmation ? Non. Prenez un parser. Gardez le regex pour les petits trucs.
Questions fréquentes
Le regex JavaScript et le PCRE, c'est pareil ?
Non. Des cousins proches, oui, ça se recoupe pas mal. Mais les flags, le lookbehind, la façon d'écrire les named groups, les règles d'échappement, tout ça finit par diverger. Donc testez là où ça va vraiment tourner.
Est-ce qu'un regex peut valider n'importe quelle adresse email ?
Pas d'une manière que vous auriez envie de mettre en prod, honnêtement. La spec complète, c'est un cauchemar. Servez-vous du regex pour écarter les évidences pourries, puis prouvez que l'adresse est réelle en lui envoyant un mail ou via ce que fait votre appli.
Est-ce qu'un regex peut parser du HTML ou du JSON ?
Il peut attraper un petit fragment par-ci par-là. Pour du vrai parsing, par contre, prenez un vrai parser. Croyez-moi sur celle-là.
Pourquoi mon regex est lent ou fige la page ?
Du catastrophic backtracking, à coup sûr ou presque. C'est cette vilaine forme de pattern, un quantifier imbriqué qui tombe sur une entrée qui ne matche pas tout à fait, et le moteur essaie chaque combinaison avant d'abandonner. Réécrivez le truc pour que les morceaux arrêtent de se chevaucher de façon ambiguë.