Aide-mémoire des expressions régulières

Une table de syntaxe, pas un tutoriel

Les expressions régulières sont denses par conception. Un motif comme ^(?:\d{1,3}\.){3}\d{1,3}$ condense un validateur IPv4 entier en trente caractères, ce qui est formidable quand vous l'avez écrit et pénible quand vous lisez celui de quelqu'un d'autre. La plupart de la difficulté n'est pas conceptuelle — c'est que le vocabulaire est vaste, concis et facile à mi-remémorer.

Cette page est une table de recherche pour ce vocabulaire, organisée comme les motifs sont réellement construits : ce qui correspond à un caractère unique, comment définir ses propres ensembles de caractères, comment dire « répète ceci », où ancrer la correspondance, comment grouper et alterner, et quels drapeaux modifient le comportement du moteur. Le filtre recherche jetons, descriptions et exemples à la fois, si bien que taper « lazy », « boundary » ou « lookbehind » saute directement à la ligne que vous mi-remémorez.

Quelle variante ces jetons suivent

Les expressions régulières ne sont pas un seul langage. Grep, PCRE, Python, Java, le RE2 de Go et JavaScript partagent un noyau commun mais diffèrent aux marges. Tout ce qui est listé ici vise la variante JavaScript définie par ECMAScript, car c'est celle qui s'exécute dans le navigateur, dans Node.js et dans la plupart des outils front-end.

Trois différences méritent d'être signalées. D'abord, le lookbehind — (?<=...) et (?<!...) — est pris en charge par les moteurs JavaScript modernes mais absent du RE2 de Go et des anciennes versions de Safari, si bien que les motifs qui en dépendent ne sont pas portables partout. Ensuite, JavaScript n'a pas de drapeau verbeux x, vous ne pouvez donc pas étaler un motif sur plusieurs lignes avec des commentaires comme le permet Python ; les longs motifs sont généralement assemblés à partir de fragments de chaîne. Enfin, \d et \w sont ASCII uniquement par défaut en JavaScript, si bien que \w ne correspond pas aux lettres accentuées ni aux caractères CJK à moins de passer aux échappements de propriété Unicode comme \p{L} avec le drapeau u.

Écrire des motifs qui restent maintenables

Deux habitudes évitent la plupart des douleurs regex. La première est d'ancrer délibérément. Un motif non ancré recherche une correspondance n'importe où dans la chaîne, ce qui est ce que vous voulez pour analyser et presque jamais ce que vous voulez pour valider. Ajouter ^ et $ transforme « contient quelque chose qui ressemble à une date » en « est une date », et cette distinction se cache derrière une part surprenante de bugs de validation.

La seconde est de préférer la paresse et les classes de caractères niées aux jokers gourmands. L'erreur classique est <.+> sur un texte de type HTML : parce que + est gourmand, il avale tout jusqu'au dernier > de la ligne. Écrire <.+?> ou, mieux, <[^>]+> correspond à une seule balise. La version à classe niée est aussi nettement plus rapide, car le moteur n'a jamais à remonter.

Enfin, méfiez-vous du retour en arrière catastrophique. Imbriquer des quantificateurs, comme dans (a+)+b, peut amener le moteur à explorer exponentiellement de nombreuses façons de découper l'entrée avant de conclure qu'il n'y a pas de correspondance, ce qui transforme un appel de validation en vecteur de déni de service quand le motif touche une saisie utilisateur. Si un motif contient un groupe quantifié qui contient lui-même un quantificateur, réécrivez-le — généralement une seule classe de caractères avec un quantificateur fait le même travail en temps linéaire. Et quand un motif dépasse une ligne ou deux, la réponse honnête est souvent qu'un vrai analyseur est le bon outil et que l'expression régulière ne l'est pas.