Bibliothèque de motifs regex, gratuite

À propos de cette bibliothèque

C'est une collection organisée et cherchable de plus de 60 motifs d'expression régulière couramment utilisés, rangés par catégorie. Chaque motif comprend une description, l'expression elle-même et des exemples de correspondances. Cliquez sur un motif pour le copier, ou utilisez le panneau de test rapide pour valider un texte contre lui directement sur cette page.

Tout s'exécute dans votre navigateur · aucun motif ni texte de test n'est envoyé nulle part. Utilisez ces motifs en JavaScript, Python, PHP, Java, Go ou tout langage qui prend en charge les expressions régulières. Pour des tests plus avancés avec drapeaux et groupes de capture, essayez notre Test et débogage de regex en ligne, gratuits.

D'où viennent les expressions régulières

L'idée mathématique d'« ensemble régulier » a été formalisée par Stephen Cole Kleene en 1951 dans le mémoire de recherche RAND Representation of Events in Nerve Nets and Finite Automata. L'opérateur * de cette page s'appelle toujours étoile de Kleene en son honneur. Ken Thompson a transformé la théorie en algorithme dans son article de juin 1968 du Communications of the ACM, Programming Techniques: Regular Expression Search Algorithm, et a livré la première implémentation de regex dans l'éditeur QED aux Bell Labs. En 1973, le même moteur alimentait ed, puis grep (le développement littéral est « globally search for regular expression and print »), sed et awk. Le Perl (1987) de Larry Wall, et surtout Perl 5 (1994), a ajouté les groupes nommés, l'anticipation/rétrospective, les quantificateurs non gourmands et la gestion Unicode qui sont devenus le dialecte de facto connu sous le nom de PCRE, porté en C par Philip Hazel en 1997.

Variantes de moteur et ce qui change entre elles

Un motif qui s'exécute proprement en JavaScript peut échouer silencieusement en Go et être carrément rejeté en POSIX. Les cinq variantes qu'un développeur est le plus susceptible de rencontrer :

• POSIX BRE / ERE (IEEE Std 1003.2-1992) : le dialecte de grep, sed et awk sur un Unix de base. Pas d'anticipation, pas de groupes nommés, pas d'échappements de propriété Unicode. BRE exige en plus d'échapper (, ), {, } et |.
• PCRE2 (Philip Hazel, 1997, version majeure actuelle 10.x) : le dialecte le plus complet en fonctionnalités. Anticipation, groupes nommés (?<name>...), groupes atomiques, quantificateurs possessifs, récursion. Utilisé par PHP preg_*, Apache, nginx, R.
• Regex ECMAScript (ECMA-262, regex section 22.2) : le dialecte JavaScript. ES2018 a ajouté les groupes nommés, la rétrospective et les drapeaux s (dotAll) et u (Unicode). ES2022 a ajouté le drapeau d pour les indices de correspondance. ES2024 a ajouté le drapeau v avec les classes en notation d'ensemble.
• Python re : proche de PCRE, mais utilise (?P<name>...) pour les groupes nommés (PEP 433) et un mode verbeux différent re.X. Le module tiers plus récent regex ajoute des motifs récursifs et la sémantique POSIX du plus long match.
• RE2 (Russ Cox, 2010) : le moteur derrière le regexp de Go et la crate regex de Rust. Pas d'anticipation, pas de rétroréférence, pas de quantificateurs possessifs, à dessein. Le compromis : temps linéaire garanti, pas de retour arrière catastrophique. Si un motif de cette bibliothèque utilise (?=...) ou \1, il ne compilera pas en Go.

Retour arrière catastrophique et ReDoS

La plupart des moteurs regex des langages courants (PCRE, Java, JS V8 / SpiderMonkey / JavaScriptCore, Python re, .NET) sont des moteurs à retour arrière. Quand un motif avec quantificateurs imbriqués comme (a+)+ rencontre une entrée qui correspond presque, le moteur peut essayer un nombre exponentiel de chemins alternatifs avant d'abandonner. C'est le retour arrière catastrophique, base de la classe d'attaques ReDoS (Regular expression Denial of Service) cataloguée par OWASP.

