Rechercher-remplacer : les pièges des expressions régulières, démontrés un par un

Gourmand et paresseux sur la même entrée

Prends la chaîne <b>bold</b> and <i>italic</i> et tente d'effacer les balises avec /<.+>/g. Le résultat est une chaîne vide. Le quantificateur + est gourmand : il prend tout ce qu'il peut et ne rend des caractères que si la suite du motif échoue, si bien que .+ avale tout jusqu'au dernier > et qu'une seule correspondance couvre toute la ligne. La première correspondance de /<.+>/ est littéralement l'entrée entière.

Deux corrections marchent, et elles ne sont pas équivalentes. Ajouter un point d'interrogation rend le quantificateur paresseux : /<.+?>/g prend le moins possible, sa première correspondance est <b>, et le remplacement rend bold and italic. Remplacer le point par une classe niée fait le même travail autrement : /<[^>]+>/g ne peut pas franchir un > du tout, et rend donc aussi bold and italic. Préfère la classe niée quand elle existe : elle dit où est la frontière au lieu de compter sur le retour arrière du moteur pour s'arrêter au bon endroit, et elle ne redevient pas gourmande en silence lorsque tu ajoutes plus tard une partie facultative au motif.

Le point s'arrête à la fin de la ligne

En JavaScript, . reconnaît n'importe quel caractère sauf un terminateur de ligne. Prends une fiche sur deux lignes : « Prix : 12,50 € », un retour à la ligne, puis « Stock : 3 unités ». Le test /Prix.*unités/ rend faux. Le même motif avec le drapeau s, /Prix.*unités/s, rend vrai, car s — dotAll — supprime l'exception du terminateur de ligne. L'ancien contournement, une classe de caractères qui couvre tout, /Prix[\s\S]*unités/, rend vrai également et fonctionne dans les moteurs antérieurs au drapeau.

C'est là qu'un remplacement échoue en silence plutôt qu'avec fracas. Un motif censé couvrir un paragraphe ne trouve simplement rien, le compte de remplacements revient à zéro, et un pipeline qui ne vérifie pas ce compte annonce un succès. C'est aussi pourquoi /.+/g fait un découpeur de lignes utilisable : sur la même fiche de deux lignes, il rend deux correspondances, une par ligne — une fonctionnalité quand on la veut, une surprise sinon.

La chaîne de remplacement a sa propre syntaxe

