Modèles PCRE (Philip Hazel)

Traduction et exemples AutoIt: danielm

• Expression régulière PCRE
• Elément particulier au début d'un modèle
• Codes des caractères EBCDIC
• Caractère et Métacaractère
• BackSlash
• Circonflexe et dollar
• Arrêt complet (virgule, point) et \N
• Match d’une unité de donnée seule
• Crochets et classe de caractère
• Classe de caractère POSIX
• Compatibilité avec les limites de mot
• Barre verticale et alternative
• Définition des options internes
• Sous-modèles
• Duplication d'un numéro de sous-modèle
• Sous-modèle nommé
• Répétition
• Groupement atomique et quantificateur possessif
• Référence arrière
• Assertion
• Sous-modèle conditionnel
• Commentaire
• Modèle récursif
• Sous-modèle en tant que sous-programme
• Syntax des sous-programme ONIGURUMA
• Appel externe
• Contrôle du backtracking
• Voir aussi
• Auteur
• Version

La syntaxe et la sémantique des expressions régulières qui sont prises en charge par PCRE sont décrites en détail ci-dessous. Il y a un résumé de la syntaxe de référence dans la page pcresyntax. PCRE essaie de coller à la syntaxe et la sémantique Perl aussi étroitement que possible. PCRE prend également en charge une syntaxe d'expression régulière alternative (qui n’entre pas en conflit avec la syntaxe Perl) afin de fournir une certaine compatibilité avec les expressions régulières en Python, .NET et Oniguruma.

Les expressions régulières Perl sont décrites dans leur propre documentation, et les expressions régulières en général sont traitées dans un certain nombre de livres, dont certains ont des exemples copieux. "Mastering Regular Expressions" de Jeffrey Friedl, publié par O'Reilly, couvre les expressions régulières dans les moindres détails. Cette description des expressions régulières PCRE se veut un manuel de référence.

Un certain nombre d'options peuvent être définies par des éléments particuliers au début d'un modèle. Plusieurs éléments peuvent apparaître, mais ils doivent tous être ensemble dès le début de la chaîne modèle.

PCRE opérait à l'origine sur des chaînes de caractères d'un octet. Cependant, il y a maintenant aussi un support pour les chaînes UTF-8 dans la bibliothèque d'origine, une bibliothèque supplémentaire prenant en charge les chaînes de caractères 16 bits et UTF-16, et une troisième bibliothèque qui prend en charge les chaînes de caractères 32 bits et UTF-32. Pour utiliser ces fonctionnalités, le modèle PCRE doit commencer par l'une des séquences spéciales suivantes:

  (*UTF8)
  (*UTF16)
  (*UTF32)
  (*UTF)

Une autre séquence spéciale qui peut apparaître au début d'un modèle est (*UCP). Elle forcera des séquences comme \d et \w à utiliser les propriétés Unicode pour déterminer les types de caractère, au lieu de reconnaître seulement les caractères de code inférieur à 128.

Si un modèle commence avec (*NO_AUTO_POSSESS), il demande à PCRE d'arrêter de rendre les quantificateurs possessifs quand ce qui suit ne peut pas matcher l'élément répété. Par exemple, par défaut a+b est traité comme a++b.

Si un modéle commence par (*NO_START_OPT), il désactive plusieurs optimisations pour atteindre rapidement les résultats "sans match".

PCRE soutient cinq conventions différentes pour indiquer un retour à la ligne dans les chaînes: le seul caractère CR (carriage return), le seul caractère LF (line feed), la séquence des deux caractères CRLF, l'une des trois précédentes, ou toute séquence newline Unicode.

Il est également possible de spécifier une convention de newline en démarrant un modèle avec l'une des cinq séquences suivantes:

  (*CR)        carriage return
  (*LF)        linefeed
  (*CRLF)      carriage return, suivi de linefeed
  (*ANYCRLF)   n'importe quelle séquence précédente
  (*ANY)       toute séquence newline Unicode

  (*CR)a.b

La convention newline affecte la façon dont les assertions 'circonflexe' et 'dollar' sont vraies. Elle affecte aussi l'interprétation du métacaractère 'dot' (le point) quand PCRE_DOTALL n'est pas défini, et le comportement de \N. Cependant, elle n'a pas d'incidence sur ce que matche la séquence d'échappement \R. Par défaut, c'est une séquence de saut de ligne Unicode, pour la compatibilité Perl. Cependant, cela peut être changé voir la description de \R dans la section intitulée "Séquences Newline" suivante. Un changement du paramètre \R peut être combiné avec un changement de convention newline.

Il est possible de définir une limite sur le nombre de matchs et sur la profondeur maximale des appels récursifs. Ces possibilités sont prévues pour arrêter des matches qui s'emballent à cause de modèles avec d'énormes arborescence de matchs (un exemple typique est un modèle avec des répétitions imbriquées illimitées) et pour éviter de manquer de pile système par trop de récursivité. Lorsque l'une de ces limites est atteinte, StringRegExp() retourne une erreur. Les limites sont définies par des éléments au début du modèle:

  (*LIMIT_MATCH=d)
  (*LIMIT_RECURSION=d)

PCRE peut être compilé pour s'exécuter dans un environnement qui utilise EBCDIC comme code de caractères plutôt que ASCII ou Unicode (généralement un système mainframe). Dans les sections ci-dessous, les valeurs de code de caractère sont ASCII ou Unicode; dans un environnement EBCDIC ces caractères peuvent avoir des valeurs de code différentes, et il n'y a pas de points de code supérieur à 255.

Une expression régulière est un modèle qui matche une chaîne sujet de gauche à droite. La plupart des caractères se représentent eux-mêmes dans un modèle, et matchent les caractères correspondants dans le sujet. Comme exemple trivial, le modèle:

  Le renard brun rapide

La puissance des expressions régulières provient de la possibilité d'inclure des alternatives et des répétitions dans le modèle. Celles-ci sont codées dans le modèle par l'utilisation de méta-caractères, qui ne sont pas interprétés pour eux-mêmes mais sont interprétés d'une manière spéciale.