Stack Overflow, 20 juillet 2016 : un motif conçu pour rogner les espaces en début et fin, appliqué à un corps de question contenant 20 000 caractères d'espacement consécutifs, a pris 11 minutes de CPU par requête et a rendu le site inaccessible pendant 34 minutes. Le post-mortem sur le blog officiel Stack Status a recommandé de remplacer les regex de rognage par le trim natif de chaîne.

Cloudflare, 2 juillet 2019 : une règle WAF contenant le motif à quantificateurs imbriqués .*(?:.*=.*) a été déployée globalement et a consommé 100 % du CPU sur chaque serveur edge pendant 27 minutes, mettant hors ligne de larges portions d'internet public. Le post-mortem de Cloudflare sur leur blog a crédité le passage à la crate regex de Rust (un moteur basé sur RE2, temps linéaire) pour avoir évité la récidive.

Les leçons défensives : éviter les quantificateurs imbriqués ((a+)+, (a*)*, (a|aa)+) ; éviter les rognages style \s+$ sur des entrées contrôlées par l'attaquant ; préférer les groupes atomiques (?>...) ou les quantificateurs possessifs a++ en PCRE ; et pour les services à haut débit, envisager un moteur basé sur RE2.

Email, URL, téléphone, date, carte de crédit : quand ne pas utiliser regex

Email. La grammaire complète de la RFC 5322 (octobre 2008) se compile en une regex d'environ 3 000 caractères. La spécification HTML5 du W3C pour la validation <input type="email"> utilise une regex beaucoup plus courte « est-ce plausiblement un email » qui est le bon point de départ pour les indications côté client. La RFC 6531 (février 2012) autorise les adresses non-ASCII comme 用户@example.com, qu'une regex ASCII-only rejettera à tort. Le consensus de l'industrie depuis la RFC 6532 : ne validez pas les emails avec une regex, envoyez plutôt un email de vérification.

URL. La RFC 3986 (janvier 2005) est la spec de syntaxe générique URI, mais le WHATWG URL Living Standard en diverge délibérément pour correspondre à ce que les navigateurs acceptent réellement. Utilisez new URL("...") en JavaScript ou urllib.parse en Python plutôt qu'une regex au-delà d'une vérification visuelle rapide.

Numéros de téléphone. La Recommandation E.164 de l'UIT-T (révision actuelle novembre 2010) permet jusqu'à 15 chiffres avec un préfixe + optionnel, mais les règles spécifiques aux pays varient énormément. La bibliothèque open source de Google libphonenumber encode les règles par pays pour chaque territoire et est le seul validateur fiable inter-pays.

Dates. Une regex comme ^\d{4}-\d{2}-\d{2}$ correspond au format calendrier ISO 8601-1:2019, mais elle accepte aussi 2026-02-31. La validité d'une date nécessite la logique calendaire, pas la correspondance de motif ; utilisez Date.parse() ou une bibliothèque de dates.

Cartes de crédit. Une regex peut faire correspondre la longueur en chiffres et le préfixe IIN (Visa commence par 4, Mastercard par 51-55 ou 2221-2720, Amex par 34 ou 37) mais ne peut pas vérifier la somme de contrôle Luhn (Hans Peter Luhn, IBM, brevet US 2 950 048 délivré en août 1960). Luhn nécessite une somme chiffre par chiffre modulo 10.

Façons courantes dont les développeurs utilisent cette bibliothèque

• Indications de formulaire côté client, en comprenant qu'une regex est un indice, pas une validation finale.
• Extraction de logs, tirer des horodatages, IP, codes d'erreur et URL des logs d'application vers un pipeline.
• Nettoyage de données ponctuel : normaliser les espaces, éliminer les balises HTML, convertir entre formats de date, slugifier les titres.
• Recherche-remplacement dans l'éditeur dans VS Code, Sublime, vim, IntelliJ où la variante regex est proche de PCRE.
• Motifs de correspondance routeur et URL dans Express, Flask, FastAPI, Rails.
• Règles WAF et détection d'intrusion, avec une extrême prudence face au ReDoS comme l'incident Cloudflare 2019 l'a démontré.
• Test rapide de chaînes dans le panneau de test en bas de page, avant de valider le motif dans le code.

