Aide-mémoire regex, gratuit

Brève histoire du langage de motifs

Les expressions régulières ont commencé comme un morceau d'informatique théorique. Stephen Kleene a défini les « ensembles réguliers » dans un article de 1956 sur les réseaux neuronaux ; Ken Thompson les a intégrées à Unix en 1968 avec grep. La bibliothèque regex open-source d'Henry Spencer (milieu des années 1980) est devenue la base de nombreuses implémentations ultérieures. Larry Wall a étendu la syntaxe de manière spectaculaire dans Perl, et ses « expressions régulières compatibles Perl » (PCRE) sont devenues le standard de fait que la plupart des langages modernes ont suivi. Aujourd'hui il existe plusieurs saveurs de regex étroitement liées mais subtilement différentes, et un motif qui marche dans un moteur ne marche pas toujours à l'identique dans un autre.

Le moteur dans lequel vit votre motif

La même syntaxe peut signifier des choses différentes dans différents moteurs. Les grandes familles :

• POSIX BRE (Basic Regular Expressions), utilisée par le mode par défaut de grep, par sed. Beaucoup de métacaractères nécessitent un échappement par antislash : (, ), {, }, +, ?, | sont littéraux sauf s'ils sont échappés.
• POSIX ERE (Extended Regular Expressions), utilisée par egrep, awk. Les métacaractères ci-dessus marchent sans échappement.
• PCRE (Perl-Compatible Regular Expressions), étend ERE avec lookarounds, atomic groups, captures nommées et backreferences. Utilisée par PHP et la plupart des langages modernes. Les classes raccourcies dérivées de Perl \d / \w / \s sont communes à PCRE, JavaScript, .NET, Java et Python.
• JavaScript RegExp, proche de PCRE mais avec des différences notables. ES2018 a ajouté les lookbehinds, les groupes de capture nommés, le flag dotall s et les Unicode property escapes via le flag u. Le flag v pour la notation d'ensembles est arrivé en ES2024.
• re de Python et regex de Python, re est dans la bibliothèque standard ; le module tiers regex ajoute des fonctionnalités Unicode-aware, des lookbehinds de largeur variable et d'autres améliorations de style PCRE.
• RE2 (la bibliothèque de Google, utilisée en Go), garantit un temps linéaire mais ne supporte pas les backreferences ni les lookarounds. Le compromis : performance prévisible, moins de fonctionnalités.

Le testeur interactif de cette antisèche tourne en JavaScript, donc le motif est évalué par le moteur JS du navigateur. Des motifs qui marchent ici peuvent se comporter différemment en Python ou PHP. La plupart des différences sont dans les fonctionnalités avancées (lookbehinds, Unicode property escapes, backreferences) plutôt que dans la syntaxe de base.

Les blocs de construction de base

Presque chaque motif regex est construit à partir de ces éléments :

• Littéraux, se correspondent à eux-mêmes. cat correspond à la sous-chaîne « cat ».
• Ancres, ^ (début de chaîne / ligne), $ (fin), \b (frontière de mot), \B (non-frontière de mot).
• Classes de caractères, [abc] correspond à a, b ou c. [^abc] nie. [a-z] est une plage. Raccourcis : \d (chiffre), \w (caractère de mot : lettre, chiffre, underscore), \s (espace blanc) et versions majuscules pour la négation (\D, \W, \S).
• Quantificateurs, ? (0 ou 1), * (0 ou plus), + (1 ou plus), {n}, {n,}, {n,m}. Gourmands par défaut (correspondent au plus possible) ; ajoutez ? pour la version paresseuse : *?, +?, ??.
• Groupes, (...) capturant, (?:...) non-capturant, (?<name>...) nommé (PCRE / JS / Python).
• Alternance, cat|dog correspond à l'un ou l'autre.
• Lookarounds, (?=...) lookahead positif, (?!...) lookahead négatif, (?<=...) lookbehind positif, (?<!...) lookbehind négatif. Correspondent sans consommer.
• Backreferences, \1, \2 (numérotées), \k<name> (nommées). Correspondent au même texte que la capture correspondante.
• Flags, g (global), i (insensible à la casse), m (multiligne : ^ et $ correspondent aux frontières de ligne), s (dotall : . correspond aussi aux retours à la ligne), u (Unicode), y (sticky en JS).

