La moitié des regex qui partent en production ont été écrites par quelqu’un qui les a testées contre trois lignes et qui a appelé ça une journée. L’autre moitié a été écrite contre trente lignes et a échoué à la trente-et-unième — l’URL avec un numéro de port, le courriel avec un tag +, l’IPv4 avec un zéro de tête. Un testeur de regex est la seule façon pratique d’itérer contre de la vraie entrée sans redéployer. Le testeur de regex de PortJar sert au moment où vous arrêtez de faire confiance au fait que le motif dans le billet ouvert fait vraiment ce que son auteur croyait.
Ce que l’outil fait
Le testeur de regex est un testeur en direct pour des expressions régulières aux saveurs JavaScript (ECMAScript). Vous entrez un motif, optionnellement un jeu de drapeaux (g, i, m, s, u, y), et un corps de texte de test. L’outil retourne chaque correspondance dans le texte, l’index où chaque correspondance commence, et le contenu de chaque groupe de capture. Les puces d’exemple chargent des motifs de départ courants — courriel, IPv4, URL, UUID, code de couleur hex, date ISO — pour que vous n’ayez pas à réécrire la même regex de base à partir de zéro chaque fois.
Le moteur, c’est celui que livre votre navigateur, ce qui veut dire que tout ce que le JavaScript moderne supporte fonctionne : regards arrière, groupes de capture nommés ((?<nom>…)), échappements de propriétés Unicode (\p{…}). Les fonctionnalités spécifiques à PCRE — groupes atomiques, récursion, conditions — ne fonctionnent pas. Si vous écrivez un motif pour grep -P, pcregrep ou un langage côté serveur qui utilise PCRE (preg_* de PHP, anciens modules nginx), validez-le aussi dans un outil compatible PCRE ; la syntaxe se recoupe mais la sémantique diverge.
Comment l’utiliser
Ouvrez portjar.com/tools/regex. Collez votre motif dans le premier champ, fixez les drapeaux si besoin, collez un échantillon représentatif du texte à matcher dans le troisième champ, et appuyez sur Run. La sortie affiche chaque correspondance avec son index de début et ses groupes de capture. Utilisez les puces d’exemple sous le formulaire pour charger une base que vous modifierez plutôt que de retaper.
Avec le drapeau g actif, l’outil retourne toutes les correspondances et plafonne la liste à 500 pour garder la sortie lisible — assez pour valider contre un échantillon représentatif de journal, pas tellement qu’un motif qui s’emballe gèle la page. Sans g, vous obtenez une seule correspondance, le comportement à la exec ; utile quand vous voulez seulement savoir si un motif matche, et ce qu’il a capturé.
Quand y recourir
- Valider une regex de parsing de journal contre un vrai échantillon de journal avant de la déployer dans un pipeline Filebeat, Vector ou Logstash. Le motif qui marchait sur les trois exemples du développeur va échouer sur les cas limites du journal d’exploitation — adresses IPv6, traces d’exception multi-lignes, lignes avec chaînes entre guillemets contenant des guillemets échappés.
- Bâtir un validateur de courriel ou d’URL sans en écrire un de zéro. Les puces d’exemple vous donnent un point de départ qui marche ; itérez à partir de là plutôt qu’à partir du RFC 5322 au complet.
- Vérifier ce qu’une règle tierce matche vraiment — un bloc
locationNginx, une règle WAF, un filtre d’alerte — en collant des lignes de requête représentatives et en regardant si le motif les attrape toutes ou en rate certaines. - Diagnostiquer un signalement « cette alerte se déclenche trop souvent » ou « cette alerte ne se déclenche jamais », où le matcher sous-jacent est une regex. Collez le motif, collez une fenêtre de vraies lignes de journal, et les sur-correspondances ou sous-correspondances deviennent visibles immédiatement.
- Inférer ce qu’un groupe de capture alimente en aval. Si un motif est censé extraire un identifiant de requête, un nom d’hôte ou un code de statut, lancez-le contre un échantillon et lisez la sortie du groupe de capture — le gabarit d’alerte ou l’étiquette de tableau de bord est généralement déjà faux quand ça arrive là.
Quoi faire du résultat
Un motif qui retourne les correspondances que vous attendiez, aux positions attendues, avec les groupes de capture contenant ce qui était attendu, fait son travail. Sauvegardez-le et expédiez-le.
Un motif qui ne retourne aucune correspondance alors que vous en attendiez, c’est presque toujours une de trois choses : la sensibilité à la casse (essayez le drapeau i), les ancres (^ et $ se comportent différemment avec le drapeau m contre une entrée multi-ligne), ou des hypothèses sur les classes de caractères (\d matche les chiffres Unicode avec le drapeau u, seulement ASCII sans). Ajoutez ou retirez les drapeaux un à la fois avant de changer le motif lui-même.
Un motif qui retourne plus de correspondances qu’attendu est généralement tombé dans un de deux pièges : les quantificateurs gourmands (.* va avaler tout entre le premier et le dernier délimiteur, pas le premier et le plus proche), ou les classes de caractères trop permissives ([^"]* va joyeusement traverser les sauts de ligne à moins que vous excluiez aussi \n). Passez à des quantificateurs paresseux (.*?) ou resserrez la classe de caractères.
Un motif qui prend un temps notable sur une petite entrée est un avertissement. La combinaison de quantificateurs imbriqués et de backtracking peut produire des temps d’exécution exponentiels sur des entrées qui semblent inoffensives (« ReDoS » — déni de service par regex). La forme classique, c’est (a+)+b contre aaaaaaaaaaaaaaaaaac. Si l’outil ralentit ou gèle sur une ligne de journal réaliste, le même motif dans un pipeline de production finira par tomber le worker qui l’exécute. Réécrivez pour éviter les quantificateurs imbriqués et la répétition non bornée sur la même classe de caractères.
La sortie des groupes de capture, c’est la partie que la plupart sautent. Si un système en aval s’attend à ce que le groupe 1 soit un nom d’hôte et le groupe 2 un code de statut, lancez le motif contre une vraie ligne et lisez les groupes dans l’ordre où ils apparaissent. Un groupe de capture qui revient vide alors que la correspondance a réussi, c’est presque toujours un problème d’alternance — (foo|bar)(baz)? laissera le groupe 2 vide quand il n’y a pas de baz, et tout code qui suppose que le groupe 2 est rempli va mal se comporter.
Stack Harbor utilise le test de regex pendant le réglage de pipelines de journaux, les revues de règles d’alerte et le travail de schéma d’ingestion menés dans le cadre du soutien et supervision.