Générateur et testeur de regex

Construis un regex pragmatique, règle les boundaries et les flags, puis teste-le sur tes cas positifs et négatifs. Tout tourne en local dans ton navigateur.

Ce générateur de regex construit une expression régulière pragmatique à partir d'un type de pattern connu ou de ta propre phrase personnalisée, puis la prouve avant que tu copies quoi que ce soit. Choisis email, URL, IPv4 strict, domaine, UUID v4, date ISO, slug, couleur HEX ou texte custom, règle le boundary sur find in text, whole value ou word boundary, et choisis les flags pour la casse, le scan global et le multiline. Emballe le résultat dans un named capture quand le code en aval a besoin d'une valeur lisible. Le builder passe ton pattern sur des cas de test positifs et négatifs, surligne chaque match dans ton texte avec les positions de début et de fin, et te rend un snippet prêt à copier pour JavaScript, PHP PCRE ou Python. Tout tourne en local dans ton navigateur, donc rien de ce que tu colles ne quitte la page. Considère la sortie comme un point de départ testé et garde les règles métier, le choix du parser et les contrôles de sécurité dans le système qui l'exécute.

100% dans votre navigateur. Rien de ce que vous tapez ne quitte cette page.

Constructeur d'expressions régulières et banc de test

Choisis un pattern connu ou tape ta propre expression. Règle les boundaries et les flags. L'outil construit le regex, le passe sur tes exemples positifs et négatifs, et te montre exactement ce qui a matché dans le texte de test. Ensuite il te file un bout de code adapté au langage vers lequel tu te diriges. Franchement, la partie que la plupart des gens zappent (les tests) c'est justement celle qui te sauve plus tard.

Type de pattern

Boundary

Langage du snippet

Sortie de capture

Mode casse

Mode de recherche

Phrase personnalisée

Libellé du named capture

Texte de test à scanner

Cas de test positifs, un par ligne

Cas de test négatifs, un par ligne

Considère ce qui sort comme un point de départ testé, pas comme un produit fini. Les règles métier, le choix du parser, les contrôles de sécurité : tout ça vit encore dans le système qui va réellement utiliser le pattern.

Ce qu'un générateur de regex devrait faire avant que tu copies un pattern

Un générateur de regex gagne sa place quand il raccourcit ces dix premières minutes pénibles sans te cacher les risques au passage. Peut-être que tu traques des URLs dans un fichier de log. Peut-être que c'est un slug, ou que tu grattes des UUID dans un export. Le pattern de départ, c'est le plus facile, honnêtement. Ce sont les boundaries, les flags et les test cases qui décident si ça marche vraiment. Trop large, et il ramasse n'importe quoi. Trop strict, et il claque la porte au nez de données que ton vrai système acceptait déjà tranquillement.

Ce que fait ce builder, c'est garder tout ça à découvert. Il génère les regular expressions habituelles, te montre la vraie source, prévisualise un snippet taillé pour ton langage, et illumine les matches dans ton texte de test tout en signalant les lignes qui devraient échouer. Besoin d'un group lisible pour le code en aval ? Emballe-le dans un named capture. C'est quand même mieux que de coller une one-liner cryptique trouvée on-ne-sait-où et de lui faire confiance juste parce qu'elle avait l'air sûre d'elle.

Comment construire un regex adapté à la tâche

Nomme la tâche d'abord. Pêcher un seul email dans un paragraphe, c'est complètement différent de vérifier qu'un champ contient exactement un email et rien d'autre. Une recherche dans des logs veut un global scan. Une validation de formulaire veut en général des whole-value anchors, plus tout un tas de règles qui vivent en dehors du regex. Et si la donnée atterrit en JavaScript ou en Python, prends le snippet de ce langage et regarde vraiment l'escaping avant que ça touche quoi que ce soit qu'on appellerait de la prod.

Type de pattern te donne une base utilisable. Email, URL, IPv4, domain, UUID, une date, un slug, une couleur, ou juste du texte custom.
Boundary décide si le regex se balade à l'intérieur du texte ou se verrouille sur une valeur complète.
Flags changent la gestion de la casse, le fait de scanner globalement, et la façon dont les multiline anchors se comportent.
Matches de l'échantillon te montrent ce que le truc attrape réellement, et où commence chaque hit.
Tests positifs et négatifs font remonter les faux positifs et les faux négatifs, idéalement avant que le pattern parte se balader dans ton codebase.

Des exemples de regex qui méritent un second coup d'oeil

Les patterns email et URL sont réputés pour avoir l'air finis bien avant de l'être. Un regex email pragmatique va attraper sans problème les adresses courantes pour un formulaire ou une passe de nettoyage, d'accord, mais tu as encore la confirmation de compte et la politique de domaine sur les bras. Un pattern URL peut récupérer les liens dans du texte collé et laisser tout simplement la galère de la ponctuation finale au caller. IPv4 c'est le cas intéressant. Tu dois vraiment trancher : est-ce que des valeurs au-dessus de 255 passent comme de simples tokens de log, ou est-ce que tu les rejettes parce que ce ne sont pas de vraies adresses ? Cet outil est strict sur IPv4, ce qui me semble le default le plus sûr, même si j'avoue que ça dépend de ce que tu parses.

Un workflow humain pour travailler ses patterns plus sereinement

Construis le plus petit pattern qui nomme vraiment la valeur que tu veux. Rien de plus sophistiqué.
Ne sors les whole-value anchors que quand l'input entier doit être cette valeur, du début à la fin.
Balance de vrais exemples tirés de tes propres données, et quelques near misses qui ne doivent absolument pas matcher.
Lis l'échantillon surligné et la table des matches. Ensuite copie le code, pas avant.
Quand la donnée devient sale, repousse les parsers, la normalisation et la validation de sécurité hors du regex, là où ils ont leur place.

Questions fréquentes

Un regex peut-il valider parfaitement n'importe quel email ou URL ?

Non. Honnêtement, rien ne le peut. Le regex fait un premier filtre correct et c'est à peu près tout. Les vraies règles d'acceptation dépendent de ton appli, de la normalisation, et le plus souvent d'une étape de confirmation ou d'un vrai parser qui fait le gros du boulot.

Pourquoi utiliser des named capture groups ?

Surtout pour la lisibilité. Quand tu extrais une valeur qui veut vraiment dire quelque chose, un named group rend le code en aval bien moins cryptique pour celui qui le lira ensuite (probablement toi, dans trois mois). C'est optionnel ceci dit. Plein d'engines et de workflows s'en sortent très bien sans.

Devrais-je parser du JSON ou du HTML avec du regex ?

Pour un parsing complet ? Non. S'il te plaît, non. Prends le JSON parser, le DOM parser, une librairie dédiée. Ensuite, une fois la structure correctement gérée, le regex est génial pour les petits jobs de texte où c'est vraiment le bon outil.

Pourquoi mon regex matche trop ?

Neuf fois sur dix c'est un greedy quantifier, ou un pattern sans anchors. Mets des anchors (^ et $). Rends les greedy quantifiers lazy en ajoutant ?. Et resserre ces character classes pour qu'elles arrêtent d'attraper des trucs que tu ne voulais jamais.

Les patterns regex sont-ils portables d'un langage à l'autre ?

En gros oui, mais les flavors diffèrent d'une manière qui va te piquer. Lookbehind, named groups, gestion de l'Unicode : JavaScript, PCRE, Python, Go, ils ont chacun leurs propres avis. Donc teste le pattern dans l'engine où tu vas réellement le faire tourner. Pas dans un similaire.