Motifs qui valent la peine d'être mémorisés

Une poignée de motifs reviennent si souvent qu'il vaut la peine de les avoir en tête :

Note sur la regex e-mail : la validation complète RFC 5322 nécessite une regex monstre de 6 000 caractères. La forme simple ci-dessus accepte 99 % des vraies adresses e-mail et n'en rejette aucune légitime ; en production, envoyez un e-mail de confirmation plutôt que d'essayer de valider parfaitement la syntaxe.

Gourmand vs paresseux : une surprise courante

Par défaut, les quantificateurs sont gourmands : ils correspondent au plus possible tout en permettant au motif global de correspondre. Donc <.+> contre <a>text</a> capture l'ensemble, pas seulement <a>, parce que .+ attrape autant qu'il peut. Pour correspondre à la plus petite chaîne possible, ajoutez ? au quantificateur : <.+?> correspond à <a> puis à </a> séparément. Le choix gourmand/paresseux est l'une des sources les plus courantes de bugs « pourquoi ma regex ne correspond pas à ce que j'attendais ».

Backtracking catastrophique et ReDoS

Certains motifs regex peuvent prendre un temps exponentiel à échouer sur certaines entrées, une classe de vulnérabilité de déni de service appelée ReDoS (Regular Expression Denial of Service). Les coupables classiques sont les quantificateurs imbriqués comme (a+)+ ou (a|aa)+ appliqués à une longue chaîne de a suivie d'un caractère non correspondant. Le moteur essaie toutes les façons possibles de découper la chaîne avant d'abandonner, et le nombre de façons est exponentiel.

Incidents réels : la panne Cloudflare de 2019 a été déclenchée par une regex déployée dans une règle WAF qui a backtracké catastrophiquement sur certaines entrées. Stack Overflow a eu un incident similaire en juillet 2016 : une regex de post-trim (^[\s‌]+|[\s‌]+$) a heurté un backtracking exponentiel sur un seul commentaire contenant environ 20 000 caractères d'espace blanc consécutifs et a fait tomber le site pendant 34 minutes. Habitudes défensives : éviter les quantificateurs imbriqués, préférer les atomic groups ((?>...)) là où ils sont supportés, et envisager d'utiliser RE2 / des moteurs en temps linéaire pour les entrées non fiables.

Particularités par langage à connaître

• JavaScript : les antislashs nécessitent un double échappement dans les littéraux de chaîne ("\\d") mais pas dans les littéraux regex (/\d/). Utilisez la forme littérale regex quand c'est possible.
• Python : utilisez les chaînes brutes (r"\d+") pour éviter les problèmes d'antislash. Le module re est dans la bibliothèque standard ; regex sur PyPI ajoute des fonctionnalités supplémentaires.
• Java : les antislashs nécessitent un quadruple échappement ("\\\\d" pour \d) parce que les littéraux de chaîne Java utilisent \ comme caractère d'échappement et le compilateur regex voit ensuite \\d.
• Bash : la correspondance regex dans [[ string =~ pattern ]] utilise POSIX ERE. Les règles de quotation sont délicates ; consultez man bash.
• Go : utilise RE2, donc les backreferences et les lookarounds ne sont pas disponibles. Compromis : garantie de temps linéaire.

Quand NE PAS utiliser regex

La célèbre phrase de Jamie Zawinski en 1997 : « Some people, when confronted with a problem, think 'I know, I'll use regular expressions.' Now they have two problems. »

• Ne parsez pas HTML / XML avec regex. Utilisez un vrai parseur (DOMParser dans les navigateurs, BeautifulSoup en Python, jsoup en Java, etc.). La structure imbriquée du HTML dépasse fondamentalement ce que regex peut exprimer proprement.
• Ne parsez pas JSON avec regex. Utilisez JSON.parse / les parseurs JSON de la bibliothèque standard.
• Ne validez pas strictement les e-mails avec regex. Envoyez un e-mail de confirmation ; c'est le seul test fiable.
• N'écrivez pas un parseur CSV en regex. Les champs entre guillemets avec virgules embarquées, les guillemets échappés et les valeurs multi-lignes dépassent rapidement ce que regex gère proprement.
• N'essayez pas de matcher des parenthèses équilibrées. La regex standard ne le peut pas (c'est un langage hors-contexte) ; certains moteurs PCRE ont des fonctionnalités de récursion qui trichent, mais un vrai parseur est plus propre.