Le second argument de replace n'est pas du texte brut. C'est un petit langage, et son unique métacaractère est $. Sur « Total : 42 EUR » avec /(\d+) (USD|EUR)/, le remplacement [$&] donne « Total : [42 EUR] », $1 donne « Total : 42 », et $<amount> — le groupe étant nommé dans le motif — donne « Total : [42] ». La liste complète est courte : $&, $1 à $99, $<nom>, $` pour tout ce qui précède la correspondance, $' pour tout ce qui suit, et $$ pour un dollar littéral.

Deux pièges en découlent. Le premier : le $ d'un remplacement n'est pas le $ d'un motif. Dans un motif, $ est une ancre signifiant fin d'entrée ; dans un remplacement, il ne signifie jamais cela. Écrire $ là où l'on veut un symbole monétaire ne produit un $ littéral que par chance — replace(/EUR/, '$') rend bien « Total : 42 $ », car un $ isolé suivi de rien de particulier passe tel quel, mais dès qu'il est suivi d'un chiffre ou d'une esperluette le sens change. Écris $$ et n'y pense plus.

Le second piège est une ambiguïté de chiffre. $10 signifie le groupe 10 quand le motif compte dix groupes capturants, et le groupe 1 suivi du caractère 0 quand ce n'est pas le cas : sur un motif à dix groupes, le remplacement [$10] a rendu [j], et sur un motif à un seul groupe, il a rendu [a0]. Le sens de ta chaîne de remplacement dépend donc du nombre de groupes que contient le motif : ajoute un groupe et le remplacement change de comportement sans avoir été modifié. Les groupes nommés suppriment l'ambiguïté, et si le remplacement est une donnée plutôt que du code, passe une fonction : sa valeur de retour est insérée telle quelle, si bien que replace(/\d+/, () => '$&') sur « Total : 42 EUR » produit le littéral « $& » au lieu du nombre trouvé.

Une regex /g se souvient de son point d'arrêt

Un objet RegExp portant le drapeau g transporte une propriété mutable lastIndex, que .test() et .exec() lisent et écrivent. Réutilise le même objet sur plusieurs chaînes et chaque recherche démarre là où la précédente s'est arrêtée. Prends const re = /\d+/g et teste-la sur trois lignes — « order 12 », « order 7 », « order 349 » — et les résultats sont vrai, faux, vrai. La ligne du milieu contient bien un nombre. Elle a été sautée parce que lastIndex valait 8 au début de la recherche, et après le troisième appel lastIndex valait 9.

Le même effet apparaît sur une seule chaîne. Quatre appels consécutifs re.test('banana') avec /a/g rendent vrai, vrai, vrai, faux : trois a, puis une recherche infructueuse qui remet lastIndex à 0, si bien qu'un cinquième appel rendrait vrai de nouveau. Rien de tout cela n'est un bug — c'est ce qui rend exec() utilisable dans une boucle while — mais cela transforme une constante regex de niveau module en variable mutable partagée déguisée.

Trois corrections, par ordre de préférence. Ne mets pas g sur une regex utilisée avec .test() : le drapeau n'y apporte rien et provoque tout ce qui précède. Utilise matchAll ou match avec g quand tu veux toutes les occurrences, car les deux gèrent l'index pour toi. Ou, si tu dois réutiliser un objet, remets re.lastIndex = 0 avant chaque recherche, en sachant que tu as choisi l'option fragile.

L'insensibilité à la casse n'est pas une connaissance des langues

Le drapeau i applique le repli de casse Unicode, qui est une table fixe et non une règle de locale. Le contre-exemple le plus net est le turc, dont l'alphabet compte deux i : le i pointé i/İ et le i sans point ı/I. Exécute les tests : /i/i ne reconnaît pas İ, et /I/i ne reconnaît pas ı — les deux rendent faux. Pendant ce temps, 'I'.toLowerCase() rend 'i' mais 'I'.toLocaleLowerCase('tr') rend 'ı', et 'i'.toLocaleUpperCase('tr') rend 'İ'. On peut informer les fonctions de casse d'une locale. Le drapeau de regex, non.

Trois autres résultats de la même exécution, dont chacun a coûté une matinée à quelqu'un. /ss/i ne reconnaît pas ß et /ß/i ne reconnaît pas SS, parce que le repli de casse est une correspondance caractère à caractère et que l'eszett allemand se développe en deux lettres. /k/i ne reconnaît pas le signe kelvin K, mais /k/iu — avec le drapeau Unicode — le reconnaît, car u active le repli de casse simple : ajouter un drapeau d'apparence purement syntaxique change donc les caractères considérés comme égaux. Et /é/i ne reconnaît pas un É décomposé, un e suivi d'un accent aigu combinant : le repli de casse n'est pas la normalisation, et les deux sont des décisions indépendantes, comme l'article de cette série consacré aux accents le détaille.

L'ancrage, et pourquoi \b ment sur les mots accentués

\b n'est pas un caractère. C'est une assertion de largeur nulle qui réussit là où un caractère de mot (en JavaScript : [A-Za-z0-9_]) se trouve d'un seul côté. Cette définition est purement ASCII, et elle produit un résultat exactement inverse pour toute langue à signes diacritiques. /\bcafé\b/ ne reconnaît pas « un café noir », parce qu'après le é — qui n'est pas un caractère de mot — vient une espace, qui n'en est pas un non plus : il n'y a donc pas de frontière. Le même motif reconnaît « un cafés », parce que le é est suivi d'un s et que cela constitue une frontière. L'assertion se déclenche là où le mot continue et échoue là où il finit.

Le remplaçant de \b est une paire d'assertions Unicode : /(?<![\p{L}\p{N}])café(?![\p{L}\p{N}])/u reconnaît « un café noir » et refuse « un cafés », ce qui correspond à ce qu'une personne entend par mot entier. Le drapeau u est indispensable pour que \p{…} soit seulement reconnu. Quand le mot remplacé est purement ASCII, \b reste convenable — /\bchat\b/ se comporte bien — mais dès que le motif contient une lettre hors de A–Z, vérifie les deux extrémités à la main.

Compter, puis remplacer : un exemple traité

Prends la ligne : chat, château, tchat, le chat dort. Il s'agit de remplacer l'animal par chien. Compte d'abord : la ligne.match(/chat/g).length vaut 3. Tu en attendais 2. Ce seul nombre, lu avant d'écrire quoi que ce soit, constitue toute la protection — et si tu avais remplacé au lieu de compter, la sortie aurait été « chien, château, tchien, le chien dort », le mot tchat ayant été mutilé au passage.

Ancre puis recompte : /\bchat\b/g trouve 2, le nombre attendu, et c'est seulement alors qu'il est sûr de remplacer. Le résultat est « chien, château, tchat, le chien dort ». Ensuite, recompte : /\bchat\b/g doit maintenant trouver 0 et /\bchien\b/g doit trouver 2. Trois comptes et un remplacement, quatre lignes en tout, et chacune est une ligne que tu peux montrer à quelqu'un qui demande ce qu'a fait la modification.

Un détail de la version allemande du même exercice mérite d'être retenu. Remplacer Bahn par Zug dans « Bahn, Bahnhof, Autobahn, die Bahn fährt » sans ancres donne 3 correspondances, pas 4 : le motif est sensible à la casse, il frappe donc Bahnhof mais rate le bahn minuscule à l'intérieur d'Autobahn. Un compte inférieur à l'attente est aussi informatif qu'un compte supérieur, et il désigne un autre bug.

Questions fréquentes

Pourquoi mon remplacement a-t-il effacé une ligne entière ?

Presque toujours un quantificateur gourmand entre deux délimiteurs qui apparaissent plusieurs fois. /<.+>/ sur une ligne à deux balises va du premier < au dernier > : la correspondance unique est la ligne entière. Ajoute un point d'interrogation pour rendre le quantificateur paresseux, /<.+?>/, ou mieux, interdis le délimiteur fermant à l'intérieur de la correspondance avec une classe niée, /<[^>]+>/.

Pourquoi la même regex donne-t-elle une autre réponse au second appel ?

Parce qu'elle porte le drapeau g et un lastIndex qui survit d'un appel à l'autre. /a/g testée quatre fois sur « banana » rend vrai, vrai, vrai, faux. Retire le drapeau g quand tu ne veux qu'une réponse oui ou non, utilise matchAll quand tu veux toutes les occurrences, ou remets re.lastIndex = 0 avant chaque recherche si l'objet doit vraiment être partagé.

Comment mettre un dollar littéral dans le remplacement ?

Écris $$. Un $ isolé ne fonctionne que si rien de particulier ne le suit, ce qui en fait un bug qui attend la prochaine retouche : « $$$1 » sur « Total : 42 EUR » donne « Total : $42 », tandis que l'intuitif « $$& » donne le littéral « $& » plutôt que la correspondance. Si le texte de remplacement est une donnée — une valeur de formulaire, une traduction, tout ce que tu n'as pas tapé —, passe une fonction plutôt qu'une chaîne : sa valeur de retour est insérée sans aucun traitement des $.

Le drapeau i comprend-il les accents et les autres alphabets ?

Il comprend le repli de casse et rien d'autre. Il assimilera a et A sur presque tout Unicode, mais il ne normalise pas : /é/i échoue sur un É décomposé ; il ne développe pas : /ss/i échoue sur ß ; et il ne connaît aucune locale : /i/i échoue sur le İ turc. Si tu as besoin de l'un de ces comportements, normalise le texte d'abord et utilise un collateur de sensibilité « base » pour la comparaison, plutôt que d'attendre du drapeau une connaissance des langues qu'il n'a jamais eue.

Comment faire correspondre sur deux lignes ?

Ajoute le drapeau s, qui fait reconnaître au point les terminateurs de ligne : /Prix.*unités/ est faux sur deux lignes et /Prix.*unités/s est vrai. Ne le confonds pas avec m, qui concerne les ancres et non le point : m fait correspondre ^ et $ au début et à la fin de chaque ligne plutôt qu'à l'entrée entière, et laisse le point inchangé. On veut souvent les deux, et ils sont indépendants.

Pourquoi \b échoue-t-il sur un mot finissant par une lettre accentuée ?

Parce que \b est défini sur la classe de mot ASCII [A-Za-z0-9_], et qu'une lettre accentuée n'en fait pas partie. Une frontière exige un caractère de mot d'un seul côté : entre é et l'espace qui suit, il n'y en a aucun, et /\bcafé\b/ ne reconnaît pas « un café noir » — alors qu'il reconnaît « un cafés », où le é est suivi d'un s ASCII. Remplace les assertions par des assertions Unicode : /(?<![\p{L}\p{N}])café(?![\p{L}\p{N}])/u, en gardant à l'esprit que \p{…} exige le drapeau u.