Erreurs courantes

• Oublier les ancres. Sans ^ et $ (ou \A et \z en PCRE), une regex de validation correspond si le motif apparaît n'importe où dans la chaîne. /\d{4}/ correspond à « year 2026 was good », ce qui n'est presque jamais voulu.
• Faire confiance à .* sur plusieurs choses. <a href=".*"> sur l'entrée <a href="a"><a href="b"> capture à travers les deux balises parce que .* est gourmand. Utilisez .*? pour le mode paresseux, ou mieux, parsez avec un vrai parseur.
• Supposer que le point correspond aux retours à la ligne. Par défaut . correspond à tout sauf aux terminateurs de ligne. Utilisez le drapeau s (dotAll) en JS, ou re.DOTALL en Python, ou le modificateur inline (?s) en PCRE.
• Supposer que \w inclut les lettres non-ASCII. En mode ASCII, \w est [a-zA-Z0-9_]. Ajoutez le drapeau u en JS (ES2018+) et utilisez \p{L} pour toute lettre Unicode ; en Python, ajoutez re.UNICODE (défaut en Python 3).
• Rétroréférences en Go. Le regexp de Go est RE2 et rejette \1 à la compilation. L'erreur « error parsing regexp: invalid escape sequence: \1 » signifie que le motif doit être décomposé en une approche non-regex.
• Parser HTML avec regex. Notoirement impossible : HTML n'est pas un langage régulier. Utilisez un parseur DOM (le DOMParser intégré au navigateur, cheerio, BeautifulSoup, lxml).

Plus de questions fréquentes

Pourquoi certains motifs utilisent-ils (?:...) au lieu de (...) ?

(?:...) est un groupe non capturant : il groupe pour la répétition ou l'alternance mais n'alloue pas de slot de rétroréférence. Plus rapide et évite de polluer $1, $2 dans le tableau de résultats. Utilisez (...) quand vous avez besoin d'extraire le texte capturé ; utilisez (?:...) pour le groupement seul.

Quels sont les drapeaux regex les plus courants ?

i insensible à la casse, g global (trouver tout, comportement spécifique JS), m multilignes (donc ^ et $ correspondent aux frontières de ligne), s dotAll (donc . correspond aux retours à la ligne, ES2018+), u Unicode (ES2015+), y sticky (ES2015+), d hasIndices (ES2022+), v classes en notation d'ensemble (ES2024+). Combinez avec /pattern/gimsu.

Comment faire correspondre un caractère spécial littéral ?

Échappez-le avec une barre oblique inverse. Les métacaractères regex à échapper pour une correspondance littérale sont : . ^ $ * + ? ( ) [ ] { } | \ /. Dans une classe de caractères [...] l'ensemble des caractères spéciaux est plus petit : seuls ] \ ^ - ont besoin d'échappement, selon la position.

Puis-je utiliser les motifs de cette bibliothèque dans des scripts shell ?

Oui, avec des réserves. grep utilise POSIX BRE par défaut ; grep -E utilise ERE ; grep -P utilise PCRE sur les systèmes où libpcre est lié (GNU grep, macOS grep avec Homebrew). Les motifs utilisant l'anticipation, les groupes nommés ou les échappements Unicode nécessitent grep -P ou ripgrep (qui utilise le moteur RE2-based de Rust et rejette l'anticipation).

Ces motifs sont-ils envoyés à un serveur ?

Non. Chaque regex de cette page, chaque recherche que vous tapez et chaque chaîne testée dans le panneau de test rapide est traitée par le moteur JavaScript de votre navigateur. Aucun appel réseau n'est effectué. Les données de motif elles-mêmes sont livrées comme fichier JSON statique dans le bundle de la page. Ouvrez l'onglet Réseau dans DevTools pour vérifier.