Il existe deux ensembles différents de méta-caractères: ceux qui sont reconnus partout dans le modèle, excepté ceux entre crochets, et ceux qui sont reconnus entre crochets. En dehors des crochets, les méta-caractères sont les suivants:

  \      caractère d'échappement général avec plusieurs utilisations
  ^      assertion de début de chaîne (ou de ligne, en mode multi-ligne)
  $      assertion de fin de chaîne (ou de ligne, en mode multi-ligne)
  .      matche n’importe quel caractère sauf newline (par défaut)
  [      démarre la définition d’une classe de caractères
  |      démarre une branche alternative
  (      début d’un sous-modèle
  )      fin d’un sous-modèle
  ?      étend la signification de (
         aussi  quantificateur 0 ou 1
         aussi quantificateurs qui minimise
  *      quantificateur 0 ou plus
  +      quantificateur 1 ou plus
         aussi "quantificateur possessif"
  {      démarre un quantificateur min/max

  \      Caractère d'échappement général
  ^      négation de la classe, mais seulement en premier caractère
  -      indique une plage de caractères
  [      classe de caractères POSIX (uniquement si elle est suivie par la syntaxe POSIX)
  ]      termine la classe de caractères

Le caractère backslash a plusieurs utilisations. Tout d'abord, s’il est suivi par un caractère qui n’est pas un chiffre ou une lettre, il enlève toute signification spéciale que peut avoir ce caractère. Cette utilisation de la barre oblique inverse comme caractère d'échappement s’applique à la fois à l'intérieur et à l'extérieur des classes de caractères.

Par exemple, si vous voulez matcher le caractère *, vous écrivez \* dans le modèle. L’action d’échapper un caractère peut se faire pour un caractère qui par ailleurs pourrait être interprété comme un métacaractère, mais pas nécessairement, donc il est toujours plus sûr de faire précéder un caractère non-alphanumérique par un backslash pour indiquer qu'il représente lui-même. En particulier, si vous voulez matcher une barre oblique inverse, vous écrirez \\.

Dans un mode UTF, seuls les chiffres et les lettres ASCII ont une signification spéciale après une barre oblique inverse. Tous les autres caractères (en particulier, ceux dont le code est supérieur à 127) sont traités comme des littéraux.

Si un modèle est utilisé avec l'option x (PCRE_EXTENDED, qui permet d'introduire des commentaires dans un modèle), les espaces dans le modèle (autre que dans une classe de caractères) et les caractères entre un # en dehors d'une classe de caractères et le saut de ligne suivant sont ignorés. Un backslash peut être utilisée pour inclure un espace ou un caractère # comme partie du modèle.

Si vous souhaitez supprimer la signification spéciale à partir d'une séquence de caractères, vous pouvez le faire en les mettant entre \Q et \E. Ceci est différent de Perl en ce que $ et @ sont traités comme des littéraux dans les séquences \Q ... \E dans PCRE, alors que dans Perl, $ et @ provoque une interpolation de variable. Noter les exemples suivants:

  Modèles           Matchs PCRE

  \Qabc$xyz\E        abc$xyz
  \Qabc\$xyz\E       abc\$xyz
  \Qabc\E\$\Qxyz\E   abc$xyz

Une deuxième utilisation de l'antislash fournit un moyen de coder les caractères non affichables dans les modèles d'une manière visible. Il n'y a aucune restriction quant à l'apparition de caractères non affichables, en dehors du zéro binaire qui met fin à un modèle, mais quand un modèle est en cours de préparation en éditant le texte, il est souvent plus facile d'utiliser l'une des séquences d'échappement suivantes que le caractère binaire qu'elle représente:

  \a        alarme, qui est, le caractère BEL (hex 07)
  \cx       "control-x", où x est un caractère ASCII
  \e        escape (hex 1B)
  \f        formfeed (hex 0C)
  \n        linefeed (hex 0A)
  \r        retour chariot (hex 0D)
  \t        tabulation (hex 09)
  \0dd      caractère avec un code octal 0dd
  \ddd      caractère avec le code octal ddd, ou référence arrière
  \o{ddd..} caractère avec un code octal ddd..
  \xhh	    caractère avec le code hexadécimal hh
  \x{hhh..} caractère avec le code hexadécimal hhh.. (mode non-JavaScript)
  \uhhhh    caractère avec le code hexadécimal hhhh (mode JavaScript seulement)

La fonctionnalité \c a été conçue pour être utilisée avec des caractères ASCII, mais avec l'extension à Unicode elle est moins utile qu'elle l'était autrefois.

Après \0 jusqu'à deux autres chiffres octaux sont lus. S'il y a moins de deux chiffres, seuls ceux qui sont présents sont utilisés. Ainsi la séquence \0\x\07 spécifie deux zéros binaires suivis d'un caractère BEL (valeur de code 7). Assurez-vous de fournir deux chiffres après le zéro initial si le caractère de modèle qui suit est lui-même un chiffre octal.

L'échappement \o doit être suivi d'une séquence de chiffres octaux entre parenthèses. Une erreur se produit si ce n'est pas le cas. Cet échappement est une addition récente de Perl; il permet de spécifier des points de code de caractères en nombres octaux supérieurs à 0777, et il permet également de spécifier sans ambiguité les nombres octaux et les références arrière.

Pour plus de clarté et sans ambiguïté, il est préférable d'éviter de faire suivre \ par un chiffre supérieur à zéro. A la place, utilisez \o{} ou \x{} pour spécifier les caractères nombres, et \g{} pour spécifier les références arrières. Les paragraphes suivants décrivent l'ancienne syntaxe ambiguë.

Le traitement d'un backslash suivi d'un chiffre autre que 0 est compliqué, et Perl a changé dans les versions récentes, entrainant PCRE à changer également. En dehors d'une classe de caractères, PCRE lit un chiffre et tous les chiffres suivants sous forme de nombre décimal. Si le nombre est inférieur à 8, ou s'il y en a eu au moins autant de parenthèses capturantes à gauche dans l'expression, la séquence entière est prise comme référence arrière. Une description de ce fonctionnement est donnée plus loin à la suite des sous-modèles entre parenthèses.

A l'intérieur d'une classe de caractères, ou si le nombre décimal qui suit \ est supérieur à 7 et s’il n'y a pas eu de sous-modèles capturants, PCRE traite \8 et \9 comme les caractères littéraux "8" et "9", et autrement re-lit jusqu'à trois chiffres octaux qui suivent le backslash, en les utilisant pour générer un caractère de données. Les chiffres suivants représentent eux-mêmes. Par exemple:

  \040    est une autre façon d'écrire un espace ASCII
  \40     est pareil, à condition qu'il y ait moins que 40 sous modèles capturant précédents
  \7      est toujours une référence arrière
  \11     peut être une référence arrière, ou une autre façon d'écrire une tabulation
  \011    est toujours une tabulation
  \0113   est une tabulation suivi du caractère "3"
  \113    peut être une référence arrière, sinon le caractère avec le code octal 113
  \377    peut être une référence arrière, sinon la valeur 255 (décimal)
  \81     est une référence arrière ou les deux caractères "8" et "1"

Par défaut, après \x qui n'est pas suivi de {, de zéro à deux chiffres hexadécimaux sont lus (les lettres peuvent être en majuscule ou en minuscule). Un nombre quelconque de chiffres hexadécimaux peuvent apparaître entre \x{ et }. Si un caractère autre qu'un chiffre hexadécimal apparaît entre \x{ et }, ou s'il n'y a pas de terminaison }, une erreur se produit.

Si l'option PCRE_JAVASCRIPT_COMPAT est définie, l'interprétation de \x est comme décrite ci-dessus seulement lorsqu'il est suivi de deux chiffres hexadécimaux. Sinon, il matche un caractère littéral "x". En mode JavaScript, le support de codes supérieurs à 256 est fourni par \u, qui doit être suivi par quatre chiffres hexadécimaux; sinon, il matche le caractère littéral "u".

Les caractères dont la valeur est inférieure à 256 peuvent être définis avec une des deux syntaxes \x (ou par \u en mode JavaScript). Il n'y a pas de différence dans la façon dont ils sont gérés. Par exemple, \xdc est exactement pareil que \x{dc} (ou \u00dc en mode JavaScript).

Les caractères qui sont spécifiées en utilisant des nombres octaux ou hexadécimaux sont limités à certaines valeurs, de la façon suivante:

  8-bit non-UTF mode    moins que 0x100
  8-bit UTF-8 mode      moins que 0x10ffff et un point de code valide
  16-bit non-UTF mode   moins que 0x10000
  16-bit UTF-16 mode    moins que 0x10ffff et un codepoint valide
  32-bit non-UTF mode   moins que 0x100000000
  32-bit UTF-32 mode    moins que 0x10ffff et un codepoint valide

Toute séquence qui définit une valeur de caractère isolé Peut êre utilisée aussi bien dans une classe de caractère qu'en dehors. De plus, dans une classe de caractère, \b est interprété comme le caractère backspace (hex 08).

\N n'est pas autorisé dans une classe de caractère. \B, \R, and \X ne sont pas spéciaux dans une classe de caractère. Comme d'autres séquences d'échappement non reconnues, elles sont traitées comme les caractères littéraux "B", "R", and "X" par défaut, mais provoque une erreur si l'option PCRE_EXTRA est définie. En dehors d'une classe de caractère, ces séquences ont des significations différentes.

En Perl, les séquences \l, \L, \u et \U sont reconnus par son gestionnaire de chaîne et utilisé pour modifier la casse des caractères qui suivent. Par défaut, PCRE ne supporte pas ces séquences d'échappement.

La séquence \g suivie d'un nombre non signé ou d’un nombre négatif, éventuellement encadré par des accolades, est une référence arrière absolue ou relative. Une référence arrière nommée peut être codé par \g{name}. Les références arrières sont étudiées plus loin, après les sous-modèles parenthésés.

Pour la compatibilité avec Oniguruma, la syntaxe non-Perl \g suivie d'un nom ou d’un nombre encadré par des crochets ou des guillemets simples, est une syntaxe alternative pour référencer un sous-modèle comme un "sous-programme". Les détails sont étudiés plus loin.. Notez que \g{...} (syntaxe Perl) et \g<...> (syntaxe Oniguruma) ne sont pas synonymes. Le premier est une référence arrière; le dernier est un appel à un sous-programme.

Une autre utilisation de l'antislash est la spécification d’un type de caractères générique:

  \d    un chiffre décimal
  \D    tout caractère qui est pas un chiffre décimal
  \h    tout caractère d’espacement horizontal
  \H    tout caractère qui n’es pas un caractère d’espacement horizontal
  \s    tout caractère d’espacement
  \S    tout caractère qui n’est pas un caractère d’espacement
  \v    tout caractère d’espacement vertical
  \V    tout caractère qui n’est pas un caractère d’espacement vertical
  \w    tout caractère de "mot"
  \W    tout caractère qui n’est pas un caractère "mot"

Chaque paire de séquences d’échappement de minuscule et majuscule partitionne l'ensemble des caractères en deux ensembles disjoints. Chaque caractère donné matche une, et une seule, de chaque paire. Les séquences peuvent apparaître à la fois à l'intérieur et à l'extérieur des classes de caractères. Elles matchent chacune un caractère du type approprié. Si le point du match est à la fin de la chaîne sujet, elles échouent toutes les deux, parce qu'il n'y a pas de caractère à matcher.

Pour la compatibilité avec Perl, \s ne matche pas le caractère VT (code 11), ce qui le rend différent de la classe POSIX "space". Cependant, Perl a ajouté VT à la version 5.18, et PCRE a suivi à la version 8.34. Par défaut, les caractères \s sont HT (9), LF (10), VT (11), FF(12), CR(13), et space(32) qui sont définis comme espace blancs dans la locale "C". Cette liste peut varier si un match spécifique aux paramètres régionaux est demandé. Par exemple, dans certains locales, le caractère "espace insécable" (\xA0) est reconnu comme espace blanc, et dans d'autres le caractère VT ne l'est pas.

Un caractère de "mot" est le caractère de soulignement ou tout caractère qui est une lettre ou un chiffre. Par défaut, la définition des lettres et des chiffres est contrôlée par des tables de caractères de valeurs basses de PCRE, et peut varier si un match spécifique à la localisation a lieu (voir "Support des paramètres régionaux" dans la page pcreapi. Par exemple, dans la locale French telle que "fr_FR" dans les systèmes de type Unix, ou "french" dans Windows, certains codes de caractères supérieurs à 127 sont utilisés pour les caractères accentués, et ceux - ci sont ensuite matchés par \w. L'utilisation des paramètres régionaux avec Unicode est déconseillée.

Par défaut, les caractères dont le code est supérieur à 128 ne matchent jamais \d, \s ou \w, et matchent toujours \D, \S, et \W, bien que cela puisse varier pour les caractères dans la plage 128-255 lorsqu'un match spécifique à des paramètres régionaux se produit. Ces séquences d'échappement conservent leurs significations originales d’avant que le support UTF soit disponible, principalement pour des raisons d'efficacité. Si PCRE est compilé avec le support Unicode, et si l'option PCRE_UCP est activée, le comportement est modifié de sorte que les propriétés Unicode soient utilisées pour déterminer les types de caractères, comme suit:

  \d 		tout caractère qui matche \p{Nd}  (chiffre décimal)
  \s		tout caractère qui matche \p{Z}, ou \h ou \v
  \w 		tout caractère qui matche \p{L} ou \p{N}, plus soulignement

Les séquences \h, \H, \v, et \V sont des caractéristiques qui ont été ajoutées à Perl dans la version 5.10. Contrairement aux autres séquences, qui matchent uniquement des caractères ASCII par défaut, celles-ci matchent toujours certains code de valeur haute, que PCRE_UCP soit activé ou pas. Les espaces horizontaux sont:

  U+0009 	Tabulation horizontale
  U+0020 	Espace
  U+00A0 	Espace insécable
  U+1680 	Marque d’espace Ogham
  U+180E 	Séparateur de voyelle Mongolian
  U+2000 	En quad
  U+2001 	Em quad
  U+2002 	Espace En
  U+2003 	Espace Em
  U+2004 	Espace Trois-per-em
  U+2005 	Espace Quatre-per-em
  U+2006 	Espace Six-per-em
  U+2007 	Espace Figure
  U+2008 	Epace Ponctuation
  U+2009 	Epace étroit
  U+200A 	Espace Hair
  U+202F 	Narrow insécable rapproché
  U+205F 	Espace moyen mathématique
  U+3000 	Espace idéographique

  U+000A 	Linefeed (LF)
  U+000B 	Tabulation verticale (VT)
  U+000C 	Formfeed (FF)
  U+000D 	Carriage return (CR)
  U+0085 	Ligne suivante (NEL)
  U+2028 	Séparateur Ligne
  U+2029 	Séparateur Paragraphe

En dehors d'une classe de caractères, par défaut, la séquence d'échappement \R matche toute séquence de saut de ligne Unicode. En mode 8 bits non-UTF-8 \R est équivalent à ce qui suit:

  (?> \r\n | \n | \x0b | \f | \r | \x85)

Dans les autres modes, deux caractères supplémentaires dont les codes sont supérieurs à 255 sont ajoutés: LS (séparateur de ligne, U+2028) et PS (séparateur de paragraphe, U+2029). Le support des caractères Unicode n’est pas nécessaire pour que ces caractères soient reconnus.

Il est possible de restreindre \R pour matcher uniquement CR, LF ou CRLF (au lieu de l'ensemble complet des fins de ligne Unicode) en démarrant un modèle avec l'une des séquences suivantes (BSR est l'abréviation de "BackSlash \R"):

  (*BSR_ANYCRLF)   CR, LF, or CRLF seulement
  (*BSR_UNICODE)   toute séquence newline Unicode

  (*ANY) (*BSR_ANYCRLF)

Lorsque l'option Unicode est active, trois séquences d'échappement supplémentaires qui matchent des caractères avec des propriétés spécifiques sont disponibles. En mode 8-bit non-UTF-8, ces séquences sont bien sûr limitées aux caractères d'essais dont les codes sont inférieurs à 256, mais ils fonctionnent dans ce mode. Ces séquences d'échappement supplémentaires sont:

  \p{xx}   un caractère avec la propriété xx
  \P{xx}   un caractère SANS la propriété xx
  \X       un élément graphème étendue Unicode

Les ensembles de caractères Unicode sont définis comme appartenant à certains scripts. Un caractère d'un de ces ensembles peut être matché en utilisant un nom de script. Par exemple:

  \p{Greek}
  \P{Han}

Arabic, Armenian, Avestan, Balinese, Bamum, Bassa_Vah, Batak, Bengali, Bopomofo, Brahmi, Braille, Buginese, Buhid, Canadian_Aboriginal, Carian, Caucasian_Albanian, Chakma, Cham, Cherokee, Common, Coptic, Cuneiform, Cypriot, Cyrillic, Deseret, Devanagari, Duployan, Egyptian_Hieroglyphs, Elbasan, Ethiopic, Georgian, Glagolitic, Gothic, Grantha, Greek, Gujarati, Gurmukhi, Han, Hangul, Hanunoo, Hebrew, Hiragana, Imperial_Aramaic, Inherited, Inscriptional_Pahlavi, Inscriptional_Parthian, Javanese, Kaithi, Kannada, Katakana, Kayah_Li, Kharoshthi, Khmer, Khojki, Khudawadi, Lao, Latin, Lepcha, Limbu, Linear_A, Linear_B, Lisu, Lycian, Lydian, Mahajani, Malayalam, Mandaic, Manichaean, Meetei_Mayek, Mende_Kikakui, Meroitic_Cursive, Meroitic_Hieroglyphs, Miao, Modi, Mongolian, Mro, Myanmar, Nabataean, New_Tai_Lue, Nko, Ogham, Ol_Chiki, Old_Italic, Old_North_Arabian, Old_Permic, Old_Persian, Old_South_Arabian, Old_Turkic, Oriya, Osmanya, Pahawh_Hmong, Palmyrene, Pau_Cin_Hau, Phags_Pa, Phoenician, Psalter_Pahlavi, Rejang, Runic, Samaritan, Saurashtra, Sharada, Shavian, Siddham, Sinhala, Sora_Sompeng, Sundanese, Syloti_Nagri, Syriac, Tagalog, Tagbanwa, Tai_Le, Tai_Tham, Tai_Viet, Takri, Tamil, Telugu, Thaana, Thai, Tibetan, Tifinagh, Tirhuta, Ugaritic, Vai, Warang_Citi, Yi.

Chaque caractère a exactement une propriété de catégorie générale Unicode, spécifiée par une abréviation de deux lettres. Pour la compatibilité avec Perl, la négation peut être spécifié en incluant un accent circonflexe entre l'accolade d'ouverture et le nom de la propriété. Par exemple, \p{^Lu} est identique à \P{Lu}.

Si une seule lettre est spécifiée avec \p ou \P, il est inclut toutes les propriétés de catégories générales qui commencent par cette lettre. Dans ce cas, en l'absence de négation, les accolades dans la séquence d'échappement sont facultatives; ces deux exemples ont le même effet:

  \p{L}
  \pL

  C         Autres
  Cc        Contrôle
  Cf        Format
  Cn        Unassigned
  Co        Utilisation réservée
  Cs        Surrogate

  L         Lettre
  Ll        Lettre minuscule
  Lm        Lettre modifiée
  Lo        Autre lettre
  Lt        Lettre en casse Titre
  Lu        Lettre majuscule

  M         Marque
  Mc        Marque d’espacement
  Me        Marque d’encadrement
  Mn        Marque non-espacement

  N         Nombre
  Nd        Nombre décimal
  Nl        Nombre lettre
  No        Autre nombre

  P         Ponctuation
  Pc        Ponctuation de connexion
  Pd        Ponctuation Dash
  Pe        Ponctuation de fermeture
  Pf        Ponctuation finale
  Pi        Ponctuation initiale
  Po        Autres signes de ponctuation
  Ps        Ponctuation d’ouverture

  S         Symbole
  Sc        Symbole monétaire
  Sk        Symbole Modificateur
  Sm        Symbole mathématique
  So        Autre symbole

  Z         Séparateur
  Zl        Séparateur de Ligne
  Zp        Séparateur de Paragraphe
  Zs        Séparateur Espace

Les synonymes longs des noms de propriétés que Perl soutient (comme \p{Lettre}) ne sont pas pris en charge par PCRE, pas plus que le préfixe de l'une de ces propriétés avec "Is".

Aucun caractère qui est dans la table Unicode a la propriété Cn (unassigned). Au lieu de cela, cette propriété est soutenue pour tout code qui n’est pas dans la table Unicode.

La spécification insensible à la casse d’un match n'affecte pas ces séquences d'échappement. Par exemple, \p{Lu} matche toujours uniquement des lettres majuscules. Ceci est différent du comportement des versions courantes de Perl.

Le match des caractères par propriétés Unicode n'est pas rapide, car PCRE doit effectuer des recherches de table à plusieurs étages afin de trouver la propriété d'un caractère. C'est pourquoi les séquences d'échappement traditionnelles telles que \d et \w n'utilisent pas les propriétés Unicode dans PCRE par défaut, mais vous pouvez les faire en démarrant le modèle avec (*UCP).

L’échappement \X matche un certain nombre de caractères Unicode qui forment un "extended grapheme cluster", et traite la séquence comme un groupe atomique (voir ce qui suit). Jusqu'à la version 8.31 incluse, PCRE utilisait une définition antérieure plus simple qui était équivalente à:

  (?>\PM\pM*)

Cette définition simple a été étendue en Unicode pour inclure des sortes plus compliquées de caractères composites en donnant à chaque caractère une propriété de rupture de graphème, et en créant des règles qui utilisent ces propriétés pour définir les limites des groupes de graphèmes étendues. Dans les versions de PCRE ultérieures à 8.31, \X matche un de ces groupes.

\X matche toujours au moins un caractère. Ensuite, il décide d'ajouter ou non des caractères supplémentaires selon les règles suivantes pour mettre fin à un groupe:

1. Fin à la fin de la chaîne de sujet.

2. Ne pas se terminer entre CR et LF; sinon se terminer après tout caractère de contrôle.

3. Ne cassez pas les séquences de syllabes Hangul (un script Korean). Les caractères Hangul sont de cinq types: L, V, T, LV et LVT. Un caractère L peut être suivi d'un caractère L, V, LV ou LVT; un caractère LV ou V peut être suivi d'un caractère V ou T; un caractère LVT ou T ne peut être suivi que d'un caractère T.

4. Ne se termine pas avant l'extension des caractères ou les marques d'espacement. Les caractères avec la propriété "mark" possède toujours la propriété de rupture de graphème "extend".

5. Ne pas se terminer après avoir préfixé un caractère.

6. Sinon, terminer le cluster.

En plus des propriétés Unicode standards décrites dans la section précédente, PCRE soutient quatre autres prppriétés qui permettent de convertir des séquences d'échappement traditionnelles telles que \w et \s pour utiliser les propriétés Unicode. PCRE utilise ces propriétés non-standards, non-Perl en interne lorsque PCRE_UCP est activé. Ces propriétés sont:

  Xan      Tout caractère alphanumérique
  Xps      Tout caractère d'espace POSIX
  Xsp      Tout caractère d'espace Perl
  Xwd      Tout caractère  "mot" Perl

Il existe une autre propriété non standard, Xuc, qui matche n'importe quel caractère qui peut être représenté par un nom de caractère universel en C++ et autre langage de programmation. Ce sont les caractères $, @, `(accent grave) et tous les caractères avec des points de code Unicode supérieurs ou égaux à U + 00A0, à l'exception des surrogates U+D800 à U+DFFF. Notez que la plupart des caractères de base (ASCII) sont exclus. (Les noms de caractères universels sont de la forme des séquences \uHHH ou \UHHHHHHHH où H est un chiffre hexadécimal. Notez que la propriété Xuc ne matche pas ces séquences mais les caractères qu'ils représentent.)

La séquence d'échappement \K fait que tous les caractères précédemment matchés ne seront pas inclus dans la séquence matchée, finale. Dans l’exemple:

ConsoleWrite(StringRegExp('abcdef', 'abc\Kdef', 1)[0] & @crlf) ; def

  $regex = "(?x) (abc) \K de(f)"
  _ArrayDisplay(StringRegExp("abcdef", $regex, 4)[0]) ; def

Perl documente l'utilisation de \K dans les assertions en précisant qu’elle "n’est pas bien défini". Dans PCRE, \K est traité quand il apparait à l'intérieur des assertions positives, mais est ignoré dans les assertions négatives. Notez que lorsqu'un modèle comme (?=ab\K) matche, le début rapporté du match peut être plus grand que la fin du match.

L'utilisation finale de l'antislash concerne certaines assertions simples. Une assertion spécifie une condition qui doit être remplie à un point particulier d’un match, sans consommer les caractères de la chaîne sujet. L'utilisation de sous-modèles pour des assertions plus complexes est décrite ci-dessous. Les assertions avec backslash sont:

  \b		matche à la limite d’un mot
  \B 		matche lorsque ce n’est pas la limite d’un mot
  \A 		matche au début  de la chaîne sujet
  \Z 		matche à la fin de la chaîne sujet
			matche aussi avant un saut de ligne à la fin du sujet
  \z 		matche seulement à la fin du sujet
  \G 		matche à la première position du match dans le sujet

Une limite de mot est une position dans la chaîne sujet où le caractère courant et le caractère précédent ne matche pas à la fois \w et \W (i.e. un doit matcher \w et l’autre doit matcher \W), ou le début ou la fin de la chaîne si le premier ou le dernier caractère matche \w, respectivement. Dans un mode UTF, les significations de \w et \W peuvent être modifiés en définissant l'option PCRE_UCP. Lorsque cela est fait, il affecte aussi \b et \B. Ni PCRE, ni Perl disposent de méta-séquence "début de mot" et "fin du mot" différentes. Cependant, quel que soit ce qui suit \b normalement détermine ce qu'il est. Par exemple, le fragment \ba matche "a" au début d'un mot.

Les assertions \A, \Z, et \z diffèrent du circonflexe traditionnel et du caractère dollar (décrit dans la section suivante) en ce sens qu'ils ne matchent jamais au tout début et à la fin de la chaîne sujet, quelles que soient les options qui sont définies. Ainsi, ils sont indépendants du mode multiligne. Ces trois assertions ne sont pas affectées par les options PCRE_NOTBOL ou PCRE_NOTEOL, qui affectent seulement le comportement des métacaractères circonflexe et dollar. Toutefois, si l’argument startOffset de pcre_exec () n’est pas nul, ce qui indique que le match doit commencer à un point autre que le début du sujet, \A ne peut jamais matcher. La différence entre \Z et \z est que \Z matche avant un saut de ligne à la fin de la chaîne, ainsi que tout à la fin, alors que \z matche seulement à la fin.

L'assertion \G est vrai seulement lorsque la position du match actuel est au point de départ du match, comme spécifié par l’argument startOffset de pcre_exec() . Elle se distingue de \A lorsque la valeur de startOffset est non nul. En appelant pcre_exec () plusieurs fois avec des arguments appropriés, vous pouvez imiter l’option /g de Perl, et c’est dans ce genre de mise en œuvre que \G peut être utile.

Notez, cependant, que l'interprétation PCRE de \G, comme le début du match en cours, est subtilement différent de celui de Perl, qui le définit comme la fin du match précédent. En Perl, ceci peut être différent lorsque la chaîne matchée précédemment était vide. Parce que PCRE fait juste un match à la fois, il ne peut pas reproduire ce comportement.

Si toutes les alternatives d'un modèle commencent par \G, l'expression est ancrée à la position de match de départ, et le flag "anchored" est défini dans l'expression régulière compilée.

Circonflexe et dollar

Les métacaractères circonflexe et dollar sont des assertions de largeur nulle. Ce qui signifie qu'ils testent si une condition particulière est vraie sans consommer de caractère dans la chaîne de sujet.

En dehors d'une classe de caractères, dans le mode de match par défaut, le caractère circonflexe est une assertion qui est vraie que si le point de match actuel est au début de la chaîne sujet. Si l’argument startOffset de pcre_exec () n’est pas nul, circonflexe ne peut jamais matcher si l'option PCRE_MULTILINE n’est pas activée. A l'intérieur d'une classe de caractères, circonflexe a un tout autre sens (voir ci-dessous).

Circonflexe n'a pas besoin d'être le premier caractère du modèle si un certain nombre d'alternatives sont impliqués, mais il devrait être le premier de chaque alternative dans laquelle il doit apparaître si le modèle est toujours de matcher cette branche. Si toutes les alternatives possibles commencent avec un circonflexe, ce qui est le cas si le modèle est contraint de matcher seulement au début du sujet, il est déclaré être un modèle "ancré". (Il existe également d'autres constructions qui peuvent faire un modèle ancré.)

Le caractère dollar est une assertion qui est vraie seulement si le point de match en cours est à la fin de la chaîne sujet, ou immédiatement avant un saut de ligne à la fin de la chaîne (par défaut). Dollar ne doit pas être le dernier caractère du modèle si des alternatives sont impliquées, mais il doit être le dernier caractère de chaque branche dans laquelle il doit apparaitre. Dollar n'a pas de signification particulière dans une classe de caractères.

La signification du dollar peut être modifiée afin qu'il matche seulement la fin de la chaîne, en définissant l'option PCRE_DOLLAR_ENDONLY au moment de la compilation. Cela n'a aucune incidence sur l'assertion \Z.

Les significations des caractères circonflexe et dollar sont modifiées si l'option PCRE_MULTILINE est activée. Lorsque tel est le cas, un circonflexe matche immédiatement après des sauts de ligne interne aussi bien qu'au début de la chaîne sujet. Il ne matche pas à la suite d'un saut de ligne qui termine la chaîne. Un dollar matche avant tout saut de ligne dans la chaîne, ainsi que tout à la fin, lorsque PCRE_MULTILINE est activée. Lorsque newline est spécifié comme la séquence de deux caractères CRLF, les caractères CR et LF isolés n’indique pas un saut de ligne.

Par exemple, le modèle ^abc$ matche la chaîne "def\nabc" (où \n représente un saut de ligne) en mode multiligne, mais pas autrement. Par conséquent, les modèles qui sont ancrés en mode ligne unique parce que toutes les branches commencent par ^ ne sont pas ancrés dans le mode multiligne, et un match pour circonflexe est possible lorsque l’argument startOffset de pcre_exec() est non nul. L'option PCRE_DOLLAR_ENDONLY est ignorée si PCRE_MULTILINE est activée.

Notez que les séquences \A, \Z, et \z peuvent être utilisés pour matcher le début et la fin du sujet dans les deux modes, et si toutes les branches d'un modèle commencent par \A, il est toujours ancrée, que PCRE_MULTILINE soit activée ou pas.

En dehors d'une classe de caractères, un point dans un modèle matche un seul caractère dans la chaîne sujet, sauf (par défaut) un caractère qui signifie la fin d'une ligne.

Quand une fin de ligne est définie comme un seul caractère, le point ne matche jamais ce caractère; lorsque la séquence de deux caractères CRLF est utilisée, le point ne matche pas CR si il est immédiatement suivi par LF, mais sinon, il matche tous les caractères (y compris les CRs et LFs isolés). Lorsque les fins de ligne Unicode sont reconnus, le point ne matche pas CR ou LF ou d’autres caractères de fin de ligne.

Le comportement du point à l'égard de newline peut être modifié. Si l'option PCRE_DOTALL est activée, un point matche un seul caractère, sans exception. Si la séquence de deux caractères CRLF est présente dans la chaîne sujet, il faudra deux points pour la matcher.

Le traitement du point est tout à fait indépendant du traitement du circonflexe et dollar, la seule relation est que les deux impliquent un saut de ligne. Le point n'a pas de signification particulière dans une classe de caractères.

La séquence d'échappement \N se comporte comme un point, sauf qu'elle n'est pas affectée par l'option PCRE_DOTALL. En d'autres termes, elle matche tout caractère sauf un caractère qui signifie fin d'une ligne. Perl utilise aussi \N pour matcher des caractères par nom; PCRE ne supporte pas cela.

En dehors d'une classe de caractères, la séquence d'échappement \C matche à toute une unité de données, que ce soit ou non avec un mode UTF activé. Dans la bibliothèque 8 bits, une unité de données est un octet; dans la bibliothèque 16 bits, une unité de 16 bits; dans la bibliothèque 32 bits, une unité de 32 bits. Contrairement au point, \C matche toujours des caractères de fin de ligne. La fonctionnalité est fournie en Perl afin de faire correspondre les octets individuels en mode UTF-8, mais on ne sait pas comment il peut être utilement utilisé. Parce que \C décompose les caractères en unités de données individuelles, matchant une unité avec \C en mode UTF signifie que le reste de la chaîne peut commencer par un caractère UTF malformé. Cela a des résultats imprévus, parce PCRE suppose qu'il traite avec des chaînes UTF valides (et par défaut, il vérifie cela au début du traitement, sauf si l'option PCRE_NO_UTF8_CHECK, PCRE_NO_UTF16_CHECK ou PCRE_NO_UTF32_CHECK est activée).

PCRE n'autorise pas \C dans des assertions arrières (décrites ci-dessous dans un mode UTF, parce que cela rendrait impossible le calcul de la longueur de lookbehind.

En général, il est préférable d'éviter la séquence d'échappement \C. Cependant, une façon de l'utiliser qui permet d'éviter le problème des caractères UTF malformés est d'utiliser un lookahead pour vérifier la longueur du caractère suivant, comme dans ce modèle, qui pourrait être utilisé avec une chaîne UTF-8 (ignorer les espaces et les sauts de ligne):

  (?| (?=[\x00-\x7f])(\C) |
      (?=[\x80-\x{7ff}])(\C)(\C) |
      (?=[\x{800}-\x{ffff}])(\C)(\C)(\C) |
      (?=[\x{10000}-\x{1fffff}])(\C)(\C)(\C)(\C))

Un crochet ouvrant introduit une classe de caractères, terminée par un crochet fermant. Un crochet fermant sur lui-même n'est pas spécial par défaut. Cependant, si l'option PCRE_JAVASCRIPT_COMPAT est définie, un crochet fermant seul provoque une erreur de compilation. Si un crochet de fermeture est nécessaire en tant que membre de la classe, il doit être le premier caractère de données dans la classe (après un circonflexe initial, le cas échéant) ou échappé avec un backslash.

Une classe de caractères matche un seul caractère dans le sujet. Dans un mode UTF, le caractère peut avoir plus d'une unité de données de longueur. Un caractère matché doit être dans le jeu de caractères définis par la classe, à moins que le premier caractère dans la définition de la classe soit un circonflexe, auquel cas le caractère du sujet ne doit pas être dans l'ensemble défini par la classe. Si un circonflexe est nécessaire en tant que membre de la classe, assurez-vous qu'il ne soit pas le premier caractère, ou échappez-le avec un backslash.

Par exemple, la classe de caractères [aeiou] matche toute voyelle minuscule, alors que [^aeiou] matche tout caractère qui n'est pas une voyelle minuscule. Notez qu'un circonflexe est juste une notation pratique pour spécifier les caractères qui sont dans la classe en énumérant ceux qui n'y sont pas. Une classe qui commence par un circonflexe n'est pas une assertion; il consomme encore un caractère de la chaîne sujet, et donc il échoue si le pointeur courant est à la fin de la chaîne.

En mode UTF-8 (UTF-16, UTF-32), des caractères avec des valeurs supérieures à 255 (0xffff) peuvent être inclus dans une classe comme une chaîne littérale d'unités de données, ou en utilisant le mécanisme d'échappement \x{ .

Lorsque le match est défini insensible à la casse, toutes les lettres dans une classe représentent à la fois les versions majuscules et minuscules, de sorte que par exemple, [aeiou] matche "A" ainsi que "a", et [^aeiou] ne matche pas "A", alors qu'une version sensible à la casse le ferait. Dans un mode UTF, PCRE comprend toujours le concept de casse pour les caractères dont les valeurs sont inférieures à 128, donc un match insensible à la casse est toujours possible. Pour les caractères avec des valeurs plus élevées, le concept de casse est pris en charge si PCRE est compilé avec le support de propriété Unicode, mais pas autrement. Si vous voulez utiliser un match insensible à la casse en mode UTF pour les caractères 128 et au-dessus, vous devez vous assurer que PCRE est compilé avec le support de propriété Unicode, ainsi qu'avec le support UTF.

Les caractères qui pourraient indiquer les sauts de ligne ne sont jamais traités d'une manière particulière lors du match des classes de caractères, quelle que soit la séquence de fin de ligne en cours d'utilisation, et quel que soit le réglage des options PCRE_DOTALL et PCRE_MULTILINE. Une classe telle que [^a] matche toujours un de ces caractères.

Le caractère moins (tiret) peut être utilisé pour spécifier une plage de caractères dans une classe de caractères. Par exemple, [d-m] matche toute lettre entre d et m inclus. Si un caractère moins est nécessaire dans une classe, il doit être échappé avec un backslash ou apparaitre dans une position où il ne peut pas être interprétée comme indiquant une plage, généralement comme le premier ou le dernier caractère de la classe, ou immédiatement après une plage. Par exemple, [b-d-z] matche les lettres entre b et d, le caractère tiret, ou z.

Il est impossible d'avoir le caractère littéral "]" comme caractère de fin d'une plage. Un modèle tel que [W-\]46] est interprété comme une classe de deux caractères ("W" et "-") suivi d'une chaîne littérale "46]", il matche "W46]" ou "-46]". Toutefois, si le "]" est échappé avec un backslash il est interprété comme la fin de la plage, donc [W-\]46] est interprété comme une classe contenant une plage suivie par deux autres caractères. La représentation octale ou hexadécimale de "]" peut également être utilisé pour terminer une plage.

Une erreur est levée si une classe de caractère POSIX (voir ci-dessous) ou une séquence d'échappement autre que celle qui définit un seul caractère apparaît à un point où un caractère de fin de plage est attendu. Par exemple, [z-\xff] est valable, mais [A-\d] et [A-[:digit:]] ne le sont pas.

Les plages fonctionnent dans l'ordre de classement des valeurs de caractères. Elles peuvent également être utilisées pour des caractères spécifiés numériquement, par exemple [\000-\037]. Les plages peuvent inclure tous les caractères qui sont valides pour le mode actuel.

Si une plage qui comprend des lettres est utilisée lors d'un match insensible à la casse, il matche les lettres dans les deux cas. Par exemple, [W-c] est équivalent à [][\\^_`wxyzabc], défini insensible à la casse, et dans un mode non-UTF, si les tables de caractères pour une locale French sont en cours d'utilisation, [\xc8-\xcb] matche les caractères accentués E dans les deux cas. Dans les modes UTF, PCRE soutient le concept de casse pour les caractères avec des valeurs supérieures à 128 seulement quand il est compilé avec le support de propriété Unicode.

Les séquences d'échappement de caractère \d, \D, \h, \H, \p, \P, \s, \S \v, \V, \w et \W peuvent apparaître dans une classe de caractères, et ajouter les caractères qui matchent à la classe. Par exemple, [\dABCDEF] matche tous chiffres hexadécimal. Dans les modes de UTF, l'option PCRE_UCP affecte les significations de \d, \s, \w et leurs partenaires majuscules, comme c'est le cas quand ils apparaissent en dehors d'une classe de caractères, tel que décrit dans la section intitulée "Types de caractères génériques" ci-dessus. La séquence d'échappement \b a une signification différente à l'intérieur d'une classe de caractères; elle matche le caractère backspace. Les séquences \B, \N, \R et \X ne sont pas spéciales à l'intérieur d'une classe de caractères. Comme toutes les autres séquences d'échappement non reconnus, elles sont traités comme des caractères littéraux "B", "N", "R", et "X" par défaut, mais provoquent une erreur si l'option PCRE_EXTRA est installée.

Un circonflexe peut être utilisé avec les types de caractères majuscules pour spécifier un ensemble plus restreint de caractères que le type minuscule. Par exemple, la classe [^\W_] matche une lettre ou un chiffre, mais pas le caractère de soulignement, alors que [\w] inclut le soulignement. Une classe de caractère positif doit être lu comme "quelque chose ou quelque chose ou ..." et une classe négative comme "pas quelque chose et pas quelque chose et pas ...".

Les seuls métacaractères qui sont reconnus dans les classes de caractères sont backslash, tiret (seulement où il peut être interprété comme spécifiant une plage), circonflexe (seulement au début), crochet ouvrant (seulement quand il peut être interprété comme l'introduction d'un nom de classe POSIX, ou des raisons de compatibilité spéciales - voir les deux sections suivantes), et le crochet fermant de terminaison. Cependant, en échappant d'autres caractères non alphanumériques ne fait aucun mal.

Perl supporte la notation POSIX pour les classes de caractères. Il utilise des noms entourés par [: et :] à l'intérieur de crochets englobant. PCRE soutient également cette notation. Par exemple,

  [01[:alpha:]%]

_ArrayDisplay(StringRegExp("012aAB%çéà=", "[01[:alpha:]%]", 3))

  alnum    lettres et chiffres
  alpha    lettres
  ascii    codes de caractère 0 - 127
  blank    espace ou tabulation seulement
  cntrl    caractères de contrôle
  digit    chiffres décimaux (comme \d)
  graph    caractères graphiques, sauf espace
  lower    lettres minuscules
  print    caractères affichables, y compris espace
  punct    caractères affichables, non compris les lettres, les chiffres et l'espace
  space    espaces blancs (comme \s à partir de PCRE 8.34)
  upper    lettres majuscules
  word     caractères "word" (comme \w)
  xdigit   chiffres hexadécimaux

Le nom "word" est une extension Perl, et "blank" est une extension GNU à partir de Perl 5.8. Une autre extension Perl est la négation, qui est indiquée par le caractère ^ après les deux points. Par exemple,

  [12[:^digit:]]

_ArrayDisplay(StringRegExp("012aAB%çéà=:", "[12[:^digit:]]", 3))

Par défaut, les caractères avec des valeurs supérieures à 128 ne matchent à aucune classe de caractère POSIX. Cependant, si l'option PCRE_UCP est activée, certaines classes sont modifiées pour que les propriétés des caractères Unicode soient utilisées. Ceci est réalisé en remplaçant certaines classes POSIX par d'autres séquences, comme il suit:

  [:alnum:]  devient  \p{Xan}
  [:alpha:]  devient  \p{L}
  [:blank:]  devient  \h
  [:digit:]  devient  \p{Nd}
  [:lower:]  devient  \p{Ll}
  [:space:]  devient  \p{Xps}
  [:upper:]  devient  \p{Lu}
  [:word:]   devient  \p{Xwd}

_ArrayDisplay(StringRegExp("ÉEéçab:1", "(*UCP)[12\p{Lu}]", 3))

[:graph:] Elle matche les caractères qui ont des glyphes qui marquent la page lors de l'impression. En termes de propriété Unicode, elle matche tous les caractères avec les propriétés L, M, N, P, S ou Cf, à l'exception de:

  U+061C           Arabic Letter Mark
  U+180E           Mongolian Vowel Separator
  U+2066 - U+2069  Various "isolate"s

[:print:] Elle matche les mêmes caractères que [:graph:] plus les caractères Space qui ne sont pas des contrôles, c'est-à-dire, des caractères avec la propriété Zs.

[:punct:] Elle matche tous les caractères qui ont la propriété Unicode P (Ponctuation), plus les caractères dont le code est inférieur à 128 qui ont la propriété S (Symbol).

Les autres classes POSIX sont inchangées, et matchent seulement les caractères avec un code inférieur à 128.

Dans la bibliothèque compatible POSIX.2 qui a été incluse dans 4.4BSD Unix, la syntaxe laide [[:<:]] et [[:>:]] est utilisée pour un match au "début de mot" et "fin de mot". PCRE traite ces éléments comme il suit:

  [[:<:]]  est converti en  \b(?=\w)
  [[:>:]]  est converti en  \b(?<=\w)

Le caractère Barre verticale est utilisé pour séparer des modèles alternatifs. Par exemple, le modèle

  gilbert|sullivan

Les paramètres d'options PCRE_CASELESS, PCRE_MULTILINE, PCRE_DOTALL, et PCRE_EXTENDED (qui sont compatibles Perl) peuvent être activés à l'intérieur du modèle par une séquence de lettres d'option Perl encadrées entre "(?" and ")". Les lettres d'option sont:

  i  pour PCRE_CASELESS
  m  pour PCRE_MULTILINE
  s  pour PCRE_DOTALL
  x  pour PCRE_EXTENDED

D'autres options spécifiques PCRE peuvent être modifiées de la même façon que les options compatibles Perl:

   J  pour PCRE_DUPNAMES
   U  pour PCRE_UNGREEDY
   X  pour PCRE_EXTRA

Lorsque l'une de ces options de changement apparait au plus haut niveau (c’est-à-dire, pas à l’intérieur des parenthèses d’un sous-modèle), le changement s'applique au reste du modèle qui suit.

Un changement d'option à l'intérieur d'un sous-modèle (voir ci-dessous pour une description de sous-modèle) affecte uniquement la partie du sous-modèle qui la suit, ainsi:

  (a(?i)b)c

  (a(?i)b|c)

_ArrayDisplay(StringRegExp("abaBcC", "(a(?i)b|c)", 3))

Remarque: Il existe d'autres options spécifiques à PCRE qui peuvent être activées par l'application lorsque les fonctions de compilation ou de match sont appelés. Dans certains cas, le modèle peut contenir des séquences d’entête spéciales telle que (*CRLF) pour surcharger ce que l'application a établi ou ce qui a été fait par défaut. Des détails sont donnés dans la section intitulée "Séquences Newline" ci-dessus. Il y a aussi les séquences d’entête (*UTF8), (*UTF16),(*UTF32) et (*UCP) qui peuvent être utilisées pour définir les modes UTF et Unicode; elles sont équivalentes à la définition des options PCRE_UTF8, PCRE_UTF16, PCRE_UTF32 et PCRE_UCP, respectivement. La séquence (*UTF) est une version générique qui permet d'utiliser bibliothèques.

Les sous-modèles sont délimités par des parenthèses, qui peuvent être imbriquées. La transformation d’une partie d'un modèle en un sous-modèle sert à deux choses:

1. Localiser un ensemble d’alternatives. Par exemple, le modèle:

   cat(amaran|astrophe|)

Les parenthèses ouvrantes sont comptées de gauche à droite (à partir de 1) pour affecter des numéros aux sous-modèles capturés. Par exemple, le modèle:

  le ((roi |valet )(noir|rouge))

_ArrayDisplay(StringRegExp("le roi rouge ou noir", "le ((roi |valet )(noir|rouge))", 3))

Le fait que de simples parenthèses remplissent deux fonctions n’est pas toujours utile. Il y a souvent des cas où un regroupement en sous-modèle est nécessaire, sans qu’il soit besoin d’effectuer des captures. Si une parenthèse ouvrante est suivie d'un point d'interrogation et du caractère ‘:’ , le sous-modèle ne fait pas de capture, et n’est pas compté dans le calcul des numéros des séquences de capture. Par exemple, le modèle:

  le ((roi |valet )(?:noir|rouge))

  _ArrayDisplay(StringRegExp("le roi rouge ou noir", "le ((roi |valet )(?:noir|rouge))", 3))

En guise de raccourci pratique, si des paramètres d'option sont nécessaires au début d'un sous-modèle non capturant, les lettres d'option peuvent apparaître entre le "?" et le ":". Ainsi, les deux modèles (dans lesquels il convient d’ignorer les espaces qui ne sont présents que pour la lisibilité):

  (?i: samedi | dimanche)
  (?: (?i) samedi | dimanche)

  _ArrayDisplay(StringRegExp("saMEdi, DIMANCHE, lundi", "(?i:samedi|dimanche)", 3))

Perl 5.10 introduit un concept dans lequel chaque alternative d’un sous-modèle utilise les mêmes numéros pour ses parenthèses capturantes. Un tel sous-modèle commence par (?| et est lui-même un sous-modèle non capturant. Par exemple, considérez ce modèle:

  (?|(Mer)cre|(Jeu))di

  # before  ---------------branch-reset----------- after
    ( a )  (?| x ( y ) z | (p (q) r) | (t) u (v) ) ( z )
  # 1            2         2  3        2     3     4

Preuve:
msgbox(0,"",StringRegExpReplace("apqrz", "(a)(?|x(y)z|(p(q)r)|(t)u(v))(z)", "1:\1 2:\2 3:\3 4:\4"))

  $regex = "(?|(abc)|(def))\1"
  $array = StringRegExp("abcabcdefdef", $regex, 4)
  _ArrayDisplay($array[0])
  _ArrayDisplay($array[1])

  $regex = "(?|(abc)|(def))(?1)"
  $array = StringRegExp("abcabcdefabc", $regex, 4)
  _ArrayDisplay($array[0])
  _ArrayDisplay($array[1])

Une approche alternative pour l'utilisation de la fonctionnalité "réinitialisation sur les branches" consiste à utiliser des sous-modèles nommés dupliqués, comme décrit dans la section suivante.

L’identification des parenthèses capturantes par un numéro est simple, mais elle peut être très difficile de garder la trace des numéros dans les expressions régulières complexes. En outre, si une expression est modifiée, les numéros peuvent changer. Pour aider à cette difficulté, PCRE propose de nommer les sous-modèles. Ce concept a été ajouté à Perl à la version 5.10. Python a intégré cette fonctionnalité plus tôt, et PCRE la introduite à la version 4.0, en utilisant la syntaxe Python. PCRE prend désormais en charge la syntaxe Perl et Python. Perl permet à des sous-modèles de même numéro d'avoir des noms différents, mais pas PCRE.

En PCRE, un sous-modèle peut être nommé de l'une des trois façons suivantes: (?<name>...) ou (?'name'...) comme en Perl, ou (?P<name>...) comme en Python. Les références aux parenthèses capturantes à partir d'autres parties du modèle, dans les références arrières, dans la récursivité et dans les conditions, peuvent être faites par nom, aussi bien que par numéro.

Les noms peuvent comporter jusqu'à 32 caractères alphanumériques ainsi que le caractère de soulignement mais doivent commencer par un caractère qui n'est pas un chiffre. Les parenthèses capturantes nommés sont toujours affectés de numéro ainsi que de nom, exactement comme si les noms n’étaient pas présents. L'API PCRE fournit des appels de fonction pour extraire la table de traduction nom vers numéro à partir d'un modèle compilé. Il y a aussi une fonction pratique pour l'extraction d'une sous-chaîne capturée par son nom.

La fonctionnalité suivante ne peut pas être activée dans AutoIt.

Par défaut, un nom doit être unique dans un modèle, mais il est possible de s’affranchir de cette contrainte en définissant l'option PCRE_DUPNAMES (?J) en début de modèle. (Les doublons sont également toujours autorisés pour des sous-modèles avec le même numéro, comme décrit dans la section précédente). Dupliquer les noms peut être utile pour des modèles où une seule instance de parenthèses nommées peut matcher. Supposons que vous vouliez matcher le nom d'un jour de la semaine, soit comme une abréviation à 3 lettres soit comme un nom complet, et dans les deux cas que vous vouliez extraire l'abréviation. Ce modèle (en ignorant les sauts de ligne) fait le travail:

$regex = '(?Jix)' & _
  '(?<Jour>Lun|Mar|Jeu)(?:di)? | ' & _
  '(?<Jour>Mer)(?:credi)? | ' & _
  '(?<Jour>Ven)(?:dredi)? | ' & _
  '(?<Jour>Sam)(?:edi)? | ' & _
  '(?<Jour>Dim)(?:anche)?'

$sujet = 'Lun Mardi Mercredi jeudi Ven Sam dimanche'
$arr = StringRegExp($sujet, $regex, 4)
For $i=0 to 6
    _ArrayDisplay($arr[$i])
Next

La fonction pratique pour l'extraction de données par nom retourne la sous-chaîne du premier (et, dans cet exemple, le seul) sous-modèle de ce nom qui matche. Cela permet d'économiser la recherche pour trouver lequel du sous-modèle il était.

Si vous faites une référence arrière à un sous-modèle nommé non unique à partir d’un autre endroit du modèle, les sous-modèles auquel le nom se réfère sont examinés dans l'ordre dans lequel ils apparaissent dans le modèle global. Le premier qui est défini est utilisé pour la référence. Par exemple, ce modèle matche à la fois "aa" et "bb" mais pas "ab" ou "ba":

  $regex = "(?<n>(a|b))\g{n}"
  msgbox(0,"",StringRegExp("aa", $regex, 0))
  msgbox(0,"",StringRegExp("bb", $regex, 0))
  msgbox(0,"",StringRegExp("ab", $regex, 0))
  msgbox(0,"",StringRegExp("ba", $regex, 0))

Si vous effectuez un appel de sous-programme à un sous-modèle dont le nom n'est pas unique, celui qui correspond à la première occurrence du nom est utilisé. En l'absence de numéro doublon (voir la section précédente) c'est celui avec le plus petit numéro.

Si vous utilisez une référence nommée dans un test de condition (voir la section sur les conditions ci-dessous), soit pour vérifier si un sous-modèle a matché, soit pour vérifier une récursivité, tous les sous-modèles du même nom sont testés. Si la condition est vraie pour l'un d'entre eux, la condition générale est vraie. C'est le même comportement que les tests avec les numéros. Pour plus de détails sur les interfaces pour traiter les sous-modèles nommés, voir la documentation pcreapi.

Attention: Vous ne pouvez pas utiliser des noms différents pour distinguer entre deux sous-modèles avec le même numéro, car PCRE utilise uniquement les numéros lors des matchs. Pour cette raison, une erreur est donnée au moment de la compilation si des noms différents sont donnés à des sous-modèles qui ont le même numéro. Cependant, vous pouvez donner le même nom à des sous-modèles qui ont le même numéro, même lorsque PCRE_DUPNAMES n’est pas définie.

Les répétitions sont spécifiées par des quantificateurs, qui peuvent suivre l'un des éléments suivants:

  un caractère littéral
  le métacaractère point
  la séquence d'échappement \C
  la séquence d'échappement \X
  la séquence d'échappement \R
  un échappement comme \d ou \pL qui matche un seul caractère
  une classe de caractères
  une référence arrière (voir la section suivante)
  un sous-modèle parenthésé (y compris les assertions)
  un appel à un sous-programme d’un sous-modèle (récursif ou autre)

  z{2,4}

  [aeiou]{3,}

  \d{8}

Dans les modes UTF, les quantificateurs s’appliquent aux caractères plutôt qu’aux unités de données individuelles. Ainsi, par exemple, \x{100}{2} matche deux caractères, dont chacun est représenté par une séquence de deux octets dans une chaîne de caractères UTF-8. De même, \X{3} matche trois granules de graphèmes étendus Unicode, chacune d'elle pouvant être des unités de données de plusieurs longueur (et elles peuvent être de longueurs différentes).

Le quantificateur {0} est autorisé, mais l'expression se comporte comme si l'élément précédent et le quantificateur n’étaient pas présents. Cela peut être utile pour des sous-modèles qui sont référencés comme des sous-programmes provenant d'ailleurs dans le modèle (mais voir aussi la section intitulée "Définition des sous-modèles pour une utilisation par référence" ci-dessous). Les éléments autres que des sous-modèles qui ont un quantificateur {0} sont omis du modèle compilé.

Pour plus de commodité, les trois quantificateurs les plus courants ont des abréviations à caractère unique:

  * 	est équivalent à {0,}
  + 	est équivalent à {1,}
  ? 	est équivalent à {0,1}

  (a?)*

Par défaut, les quantificateurs sont "gourmands", ce qui veut dire qu’ils matchent autant que possible (jusqu'au nombre maximal de fois autorisés), sans provoquer un échec du reste du modèle. L'exemple classique où cela pose des problèmes est en essayant de matcher les commentaires de programmes C. Ils apparaissent entre /* et */ et dans un commentaire, les caractères * et / individuel peuvent apparaître. Une tentative pour matcher les commentaires C en appliquant le modèle:

  /\*.*\*/

  /* Premier commentaire */ pas de commentaire /* second commentaire */

Toutefois, si un quantificateur est suivi d'un point d'interrogation, il cesse d'être gourmand, et à la place matche un nombre minimum de fois possibles, de sorte que le modèle :

  $regex = "/\*.*?\*/"
 _ArrayDisplay(StringRegExp("/*rem1*/x=1/*rem2*/", $regex, 4)[0])
 _ArrayDisplay(StringRegExp("/*rem1*/x=1/*rem2*/", $regex, 4)[1])

  $regex = "a\d??\db" ; ?? = 0 ou 1 frugal
  _ArrayDisplay(StringRegExp("a1b", $regex, 4)[0])
  _ArrayDisplay(StringRegExp("a23b", $regex, 4)[0])

Si l'option PCRE_UNGREEDY (?U) est activée (une option qui n’est pas disponible en Perl), les quantificateurs ne sont pas gourmands par défaut, mais un quantificateur particulier peut être gourmand en le faisant suivre d’un point d'interrogation. En d'autres termes, l’option inverse le comportement par défaut.

Quand un sous-modèle parenthésé est quantifié avec un nombre minimal de répétitions qui est supérieur à 1 ou avec une limite maximale, davantage de mémoire est nécessaire pour le modèle compilé, proportionnellement à la taille de la valeur minimale ou maximale.

Si un modèle commence par .* ou .{0,} et si l'option PCRE_DOTALL (?s) (équivalent au /s de Perl) est activée, permettant ainsi au point de matcher les newlignes, le modèle est implicitement ancré, parce que tout ce qui suit sera testé à chaque position de caractère de la chaîne sujet, aussi il n'y a pas de point dans la nouvelle tentative de match global avec n’importe quelle position après la première. PCRE traite normalement un tel modèle comme si il était précédé par \A.

Dans les cas où l'on sait que la chaîne sujet ne contient pas de newligne, il est équivalent d’activer PCRE_DOTALL afin d'obtenir cette optimisation, ou encore d’utiliser ^ pour indiquer l’ancrage explicitement.

Cependant, il existe quelques cas dans lesquels l'optimisation ne peut pas être utilisée. Lorsque .* est à l'intérieur de parenthèses de capture qui font l'objet d'une référence arrière ailleurs dans le modèle, un match au début peut échouer, alors qu’un match ultérieure peut réussir. Considérons, par exemple:

$regex = "(.*)abc\1"
  _ArrayDisplay(StringRegExp("xyz123abc123", $regex, 4)[0])

Un autre cas où l'ancrage implicite n'est pas appliqué est celui où le préfixe .* est à l'intérieur d'un groupe atomique. Encore une fois, un match au début peut échouer alors qu'un match plus loin peut réussir. Considérez ce modèle:

  $regex = "(?>.*?a)b"
  _ArrayDisplay(StringRegExp("aab", $regex, 4)[0])

Quand un sous-modèle capturant est répété, la valeur capturée est la sous-chaîne qui est matchée à la dernière itération. Par exemple, après que:

  $regex = "(tweedle[dume]{3}\s*)+"
  _ArrayDisplay(StringRegExp("tweedledum tweedledee", $regex, 4)[0])

  $regex = "(a|(b))+"
  _ArrayDisplay(StringRegExp("aba", $regex, 4)[0])

En maximisant ("gourmand") et en minimisant ("frugal"), en même temps, les répétitions, l'échec de ce qui suit entraine normalement que l'élément répété sera réévalué pour voir si un nombre différent de répétitions permet au reste du modèle de matcher. Parfois, il est utile d'empêcher cela, soit en changeant la nature du match, soit en provoquant son échec plus tôt qu'il ne le ferait autrement, lorsque l'auteur du modèle sait qu'il ne sert à rien de continuer.

  \d+foo

Si nous utilisons le groupement atomique dans l'exemple précédent, le moteur renonce immédiatement à matcher "foo" à la suite du premier échec. La notation est une sorte de parenthèse spéciale, qui commence par (?> comme dans cet exemple:

  (?>\d+)foo

Une autre description est qu’un sous-modèle de ce type matche la chaîne de caractères qu'un modèle autonome identique devrait matché, s’il était ancré au point courant dans la chaîne sujet.

Le groupement atomique des sous-modèles ne font pas des sous-modèles capturants. Des cas simples tels que l'exemple ci-dessus peut être considéré comme une répétition qui maximise et qui doit avaler tout ce qu'elle peut. Donc, alors que les deux \d+ et \d+? sont prêts à ajuster le nombre de chiffres qu'ils matchent afin de faire matcher le reste du modèle, (?>\d+) ne peut matcher qu'une séquence entière de chiffres.

Les groupes atomiques, en général, peuvent bien entendu contenir des sous-modèles arbitrairement complexes, et peuvent être imbriquées. Cependant, lorsque le sous-modèle d'un groupe atomique est juste un élément isolé répété, comme dans l'exemple ci-dessus, une notation simple, appelée "quantificateur possessif" peut être utilisé. Elle consiste en un caractère supplémentaire + à la suite d’un quantificateur. En utilisant cette notation, l'exemple précédent peut être réécrit comme:

  \d++foo

  (abc|xyz){2,3}+

La syntaxe de quantificateur possessif est une extension de la syntaxe 5.8 Perl. Jeffrey Friedl origine de l'idée (et du nom) dans la première édition de son livre. Mike McCloskey l’a aimé, donc implémenté quand il a construit Java, le paquage de Sun, et PCRE l’a copié à partir de là. Elle a finalement été intégrée dans Perl à la version 5.10.

PCRE a une optimisation qui rend possessif automatiquement certaines constructions simples de modèle. Par exemple, la séquence A+B est traitée comme A++B parce qu'il n'y a pas de point de backtracking dans une séquence de A quand B doit suivre.

Quand un modèle contient une répétition illimitée à l'intérieur d'un sous-modèle, qui peut lui-même être répétée un nombre illimité de fois, l'utilisation d'un groupe atomique est la seule façon d'éviter que des matchs en cours d’échec prennent un temps très long. Le modèle:

  $regex = "(\D+|?<\d+?>)*[!?]"
  _ArrayDisplay(StringRegExp("abc!?", $regex, 4)[0])
  _ArrayDisplay(StringRegExp("?<123?>!?", $regex, 4)[0])
  _ArrayDisplay(StringRegExp("aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa!?", $regex, 4)[0])

  ((?>\D+)|?<\d+?>)*[!?]

En dehors d'une classe de caractère, un antislash suivi d'un chiffre strictement supérieur à 0 (et éventuellement d'autres chiffres) est une référence arrière à un sous-modèle capturant qui précéde, à condition qu'il y ait eu suffisamment de parenthèses gauches capturantes.

Exemple: déterminer si un nombre est premier.
Le modèle suivant (en ignorant les espaces):

    ^(..+?) \1+ $

Not StringRegExp(_StringRepeat('-', $n), '^.$|^(..+?)\1+$')

Si le nombre qui suit le backslash est strictement inférieur à 10, il est toujours considéré comme une référence arrière, et provoque une erreur seulement s'il n'y a pas le nombre de parenthèses gauches capturantes dans le modèle entier. En d'autres termes, les parenthèses qui sont référencés ne sont pas nécessairement à la gauche de la référence pour les nombres inférieurs à 10. Une "référence arrière postérieure" de ce type peut prendre un sens quand une répétition est concernée et que le sous-modèle à la droite a participé à une itération antérieure.

Il est impossible d'avoir une "référence arrière postérieure" numérique à un sous-modèle dont le nombre est 10 ou davantage, en utilisant cette syntaxe, car une séquence telle que \50 est interprété comme un caractère défini en octal. Voir la sous-section intitulée "Caractères non-imprimables" ci-dessus pour plus de détails sur l’utilisation de chiffres derrière un backslash. Il n'y a pas de problème quand des parenthèses nommées sont utilisées. Une référence arrière à un sous-modèle est possible en utilisant des parenthèses nommées (voir ci-dessous).

Une autre façon d'éviter l'ambiguïté inhérente à l'utilisation de chiffres suivant un backslash consiste à utiliser la séquence d'échappement \g. Cet échappement doit être suivi par un nombre non signé ou un nombre négatif, facultativement entre accolades. Ces exemples sont tous identiques:

  (ring), \1
  (ring), \g1
  (ring), \g{1}

  $regex = "(abc(def)ghi)\g{-1}"
  _ArrayDisplay(StringRegExp("abcdefghidef", $regex, 4)[0])
  Msgbox(0,"",StringRegExp("abcdefghiabc", $regex, 0))

Une référence arrière matche quel que soit le sous-modèle capturant qui matche actuellement dans la chaîne sujet, plutôt que quelque chose en train de matcher le sous-modèle lui-même (voir ci-dessous "Sous-modèles en tant que sous-programmes" pour une façon de faire ça). Donc, le modèle:

  $regex = "(perplex|complex)e et \1ité"
  Msgbox(0,"",StringRegExp("perplexe et perplexité", $regex, 0))
  Msgbox(0,"",StringRegExp("complexe et complexité", $regex, 0))
  Msgbox(0,"",StringRegExp("perplexe et complexité", $regex, 0))

  $regex = "((?i)abc)\s+\1"
  Msgbox(0,"",StringRegExp("abc abc", $regex, 0))
  Msgbox(0,"",StringRegExp("ABC ABC", $regex, 0))
  Msgbox(0,"",StringRegExp("abc ABC", $regex, 0))

Il existe plusieurs façons différentes d’écrire les références arrière à un sous-modèles nommés. La syntaxe .NET, \k{name} et la syntaxe Perl \k ou \k'name' sont prises en charge, de même que la syntaxe Python (?P=name). La syntaxe des référence arrières unifiées de Perl 5.10, dans laquelle \g peut être utilisé aussi bien pour les références numériques que nommées, est également prises en charge. Nous pouvons réécrire l'exemple ci-dessus de l'une quelconque des manières suivantes:

  (?<p1>(?i)abc)\s+\k<p1>
  (?'p1'(?i)abc)\s+\k{p1}
  (?P<p1>(?i)abc)\s+(?P=p1)
  (?<p1>(?i)abc)\s+\g{p1}

Il peut y avoir plus d'une référence arrière au même sous-modèle. Si un sous-modèle n'a pas été effectivement utilisé dans un match particulier, toutes les références arrière le concernant échoueront toujours, par défaut. Par exemple, le modèle:

  (a|(bc))\2

Une référence arrière qui se produit à l'intérieur des parenthèses auxquelles elle se réfère échoue lorsque le sous-modèle est utilisé en premier, donc, par exemple, (a\1) ne matche jamais. Toutefois, ces références peuvent être utiles à l'intérieur des sous-modèles répétées. Par exemple, le modèle:

  $regex = "(a|b\1)+"
  _ArrayDisplay(StringRegExp("aba", $regex, 4)[0])

Les références arrières de ce type traitent le groupe auquel elles font référence comme un groupe atomique. Une fois que l'ensemble du groupe a été matché, un échec de match ultérieur ne peut pas provoquer de retour en arrière au milieu du groupe.

Une assertion est un test sur les caractères qui suivent ou qui précèdent le point de match courant qui ne consomme pas de caractère. Les assertions simples codées \b, \B, \A, \G, \Z, \z, ^ et $ sont décrites ci-dessus.

Les assertions plus complexes sont codées comme des sous-modèles. Il en existe de deux types: celles qui regardent vers l’avant de la position actuelle dans la chaîne sujet, et celles qui regardent vers l’arrière. Un sous-modèle assertion est matché de façon normale, sauf que la position actuelle du match n’est pas modifiée.

Les sous-modèles assertions ne sont pas des sous-modèles capturants. Si une telle assertion contient des sous-modèles capturants en son sein, ils sont comptés pour les besoins de la numérotation des sous-modèles capturants dans le modèle entier. Cependant, la capture d’une sous-chaîne est effectuée uniquement pour les assertions positives (Perl quelquefois, mais pas toujours, fait des captures d'assertions négatives.)

Pour la compatibilité avec Perl, les sous-modèles assertions peuvent être répétés; mais cela n'a aucun sens d'affirmer la même chose à plusieurs reprises, l'effet de bord des parenthèses capturantes peut parfois être utile. Dans la pratique, il n'y a que trois cas:

(1) Si le quantificateur est {0}, l'assertion n’est jamais satisfaite lors d’un match. Cependant, elle peut contenir des groupes de parenthèses capturantes internes qui sont appelées d’ailleurs via le mécanisme de sous-routine.

(2) Si le quantificateur est {0, n}, où n est supérieur à zéro, l‘assertion est traitée comme si elle était {0,1}. Au moment de l'exécution, le reste du modèle est essayé avec et sans l'assertion, l'ordre dépendant de la gourmandise du quantificateur.

(3) Si la répétition minimale est supérieure à zéro, le quantificateur est ignorée. L'assertion est satisfaite juste une fois lorsqu’un match est rencontré.

Une assertion lookahead POSITIVE est un sous-modèle qui énonce une condition qui DOIT être satisfaite par le match en cours mais qui concerne les caractères qui suivent le point courant de match. Alors qu'une lookahead NEGATIVE énonce une condition qui NE DOIT PAS être satisfaite par le match.

Les assertions lookahead commencent par (?= pour les assertions positives et par (?! pour les assertions négatives. Par exemple:

  \w+(?=;)

  foo(?!bar)

  (?!foo)bar

Si vous voulez forcer un échec du match à un certain point dans un modèle, la façon la plus pratique de le faire est avec (?!), car une chaîne vide matche toujours, donc une assertion qui exige qu'il n'y ait pas de chaîne vide échoue toujours. Le verbe de contrôle backtracking (*FAIL) ou (*F) est un synonyme pour (?!).

Une assertion lookbehind POSITIVE est un sous-modèle qui énonce une condition qui DOIT être satisfaite par le match en cours mais qui concerne les caractères qui précèdent le point courant de match. Alors qu'une lookbehind NEGATIVE énonce une condition qui NE DOIT PAS être satisfaite par le match.

Les assertions Lookbehind commence par (?<= pour les assertions positives et (?<! pour les assertions négatives. Par exemple:

  (?<!foo)bar

   (?<=bullock|donkey)

   (?<!dogs?|cats?)

  (?<=ab(c|de))

  (?<=abc|abde)

La mise en œuvre des assertions lookbehind consiste, pour chaque alternative, à déplacer temporairement la position courante vers l’arrière d’une longueur fixée, puis d’essayer de matcher. S’il y a insuffisamment de caractères avant la position courante, l'assertion échoue.

Dans le mode UTF, PCRE ne permet pas l'échappement \C (qui matche une unité de données seule, même dans le mode UTF) dans les assertions lookbehind, car il est impossible de calculer la longueur d’où il faut regarder en arrière. Les échappements \X et \R, qui peuvent matcher différents nombres d'unités de données, ne sont également pas autorisés.

Les appels de "sous-routine" (voir ci-dessous) tels que (?2) ou (?&X) sont autorisés dans les assertions lookbehind, dans la mesure où le sous-modèle matche une chaîne de longueur fixe. Cependant, la récursivité n’est pas prise en charge.

Les quantificateurs possessifs peuvent être utilisés conjointement avec des assertions lookbehind pour spécifier un match efficace des chaînes de longueur fixe à la fin des chaînes sujet. Considérons un modèle simple comme:

  abcd$

  ^.*abcd$

  ^.*+(?<=abcd)

Plusieurs assertions (de toute sorte) peuvent apparaitre dans la succession. Par exemple,

  (?<=\d{3})(?<!999)foo

  (?<=\d{3}...)(?<!999)foo

Les assertions peuvent être imbriquées dans une combinaison quelconque. Par exemple,

  (?<=(?<!foo)bar)baz

  (?<=\d{3}(?!999)...)foo

Le code AutoIt suivant matche au moins deux espaces consécutifs mais seulement s'ils apparaissent immédiatement après un '.' et avant une lettre majuscule. Il remplace chaque série d'espace trouvé par un seul espace.

  $regex  = "(?<=\.) {2,}(?=[A-Z])"
  $string = "Phrase1.   Phrase2."
  $string = StringRegExpReplace($string, $regex, " ")
  msgbox(0, "", $string)

Il est possible de définir le processus de match pour qu’il satisfasse à un sous-modèle conditionnel ou pour choisir entre deux sous-modèles alternatifs, suivant le résultat d'une assertion, ou si un sous-modèle de capture spécifique a déjà été matché. Les deux formes possibles d’un sous-modèle conditionnel sont:

  (?(condition) modèle_1)
  (?(condition) modèle_1 | modèle_2)

  (?(1) (A|B|C) | (D |(?(2)E|F) | E) )

Il existe quatre sortes de conditions: les références à des sous-modèles, les références à la récursivité, une pseudo-condition appelée DEFINE et les assertions.

Si le texte entre parenthèses est une séquence de chiffres, la condition est vraie si un sous-modèle capturant de ce numéro a précédemment matché. S'il y a plus d'un sous-modèle capturant avec le même numéro (voir la section précédente sur les numéros en double des sous-modèles), la condition est vraie si l'un d'entre eux a matché. Une notation alternative accepte un signe plus ou moins devant les chiffres. Dans ce cas, le numéro du sous-modèle est relatif plutôt qu'absolue. Les parenthèses les plus récemment ouvertes peuvent être référencés par (?(-1), les suivantes les plus récentes (?(-2), et ainsi de suite. A l'intérieur des boucles, il peut également être judicieux de se référer à des groupes qui suivent. Les parenthèses suivantes ouvertes peuvent être référencées par (?(+1), et ainsi de suite. (La valeur zéro dans ces formes n’est pas utilisée; elle lève une erreur).

Considérons le modèle suivant, qui contient des espaces blancs non significatifs pour le rendre plus lisible (en supposant l'option PCRE_EXTENDED (?x)) en divisant l’expression en trois parties pour faciliter la discussion:

  ( \( )?    [^()]+    (?(1) \) )

$regex = "(?x)   ( \( )?    [^()]+    (?(1) \) )"
$sujet = "chat)(chien)(cheval"
_ArrayDisplay(StringRegExp($sujet, $regex, 4)[0])
_ArrayDisplay(StringRegExp($sujet, $regex, 4)[1])
_ArrayDisplay(StringRegExp($sujet, $regex, 4)[2])

Si vous intégrez ce modèle dans un plus grand, vous pouvez utiliser une référence relative:

  ... autres choses ... (\()?    [^()]+    (?(-1)\) ) ...

Perl utilise la syntaxe (?(<nom>)...) ou (?('nom')...) pour tester un sous-modèle utilisé par nom. Pour la compatibilité avec les versions antérieures de PCRE, qui avaient cette facilité avant Perl, la syntaxe (?(nom)...) est également reconnu.

La ré-écriture de l'exemple précédent pour utiliser un sous-modèle nommé donne ceci:

$regex = "(?x) (?<ouvrante> \( )?  [^\(\)]+  (?(ouvrante) \) )"
;              |__________|                  |__________|
;                    |_______ pas d'espace ________|
;
$sujet ="chat)(chien)(cheval"
_ArrayDisplay(StringRegExp($sujet, $regex, 4)[0])
_ArrayDisplay(StringRegExp($sujet, $regex, 4)[1])
_ArrayDisplay(StringRegExp($sujet, $regex, 4)[2])

Si la condition est la chaîne (R), et s’il n'y a pas de sous-modèle avec le nom R, la condition est vraie si un appel récursif au modèle entier ou à un sous-modèle a été fait. Si des chiffres ou un nom précédé par esperluette (&) suivent la lettre R, par exemple:

  (?(R3)...) ou (?(R&nom)...)

Au "niveau supérieur", toutes ces conditions de test de récursivité sont fausses. La syntaxe pour des modèles récursifs est décrite ci-dessous.

Si la condition est la chaîne (DEFINE), et s’il n'y a pas de sous-modèle avec le nom DEFINE, la condition est toujours fausse. Dans ce cas, il ne peut y avoir qu'une seule alternative dans le sous-modèle. Il est toujours ignoré si le contrôle atteint ce point dans le modèle; l'idée de DEFINE est qu'il peut être utilisé pour définir des sous-routines qui peuvent être appelées de n’importe où. (L'utilisation de sous-programmes est décrite ci-dessous.) Par exemple, un modèle pour matcher une adresse IPv4 comme "192.168.23.245" pourrait être écrit comme ceci (ignorez les espaces et les sauts de lignes):

  $regex = "(?x)" & _
    "(?(DEFINE) (?<byte> 2[0-4]\d | 25[0-5] | 1\d\d | [1-9]?\d) )" & _
    "(?(DEFINE) (?<IPV4> \b (?&byte) (\.(?&byte)){3} \b) )" & _
    "(?&IPV4)"
  _ArrayDisplay(StringRegExp("192.168.23.245", $regex, 4)[0])

Un autre problème du même genre consiste à matcher les comments-block d'un script AutoIt, autrement dit, les lignes comprises entre #cs ou #comments-start, et #ce ou #comments-end. La documentation précise que ces blocks peuvent s'imbriquer ce qui implique une solution récursive:

  $regex = '(?imsx) (?&Cblock)' & _
  '(?(DEFINE) (?<Cblock> (?&CSline) (?: (?&Cblock)* | (?&Comment)*? )* (?&CEline) ) )' & _
  '(?(DEFINE) (?<Comment> ^ \N*?  (?! (?&CSline) | (?&CEline) ) \R ) )' & _
  '(?(DEFINE) (?<CSline> ^ \h* \# (?: cs | comments-start ) \b \N* \R)  )' & _
  '(?(DEFINE) (?<CEline> ^ \h* \# (?: ce | comments-end ) \b \N* \R ) )'

Si la condition n’est pas dans l'un des formats ci-dessus, elle doit être une assertion. Cela peut être une assertion lookahead ou lookbehind, positive ou négative. Considérez ce modèle, contenant de nouveau des espaces non significatifs, et avec les deux alternatives sur la seconde ligne:

  (?(?=[^a-z]*[a-z])
  \d{2}-[a-z]{3}-\d{2}  |  \d{2}-\d{2}-\d{2} )

  $regex = "(?x)" & _
    "(?(?=[^a-z]*[a-z])" & _
    "\d{2}-[a-z]{3}-\d{2}  |  \d{2}-\d{2}-\d{2} )"
  _ArrayDisplay(StringRegExp("123-abc-456", $regex, 4)[0])
  _ArrayDisplay(StringRegExp("123-34-567", $regex, 4)[0])

Il existe deux façons d'inclure des commentaires dans les modèles qui sont traités par PCRE. Dans les deux cas, le début du commentaire ne doit pas être dans une classe de caractère, ni dans une séquence de caractères connexes tels que (?: ou un nom ou un numéro de sous-modèle. Les caractères qui composent un commentaire ne jouent aucun rôle dans la recherche de la concordance avec le modèle.

La séquence (?# marque le début d'un commentaire qui continue jusqu'à la prochaine parenthèse fermante. Les parenthèses imbriquées ne sont pas autorisées. Si l'option PCRE_EXTENDED (?x) est défini, un caractère # non échappé introduit également un commentaire, qui dans ce cas continue jusqu'au caractère newline suivant, y compris, ou d'une séquence de caractères dans le modèle. Quels caractères sont interprétés comme des newlines est contrôlée par une séquence spéciale au début du modèle, tel que décrit dans la section intitulée "Conventions newline" ci-dessus. Notez que la fin de ce type de commentaire est une séquence de saut de ligne littérale dans le modèle; des séquences d’échappement qui se produisent pour représenter un saut de ligne ne comptent pas. Par exemple, considérons le modèle ci- dessous lorsque PCRE_EXTENDED (?x) est défini, et que la convention de saut de ligne par défaut est en vigueur:

  abc  #commentaire \n encore commentaire

Considérons le problème du match de chaînes entre parenthèses, en permettant une imbrication illimitée des parenthèses. Sans l'utilisation de la récursivité, ce qui peut être fait de mieux est d'utiliser un modèle qui matche à une certaine profondeur fixe d’imbrication. Il est impossible de faire face à une profondeur d'imbrication arbitraire.

Depuis un certain temps, Perl a fourni une fonctionnalité qui permet des expressions régulières récursives (entre autres choses). Il le fait par interpolation de code Perl dans l'expression au moment de l'exécution, et le code peut se référer à l'expression elle-même. Un modèle Perl qui utilise l'interpolation de code pour résoudre le problème des parenthèses peut être créé comme ceci:

  $re = qr{\( (?: (?>[^()]+) | (?p{$re}) )* \)}x;

De toute évidence, PCRE ne peut pas supporter l'interpolation de code Perl. Au lieu de cela, il prend en charge la syntaxe spéciale pour la récursivité sur le modèle entier, et aussi pour la récursivité d’un sous-modèle particulier. Après son introduction en PCRE et Python, ce genre de récursivité a ensuite été introduit dans Perl à la version 5.10.

Une séquence spéciale qui consiste en (? et qui est suivie d'un nombre supérieur à zéro et d’une parenthèse fermante est un appel à un sous-programme récursif du sous-modèle du numéro donné, à condition que cela se produit à l'intérieur du sous-modèle. (Dans le cas contraire, c’est un appel non-récursif à un sous-programme, qui est décrit dans la section suivante.) La séquence spéciale (?R) ou (?0) est un appel récursif à l'expression régulière entière.

Ce modèle PCRE résout le problème des parenthèses imbriquées (l'option PCRE_EXTENDED (?x) est activée donc les espaces blanc soient ignorés):

  $regex = "(?x) \( ( [^()]++ | (?R) )* \)"
  _ArrayDisplay(StringRegExp("1+2*(3+4*(5+6*(7+8*9))", $regex, 4)[0])

Si l’expression faisait partie d'un modèle plus grand, vous ne voudriez pas la récursivité sur le modèle entier, donc à la place, vous utiliseriez ceci:

  ( \( ( [^()]++ | (?1) )* \) )

Dans un modèle plus grand, garder une trace des numéros de parenthèses peut être difficile. Ceci est rendu plus facile par l'utilisation des références relatives. Au lieu de (?1) dans le modèle ci-dessus, vous pouvez écrire (?-2) pour faire référence à la deuxième plus récente parenthèse ouverte avant la récursivité. En d'autres termes, un nombre négatif compte les parenthèses capturantes vers la gauche à partir du point où elle est rencontrée.

Il est également possible de se référer par la suite à des parenthèses ouvrantes, en écrivant des références telles que (?+2). Cependant, celle-ci ne peut pas être récursive car la référence n’est pas à l'intérieur des parenthèses qui sont référencés. Ce sont toujours des appels

A l'issue d'un match, les valeurs de capture entre parenthèses sont celles du niveau le plus haut. Si vous souhaitez obtenir des valeurs intermédiaires, une fonction callout peut être utilisée (voir ci-dessous et la documentation pcrecallout). Si le modèle ci-dessus est exécuté sur le sujet "(ab(cd)ef)" la valeur pour la capture des parenthèses intérieures (numérotée 2) est "ef", qui est la dernière valeur prise au plus haut niveau. Si un sous-modèle capturant n’est pas matché au niveau supérieur, sa valeur finale capturée est détruite, même si elle était (temporairement) fixée à un niveau plus profond au cours du processus de match.

S'il y a plus de 15 parenthèses de capture dans un modèle, PCRE doit obtenir davantage de mémoire pour stocker des données lors d'une récursivité, ce qu'il fait en utilisant pcre_malloc, la libérant via pcre_free après. Si aucune mémoire peut être obtenu, le match échoue avec l'erreur PCRE_ERROR_NOMEMORY.

Ne confondez pas la séquence (?R) avec la condition (R), qui teste la récursivité. Considérez le modèle ci-dessous, qui matche un texte entre <>, permettant l'imbrication arbitraire. Seuls les chiffres sont autorisés entre <> imbriqués (lors des appels récursifs), alors que tous les caractères sont autorisés au niveau externe.

  $regex = "(?x) < (?: (?(R) \d++  | [^<>]*+) | (?R)) * >"
  ;                    |____________________|
  ;                |________________________________|

  _ArrayDisplay(StringRegExp("a<bc<12>de>f", $regex, 4)[0])

Le traitement récursif dans PCRE diffère de Perl de deux façons importantes. Dans PCRE (comme Python, mais contrairement à Perl), un appel à un sous-modèle récursif est toujours traité comme un groupe atomique. Autrement dit, une fois qu'il a matché quelque chose dans la chaîne sujet, le modèle n’est jamais ré-entré, même si ce sous-modèle contient des alternatives non essayées ou s’il y a un échec de match ultérieurement. Ceci peut être illustré par le modèle suivant, qui est censé matcher une chaîne palindrome qui contient un nombre impair de caractères (par exemples, "a", "aba", "ABCBA", "abcdcba"):

  ^(.|(.)(?1)\2)$

Au niveau supérieur, le premier caractère "a" est matché, mais comme il n'est pas à la fin de la chaîne, la première alternative échoue; la seconde alternative est prise et la récursivité agit. L'appel récursif au sous-modèle 1 matche avec succès le caractère suivant "b". (Notez que les tests de début et de fin de ligne ne font pas partie de la récursivité).

Donc retour au niveau supérieur, le caractère suivant "c" est comparé avec ce que le sous-modèle 2 a matché, qui était "a". Cela échoue. Parce que la récursivité est traitée comme un groupe atomique, il y a maintenant aucun point de backtracking, et ainsi le match entier échoue. (Perl est en mesure, à ce stade, de ré-entrer la récursivité et d’essayer la seconde alternative.) Toutefois, si le modèle est écrit avec les alternatives dans l’autre sens, les choses sont différentes:

  ^((.)(?1)\2|.)$

  $regex = "^((.)(?1)\2|.)$"
  _ArrayDisplay(StringRegExp("abcxcba", $regex, 4)[0])

Pour modifier le modèle afin qu'il matche toutes les chaînes de palindromes, pas seulement celles qui ont un nombre impair de caractères, il est tentant de changer le modèle comme ceci:

  ^((.)(?1)\2|.?)$

  $regex = "(?x) ^(?: ( (.)(?1)\2 | ) | ((.)(?3)\4 | .) )$"
  _ArrayDisplay(StringRegExp("abccba", $regex, 4)[0])

  $regex = "(?xi) ^\W*+ (?: ((.)\W*+(?1)\W*+\2 | ) | ((.)\W*+(?3)\W*+\4 | \W*+.\W*+) ) \W*+$"
  _ArrayDisplay(StringRegExp("A man, a plan, a canal: Panama!", $regex, 4)[0])

AVERTISSEMENT: Les modèles ci-dessus qui matchent des palindromes ne fonctionne que si la chaîne sujet ne débute pas avec un palindrome qui est plus court que la chaîne entière. Par exemple, bien que "abcba" soit correctement matché, si le sujet est "ababa", PCRE trouve le palindrome "aba" au début, puis échoue au niveau le plus haut parce que la fin de la chaîne ne suit pas. Encore une fois, le moteur ne peut pas revenir en arrière dans la récursivité pour essayer d'autres alternatives, donc tout le match échoue.

La deuxième façon dont PCRE et Perl diffèrent dans leur traitement de la récursivité est dans le traitement des valeurs capturées. En Perl, quand un sous-modèle est appelé récursivement ou comme un sous-modèle (voir la section suivante), il n'a pas accès à toutes les valeurs qui ont été capturées en dehors de la récursivité, alors que dans PCRE ces valeurs peuvent être référencées. Considérez ce modèle:

  ^(.)(\1|a(?2))

Si la syntaxe d'un appel d’un sous-modèle récursif (par numéro ou par nom) est utilisée en dehors des parenthèses auxquelles il se réfère, il opère comme un sous-programme dans un langage de programmation. Le sous-modèle appelé peut être défini avant ou après la référence. Une référence numérotée peut être absolue ou relative, comme dans ces exemples:

  (...(absolute)...)...(?2)...
  (...(relative)...)...(?-1)...
  (...(?+1)...(relative)...

  (perplex|complex)e et \1ité

  (perplex|complex)e et (?1)ité

Tous les appels de sous-programme, récursif ou non, sont toujours traités comme des groupes atomiques. Autrement dit, une fois qu’un sous-programme a matché quelque chose dans la chaîne sujet, il n’est jamais re-entré de nouveau, même si il contient des alternatives non essayées ou s’il y a un échec de match ultérieur. Des parenthèses capturantes qui sont définies lors de l'appel du sous-programme reviennent à leurs valeurs précédentes après.

Les options de traitement telles que l’insensibilité à la casse sont fixés lorsqu'un sous-modèle est défini, donc si il est utilisé comme un sous-programme, ces options ne peuvent pas être modifiés pour des appels différents. Par exemple, considérons ce modèle:

  (abc)(?i:(?-1))

$regex = "(abc)(?i:(?-1))"
msgbox(0,"abcabc",StringRegExp("abcabc", $regex, 0))
msgbox(0,"abcABC",StringRegExp("abcABC", $regex, 0))

Pour la compatibilité avec Oniguruma, la syntaxe non-Perl \g suivie d'un nom ou d'un nombre entouré de crochets ou de simples guillemets, est une syntaxe alternative pour référencer un sous-modèle en tant que sous-programme, éventuellement récursif. Ci-joint, deux des exemples utilisés ci-dessus, réécrits en utilisant cette syntaxe:

  (?<pn> \( ( (?>[^()]+) | \g<pn> )* \) )
  (sens|respons)e and \g'1'ibility

  (abc)(?i:\g<-1>)

Cette fonctionnalité n'est pas utilisable avec AutoIt.

Perl dispose d'une fonction pour laquelle l'utilisation de la séquence (?{...}) permet d'obéir à un code Perl arbitraire au milieu d’un match d'une expression régulière. Ceci permet, entre autre, d'extraire les différentes sous-chaînes qui matchent la même paire de parenthèses quand il y a une répétition.

PCRE fournit une fonctionnalité semblable, mais bien sûr, ne peut pas obéir à un code Perl arbitraire. Le concept est appelée "callout". L'appelant de PCRE fournit une fonction externe en mettant son point d'entrée dans la variable globale pcre_callout(8-bit library) ou pcre[16|32]_callout (16-bit ou 32-bit library). Par défaut, cette variable contient NULL, ce qui désactive tous les appels externes.

Dans une expression régulière, (?C) indique les points où la fonction externe doit être appelée. Si vous voulez identifier les différents points de callout, vous pouvez mettre un nombre inférieur à 256 après la lettre C. La valeur par défaut est zéro. Par exemple, ce modèle a deux points callout:

  (?C1)abc(?C2)def

  (?(?C9)(?=a)abc|def)

Pendant un match, lorsque PCRE atteint un point de callout, la fonction externe est appelée. Elle est fournie avec le numéro du callout, la position dans le modèle, et, facultativement, un élément de donnée fourni à l'appelant de la fonction de match. La fonction callout peut entraîner le backtracking, ou échouer complètement.

Par défaut, PCRE implémente un certain nombre d'optimisations au moment de la compilation et pendant le match, et un effet de bord se produit en ignorant parfois les appels. Si vous avez besoin de tous les appels possibles, vous devez définir les options qui désactivent les optimisations pertinentes. Plus de détails et une description complète de l'interface de la fonction callout, sont donnés dans la documentation pcrecallout.

Perl 5.10 introduit un certain nombre de "Verbes spéciaux de contrôle du Backtracking", qui sont décrits dans la documentation Perl comme "expérimental et sujet à modifications ou à suppression dans une version future de Perl". Elle poursuit en disant: "Leur utilisation dans un code de production devrait le noter pour éviter des problèmes lors des mises à jour. Les mêmes remarques s’appliquent aux caractéristiques PCRE décrites dans cette section.

Les nouveaux verbes utilisent une syntaxe auparavant invalide: une parenthèse ouvrante suivie d'un astérisque. Ils sont généralement de la forme (*VERB) ou (*VERB:NOM). Certains peuvent prendre n'importe quelle forme, et il est possible qu'ils se comportent différemment selon qu'un nom est présent ou non. Un nom est n'importe quelle séquence de caractères qui n'inclut pas de parenthèse fermante. Le maximum de la longueur d'un nom est 255 dans la bibliothèque 8 bits et 65535 dans les bibliothèques 16 bits et 32 bits. Si le nom est vide, c'est-à-dire si la parenthèse fermante suit immédiatement le caractère deux-points, l'effet est comme si le : n'était pas là. N'importe quel nombre de ces verbes peut apparaître dans un modèle.

Étant donné que ces verbes sont spécifiquement liés au backtracking, la plupart d'entre eux peuvent être utilisés que lorsque le modèle doit matcher en utilisant l'une des fonctions de match traditionnelles, parce qu'elles utilisent un algorithme de backtracking. A l'exception de (*FAIL), qui se comporte comme l’échec d’une assertion négative, les verbes de contrôle du backtraking provoquent une erreur si ils sont rencontrés par une fonction de match DFA.

Le comportement de ces verbes dans groupes répétés, assertions, et dans Sous-modèles appelés comme sous-programmes (récursif ou pas) est documenté ci-dessus.

PCRE contient quelques optimisations qui sont utilisés pour accélérer le match en exécutant certains contrôles au début de chaque tentative de match. Par exemple, il peut savoir la longueur minimale du sujet correspondant, ou si un caractère particulier doit être présent. Lorsque l'une de ces optimisations supprime le déroulement d'un match, tous les verbes de backtracking inclus ne seront pas traités, bien sûr. Vous pouvez supprimer les optimisations de début de match en mettant l'option PCRE_NO_START_OPTIMIZE lorsque vous appelez pcre_compile() ou pcre_exec() , ou en démarrant le modèle avec (*NO_START_OPT). ll y a plus de détails dans la section intitulée "Bits d'option pour pcre_exec()" dans la documentation pcreapi.

Des expériences avec Perl suggèrent qu'il a trop d’optimisations similaires, conduisant parfois à des résultats anormaux.

Les verbes suivants agissent dès qu'ils sont rencontrés dans le modèle. Ils ne peuvent pas être suivis par un nom.

   (*ACCEPT)

Si (*ACCEPT) est à l'intérieur de parenthèses capturantes, les données jusqu'à cet instant sont capturées. Par exemple le modèle:

  A((?:A|B(*ACCEPT)|C)D)

$regex = "A((?:A|B(*ACCEPT)|C)D)"
_ArrayDisplay(StringRegExp("AB", $regex, 4)[0])
_ArrayDisplay(StringRegExp("AAD", $regex, 4)[0])
_ArrayDisplay(StringRegExp("ACD", $regex, 4)[0])

   (*FAIL) ou (*F)

  a+(?C)(*FAIL)

Cette section n'est pas utilisable avec AutoIt.

Il y a un verbe dont le but principal est de traquer comment un match a réussi, mais il a aussi une utilisation secondaire en conjonction avec l'avancement du point de match de départ (voir (*SKIP) ci-dessous).

  (*MARK:NAME) or (*:NAME)

Lorsqu'un match réussit, le nom du dernier rencontré (*MARK:NAME), (*PRUNE:NAME), ou (*THEN:NAME) sur le chemin du match est retourné à l'appelant comme décrit dans la section intitulée "Données supplémentaires pour pcre_exec()" dans la documentation pcreapi. Voici un exemple de sortie de pcretest, où le modificateur /K demande la récupération et l’affichage des données (*MARK):

    re> /X(*MARK:A)Y|X(*MARK:B)Z/K
  data> XY
   0: XY
  MK: A
  XZ
   0: XZ
  MK: B

Si un verbe avec un nom est rencontré dans une assertion positive qui est vraie, le nom est enregistré et passé en retour s'il est le dernier rencontré. Cela ne se produit pas pour les assertions négatives pour les assertions négatives ou les assertions positives en échec.

Après un match partiel ou un match échoué, le dernier nom rencontré dans le processus de mach entier est retourné. Par exemple:

    re> /X(*MARK:A)Y|X(*MARK:B)Z/K
  data> XP
  No match, mark = B

Si vous êtes intéressé par les valeurs de (*MARK) après l'échec d'un match, vous définirez probablement l'option PCRE_NO_START_OPTIMIZE (voir ci-dessous) pour vous assurer que le match est toujours tenté.

Les verbes suivants ne font rien quand ils sont rencontrés. Le processus de match continue avec ce qui suit, mais s'il n'y a pas de match ultérieur, provoquant un retour en arrière au verbe, un échec est forcé. Autrement dit, le backtracking ne peut pas passer à la gauche du verbe. Cependant, lorsque l'un de ces verbes apparaît à l'intérieur d'un groupe atomique ou une assertion qui est vraie, son effet est limité à ce groupe, car une fois que le groupe a été identifié, il n'y a jamais backtracking en lui. Dans cette situation, le backtracking peut "sauter en arrière" à la gauche du groupe atomique entier. (Rappelez-vous aussi, comme indiqué ci-dessus, que cette localisation est également valable dans les appels de sous-programmes.)

Ces verbes diffèrent suivant le type d'échec qui se produit lorsque le backtracking les atteint. Le comportement décrit ci-dessous est ce qui se passe quand le verbe n'est pas dans un sous-programme ou une assertion. Les sections suivantes couvrent ce cas.

  (*COMMIT)

  a+(*COMMIT)b

$regex = "a+(*COMMIT)b"
Msgbox(0, "xyaab", StringRegExp("xyaab", $regex, 0)) ; réussite du match
Msgbox(0, "aacaab", StringRegExp("aacaab", $regex, 0)); échec du match

S'il y a plus d'un verbe de backtracking dans un modèle, un verbe différent qui suit (*COMMIT) peut être déclenché en premier, donc simplement passer (*COMMIT) pendant un match ne garantit pas toujours qu'un match doit être à ce point de départ.

Notez que (*COMMIT) au début d'un modèle n'est pas la même chose que l'ancrage, à moins que les optimisations de début de match de PCRE soient désactivées, comme le montre cet exemple de pcretest:

    re> /(*COMMIT)abc/
  data> xyzabc
   0: abc
  data> xyzabc\Y
  No match

  (*PRUNE) or (*PRUNE:NAME)

Le comportement de (*PRUNE:NAME) n'est pas le même que (*MARK:NAME)(*PRUNE). C'est le même que (*MARK: NAME) en ce que le nom est mémorisé pour le retour à l'appelant. Cependant, (*SKIP: NAME) recherche uniquement les noms définis avec (*MARK).

  (*SKIP)

  a+(*SKIP)b

  (*SKIP:NAME)

Notez que (*SKIP:NAME) cherche seulement les noms définis par (*MARK:NAME). Il ignore les noms qui sont définis par (*PRUNE:NAME) ou (*THEN:NAME).

  (*THEN) or (*THEN:NAME)

  ( COND1 (*THEN) FOO | COND2 (*THEN) BAR | COND3 (*THEN) BAZ ) ...

Le comportement de (*THEN:NAME) n'est pas le même que (* MARK: NAME) (* THEN). Il est comme (*MARK:NAME) en ce que le nom est rappelé pour le renvoi à l'appelant. Cependant, (*SKIP:NAME) recherche uniquement les noms définis avec (* MARK).

Un sous-modèle qui ne contient pas de caractère | est juste une partie de l'alternative dans les parenthèses; il n'est pas une alternation imbriquée avec une seule alternative. L'effet de (*THEN) va au-delà d'un tel sous-modèle d'alternative entre parenthèses. Considérez ce modèle, où A, B, etc. sont des fragments de modèles complexes qui ne contiennent pas de | à ce niveau:

  A (B(*THEN)C) | D

  A (B (*THEN)C | (*FAIL)) | D

Notez qu'un sous-modèle conditionnel n'est pas considéré comme ayant deux alternatives, car une seule est utilisée. En d'autres termes, le caractère | dans un sous-modèle conditionnel a une signification différente. En ignorant les espaces blancs, considérez:

  ^.*? (?(?=a) a | b(*THEN)c )

Les verbes qui viennent d'être décrits fournissent quatre "forces" différentes de contrôle quand les matchs successifs échouent. (*THEN) est la plus faible, portant sur le match à l'alternative suivante. (*PRUNE) vient ensuite, à défaut du match à la position de départ actuelle, mais permettant une avance au caractère suivant (pour un modèle non ancré). (*SKIP) est similaire, sauf que l'avance peut être de plus d'un caractère. (*COMMIT) est la plus forte, ce qui provoque l'échec du match entier.

Si plus d'un verbe de backtracking est présent dans un modèle, celui qui subit le backtracking agit en premier. Par exemple, considérons ce modèle, où A, B, etc. sont des fragments de motifs complexes:

   (A(*COMMIT)B(*THEN)C|ABD)

   ...(*COMMIT)(*PRUNE)...

PCRE diffère de Perl dans sa gestion des verbes backtracking dans les groupes répétés. Par exemple, considérez:

   (a(*COMMIT)b)+ac

(*FAIL) dans une assertion a son effet normal: il force un retour arrière immédiat.

(*ACCEPT) dans une assertion positive provoque la réussite de l'assertion sans aucun traitement ultérieur. Dans une assertion négative, (*ACCEPT) provoque l'échec de l'assertion sans autre traitement.

Les autres verbes backtracking ne sont pas traités spécialement s'ils apparaissent dans une assertion positive. En particulier, (*THEN) passe à l'alternative suivante dans le groupe le plus interne qui a des alternances, que ce soit ou non dans l'assertion.

Les affirmations négatives sont toutefois différentes, afin de garantir que le changement d'une assertion positive en une assertion négative change son résultat. Le baktracking dans (*COMMIT), (*SKIP) ou (*PRUNE) entraine qu'une assertion négative est vraie, sans considérer d'autres branches alternatives dans l'assertion. Le backtracking dans (*THEN) le fait passer à la prochaine alternative englobante dans l'assertion (le comportement normal), mais si l'assertion n'a pas une telle alternative, (*THEN) se comporte comme (*PRUNE).

Ces comportements se produisent si le modèle est appelé récursivement ou non. Le traitement par Perl des sous-programmes est différent dans certains cas.

(*FAIL) dans un sous-modèle appelé comme sous-programme a son effet normal: il force un backtracking immédiat.

(*ACCEPT) dans un sous-modèle appelé comme sous-programme provoque le succès du match du sous-programme sans aucun traitement supplémentaire. Le match se poursuit ensuite après l'appel de sous-programme.

(*COMMIT), (*SKIP) et (*PRUNE) dans un sous-modèle appelé comme sous-programme provoque l'échec du sous-programme.

(*THEN) passe à l'alternative suivante dans le groupe le plus proche englobant à l'intérieur du sous-modèle qui a les alternatives. S'il n'y a pas de tel groupe dans le sous-modèle, (*THEN) provoque l'échec du match du sous-programme.

pcreapi(3), pcrecallout(3), pcrematching(3), pcresyntax(3), pcre(3), pcre16(3), pcre32(3).

Philip Hazel / Traduction danielm
University Computing Service
Cambridge CB2 3QH, England.

Last updated: 08 January 2014
Copyright © 1997-2014 University of Cambridge.