Erreurs courantes

1. Oublier d'échapper les caractères spéciaux. ., *, ?, +, (, ), [, ], {, }, \, ^, $, |, / ont tous des sens spéciaux. Pour les correspondre littéralement, préfixez par antislash.
2. Quantificateurs gourmands consommant trop. Ajoutez ? pour une correspondance paresseuse quand vous voulez la plus petite correspondance possible.
3. Oublier le flag global et se demander pourquoi seule la première correspondance s'affiche. Le String.prototype.match() de JavaScript ne retourne que la première correspondance sans le flag g.
4. Backtracking catastrophique sur de longues entrées. Les quantificateurs imbriqués comme (a+)+ peuvent bloquer sur certaines entrées. Testez avec des cas limites.
5. Supposer que la même regex se comporte de la même manière dans chaque langage. Lookbehinds, échappements Unicode et raccourcis de classe de caractères varient tous.
6. Essayer de valider les e-mails trop strictement. La regex techniquement correcte RFC 5322 n'est pas maintenable ; une regex simple plus un e-mail-de-confirmation-à-l'inscription est le motif qui marche.
7. Utiliser regex sur HTML, JSON ou CSV. Utilisez un vrai parseur ; le temps gagné en amont sera perdu en bugs.

Questions fréquentes supplémentaires

Pourquoi mon motif marche ici mais échoue dans mon code ?

La cause la plus courante est les différences de moteur. Le RegExp de JavaScript ne supporte pas certaines fonctionnalités que PCRE supporte (et vice versa). Pièges courants : les lookbehinds ajoutés tard à JS (ES2018), la syntaxe des groupes nommés diffère légèrement, les Unicode property escapes nécessitent le flag u, et les classes de caractères POSIX comme [[:alpha:]] sont presque absentes de JS. Testez dans le moteur sur lequel vous déploierez.

Y a-t-il un moyen « global » de matcher sur plusieurs lignes ?

Deux flags marchent ensemble. Le flag m (multiligne) fait que ^ et $ correspondent au début et à la fin de chaque ligne plutôt qu'à toute la chaîne. Le flag s (dotall) fait que . correspond aussi aux caractères de nouvelle ligne. Combiné avec g pour global, vous pouvez écrire des motifs qui s'étendent sur plusieurs lignes et trouvent chaque correspondance : /^foo.+$/gms.

Mes motifs et mon texte de test sont-ils envoyés quelque part ?

Non. La correspondance de motif utilise le moteur RegExp JavaScript intégré au navigateur ; rien n'est téléversé vers un serveur. Cela compte quand vous testez des motifs contre des données de log de production réelles, des réponses d'API internes ou du contenu sensible.

Devrais-je apprendre les lookbehinds ?

Utiles mais pas essentiels. Les lookbehinds vous permettent de matcher du texte précédé par quelque chose sans inclure ce « quelque chose » dans la correspondance. Exemple : (?<=\$)\d+ correspond aux chiffres après un signe dollar sans consommer le signe dollar. Ils sont supportés en PCRE, en JavaScript moderne (ES2018+) et dans le module regex de Python. Si vous écrivez des motifs portables, vérifiez d'abord le moteur cible.

Pourquoi utiliser (?:...) plutôt que (...) ?

Les groupes non-capturants ((?:...)) sont légèrement plus rapides, ne prennent pas de slot dans le tableau de captures et gardent vos résultats de correspondance propres. Utilisez-les chaque fois que vous avez besoin d'un groupement pour l'alternance ou la quantification mais pas d'extraire le texte correspondant. (http|https):// crée une capture dont vous n'avez peut-être pas besoin ; (?:http|https):// non.

Quelle est la bonne façon de matcher les caractères Unicode ?

En JavaScript, ajoutez le flag u et utilisez les Unicode property escapes : /\p{Letter}+/gu correspond à des séquences de lettres dans n'importe quelle écriture. Sans le flag u, \w ne correspond qu'aux caractères de mot ASCII. Le module re de Python est Unicode-aware par défaut en Python 3. Java a besoin de Pattern.UNICODE_CHARACTER_CLASS. La plupart des moteurs ont une façon d'être Unicode-aware ; vérifiez la doc du vôtre.