| '\" t | |
| .\" Title: pcre2pattern | |
| .\" Author: [see the "AUTHOR(S)" section] | |
| .\" Generator: Asciidoctor 2.0.26 | |
| .\" Date: 25 October 2025 | |
| .\" Manual: PCRE2 | |
| .\" Source: PCRE2 10.50-DEV | |
| .\" Language: English | |
| .\" | |
| .TH "PCRE2PATTERN" "3" "25 October 2025" "PCRE2 10.50\-DEV" "PCRE2" | |
| .ie \n(.g .ds Aq \(aq | |
| .el .ds Aq ' | |
| .ss \n[.ss] 0 | |
| .nh | |
| .ad l | |
| .de URL | |
| \fI\\$2\fP <\\$1>\\$3 | |
| .. | |
| .als MTO URL | |
| .if \n[.g] \{\ | |
| . mso www.tmac | |
| . am URL | |
| . ad l | |
| . . | |
| . am MTO | |
| . ad l | |
| . . | |
| . LINKSTYLE blue R < > | |
| .\} | |
| .SH "NAME" | |
| pcre2pattern \- PCRE2 pattern syntax | |
| .SH "PCRE2 REGULAR EXPRESSION DETAILS" | |
| .sp | |
| The syntax and semantics of the regular expressions that are supported by PCRE2 | |
| are described in detail below. There is a quick\-reference syntax summary in the | |
| \f(CRpcre2syntax\fP | |
| page. PCRE2 tries to match Perl syntax and semantics as closely as it can. | |
| PCRE2 also supports some alternative regular expression syntax that does not | |
| conflict with the Perl syntax in order to provide some compatibility with | |
| regular expressions in Python, .NET, and Oniguruma. There are in addition some | |
| options that enable alternative syntax and semantics that are not the same as | |
| in Perl. | |
| .sp | |
| Perl\(cqs regular expressions are described in its own documentation, and regular | |
| expressions in general are covered in a number of books, some of which have | |
| copious examples. Jeffrey Friedl\(cqs "Mastering Regular Expressions", published | |
| by O\(cqReilly, covers regular expressions in great detail. This description of | |
| PCRE2\(cqs regular expressions is intended as reference material. | |
| .sp | |
| This document discusses the regular expression patterns that are supported by | |
| PCRE2 when its main matching function, \f(CBpcre2_match()\fP, is used. PCRE2 also | |
| has an alternative matching function, \f(CBpcre2_dfa_match()\fP, which matches | |
| using a different algorithm that is not Perl\-compatible. Some of the features | |
| discussed below are not available when DFA matching is used. The advantages and | |
| disadvantages of the alternative function, and how it differs from the normal | |
| function, are discussed in the | |
| \f(CRpcre2matching\fP | |
| page. | |
| .SH "EBCDIC CHARACTER CODES" | |
| .sp | |
| Most computers use ASCII or Unicode for encoding characters, and PCRE2 assumes | |
| this by default. However, it can be compiled to run in an environment that uses | |
| the EBCDIC code, which is the case for some IBM mainframe operating systems. In | |
| the sections below, character code values are ASCII or Unicode; in an EBCDIC | |
| environment these characters may have different code values, and there are no | |
| code points greater than 255. Differences in behaviour when PCRE2 is running in | |
| an EBCDIC environment are described in the section EBCDIC ENVIRONMENTS | |
| below, which you can ignore unless you really are in an EBCDIC environment. | |
| .SH "SPECIAL START\-OF\-PATTERN ITEMS" | |
| .sp | |
| A number of options that can be passed to \f(CBpcre2_compile()\fP can also be set | |
| by special items at the start of a pattern. These are not Perl\-compatible, but | |
| are provided to make these options accessible to pattern writers who are not | |
| able to change the program that processes the pattern. Any number of these | |
| items may appear, but they must all be together right at the start of the | |
| pattern string, and the letters must be in upper case. | |
| .SS "UTF support" | |
| .sp | |
| In the 8\-bit and 16\-bit PCRE2 libraries, characters may be coded either as | |
| single code units, or as multiple UTF\-8 or UTF\-16 code units. UTF\-32 can be | |
| specified for the 32\-bit library, in which case it constrains the character | |
| values to valid Unicode code points. To process UTF strings, PCRE2 must be | |
| built to include Unicode support (which is the default). When using UTF strings | |
| you must either call the compiling function with one or both of the \f(CBPCRE2_UTF\fP | |
| or \f(CBPCRE2_MATCH_INVALID_UTF\fP options, or the pattern must start with the special | |
| sequence \f(CI(*UTF)\fP, which is equivalent to setting the relevant \f(CBPCRE2_UTF\fP. How | |
| setting a UTF mode affects pattern matching is mentioned in several places | |
| below. There is also a summary of features in the | |
| \f(CRpcre2unicode\fP | |
| page. | |
| .sp | |
| Some applications that allow their users to supply patterns may wish to | |
| restrict them to non\-UTF data for security reasons. If the \f(CBPCRE2_NEVER_UTF\fP | |
| option is passed to \f(CBpcre2_compile()\fP, \f(CI(*UTF)\fP is not allowed, and its | |
| appearance in a pattern causes an error. | |
| .SS "Unicode property support" | |
| .sp | |
| Another special sequence that may appear at the start of a pattern is \f(CI(*UCP)\fP. | |
| This has the same effect as setting the \f(CBPCRE2_UCP\fP option: it causes sequences | |
| such as \f(CI\(rsd\fP and \f(CI\(rsw\fP to use Unicode properties to determine character types, | |
| instead of recognizing only characters with codes less than 256 via a lookup | |
| table. If also causes upper/lower casing operations to use Unicode properties | |
| for characters with code points greater than 127, even when UTF is not set. | |
| These behaviours can be changed within the pattern; see the section | |
| INTERNAL OPTION SETTING | |
| below. | |
| .sp | |
| Some applications that allow their users to supply patterns may wish to | |
| restrict them for security reasons. If the \f(CBPCRE2_NEVER_UCP\fP option is passed to | |
| \f(CBpcre2_compile()\fP, \f(CI(*UCP)\fP is not allowed, and its appearance in a pattern | |
| causes an error. | |
| .SS "Locking out empty string matching" | |
| .sp | |
| Starting a pattern with \f(CI(*NOTEMPTY)\fP or \f(CI(*NOTEMPTY_ATSTART)\fP has the same effect | |
| as passing the \f(CBPCRE2_NOTEMPTY\fP or \f(CBPCRE2_NOTEMPTY_ATSTART\fP option to whichever | |
| matching function is subsequently called to match the pattern. These options | |
| lock out the matching of empty strings, either entirely, or only at the start | |
| of the subject. | |
| .SS "Disabling auto\-possessification" | |
| .sp | |
| If a pattern starts with \f(CI(*NO_AUTO_POSSESS)\fP, it has the same effect as setting | |
| the \f(CBPCRE2_NO_AUTO_POSSESS\fP option, or calling \f(CBpcre2_set_optimize()\fP with | |
| a \f(CBPCRE2_AUTO_POSSESS_OFF\fP directive. This stops PCRE2 from making quantifiers | |
| possessive when what follows cannot match the repeated item. For example, by | |
| default \f(CIa+b\fP is treated as \f(CIa++b\fP. For more details, see the | |
| \f(CRpcre2api\fP | |
| documentation. | |
| .SS "Disabling start\-up optimizations" | |
| .sp | |
| If a pattern starts with \f(CI(*NO_START_OPT)\fP, it has the same effect as setting the | |
| \f(CBPCRE2_NO_START_OPTIMIZE\fP option, or calling \f(CBpcre2_set_optimize()\fP with | |
| a \f(CBPCRE2_START_OPTIMIZE_OFF\fP directive. This disables several optimizations for | |
| quickly reaching "no match" results. For more details, see the | |
| \f(CRpcre2api\fP | |
| documentation. | |
| .SS "Disabling automatic anchoring" | |
| .sp | |
| If a pattern starts with \f(CI(*NO_DOTSTAR_ANCHOR)\fP, it has the same effect as | |
| setting the \f(CBPCRE2_NO_DOTSTAR_ANCHOR\fP option, or | |
| calling \f(CBpcre2_set_optimize()\fP with a \f(CBPCRE2_DOTSTAR_ANCHOR_OFF\fP directive. | |
| This disables optimizations that apply to patterns whose top\-level branches | |
| all start with \f(CI.*\fP (match any number of arbitrary characters). For more details, | |
| see the | |
| \f(CRpcre2api\fP | |
| documentation. | |
| .SS "Disabling JIT compilation" | |
| .sp | |
| If a pattern that starts with \f(CI(*NO_JIT)\fP is successfully compiled, an attempt by | |
| the application to apply the JIT optimization by calling | |
| \f(CBpcre2_jit_compile()\fP is ignored. | |
| .SS "Setting match resource limits" | |
| .sp | |
| The \f(CBpcre2_match()\fP function contains a counter that is incremented every | |
| time it goes round its main loop. The caller of \f(CBpcre2_match()\fP can set a | |
| limit on this counter, which therefore limits the amount of computing resource | |
| used for a match. The maximum depth of nested backtracking can also be limited; | |
| this indirectly restricts the amount of heap memory that is used, but there is | |
| also an explicit memory limit that can be set. | |
| .sp | |
| These facilities are provided to catch runaway matches that are provoked by | |
| patterns with huge matching trees. A common example is a pattern with nested | |
| unlimited repeats applied to a long string that does not match. When one of | |
| these limits is reached, \f(CBpcre2_match()\fP gives an error return. The limits | |
| can also be set by items at the start of the pattern of the form | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CI(*LIMIT_HEAP=\fP\f(CId\fP\f(CI) | |
| (*LIMIT_MATCH=\fP\f(CId\fP\f(CI) | |
| (*LIMIT_DEPTH=\fP\f(CId\fP\f(CI)\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| where \fId\fP is any number of decimal digits. However, the value of the setting must | |
| be less than the value set (or defaulted) by the caller of \f(CBpcre2_match()\fP | |
| for it to have any effect. In other words, the pattern writer can lower the | |
| limits set by the programmer, but not raise them. If there is more than one | |
| setting of one of these limits, the lower value is used. The heap limit is | |
| specified in kibibytes (units of 1024 bytes). | |
| .sp | |
| Prior to release 10.30, LIMIT_DEPTH was called LIMIT_RECURSION. This name is | |
| still recognized for backwards compatibility. | |
| .sp | |
| The heap limit applies only when the \f(CBpcre2_match()\fP or | |
| \f(CBpcre2_dfa_match()\fP interpreters are used for matching. It does not apply | |
| to JIT. The match limit is used (but in a different way) when JIT is being | |
| used, or when \f(CBpcre2_dfa_match()\fP is called, to limit computing resource | |
| usage by those matching functions. The depth limit is ignored by JIT but is | |
| relevant for DFA matching, which uses function recursion for recursions within | |
| the pattern and for lookaround assertions and atomic groups. In this case, the | |
| depth limit controls the depth of such recursion. | |
| .SS "Newline conventions" | |
| .sp | |
| PCRE2 supports six different conventions for indicating line breaks in | |
| strings: a single CR (carriage return) character, a single LF (linefeed) | |
| character, the two\-character sequence CRLF, any of the three preceding, any | |
| Unicode newline sequence, or the NUL character (binary zero). The | |
| \f(CRpcre2api\fP | |
| page has | |
| further discussion | |
| about newlines, and shows how to set the newline convention when calling | |
| \f(CBpcre2_compile()\fP. | |
| .sp | |
| It is also possible to specify a newline convention by starting a pattern | |
| string with one of the following sequences: | |
| .sp | |
| .RS 4 | |
| .PD 0 | |
| .TP 11 | |
| \f(CI(*CR)\fP | |
| .ad l | |
| Carriage return | |
| .TP 11 | |
| \f(CI(*LF)\fP | |
| .ad l | |
| Linefeed | |
| .TP 11 | |
| \f(CI(*CRLF)\fP | |
| .ad l | |
| Carriage return, followed by linefeed | |
| .TP 11 | |
| \f(CI(*ANYCRLF)\fP | |
| .ad l | |
| Any of the three above | |
| .TP 11 | |
| \f(CI(*ANY)\fP | |
| .ad l | |
| All Unicode newline sequences | |
| .TP 11 | |
| \f(CI(*NUL)\fP | |
| .ad l | |
| The NUL character (binary zero) | |
| .PD | |
| .RE | |
| .PP | |
| .ad l | |
| .sp | |
| These override the default and the options given to the compiling function. For | |
| example, on a Unix system where LF is the default newline sequence, the pattern | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CI(*CR)a.b\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| changes the convention to CR. That pattern matches \f(CIa\(rsnb\fP because LF is no | |
| longer a newline. If more than one of these settings is present, the last one | |
| is used. | |
| .sp | |
| The newline convention affects where the circumflex and dollar assertions are | |
| true. It also affects the interpretation of the dot metacharacter when | |
| \f(CBPCRE2_DOTALL\fP is not set, and the behaviour of \f(CI\(rsN\fP when not followed by an | |
| opening brace. However, it does not affect what the \f(CI\(rsR\fP escape sequence | |
| matches. By default, this is any Unicode newline sequence, for Perl | |
| compatibility. However, this can be changed; see the section | |
| Specifying what \f(CI\(rsR\fP matches and the | |
| description of \f(CI\(rsR\fP in the section Newline sequences | |
| below. A change of \f(CI\(rsR\fP setting can be combined with a change of newline | |
| convention. | |
| .SS "Specifying what \f(CI\(rsR\fP matches" | |
| .sp | |
| It is possible to restrict \f(CI\(rsR\fP to match only CR, LF, or CRLF (instead of the | |
| complete set of Unicode line endings) by setting the option \f(CBPCRE2_BSR_ANYCRLF\fP | |
| at compile time. This effect can also be achieved by starting a pattern with | |
| \f(CI(*BSR_ANYCRLF)\fP. For completeness, \f(CI(*BSR_UNICODE)\fP is also recognized, | |
| corresponding to \f(CBPCRE2_BSR_UNICODE\fP. | |
| .SH "CHARACTERS AND METACHARACTERS" | |
| .sp | |
| A regular expression is a pattern that is matched against a subject string from | |
| left to right. Most characters stand for themselves in a pattern, and match the | |
| corresponding characters in the subject. As a trivial example, the pattern | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CIThe quick brown fox\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| matches a portion of a subject string that is identical to itself. When | |
| caseless matching is specified (the \f(CBPCRE2_CASELESS\fP option or \f(CI(?i)\fP within the | |
| pattern), letters are matched independently of case. Note that there are two | |
| ASCII characters, K and S, that, in addition to their lower case ASCII | |
| equivalents, are case\-equivalent with Unicode \f(CRU+212A\fP (Kelvin sign) and \f(CRU+017F\fP | |
| (long S) respectively when either \f(CBPCRE2_UTF\fP or \f(CBPCRE2_UCP\fP is set, unless the | |
| \f(CBPCRE2_EXTRA_CASELESS_RESTRICT\fP option is in force (either passed to | |
| \f(CBpcre2_compile()\fP or set by \f(CI(*CASELESS_RESTRICT)\fP or \f(CI(?r)\fP within the | |
| pattern). If the \f(CBPCRE2_EXTRA_TURKISH_CASING\fP option is in force (either passed | |
| to \f(CBpcre2_compile()\fP or set by \f(CI(*TURKISH_CASING)\fP within the pattern), then | |
| the \*(Aqi\*(Aq letters are matched according to Turkish and Azeri languages. | |
| .sp | |
| The power of regular expressions comes from the ability to include wild cards, | |
| character classes, alternatives, and repetitions in the pattern. These are | |
| encoded in the pattern by the use of \fImetacharacters\fP, which do not stand | |
| for themselves but instead are interpreted in some special way. | |
| .sp | |
| There are two different sets of metacharacters: those that are recognized | |
| anywhere in the pattern except within square brackets, and those that are | |
| recognized within square brackets. Outside square brackets, the metacharacters | |
| are as follows: | |
| .sp | |
| .RS 4 | |
| .PD 0 | |
| .TP 7 | |
| \f(CI\(rs\fP | |
| .ad l | |
| general escape character with several uses | |
| .TP 7 | |
| \f(CI^\fP | |
| .ad l | |
| assert start of string (or line, in multiline mode) | |
| .TP 7 | |
| \f(CI$\fP | |
| .ad l | |
| assert end of string (or line, in multiline mode) | |
| .TP 7 | |
| \f(CI.\fP | |
| .ad l | |
| match any character except newline (by default) | |
| .TP 7 | |
| \f(CI[\fP | |
| .ad l | |
| start character class definition | |
| .TP 7 | |
| \f(CI|\fP | |
| .ad l | |
| start of alternative branch | |
| .TP 7 | |
| \f(CI(\fP | |
| .ad l | |
| start group or control verb | |
| .TP 7 | |
| \f(CI)\fP | |
| .ad l | |
| end group or control verb | |
| .TP 7 | |
| \f(CI*\fP | |
| .ad l | |
| 0 or more quantifier | |
| .TP 7 | |
| \f(CI+\fP | |
| .ad l | |
| 1 or more quantifier; also "possessive quantifier" | |
| .TP 7 | |
| \f(CI?\fP | |
| .ad l | |
| 0 or 1 quantifier; also quantifier minimizer | |
| .TP 7 | |
| \f(CI{\fP | |
| .ad l | |
| potential start of min/max quantifier | |
| .PD | |
| .RE | |
| .PP | |
| .ad l | |
| .sp | |
| Brace characters \f(CI{\fP and \f(CI}\fP are also used to enclose data for constructions such | |
| as \f(CI\(rsg{2}\fP or \f(CI\(rsk{\fP\f(CIname\fP\f(CI}\fP. In almost all uses of braces, space and/or horizontal | |
| tab characters that follow \f(CI{\fP or precede \f(CI}\fP are allowed and are ignored. In the | |
| case of quantifiers, they may also appear before or after the comma. The | |
| exception to this is \f(CI\(rsu{...}\fP which is an ECMAScript compatibility feature | |
| that is recognized only when the \f(CBPCRE2_EXTRA_ALT_BSUX\fP option is set. ECMAScript | |
| does not ignore such white space; it causes the item to be interpreted as | |
| literal. | |
| .sp | |
| Part of a pattern that is in square brackets is called a "character class". In | |
| a character class the only metacharacters are: | |
| .sp | |
| .RS 4 | |
| .PD 0 | |
| .TP 7 | |
| \f(CI\(rs\fP | |
| .ad l | |
| general escape character | |
| .TP 7 | |
| \f(CI^\fP | |
| .ad l | |
| negate the class, but only if the first character | |
| .TP 7 | |
| \f(CI\-\fP | |
| .ad l | |
| indicates character range | |
| .TP 7 | |
| \f(CI[\fP | |
| .ad l | |
| POSIX character class (if followed by POSIX syntax) | |
| .TP 7 | |
| \f(CI]\fP | |
| .ad l | |
| terminates the character class | |
| .PD | |
| .RE | |
| .PP | |
| .ad l | |
| .sp | |
| If a pattern is compiled with the \f(CBPCRE2_EXTENDED\fP option, most white space in | |
| the pattern, other than in a character class, within a \f(CI\(rsQ...\(rsE\fP sequence, or | |
| between a \f(CI#\fP outside a character class and the next newline, inclusive, is | |
| ignored. An escaping backslash can be used to include a white space or a # | |
| character as part of the pattern. If the \f(CBPCRE2_EXTENDED_MORE\fP option is set, the | |
| same applies, but in addition unescaped space and horizontal tab characters are | |
| ignored inside a character class. Note: only these two characters are ignored, | |
| not the full set of pattern white space characters that are ignored outside a | |
| character class. Option settings can be changed within a pattern; see the | |
| section INTERNAL OPTION SETTING | |
| below. | |
| .sp | |
| The following sections describe the use of each of the metacharacters. | |
| .SH "BACKSLASH" | |
| .sp | |
| The backslash character has several uses. Firstly, if it is followed by a | |
| character that is not a digit or a letter, it takes away any special meaning | |
| that character may have. This use of backslash as an escape character applies | |
| both inside and outside character classes. | |
| .sp | |
| For example, if you want to match a \f(CI*\fP character, you must write \f(CI\(rs*\fP in the | |
| pattern. This escaping action applies whether or not the following character | |
| would otherwise be interpreted as a metacharacter, so it is always safe to | |
| precede a non\-alphanumeric with backslash to specify that it stands for itself. | |
| In particular, if you want to match a backslash, you write \f(CI\(rs\(rs\fP. | |
| .sp | |
| Only ASCII digits and letters have any special meaning after a backslash. All | |
| other characters (in particular, those whose code points are greater than 127) | |
| are treated as literals. | |
| .sp | |
| If you want to treat all characters in a sequence as literals, you can do so by | |
| putting them between \f(CI\(rsQ\fP and \f(CI\(rsE\fP. Note that this includes white space even when | |
| the \f(CBPCRE2_EXTENDED\fP option is set so that most other white space is ignored. The | |
| behaviour is different from Perl in that $ and @ are handled as literals in | |
| \f(CI\(rsQ...\(rsE\fP sequences in PCRE2, whereas in Perl, $ and @ cause variable | |
| interpolation. Also, Perl does "double\-quotish backslash interpolation" on any | |
| backslashes between \f(CI\(rsQ\fP and \f(CI\(rsE\fP which, its documentation says, "may lead to | |
| confusing results". PCRE2 treats a backslash between \f(CI\(rsQ\fP and \f(CI\(rsE\fP just like any | |
| other character. Note the following examples: | |
| .TS | |
| allbox tab(:); | |
| ltB ltB ltB. | |
| T{ | |
| .sp | |
| Pattern | |
| T}:T{ | |
| .sp | |
| PCRE2 matches | |
| T}:T{ | |
| .sp | |
| Perl matches | |
| T} | |
| .T& | |
| lt lt lt. | |
| T{ | |
| .sp | |
| \f(CI\(rsQabc$xyz\(rsE\fP | |
| T}:T{ | |
| .sp | |
| \f(CIabc$xyz\fP | |
| T}:T{ | |
| .sp | |
| \f(CIabc\fP followed by the contents of \f(CR$xyz\fP | |
| T} | |
| T{ | |
| .sp | |
| \f(CI\(rsQabc\(rs$xyz\(rsE\fP | |
| T}:T{ | |
| .sp | |
| \f(CIabc\(rs$xyz\fP | |
| T}:T{ | |
| .sp | |
| \f(CIabc\(rs$xyz\fP | |
| T} | |
| T{ | |
| .sp | |
| \f(CI\(rsQabc\(rsE\(rs$\(rsQxyz\(rsE\fP | |
| T}:T{ | |
| .sp | |
| \f(CIabc$xyz\fP | |
| T}:T{ | |
| .sp | |
| \f(CIabc$xyz\fP | |
| T} | |
| T{ | |
| .sp | |
| \f(CI\(rsQA\(rsB\(rsE\fP | |
| T}:T{ | |
| .sp | |
| \f(CIA\(rsB\fP | |
| T}:T{ | |
| .sp | |
| \f(CIA\(rsB\fP | |
| T} | |
| T{ | |
| .sp | |
| \f(CI\(rsQ\(rs\(rsE\fP | |
| T}:T{ | |
| .sp | |
| \f(CI\(rs\fP | |
| T}:T{ | |
| .sp | |
| \f(CI\(rs\(rsE\fP | |
| T} | |
| .TE | |
| .sp | |
| .sp | |
| The \f(CI\(rsQ...\(rsE\fP sequence is recognized both inside and outside character classes. | |
| An isolated \f(CI\(rsE\fP that is not preceded by \f(CI\(rsQ\fP is ignored. If \f(CI\(rsQ\fP is not followed | |
| by \f(CI\(rsE\fP later in the pattern, the literal interpretation continues to the end of | |
| the pattern (that is, \f(CI\(rsE\fP is assumed at the end). If the isolated \f(CI\(rsQ\fP is inside | |
| a character class, this causes an error, because the character class is then | |
| not terminated by a closing square bracket. | |
| .sp | |
| Another difference from Perl is that any appearance of \f(CI\(rsQ\fP or \f(CI\(rsE\fP inside what | |
| might otherwise be a quantifier causes PCRE2 not to recognize the sequence as a | |
| quantifier. Perl recognizes a quantifier if (redundantly) either of the numbers | |
| is inside \f(CI\(rsQ...\(rsE\fP, but not if the separating comma is. When not recognized as | |
| a quantifier a sequence such as \f(CI{\(rsQ1\(rsE,2}\fP is treated as the literal string | |
| \f(CI{1,2}\fP. | |
| .SS "Non\-printing characters" | |
| .sp | |
| A second use of backslash provides a way of encoding non\-printing characters | |
| in patterns in a visible manner. There is no restriction on the appearance of | |
| non\-printing characters in a pattern, but when a pattern is being prepared by | |
| text editing, it is often easier to use one of the following escape sequences | |
| instead of the binary character it represents. In an ASCII or Unicode | |
| environment, these escapes are as follows: | |
| .sp | |
| .RS 4 | |
| .PD 0 | |
| .TP 21 | |
| \f(CI\(rsa\fP | |
| .ad l | |
| alarm, that is, the BEL character (\f(CR0x07\fP) | |
| .TP 21 | |
| \f(CI\(rsc\fP\f(CIx\fP | |
| .ad l | |
| "control\-\fIx\fP", where \fIx\fP is a non\-control ASCII character | |
| .TP 21 | |
| \f(CI\(rse\fP | |
| .ad l | |
| escape (\f(CR0x1B\fP) | |
| .TP 21 | |
| \f(CI\(rsf\fP | |
| .ad l | |
| form feed (\f(CR0x0C\fP) | |
| .TP 21 | |
| \f(CI\(rsn\fP | |
| .ad l | |
| linefeed (\f(CR0x0A\fP) | |
| .TP 21 | |
| \f(CI\(rsr\fP | |
| .ad l | |
| carriage return (\f(CR0x0D\fP) (but see below) | |
| .TP 21 | |
| \f(CI\(rst\fP | |
| .ad l | |
| tab (\f(CR0x09\fP) | |
| .TP 21 | |
| \f(CI\(rs0\fP\f(CIdd\fP | |
| .ad l | |
| character with octal code 0\fIdd\fP | |
| .TP 21 | |
| \f(CI\(rs\fP\f(CIddd\fP | |
| .ad l | |
| character with octal code \fIddd\fP, or back reference | |
| .TP 21 | |
| \f(CI\(rso{\fP\f(CIddd..\fP\f(CI}\fP | |
| .ad l | |
| character with octal code \fIddd..\fP | |
| .TP 21 | |
| \f(CI\(rsx\fP\f(CIhh\fP | |
| .ad l | |
| character with hex code \fIhh\fP | |
| .TP 21 | |
| \f(CI\(rsx{\fP\f(CIhhh..\fP\f(CI}\fP | |
| .ad l | |
| character with hex code \fIhhh..\fP | |
| .TP 21 | |
| \f(CI\(rsN{U+\fP\f(CIhhh..\fP\f(CI}\fP | |
| .ad l | |
| character with Unicode hex code point \fIhhh..\fP | |
| .PD | |
| .RE | |
| .PP | |
| .ad l | |
| .sp | |
| A description of how back references work is given | |
| later, | |
| following the discussion of | |
| parenthesized groups. | |
| .sp | |
| By default, after \f(CI\(rsx\fP that is not followed by {, one or two hexadecimal | |
| digits are read (letters can be in upper or lower case). If the character that | |
| follows \f(CI\(rsx\fP is neither { nor a hexadecimal digit, an error occurs. This is | |
| different from Perl\(cqs default behaviour, which generates a NUL character, but | |
| is in line with the behaviour of Perl\(cqs \*(Aqstrict\*(Aq mode in re. | |
| .sp | |
| Any number of hexadecimal digits may appear between \f(CI\(rsx{\fP and \f(CI}\fP. If a character | |
| other than a hexadecimal digit appears between \f(CI\(rsx{\fP and \f(CI}\fP, or if there is no | |
| terminating \f(CI}\fP, an error occurs. | |
| .sp | |
| Characters whose code points are less than 256 can be defined by either of the | |
| two syntaxes for \f(CI\(rsx\fP or by an octal sequence. There is no difference in the way | |
| they are handled. For example, \f(CI\(rsxdc\fP is exactly the same as \f(CI\(rsx{dc}\fP or \f(CI\(rs334\fP. | |
| However, using the braced versions does make such sequences easier to read. | |
| .sp | |
| Support is available for some ECMAScript (JavaScript) escape sequences via | |
| two compile\-time options. If \f(CBPCRE2_ALT_BSUX\fP is set, the sequence \f(CI\(rsx\fP followed | |
| by \f(CI{\fP is not recognized. Only if \f(CI\(rsx\fP is followed by two hexadecimal digits is it | |
| recognized as a character escape. Otherwise it is interpreted as a literal \f(CIx\fP | |
| character. In this mode, support for code points greater than 256 is provided | |
| by \f(CI\(rsu\fP, which must be followed by four hexadecimal digits; otherwise it is | |
| interpreted as a literal \f(CIu\fP character. | |
| .sp | |
| \f(CBPCRE2_EXTRA_ALT_BSUX\fP has the same effect as \f(CBPCRE2_ALT_BSUX\fP and, in addition, | |
| \f(CI\(rsu{hhh..}\fP is recognized as the character specified by hexadecimal code point. | |
| There may be any number of hexadecimal digits, but unlike other places that | |
| also use curly brackets, spaces are not allowed and would result in the string | |
| being interpreted as a literal. This syntax is from ECMAScript 6. | |
| .sp | |
| The \f(CI\(rsN{U+\fP\f(CIhhh...\fP\f(CI}\fP escape sequence is recognized only when PCRE2 is operating in | |
| UTF mode. Perl also uses \f(CI\(rsN{\fP\f(CIname\fP\f(CI}\fP to specify characters by Unicode name; PCRE2 | |
| does not support this. Note that when \f(CI\(rsN\fP is not followed by an opening brace | |
| (curly bracket) it has an entirely different meaning, matching any character | |
| that is not a newline. | |
| .sp | |
| There are some legacy applications where the escape sequence \f(CI\(rsr\fP is expected to | |
| match a newline. If the \f(CBPCRE2_EXTRA_ESCAPED_CR_IS_LF\fP option is set, \f(CI\(rsr\fP in a | |
| pattern is converted to \f(CI\(rsn\fP so that it matches a LF (linefeed) instead of a CR | |
| (carriage return) character. | |
| .sp | |
| An error occurs if \f(CI\(rsc\fP is not followed by a character whose ASCII code point | |
| is in the range 32 to 126. The precise effect of \f(CI\(rsc\fP\f(CIx\fP is as follows: if \fIx\fP is a | |
| lower case letter, it is converted to upper case. Then bit 6 of the character | |
| (\f(CR0x40\fP) is inverted. Thus \f(CI\(rscA\fP to \f(CI\(rscZ\fP become \f(CR0x01\fP to \f(CR0x1A\fP (A is 41, Z is | |
| 5A), but \f(CI\(rsc{\fP becomes \f(CR0x3B\fP ({ is 7B), and \f(CI\(rsc;\fP becomes \f(CR0x7B\fP (; is 3B). If | |
| the code unit following \f(CI\(rsc\fP has a code point less than 32 or greater than 126, | |
| a compile\-time error occurs. | |
| .sp | |
| For differences in the way some escapes behave in EBCDIC environments, | |
| see section EBCDIC ENVIRONMENTS | |
| below. | |
| .SS "Octal escapes and back references" | |
| .sp | |
| The escape \f(CI\(rso\fP must be followed by a sequence of octal digits, enclosed in | |
| braces. An error occurs if this is not the case. This escape provides a way of | |
| specifying character code points as octal numbers greater than 0777, and it | |
| also allows octal numbers and backreferences to be unambiguously distinguished. | |
| .sp | |
| If braces are not used, after \f(CI\(rs0\fP up to two further octal digits are read. | |
| However, if the \f(CBPCRE2_EXTRA_NO_BS0\fP option is set, at least one more octal digit | |
| must follow \f(CI\(rs0\fP (use \f(CI\(rs00\fP to generate a NUL character). Make sure you supply | |
| two digits after the initial zero if the pattern character that follows is | |
| itself an octal digit. | |
| .sp | |
| Inside a character class, when a backslash is followed by any octal digit, up | |
| to three octal digits are read to generate a code point. Any subsequent digits | |
| stand for themselves. The sequences \f(CI\(rs8\fP and \f(CI\(rs9\fP are treated as the literal | |
| characters \f(CI8\fP and \f(CI9\fP. | |
| .sp | |
| Outside a character class, Perl\(cqs handling of a backslash followed by a digit | |
| other than 0 is complicated by ambiguity, and Perl has changed over time, | |
| causing PCRE2 also to change. From PCRE2 release 10.45 there is an option | |
| called \f(CBPCRE2_EXTRA_PYTHON_OCTAL\fP that causes PCRE2 to use Python\(cqs unambiguous | |
| rules. The next two subsections describe the two sets of rules. | |
| .sp | |
| For greater clarity and unambiguity, it is best to avoid following backslash by a | |
| digit greater than zero. Instead, use \f(CI\(rso{...}\fP or \f(CI\(rsx{...}\fP | |
| to specify numerical | |
| character code points, and \f(CI\(rsg{...}\fP to specify backreferences. | |
| .SS "Perl rules for non\-class backslash 1\-9" | |
| .sp | |
| All the digits that follow the backslash are read as a decimal number. If the | |
| number is less than 10, begins with the digit 8 or 9, or if there are at least | |
| that many previous capture groups in the expression, the entire sequence is | |
| taken as a back reference. Otherwise, up to three octal digits are read to form | |
| a character code. For example: | |
| .sp | |
| .RS 4 | |
| .PD 0 | |
| .TP 7 | |
| \f(CI\(rs040\fP | |
| .ad l | |
| is another way of writing an ASCII space | |
| .TP 7 | |
| \f(CI\(rs40\fP | |
| .ad l | |
| is the same, provided there are fewer than 40 previous capture groups | |
| .TP 7 | |
| \f(CI\(rs7\fP | |
| .ad l | |
| is always a backreference | |
| .TP 7 | |
| \f(CI\(rs11\fP | |
| .ad l | |
| might be a backreference, or another way of writing a tab | |
| .TP 7 | |
| \f(CI\(rs011\fP | |
| .ad l | |
| is always a tab | |
| .TP 7 | |
| \f(CI\(rs0113\fP | |
| .ad l | |
| is a tab followed by the character "3" | |
| .TP 7 | |
| \f(CI\(rs113\fP | |
| .ad l | |
| might be a backreference, otherwise the character with octal code 113 | |
| .TP 7 | |
| \f(CI\(rs377\fP | |
| .ad l | |
| might be a backreference, otherwise the value 255 (decimal) | |
| .TP 7 | |
| \f(CI\(rs81\fP | |
| .ad l | |
| is always a backreference | |
| .PD | |
| .RE | |
| .PP | |
| .ad l | |
| .sp | |
| Note that octal values of 100 or greater that are specified using this syntax | |
| must not be introduced by a leading zero, because no more than three octal | |
| digits are ever read. | |
| .SS "Python rules for non\-class backslash 1\-9" | |
| .sp | |
| If there are at least three octal digits after the backslash, exactly three are | |
| read as an octal code point number, but the value must be no greater than | |
| 377, even in modes where higher code point values are supported. Any | |
| subsequent digits stand for themselves. If there are fewer than three octal | |
| digits, the sequence is taken as a decimal back reference. Thus, for example, | |
| \f(CI\(rs12\fP is always a back reference, independent of how many captures there are in | |
| the pattern. An error is generated for a reference to a non\-existent capturing | |
| group. | |
| .SS "Constraints on character values" | |
| .sp | |
| Characters that are specified using octal or hexadecimal numbers are | |
| limited to certain values, as follows: | |
| .sp | |
| .RS 4 | |
| .PD 0 | |
| .TP 20 | |
| 8\-bit non\-UTF mode | |
| .ad l | |
| No greater than \f(CR0xff\fP | |
| .TP 20 | |
| 16\-bit non\-UTF mode | |
| .ad l | |
| No greater than \f(CR0xffff\fP | |
| .TP 20 | |
| 32\-bit non\-UTF mode | |
| .ad l | |
| No greater than \f(CR0xffffffff\fP | |
| .TP 20 | |
| All UTF modes | |
| .ad l | |
| No greater than \f(CR0x10ffff\fP and a valid code point | |
| .PD | |
| .RE | |
| .PP | |
| .ad l | |
| .sp | |
| Invalid Unicode code points are all those in the range \f(CR0xd800\fP to \f(CR0xdfff\fP (the | |
| so\-called "surrogate" code points). The check for these can be disabled by the | |
| caller of \f(CBpcre2_compile()\fP by setting the option | |
| \f(CBPCRE2_EXTRA_ALLOW_SURROGATE_ESCAPES\fP. However, this is possible only in UTF\-8 | |
| and UTF\-32 modes, because these values are not representable in UTF\-16. | |
| .SS "Escape sequences in character classes" | |
| .sp | |
| All the sequences that define a single character value can be used both inside | |
| and outside character classes. In addition, inside a character class, \f(CI\(rsb\fP is | |
| interpreted as the backspace character (\f(CR0x08\fP). | |
| .sp | |
| When not followed by an opening brace, \f(CI\(rsN\fP is not allowed in a character class. | |
| \f(CI\(rsB\fP, \f(CI\(rsR\fP, and \f(CI\(rsX\fP are not special inside a character class. Like other | |
| unrecognized alphabetic escape sequences, they cause an error. Outside a | |
| character class, these sequences have different meanings. | |
| .SS "Unsupported escape sequences" | |
| .sp | |
| In Perl, the sequences \f(CI\(rsF\fP, \f(CI\(rsl\fP, \f(CI\(rsL\fP, \f(CI\(rsu\fP, and \f(CI\(rsU\fP are recognized by its string | |
| handler and used to modify the case of following characters. By default, PCRE2 | |
| does not support these escape sequences in patterns. However, if either of the | |
| \f(CBPCRE2_ALT_BSUX\fP or \f(CBPCRE2_EXTRA_ALT_BSUX\fP options is set, \f(CI\(rsU\fP matches a \f(CIU\fP | |
| character, and \f(CI\(rsu\fP can be used to define a character by code point, as | |
| described above. | |
| .SS "Absolute and relative backreferences" | |
| .sp | |
| The sequence \f(CI\(rsg\fP followed by a signed or unsigned number, optionally enclosed | |
| in braces, is an absolute or relative backreference. A named backreference | |
| can be coded as \f(CI\(rsg{\fP\f(CIname\fP\f(CI}\fP. Backreferences are discussed | |
| later, | |
| following the discussion of | |
| parenthesized groups. | |
| .SS "Absolute and relative subroutine calls" | |
| .sp | |
| For compatibility with Oniguruma, the non\-Perl syntax \f(CI\(rsg\fP followed by a name or | |
| a number enclosed either in angle brackets or single quotes, is an alternative | |
| syntax for referencing a capture group as a subroutine. Details are discussed | |
| later. | |
| Note that \f(CI\(rsg{...}\fP (Perl syntax) and \f(CI\(rsg<...>\fP (Oniguruma syntax) are \fInot\fP | |
| synonymous. The former is a backreference; the latter is a | |
| subroutine | |
| call. | |
| .SS "Generic character types" | |
| .sp | |
| Another use of backslash is for specifying generic character types: | |
| .sp | |
| .RS 4 | |
| .PD 0 | |
| .TP 7 | |
| \f(CI\(rsd\fP | |
| .ad l | |
| Any decimal digit. | |
| .TP 7 | |
| \f(CI\(rsD\fP | |
| .ad l | |
| Any character that is not a decimal digit. | |
| .TP 7 | |
| \f(CI\(rsh\fP | |
| .ad l | |
| Any horizontal white space character. | |
| .TP 7 | |
| \f(CI\(rsH\fP | |
| .ad l | |
| Any character that is not a horizontal white space character. | |
| .TP 7 | |
| \f(CI\(rsN\fP | |
| .ad l | |
| Any character that is not a newline. | |
| .TP 7 | |
| \f(CI\(rss\fP | |
| .ad l | |
| Any white space character. | |
| .TP 7 | |
| \f(CI\(rsS\fP | |
| .ad l | |
| Any character that is not a white space character. | |
| .TP 7 | |
| \f(CI\(rsv\fP | |
| .ad l | |
| Any vertical white space character. | |
| .TP 7 | |
| \f(CI\(rsV\fP | |
| .ad l | |
| Any character that is not a vertical white space character. | |
| .TP 7 | |
| \f(CI\(rsw\fP | |
| .ad l | |
| Any "word" character. | |
| .TP 7 | |
| \f(CI\(rsW\fP | |
| .ad l | |
| Any "non\-word" character. | |
| .PD | |
| .RE | |
| .PP | |
| .ad l | |
| .sp | |
| The \f(CI\(rsN\fP escape sequence has the same meaning as | |
| the \f(CI.\fP metacharacter | |
| when \f(CBPCRE2_DOTALL\fP is not set, but setting \f(CBPCRE2_DOTALL\fP does not change the | |
| meaning of \f(CI\(rsN\fP. Note that when \f(CI\(rsN\fP is followed by an opening brace it has a | |
| different meaning. See the section Non\-printing characters | |
| above for details. Perl also uses \f(CI\(rsN{\fP\f(CIname\fP\f(CI}\fP to specify characters by Unicode | |
| name; PCRE2 does not support this. | |
| .sp | |
| Each pair of lower and upper case escape sequences partitions the complete set | |
| of characters into two disjoint sets. Any given character matches one, and only | |
| one, of each pair. The sequences can appear both inside and outside character | |
| classes. They each match one character of the appropriate type. If the current | |
| matching point is at the end of the subject string, all of them fail, because | |
| there is no character to match. | |
| .sp | |
| The default \f(CI\(rss\fP characters are HT (9), LF (10), VT (11), FF (12), CR (13), and | |
| space (32), which are defined as white space in the "C" locale. This list may | |
| vary if locale\-specific matching is taking place. For example, in some locales | |
| the "non\-breaking space" character (\f(CR0xA0\fP) is recognized as white space, and in | |
| others the VT character is not. | |
| .sp | |
| A "word" character is an underscore or any character that is a letter or digit. | |
| By default, the definition of letters and digits is controlled by PCRE2\(cqs | |
| low\-valued character tables, and may vary if locale\-specific matching is taking | |
| place (see | |
| "Locale support" | |
| in the | |
| \f(CRpcre2api\fP | |
| page). For example, in a French locale such as "fr_FR" in Unix\-like systems, | |
| or "french" in Windows, some character codes greater than 127 are used for | |
| accented letters, and these are then matched by \f(CI\(rsw\fP. The use of locales with | |
| Unicode is discouraged. | |
| .sp | |
| By default, characters whose code points are greater than 127 never match \f(CI\(rsd\fP, | |
| \f(CI\(rss\fP, or \f(CI\(rsw\fP, and always match \f(CI\(rsD\fP, \f(CI\(rsS\fP, and \f(CI\(rsW\fP, although this may be different | |
| for characters in the range 128\(en255 when locale\-specific matching is happening. | |
| These escape sequences retain their original meanings from before Unicode | |
| support was available, mainly for efficiency reasons. If the \f(CBPCRE2_UCP\fP option | |
| is set, the behaviour is changed so that Unicode properties are used to | |
| determine character types, as follows: | |
| .sp | |
| .RS 4 | |
| .PD 0 | |
| .TP 7 | |
| \f(CI\(rsd\fP | |
| .ad l | |
| Any character that matches \f(CI\(rsp{Nd}\fP (decimal digit). | |
| .TP 7 | |
| \f(CI\(rss\fP | |
| .ad l | |
| Any character that matches \f(CI\(rsp{Z}\fP, \f(CI\(rsh\fP, or \f(CI\(rsv\fP. | |
| .TP 7 | |
| \f(CI\(rsw\fP | |
| .ad l | |
| Any character that matches \f(CI\(rsp{L}\fP, \f(CI\(rsp{N}\fP, \f(CI\(rsp{Mn}\fP, or \f(CI\(rsp{Pc}\fP. | |
| .PD | |
| .RE | |
| .PP | |
| .ad l | |
| .sp | |
| The addition of \f(CI\(rsp{Mn}\fP (non\-spacing mark) and the replacement of an explicit | |
| test for underscore with a test for \f(CI\(rsp{Pc}\fP (connector punctuation) happened in | |
| PCRE2 release 10.43. This brings PCRE2 into line with Perl. | |
| .sp | |
| The upper case escapes match the inverse sets of characters. Note that \f(CI\(rsd\fP | |
| matches only decimal digits, whereas \f(CI\(rsw\fP matches any Unicode digit, as well as | |
| other character categories. Note also that \f(CBPCRE2_UCP\fP affects \f(CI\(rsb\fP, and | |
| \f(CI\(rsB\fP because they are defined in terms of \f(CI\(rsw\fP and \f(CI\(rsW\fP. Matching these sequences | |
| is noticeably slower when \f(CBPCRE2_UCP\fP is set. | |
| .sp | |
| The effect of \f(CBPCRE2_UCP\fP on any one of these escape sequences can be negated by | |
| the options \f(CBPCRE2_EXTRA_ASCII_BSD\fP, \f(CBPCRE2_EXTRA_ASCII_BSS\fP, and | |
| \f(CBPCRE2_EXTRA_ASCII_BSW\fP, respectively. These options can be set and reset within | |
| a pattern by means of an internal option setting | |
| (see below). | |
| .sp | |
| The sequences \f(CI\(rsh\fP, \f(CI\(rsH\fP, \f(CI\(rsv\fP, and \f(CI\(rsV\fP, in contrast to the other sequences, which | |
| match only ASCII characters by default, always match a specific list of code | |
| points, whether or not \f(CBPCRE2_UCP\fP is set. The horizontal space characters are: | |
| .sp | |
| .RS 4 | |
| .PD 0 | |
| .TP 7 | |
| \f(CRU+0009\fP | |
| .ad l | |
| Horizontal tab (HT) | |
| .TP 7 | |
| \f(CRU+0020\fP | |
| .ad l | |
| Space | |
| .TP 7 | |
| \f(CRU+00A0\fP | |
| .ad l | |
| Non\-break space | |
| .TP 7 | |
| \f(CRU+1680\fP | |
| .ad l | |
| Ogham space mark | |
| .TP 7 | |
| \f(CRU+180E\fP | |
| .ad l | |
| Mongolian vowel separator | |
| .TP 7 | |
| \f(CRU+2000\fP | |
| .ad l | |
| En quad | |
| .TP 7 | |
| \f(CRU+2001\fP | |
| .ad l | |
| Em quad | |
| .TP 7 | |
| \f(CRU+2002\fP | |
| .ad l | |
| En space | |
| .TP 7 | |
| \f(CRU+2003\fP | |
| .ad l | |
| Em space | |
| .TP 7 | |
| \f(CRU+2004\fP | |
| .ad l | |
| Three\-per\-em space | |
| .TP 7 | |
| \f(CRU+2005\fP | |
| .ad l | |
| Four\-per\-em space | |
| .TP 7 | |
| \f(CRU+2006\fP | |
| .ad l | |
| Six\-per\-em space | |
| .TP 7 | |
| \f(CRU+2007\fP | |
| .ad l | |
| Figure space | |
| .TP 7 | |
| \f(CRU+2008\fP | |
| .ad l | |
| Punctuation space | |
| .TP 7 | |
| \f(CRU+2009\fP | |
| .ad l | |
| Thin space | |
| .TP 7 | |
| \f(CRU+200A\fP | |
| .ad l | |
| Hair space | |
| .TP 7 | |
| \f(CRU+202F\fP | |
| .ad l | |
| Narrow no\-break space | |
| .TP 7 | |
| \f(CRU+205F\fP | |
| .ad l | |
| Medium mathematical space | |
| .TP 7 | |
| \f(CRU+3000\fP | |
| .ad l | |
| Ideographic space | |
| .PD | |
| .RE | |
| .PP | |
| .ad l | |
| .sp | |
| The vertical space characters are: | |
| .sp | |
| .RS 4 | |
| .PD 0 | |
| .TP 7 | |
| \f(CRU+000A\fP | |
| .ad l | |
| Linefeed (LF) | |
| .TP 7 | |
| \f(CRU+000B\fP | |
| .ad l | |
| Vertical tab (VT) | |
| .TP 7 | |
| \f(CRU+000C\fP | |
| .ad l | |
| Form feed (FF) | |
| .TP 7 | |
| \f(CRU+000D\fP | |
| .ad l | |
| Carriage return (CR) | |
| .TP 7 | |
| \f(CRU+0085\fP | |
| .ad l | |
| Next line (NEL) | |
| .TP 7 | |
| \f(CRU+2028\fP | |
| .ad l | |
| Line separator | |
| .TP 7 | |
| \f(CRU+2029\fP | |
| .ad l | |
| Paragraph separator | |
| .PD | |
| .RE | |
| .PP | |
| .ad l | |
| .sp | |
| In 8\-bit, non\-UTF\-8 mode, only the characters with code points less than 256 | |
| are relevant. | |
| .SS "Newline sequences" | |
| .sp | |
| Outside a character class, by default, the escape sequence \f(CI\(rsR\fP matches any | |
| Unicode newline sequence. In 8\-bit non\-UTF\-8 mode \f(CI\(rsR\fP is equivalent to the | |
| following: | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CI(?>\(rsr\(rsn|\(rsn|\(rsx0b|\(rsf|\(rsr|\(rsx85)\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| This is an example of an "atomic group", details of which are given | |
| below. | |
| This particular group matches either the two\-character sequence CR followed by | |
| LF, or one of the single characters LF (linefeed, \f(CRU+000A\fP), VT (vertical tab, | |
| \f(CRU+000B\fP), FF (form feed, \f(CRU+000C\fP), CR (carriage return, \f(CRU+000D\fP), or NEL (next | |
| line, \f(CRU+0085\fP). Because this is an atomic group, the two\-character sequence is | |
| treated as a single unit that cannot be split. | |
| .sp | |
| In other modes, two additional characters whose code points are greater than 255 | |
| are added: LS (line separator, \f(CRU+2028\fP) and PS (paragraph separator, \f(CRU+2029\fP). | |
| Unicode support is not needed for these characters to be recognized. | |
| .sp | |
| It is possible to restrict \f(CI\(rsR\fP to match only CR, LF, or CRLF (instead of the | |
| complete set of Unicode line endings) by setting the option \f(CBPCRE2_BSR_ANYCRLF\fP | |
| at compile time. (BSR is an abbreviation for "backslash R".) This can be made | |
| the default when PCRE2 is built; if this is the case, the other behaviour can | |
| be requested via the \f(CBPCRE2_BSR_UNICODE\fP option. It is also possible to specify | |
| these settings by starting a pattern string with one of the following | |
| sequences: | |
| .sp | |
| .RS 4 | |
| .PD 0 | |
| .TP 15 | |
| \f(CI(*BSR_ANYCRLF)\fP | |
| .ad l | |
| CR, LF, or CRLF only. | |
| .TP 15 | |
| \f(CI(*BSR_UNICODE)\fP | |
| .ad l | |
| Any Unicode newline sequence. | |
| .PD | |
| .RE | |
| .PP | |
| .ad l | |
| .sp | |
| These override the default and the options given to the compiling function. | |
| Note that these special settings, which are not Perl\-compatible, are recognized | |
| only at the very start of a pattern, and that they must be in upper case. If | |
| more than one of them is present, the last one is used. They can be combined | |
| with a change of newline convention; for example, a pattern can start with: | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CI(*ANY)(*BSR_ANYCRLF)\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| They can also be combined with the \f(CI(*UTF)\fP or \f(CI(*UCP)\fP special sequences. Inside a | |
| character class, \f(CI\(rsR\fP is treated as an unrecognized escape sequence, and causes | |
| an error. | |
| .SS "Unicode character properties" | |
| .sp | |
| When PCRE2 is built with Unicode support (the default), three additional escape | |
| sequences that match characters with specific properties are available. They | |
| can be used in any mode, though in 8\-bit and 16\-bit non\-UTF modes these | |
| sequences are of course limited to testing characters whose code points are | |
| less than \f(CRU+0100\fP or \f(CRU+10000\fP, respectively. In 32\-bit non\-UTF mode, code points | |
| greater than \f(CR0x10ffff\fP (the Unicode limit) may be encountered. These are all | |
| treated as being in the Unknown script and with an unassigned type. | |
| .sp | |
| Matching characters by Unicode property is not fast, because PCRE2 has to do a | |
| multistage table lookup in order to find a character\(cqs property. That is why | |
| the traditional escape sequences such as \f(CI\(rsd\fP and \f(CI\(rsw\fP do not use Unicode | |
| properties in PCRE2 by default, though you can make them do so by setting the | |
| \f(CBPCRE2_UCP\fP option or by starting the pattern with \f(CI(*UCP)\fP. | |
| .sp | |
| The extra escape sequences that provide property support are: | |
| .sp | |
| .RS 4 | |
| .PD 0 | |
| .TP 13 | |
| \f(CI\(rsp{\fP\f(CIxx\fP\f(CI}\fP | |
| .ad l | |
| a character with the \fIxx\fP property | |
| .TP 13 | |
| \f(CI\(rsP{\fP\f(CIxx\fP\f(CI}\fP | |
| .ad l | |
| a character without the \fIxx\fP property | |
| .TP 13 | |
| \f(CI\(rsX\fP | |
| .ad l | |
| a Unicode extended grapheme cluster | |
| .PD | |
| .RE | |
| .PP | |
| .ad l | |
| .sp | |
| For compatibility with Perl, negation can be specified by including a | |
| circumflex between the opening brace and the property. For example, \f(CI\(rsp{^Lu}\fP is | |
| the same as \f(CI\(rsP{Lu}\fP. | |
| .sp | |
| In accordance with Unicode\(cqs "loose matching" rules, ASCII white space | |
| characters, hyphens, and underscores are ignored in the properties represented | |
| by \fIxx\fP above. As well as the space character, ASCII white space can be | |
| tab, linefeed, vertical tab, formfeed, or carriage return. | |
| .sp | |
| Some properties are specified as a name only; others as a name and a value, | |
| separated by a colon or an equals sign. The names and values consist of ASCII | |
| letters and digits (with one Perl\-specific exception, see below). They are not | |
| case sensitive. Note, however, that the escapes themselves, \f(CI\(rsp\fP and \f(CI\(rsP\fP, | |
| \fIare\fP case sensitive. There are abbreviations for many names. The following | |
| examples are all equivalent: | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CI\(rsp{bidiclass=al} | |
| \(rsp{BC=al} | |
| \(rsp{ Bidi_Class : AL } | |
| \(rsp{ Bi\-di class = Al } | |
| \(rsP{ ^ Bi\-di class = Al }\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| There is support for Unicode script names, Unicode general category properties, | |
| "Any", which matches any character (including newline), Bidi_Class, a number of | |
| binary (yes/no) properties, and some special PCRE2 properties (described | |
| below). | |
| Certain other Perl properties such as "InMusicalSymbols" are not supported by | |
| PCRE2. Note that \f(CI\(rsP{Any}\fP does not match any characters, so always causes a | |
| match failure. | |
| .SS "Script properties for \f(CI\(rsp\fP and \f(CI\(rsP\fP" | |
| .sp | |
| There are three different syntax forms for matching a script. Each Unicode | |
| character has a basic script and, optionally, a list of other scripts ("Script | |
| Extensions") with which it is commonly used. Using the Adlam script as an | |
| example, \f(CI\(rsp{sc:Adlam}\fP matches characters whose basic script is Adlam, whereas | |
| \f(CI\(rsp{scx:Adlam}\fP matches, in addition, characters that have Adlam in their | |
| extensions list. The full names "script" and "script extensions" for the | |
| property types are recognized and, as for all property specifications, an | |
| equals sign is an alternative to the colon. If a script name is given without a | |
| property type, for example, \f(CI\(rsp{Adlam}\fP, it is treated as \f(CI\(rsp{scx:Adlam}\fP. Perl | |
| changed to this interpretation at release 5.26 and PCRE2 changed at release | |
| 10.40. | |
| .sp | |
| Unassigned characters (and in non\-UTF 32\-bit mode, characters with code points | |
| greater than \f(CR0x10FFFF\fP) are assigned the "Unknown" script. Others that are not | |
| part of an identified script are lumped together as "Common". The current list | |
| of recognized script names and their 4\-character abbreviations can be obtained | |
| by running this command: | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CRpcre2test \-LS\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .SS "The general category property for \f(CI\(rsp\fP and \f(CI\(rsP\fP" | |
| .sp | |
| Each character has exactly one Unicode general category property, specified by | |
| a two\-letter abbreviation. If only one letter is specified with \f(CI\(rsp\fP or \f(CI\(rsP\fP, it | |
| includes all the general category properties that start with that letter. In | |
| this case, in the absence of negation, the curly brackets in the escape | |
| sequence are optional; these two examples have the same effect: | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CI\(rsp{L} | |
| \(rspL\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| The following general category property codes are supported: | |
| .sp | |
| .RS 4 | |
| .PD 0 | |
| .TP 7 | |
| \f(CIC\fP | |
| .ad l | |
| Other | |
| .TP 7 | |
| \f(CICc\fP | |
| .ad l | |
| Control | |
| .TP 7 | |
| \f(CICf\fP | |
| .ad l | |
| Format | |
| .TP 7 | |
| \f(CICn\fP | |
| .ad l | |
| Unassigned | |
| .TP 7 | |
| \f(CICo\fP | |
| .ad l | |
| Private use | |
| .TP 7 | |
| \f(CICs\fP | |
| .ad l | |
| Surrogate | |
| .TP 7 | |
| \f(CIL\fP | |
| .ad l | |
| Letter | |
| .TP 7 | |
| \f(CILc\fP | |
| .ad l | |
| Cased letter | |
| .TP 7 | |
| \f(CILl\fP | |
| .ad l | |
| Lower case letter | |
| .TP 7 | |
| \f(CILm\fP | |
| .ad l | |
| Modifier letter | |
| .TP 7 | |
| \f(CILo\fP | |
| .ad l | |
| Other letter | |
| .TP 7 | |
| \f(CILt\fP | |
| .ad l | |
| Title case letter | |
| .TP 7 | |
| \f(CILu\fP | |
| .ad l | |
| Upper case letter | |
| .TP 7 | |
| \f(CIM\fP | |
| .ad l | |
| Mark | |
| .TP 7 | |
| \f(CIMc\fP | |
| .ad l | |
| Spacing mark | |
| .TP 7 | |
| \f(CIMe\fP | |
| .ad l | |
| Enclosing mark | |
| .TP 7 | |
| \f(CIMn\fP | |
| .ad l | |
| Non\-spacing mark | |
| .TP 7 | |
| \f(CIN\fP | |
| .ad l | |
| Number | |
| .TP 7 | |
| \f(CINd\fP | |
| .ad l | |
| Decimal number | |
| .TP 7 | |
| \f(CINl\fP | |
| .ad l | |
| Letter number | |
| .TP 7 | |
| \f(CINo\fP | |
| .ad l | |
| Other number | |
| .TP 7 | |
| \f(CIP\fP | |
| .ad l | |
| Punctuation | |
| .TP 7 | |
| \f(CIPc\fP | |
| .ad l | |
| Connector punctuation | |
| .TP 7 | |
| \f(CIPd\fP | |
| .ad l | |
| Dash punctuation | |
| .TP 7 | |
| \f(CIPe\fP | |
| .ad l | |
| Close punctuation | |
| .TP 7 | |
| \f(CIPf\fP | |
| .ad l | |
| Final punctuation | |
| .TP 7 | |
| \f(CIPi\fP | |
| .ad l | |
| Initial punctuation | |
| .TP 7 | |
| \f(CIPo\fP | |
| .ad l | |
| Other punctuation | |
| .TP 7 | |
| \f(CIPs\fP | |
| .ad l | |
| Open punctuation | |
| .TP 7 | |
| \f(CIS\fP | |
| .ad l | |
| Symbol | |
| .TP 7 | |
| \f(CISc\fP | |
| .ad l | |
| Currency symbol | |
| .TP 7 | |
| \f(CISk\fP | |
| .ad l | |
| Modifier symbol | |
| .TP 7 | |
| \f(CISm\fP | |
| .ad l | |
| Mathematical symbol | |
| .TP 7 | |
| \f(CISo\fP | |
| .ad l | |
| Other symbol | |
| .TP 7 | |
| \f(CIZ\fP | |
| .ad l | |
| Separator | |
| .TP 7 | |
| \f(CIZl\fP | |
| .ad l | |
| Line separator | |
| .TP 7 | |
| \f(CIZp\fP | |
| .ad l | |
| Paragraph separator | |
| .TP 7 | |
| \f(CIZs\fP | |
| .ad l | |
| Space separator | |
| .PD | |
| .RE | |
| .PP | |
| .ad l | |
| .sp | |
| Perl originally used the name \f(CIL&\fP for the \f(CILc\fP property. This is still supported | |
| by Perl, but discouraged. PCRE2 also still supports it. This property matches | |
| any character that has the \f(CILu\fP, \f(CILl\fP, or \f(CILt\fP property, in other words, any letter | |
| that is not classified as a modifier or "other". From release 10.45 of PCRE2 | |
| the properties \f(CILu\fP, \f(CILl\fP, and \f(CILt\fP are all treated as \f(CILc\fP when case\-independent | |
| matching is set by the \f(CBPCRE2_CASELESS\fP option or \f(CI(?i)\fP within the pattern. The | |
| other properties are not affected by caseless matching. | |
| .sp | |
| The \f(CICs\fP (Surrogate) property applies only to characters whose code points are in | |
| the range \f(CRU+D800\fP to \f(CRU+DFFF\fP. These characters are no different to any other | |
| character when PCRE2 is not in UTF mode (using the 16\-bit or 32\-bit library). | |
| However, they are not valid in Unicode strings and so cannot be tested by PCRE2 | |
| in UTF mode, unless UTF validity checking has been turned off (see the | |
| discussion of \f(CBPCRE2_NO_UTF_CHECK\fP in the | |
| \f(CRpcre2api\fP | |
| page). | |
| .sp | |
| The long synonyms for property names that Perl supports (such as \f(CI\(rsp{Letter}\fP) | |
| are not supported by PCRE2, nor is it permitted to prefix any of these | |
| properties with "Is". | |
| .sp | |
| No character that is in the Unicode table has the Cn (unassigned) property. | |
| Instead, this property is assumed for any code point that is not in the | |
| Unicode table. | |
| .SS "Binary (yes/no) properties for \f(CI\(rsp\fP and \f(CI\(rsP\fP" | |
| .sp | |
| Unicode defines a number of binary properties, that is, properties whose only | |
| values are true or false. You can obtain a list of those that are recognized by | |
| \f(CI\(rsp\fP and \f(CI\(rsP\fP, along with their abbreviations, by running this command: | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CRpcre2test \-LP\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .SS "The Bidi_Class property for \f(CI\(rsp\fP and \f(CI\(rsP\fP" | |
| .sp | |
| .RS 4 | |
| .PD 0 | |
| .TP 21 | |
| \f(CI\(rsp{Bidi_Class:\fP\f(CIclass\fP\f(CI}\fP | |
| .ad l | |
| Matches a character with the given class. | |
| .TP 21 | |
| \f(CI\(rsp{BC:\fP\f(CIclass\fP\f(CI}\fP | |
| .ad l | |
| Matches a character with the given class. | |
| .PD | |
| .RE | |
| .PP | |
| .ad l | |
| .sp | |
| The recognized classes are: | |
| .sp | |
| .RS 4 | |
| .PD 0 | |
| .TP 7 | |
| \f(CIAL\fP | |
| .ad l | |
| Arabic letter | |
| .TP 7 | |
| \f(CIAN\fP | |
| .ad l | |
| Arabic number | |
| .TP 7 | |
| \f(CIB\fP | |
| .ad l | |
| Paragraph separator | |
| .TP 7 | |
| \f(CIBN\fP | |
| .ad l | |
| Boundary neutral | |
| .TP 7 | |
| \f(CICS\fP | |
| .ad l | |
| Common separator | |
| .TP 7 | |
| \f(CIEN\fP | |
| .ad l | |
| European number | |
| .TP 7 | |
| \f(CIES\fP | |
| .ad l | |
| European separator | |
| .TP 7 | |
| \f(CIET\fP | |
| .ad l | |
| European terminator | |
| .TP 7 | |
| \f(CIFSI\fP | |
| .ad l | |
| First strong isolate | |
| .TP 7 | |
| \f(CIL\fP | |
| .ad l | |
| Left\-to\-right | |
| .TP 7 | |
| \f(CILRE\fP | |
| .ad l | |
| Left\-to\-right embedding | |
| .TP 7 | |
| \f(CILRI\fP | |
| .ad l | |
| Left\-to\-right isolate | |
| .TP 7 | |
| \f(CILRO\fP | |
| .ad l | |
| Left\-to\-right override | |
| .TP 7 | |
| \f(CINSM\fP | |
| .ad l | |
| Non\-spacing mark | |
| .TP 7 | |
| \f(CION\fP | |
| .ad l | |
| Other neutral | |
| .TP 7 | |
| \f(CIPDF\fP | |
| .ad l | |
| Pop directional format | |
| .TP 7 | |
| \f(CIPDI\fP | |
| .ad l | |
| Pop directional isolate | |
| .TP 7 | |
| \f(CIR\fP | |
| .ad l | |
| Right\-to\-left | |
| .TP 7 | |
| \f(CIRLE\fP | |
| .ad l | |
| Right\-to\-left embedding | |
| .TP 7 | |
| \f(CIRLI\fP | |
| .ad l | |
| Right\-to\-left isolate | |
| .TP 7 | |
| \f(CIRLO\fP | |
| .ad l | |
| Right\-to\-left override | |
| .TP 7 | |
| \f(CIS\fP | |
| .ad l | |
| Segment separator | |
| .TP 7 | |
| \f(CIWS\fP | |
| .ad l | |
| White space | |
| .PD | |
| .RE | |
| .PP | |
| .ad l | |
| .sp | |
| As in all property specifications, an equals sign may be used instead of a | |
| colon and the class names are case\-insensitive. Only the short names listed | |
| above are recognized; PCRE2 does not at present support any long alternatives. | |
| .SS "Extended grapheme clusters" | |
| .sp | |
| The \f(CI\(rsX\fP escape matches any number of Unicode characters that form an "extended | |
| grapheme cluster", and treats the sequence as an atomic group | |
| (see below). | |
| Unicode supports various kinds of composite character by giving each character | |
| a grapheme breaking property, and having rules that use these properties to | |
| define the boundaries of extended grapheme clusters. The rules are defined in | |
| Unicode Standard Annex 29, "Unicode Text Segmentation". Unicode 11.0.0 | |
| abandoned the use of some previous properties that had been used for emojis. | |
| Instead it introduced various emoji\-specific properties. PCRE2 uses only the | |
| Extended Pictographic property. | |
| .sp | |
| \f(CI\(rsX\fP always matches at least one character. Then it decides whether to add | |
| additional characters according to the following rules for ending a cluster: | |
| .sp | |
| .RS 4 | |
| .ie n \{\ | |
| \h'-04' 1.\h'+01'\c | |
| .\} | |
| .el \{\ | |
| . sp -1 | |
| . IP " 1." 4.2 | |
| .\} | |
| End at the end of the subject string. | |
| .RE | |
| .RS 4 | |
| .ie n \{\ | |
| \h'-04' 2.\h'+01'\c | |
| .\} | |
| .el \{\ | |
| . sp -1 | |
| . IP " 2." 4.2 | |
| .\} | |
| Do not end between CR and LF; otherwise end after any control character. | |
| .RE | |
| .RS 4 | |
| .ie n \{\ | |
| \h'-04' 3.\h'+01'\c | |
| .\} | |
| .el \{\ | |
| . sp -1 | |
| . IP " 3." 4.2 | |
| .\} | |
| Do not break Hangul (a Korean script) syllable sequences. Hangul characters | |
| are of five types: L, V, T, LV, and LVT. An L character may be followed by an | |
| L, V, LV, or LVT character; an LV or V character may be followed by a V or T | |
| character; an LVT or T character may be followed only by a T character. | |
| .RE | |
| .RS 4 | |
| .ie n \{\ | |
| \h'-04' 4.\h'+01'\c | |
| .\} | |
| .el \{\ | |
| . sp -1 | |
| . IP " 4." 4.2 | |
| .\} | |
| Do not end before extending characters or spacing marks or the zero\-width | |
| joiner (ZWJ) character. Characters with the "mark" property always have the | |
| "extend" grapheme breaking property. | |
| .RE | |
| .RS 4 | |
| .ie n \{\ | |
| \h'-04' 5.\h'+01'\c | |
| .\} | |
| .el \{\ | |
| . sp -1 | |
| . IP " 5." 4.2 | |
| .\} | |
| Do not end after prepend characters. | |
| .RE | |
| .RS 4 | |
| .ie n \{\ | |
| \h'-04' 6.\h'+01'\c | |
| .\} | |
| .el \{\ | |
| . sp -1 | |
| . IP " 6." 4.2 | |
| .\} | |
| Do not end within emoji modifier sequences or emoji ZWJ (zero\-width | |
| joiner) sequences. An emoji ZWJ sequence consists of a character with the | |
| Extended_Pictographic property, optionally followed by one or more characters | |
| with the Extend property, followed by the ZWJ character, followed by another | |
| Extended_Pictographic character. | |
| .RE | |
| .RS 4 | |
| .ie n \{\ | |
| \h'-04' 7.\h'+01'\c | |
| .\} | |
| .el \{\ | |
| . sp -1 | |
| . IP " 7." 4.2 | |
| .\} | |
| Do not break within emoji flag sequences. That is, do not break between | |
| regional indicator (RI) characters if there are an odd number of RI characters | |
| before the break point. | |
| .RE | |
| .RS 4 | |
| .ie n \{\ | |
| \h'-04' 8.\h'+01'\c | |
| .\} | |
| .el \{\ | |
| . sp -1 | |
| . IP " 8." 4.2 | |
| .\} | |
| Otherwise, end the cluster. | |
| .RE | |
| .SS "PCRE2\(cqs additional properties" | |
| .sp | |
| As well as the standard Unicode properties described above, PCRE2 supports four | |
| more that make it possible to convert traditional escape sequences such as \f(CI\(rsw\fP | |
| and \f(CI\(rss\fP to use Unicode properties. PCRE2 uses these non\-standard, non\-Perl | |
| properties internally when \f(CBPCRE2_UCP\fP is set. However, they may also be used | |
| explicitly. These properties are: | |
| .sp | |
| .RS 4 | |
| .PD 0 | |
| .TP 7 | |
| \f(CIXan\fP | |
| .ad l | |
| Any alphanumeric character | |
| .TP 7 | |
| \f(CIXps\fP | |
| .ad l | |
| Any POSIX space character | |
| .TP 7 | |
| \f(CIXsp\fP | |
| .ad l | |
| Any Perl space character | |
| .TP 7 | |
| \f(CIXwd\fP | |
| .ad l | |
| Any Perl "word" character | |
| .PD | |
| .RE | |
| .PP | |
| .ad l | |
| .sp | |
| \f(CIXan\fP matches characters that have either the \f(CIL\fP (letter) or the \f(CIN\fP (number) | |
| property. \f(CIXps\fP matches the characters tab, linefeed, vertical tab, form feed, or | |
| carriage return, and any other character that has the \f(CIZ\fP (separator) property | |
| (this includes the space character). \f(CIXsp\fP is the same as \f(CIXps\fP; in PCRE1 it used | |
| to exclude vertical tab, for Perl compatibility, but Perl changed. \f(CIXwd\fP matches | |
| the same characters as \f(CIXan\fP, plus those that match \f(CIMn\fP (non\-spacing mark) or \f(CIPc\fP | |
| (connector punctuation, which includes underscore). | |
| .sp | |
| There is another non\-standard property, \f(CIXuc\fP, which matches any character that | |
| can be represented by a Universal Character Name in C++ and other programming | |
| languages. These are the characters $, @, ` (grave accent), and all characters | |
| with Unicode code points greater than or equal to \f(CRU+00A0\fP, except for the | |
| surrogates \f(CRU+D800\fP to \f(CRU+DFFF\fP. Note that most base (ASCII) characters are | |
| excluded. (Universal Character Names are of the form \f(CI\(rsu\fP\f(CIHHHH\fP or \f(CI\(rsU\fP\f(CIHHHHHHHH\fP | |
| where H is a hexadecimal digit. Note that the \f(CIXuc\fP property does not match these | |
| sequences but the characters that they represent.) | |
| .SS "Resetting the match start" | |
| .sp | |
| In normal use, the escape sequence \f(CI\(rsK\fP causes any previously matched characters | |
| not to be included in the final matched sequence that is returned. For example, | |
| the pattern: | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CIfoo\(rsKbar\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| matches \f(CIfoobar\fP, but reports that it has matched \f(CIbar\fP. \f(CI\(rsK\fP does not interact | |
| with anchoring in any way. The pattern: | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CI^foo\(rsKbar\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| matches only when the subject begins with \f(CIfoobar\fP (in single line mode), | |
| though it again reports the matched string as \f(CIbar\fP. This feature is similar to | |
| a lookbehind assertion | |
| (described below), | |
| but the part of the pattern that precedes \f(CI\(rsK\fP is not constrained to match a | |
| limited number of characters, as is required for a lookbehind assertion. The | |
| use of \f(CI\(rsK\fP does not interfere with the setting of | |
| captured substrings. | |
| For example, when the pattern | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CI(foo)\(rsKbar\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| matches \f(CIfoobar\fP, the first substring is still set to \f(CIfoo\fP. | |
| .sp | |
| From version 5.32.0 Perl forbids the use of \f(CI\(rsK\fP in lookaround assertions. From | |
| release 10.38 PCRE2 also forbids this by default. However, the | |
| \f(CBPCRE2_EXTRA_ALLOW_LOOKAROUND_BSK\fP option can be used when calling | |
| \f(CBpcre2_compile()\fP to re\-enable the previous behaviour. When this option is | |
| set, \f(CI\(rsK\fP is acted upon when it occurs inside positive assertions, but is | |
| ignored in negative assertions. Note that when a pattern such as \f(CI(?=ab\(rsK)\fP | |
| matches, the reported start of the match can be greater than the end of the | |
| match. Using \f(CI\(rsK\fP in a lookbehind assertion at the start of a pattern can also | |
| lead to odd effects. For example, consider this pattern: | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CI(?<=\(rsKfoo)bar\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| If the subject is \f(CIfoobar\fP, a call to \f(CBpcre2_match()\fP with a starting | |
| offset of 3 succeeds and reports the matching string as \f(CIfoobar\fP, that is, the | |
| start of the reported match is earlier than where the match started. | |
| .SS "Simple assertions" | |
| .sp | |
| The final use of backslash is for certain simple assertions. An assertion | |
| specifies a condition that has to be met at a particular point in a match, | |
| without consuming any characters from the subject string. The use of | |
| groups for more complicated assertions is described | |
| below. | |
| The backslashed assertions are: | |
| .sp | |
| .RS 4 | |
| .PD 0 | |
| .TP 7 | |
| \f(CI\(rsb\fP | |
| .ad l | |
| Matches at a word boundary. | |
| .TP 7 | |
| \f(CI\(rsB\fP | |
| .ad l | |
| Matches when not at a word boundary. | |
| .TP 7 | |
| \f(CI\(rsA\fP | |
| .ad l | |
| Matches at the start of the subject. | |
| .TP 7 | |
| \f(CI\(rsZ\fP | |
| .ad l | |
| Matches at the end of the subject; also matches before a newline at the end of the subject. | |
| .TP 7 | |
| \f(CI\(rsz\fP | |
| .ad l | |
| Matches only at the end of the subject. | |
| .TP 7 | |
| \f(CI\(rsG\fP | |
| .ad l | |
| Matches at the first matching position in the subject. | |
| .PD | |
| .RE | |
| .PP | |
| .ad l | |
| .sp | |
| Inside a character class, \f(CI\(rsb\fP has a different meaning; it matches the backspace | |
| character. If any other of these assertions appears in a character class, an | |
| "invalid escape sequence" error is generated. | |
| .sp | |
| A word boundary is a position in the subject string where the current character | |
| and the previous character do not both match \f(CI\(rsw\fP or \f(CI\(rsW\fP (i.e. one matches | |
| \f(CI\(rsw\fP and the other matches \f(CI\(rsW\fP), or the start or end of the string if the | |
| first or last character matches \f(CI\(rsw\fP, respectively. When PCRE2 is built with | |
| Unicode support, the meanings of \f(CI\(rsw\fP and \f(CI\(rsW\fP can be changed by setting the | |
| \f(CBPCRE2_UCP\fP option. When this is done, it also affects \f(CI\(rsb\fP and \f(CI\(rsB\fP. Neither PCRE2 | |
| nor Perl has a separate "start of word" or "end of word" metasequence. However, | |
| whatever follows \f(CI\(rsb\fP normally determines which it is. For example, the fragment | |
| \f(CI\(rsba\fP matches \f(CIa\fP at the start of a word. | |
| .sp | |
| The \f(CI\(rsA\fP, \f(CI\(rsZ\fP, and \f(CI\(rsz\fP assertions differ from the traditional circumflex and | |
| dollar (described in the section CIRCUMFLEX AND DOLLAR) in that they only ever match at the very | |
| start and end of the subject string, whatever options are set. Thus, they are | |
| independent of multiline mode. These three assertions are not affected by the | |
| \f(CBPCRE2_NOTBOL\fP or \f(CBPCRE2_NOTEOL\fP options, which affect only the behaviour of the | |
| circumflex and dollar metacharacters. However, if the \f(CIstart_offset\fP | |
| argument of \f(CBpcre2_match()\fP is non\-zero, indicating that matching is to | |
| start at a point other than the beginning of the subject, \f(CI\(rsA\fP can never match. | |
| The difference between \f(CI\(rsZ\fP and \f(CI\(rsz\fP is that \f(CI\(rsZ\fP matches before a newline at the | |
| end of the string as well as at the very end, whereas \f(CI\(rsz\fP matches only at the | |
| end. | |
| .sp | |
| The \f(CI\(rsG\fP assertion is true only when the current matching position is at the | |
| start point of the matching process, as specified by the \f(CIstart_offset\fP | |
| argument of \f(CBpcre2_match()\fP. It differs from \f(CI\(rsA\fP when the value of | |
| \f(CIstart_offset\fP is non\-zero. By calling \f(CBpcre2_match()\fP multiple times | |
| with appropriate arguments, you can mimic Perl\(cqs /g option, and it is in this | |
| kind of implementation where \f(CI\(rsG\fP can be useful. | |
| .sp | |
| Note, however, that PCRE2\(cqs implementation of \f(CI\(rsG\fP, being true at the starting | |
| character of the matching process, is subtly different from Perl\(cqs, which | |
| defines it as true at the end of the previous match. In Perl, these can be | |
| different when the previously matched string was empty. Because PCRE2 does just | |
| one match at a time, it cannot reproduce this behaviour. | |
| .sp | |
| If all the alternatives of a pattern begin with \f(CI\(rsG\fP, the expression is anchored | |
| to the starting match position, and the "anchored" flag is set in the compiled | |
| regular expression. | |
| .SH "CIRCUMFLEX AND DOLLAR" | |
| .sp | |
| The circumflex and dollar metacharacters are zero\-width assertions. That is, | |
| they test for a particular condition being true without consuming any | |
| characters from the subject string. These two metacharacters are concerned with | |
| matching the starts and ends of lines. If the newline convention is set so that | |
| only the two\-character sequence CRLF is recognized as a newline, isolated CR | |
| and LF characters are treated as ordinary data characters, and are not | |
| recognized as newlines. | |
| .sp | |
| Outside a character class, in the default matching mode, the circumflex | |
| character is an assertion that is true only if the current matching point is at | |
| the start of the subject string. If the \f(CIstart_offset\fP argument of | |
| \f(CBpcre2_match()\fP is non\-zero, or if \f(CBPCRE2_NOTBOL\fP is set, circumflex can | |
| never match if the \f(CBPCRE2_MULTILINE\fP option is unset. Inside a character class, | |
| circumflex has an entirely different meaning | |
| (see below). | |
| .sp | |
| Circumflex need not be the first character of the pattern if a number of | |
| alternatives are involved, but it should be the first thing in each alternative | |
| in which it appears if the pattern is ever to match that branch. If all | |
| possible alternatives start with a circumflex, that is, if the pattern is | |
| constrained to match only at the start of the subject, it is said to be an | |
| "anchored" pattern. (There are also other constructs that can cause a pattern | |
| to be anchored.) | |
| .sp | |
| The dollar character is an assertion that is true only if the current matching | |
| point is at the end of the subject string, or immediately before a newline at | |
| the end of the string (by default), unless \f(CBPCRE2_NOTEOL\fP is set. Note, however, | |
| that it does not actually match the newline. Dollar need not be the last | |
| character of the pattern if a number of alternatives are involved, but it | |
| should be the last item in any branch in which it appears. Dollar has no | |
| special meaning in a character class. | |
| .sp | |
| The meaning of dollar can be changed so that it matches only at the very end of | |
| the string, by setting the \f(CBPCRE2_DOLLAR_ENDONLY\fP option at compile time. This | |
| does not affect the \f(CI\(rsZ\fP assertion. | |
| .sp | |
| The meanings of the circumflex and dollar metacharacters are changed if the | |
| \f(CBPCRE2_MULTILINE\fP option is set. When this is the case, a dollar character | |
| matches before any newlines in the string, as well as at the very end, and a | |
| circumflex matches immediately after internal newlines as well as at the start | |
| of the subject string. It does not match after a newline that ends the string, | |
| for compatibility with Perl. However, this can be changed by setting the | |
| \f(CBPCRE2_ALT_CIRCUMFLEX\fP option. | |
| .sp | |
| For example, the pattern \f(CI^abc$\fP matches the subject string \f(CIdef\(rsnabc\fP (where | |
| \f(CI\(rsn\fP represents a newline) in multiline mode, but not otherwise. Consequently, | |
| patterns that are anchored in single line mode because all branches start with | |
| ^ are not anchored in multiline mode, and a match for circumflex is possible | |
| when the \f(CIstart_offset\fP argument of \f(CBpcre2_match()\fP is non\-zero. The | |
| \f(CBPCRE2_DOLLAR_ENDONLY\fP option is ignored if \f(CBPCRE2_MULTILINE\fP is set. | |
| .sp | |
| When the newline convention (see | |
| "Newline conventions" | |
| below) recognizes the two\-character sequence CRLF as a newline, this is | |
| preferred, even if the single characters CR and LF are also recognized as | |
| newlines. For example, if the newline convention is "any", a multiline mode | |
| circumflex matches before \f(CIxyz\fP in the string \f(CIabc\(rsr\(rsnxyz\fP rather than after | |
| CR, even though CR on its own is a valid newline. (It also matches at the very | |
| start of the string, of course.) | |
| .sp | |
| Note that the sequences \f(CI\(rsA\fP, \f(CI\(rsZ\fP, and \f(CI\(rsz\fP can be used to match the start and | |
| end of the subject in both modes, and if all branches of a pattern start with | |
| \f(CI\(rsA\fP it is always anchored, whether or not \f(CBPCRE2_MULTILINE\fP is set. | |
| .SH "FULL STOP (PERIOD, DOT) AND \f(CI\(rsn\fP" | |
| .sp | |
| Outside a character class, a dot in the pattern matches any one character in | |
| the subject string except (by default) a character that signifies the end of a | |
| line. One or more characters may be specified as line terminators (see | |
| "Newline conventions" | |
| above). | |
| .sp | |
| Dot never matches a single line\-ending character. When the two\-character | |
| sequence CRLF is the only line ending, dot does not match CR if it is | |
| immediately followed by LF, but otherwise it matches all characters (including | |
| isolated CRs and LFs). When ANYCRLF is selected for line endings, no occurrences | |
| of CR of LF match dot. When all Unicode line endings are being recognized, dot | |
| does not match CR or LF or any of the other line ending characters. | |
| .sp | |
| The behaviour of dot with regard to newlines can be changed. If the | |
| \f(CBPCRE2_DOTALL\fP option is set, a dot matches any one character, without exception. | |
| If the two\-character sequence CRLF is present in the subject string, it takes | |
| two dots to match it. | |
| .sp | |
| The handling of dot is entirely independent of the handling of circumflex and | |
| dollar, the only relationship being that they both involve newlines. Dot has no | |
| special meaning in a character class. | |
| .sp | |
| The escape sequence \f(CI\(rsN\fP when not followed by an opening brace behaves like a | |
| dot, except that it is not affected by the \f(CBPCRE2_DOTALL\fP option. In other words, | |
| it matches any character except one that signifies the end of a line. | |
| .sp | |
| When \f(CI\(rsN\fP is followed by an opening brace it has a different meaning. See the | |
| section Non\-printing characters | |
| above for details. Perl also uses \f(CI\(rsN{\fP\f(CIname\fP\f(CI}\fP to specify characters by Unicode | |
| name; PCRE2 does not support this. | |
| .SH "MATCHING A SINGLE CODE UNIT" | |
| .sp | |
| Outside a character class, the escape sequence \f(CI\(rsC\fP matches any one code unit, | |
| whether or not a UTF mode is set. In the 8\-bit library, one code unit is one | |
| byte; in the 16\-bit library it is a 16\-bit unit; in the 32\-bit library it is a | |
| 32\-bit unit. Unlike a dot, \f(CI\(rsC\fP always matches line\-ending characters. The | |
| feature is provided in Perl in order to match individual bytes in UTF\-8 mode, | |
| but it is unclear how it can usefully be used. | |
| .sp | |
| Because \f(CI\(rsC\fP breaks up characters into individual code units, matching one unit | |
| with \f(CI\(rsC\fP in UTF\-8 or UTF\-16 mode means that the rest of the string may start | |
| with a malformed UTF character. This has undefined results, because PCRE2 | |
| assumes that it is matching character by character in a valid UTF string (by | |
| default it checks the subject string\(cqs validity at the start of processing | |
| unless the \f(CBPCRE2_NO_UTF_CHECK\fP or \f(CBPCRE2_MATCH_INVALID_UTF\fP option is used). | |
| .sp | |
| An application can lock out the use of \f(CI\(rsC\fP by setting the | |
| \f(CBPCRE2_NEVER_BACKSLASH_C\fP option when compiling a pattern. It is also possible to | |
| build PCRE2 with the use of \f(CI\(rsC\fP permanently disabled. | |
| .sp | |
| PCRE2 does not allow \f(CI\(rsC\fP to appear in lookbehind assertions | |
| (described below) | |
| in UTF\-8 or UTF\-16 modes, because this would make it impossible to calculate | |
| the length of the lookbehind. Neither the alternative matching function | |
| \f(CBpcre2_dfa_match()\fP nor the JIT optimizer support \f(CI\(rsC\fP in these UTF modes. | |
| The former gives a match\-time error; the latter fails to optimize and so the | |
| match is always run using the interpreter. | |
| .sp | |
| In the 32\-bit library, however, \f(CI\(rsC\fP is always supported (when not explicitly | |
| locked out) because it always matches a single code unit, whether or not UTF\-32 | |
| is specified. | |
| .sp | |
| In general, the \f(CI\(rsC\fP escape sequence is best avoided. However, one way of using | |
| it that avoids the problem of malformed UTF\-8 or UTF\-16 characters is to use a | |
| lookahead to check the length of the next character, as in this pattern, which | |
| could be used with a UTF\-8 string (ignore white space and line breaks): | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CI(?| (?=[\(rsx00\-\(rsx7f])(\(rsC) | | |
| (?=[\(rsx80\-\(rsx{7ff}])(\(rsC)(\(rsC) | | |
| (?=[\(rsx{800}\-\(rsx{ffff}])(\(rsC)(\(rsC)(\(rsC) | | |
| (?=[\(rsx{10000}\-\(rsx{1fffff}])(\(rsC)(\(rsC)(\(rsC)(\(rsC))\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| In this example, a group that starts with \f(CI(?|\fP resets the capturing parentheses | |
| numbers in each alternative (see | |
| "Duplicate Group Numbers" | |
| below). The assertions at the start of each branch check the next UTF\-8 | |
| character for values whose encoding uses 1, 2, 3, or 4 bytes, respectively. The | |
| character\(cqs individual bytes are then captured by the appropriate number of | |
| \f(CI\(rsC\fP groups. | |
| .SH "SQUARE BRACKETS AND CHARACTER CLASSES" | |
| .sp | |
| An opening square bracket introduces a character class, terminated by a closing | |
| square bracket. A closing square bracket on its own is not special by default. | |
| If a closing square bracket is required as a member of the class, it should be | |
| the first data character in the class (after an initial circumflex, if present) | |
| or escaped with a backslash. This means that, by default, an empty class cannot | |
| be defined. However, if the \f(CBPCRE2_ALLOW_EMPTY_CLASS\fP option is set, a closing | |
| square bracket at the start does end the (empty) class. | |
| .sp | |
| A character class matches a single character in the subject. A matched | |
| character must be in the set of characters defined by the class, unless the | |
| first character in the class definition is a circumflex, in which case the | |
| subject character must not be in the set defined by the class. If a circumflex | |
| is actually required as a member of the class, ensure it is not the first | |
| character, or escape it with a backslash. | |
| .sp | |
| For example, the character class \f(CI[aeiou]\fP matches any lower case English vowel, | |
| whereas \f(CI[^aeiou]\fP matches all other characters. Note that a circumflex is just a | |
| convenient notation for specifying the characters that are in the class by | |
| enumerating those that are not. A class that starts with a circumflex is not an | |
| assertion; it still consumes a character from the subject string, and therefore | |
| it fails to match if the current pointer is at the end of the string. | |
| .sp | |
| Characters in a class may be specified by their code points using \f(CI\(rso\fP, \f(CI\(rsx\fP, or | |
| \f(CI\(rsN{U+\fP\f(CIhh...\fP\f(CI}\fP in the usual way. When caseless matching is set, any letters in a | |
| class represent both their upper case and lower case versions, so for example, | |
| a caseless \f(CI[aeiou]\fP matches \f(CIA\fP as well as \f(CIa\fP, and a caseless \f(CI[^aeiou]\fP does not | |
| match \f(CIA\fP, whereas a caseful version would. Note that there are two ASCII | |
| characters, K and S, that, in addition to their lower case ASCII equivalents, | |
| are case\-equivalent with Unicode \f(CRU+212A\fP (Kelvin sign) and \f(CRU+017F\fP (long S) | |
| respectively when either \f(CBPCRE2_UTF\fP or \f(CBPCRE2_UCP\fP is set. If you do not want | |
| these ASCII/non\-ASCII case equivalences, you can suppress them by setting | |
| \f(CBPCRE2_EXTRA_CASELESS_RESTRICT\fP, either as an option in a compile context, or by | |
| including \f(CI(*CASELESS_RESTRICT)\fP or \f(CI(?r)\fP within a pattern. | |
| .sp | |
| Characters that might indicate line breaks are never treated in any special way | |
| when matching character classes, whatever line\-ending sequence is in use, and | |
| whatever setting of the \f(CBPCRE2_DOTALL\fP and \f(CBPCRE2_MULTILINE\fP options is used. A | |
| class such as \f(CI[^a]\fP always matches one of these characters. | |
| .sp | |
| The generic character type escape sequences \f(CI\(rsd\fP, \f(CI\(rsD\fP, \f(CI\(rsh\fP, \f(CI\(rsH\fP, \f(CI\(rsp\fP, \f(CI\(rsP\fP, \f(CI\(rss\fP, | |
| \f(CI\(rsS\fP, \f(CI\(rsv\fP, \f(CI\(rsV\fP, \f(CI\(rsw\fP, and \f(CI\(rsW\fP may appear in a character class, and add the | |
| characters that they match to the class. For example, \f(CI[\(rsdABCDEF]\fP matches any | |
| hexadecimal digit. In UTF modes, the \f(CBPCRE2_UCP\fP option affects the meanings of | |
| \f(CI\(rsd\fP, \f(CI\(rss\fP, \f(CI\(rsw\fP and their upper case partners, just as it does when they appear | |
| outside a character class, as described in the section | |
| Generic character types | |
| above. The escape sequence \f(CI\(rsb\fP has a different meaning inside a character | |
| class; it matches the backspace character. The sequences \f(CI\(rsB\fP, \f(CI\(rsR\fP, and \f(CI\(rsX\fP are | |
| not special inside a character class. Like any other unrecognized escape | |
| sequences, they cause an error. The same is true for \f(CI\(rsN\fP when not followed by | |
| an opening brace. | |
| .sp | |
| The minus (hyphen) character can be used to specify a range of characters in a | |
| character class. For example, \f(CI[d\-m]\fP matches any letter between d and m, | |
| inclusive. If a minus character is required in a class, it must be escaped with | |
| a backslash or appear in a position where it cannot be interpreted as | |
| indicating a range, typically as the first or last character in the class, | |
| or immediately after a range. For example, \f(CI[b\-d\-z]\fP matches letters in the range | |
| b to d, a hyphen character, or z. | |
| .sp | |
| There is some special treatment for alphabetic ranges in EBCDIC environments; | |
| see the section EBCDIC ENVIRONMENTS | |
| below. | |
| .sp | |
| Perl treats a hyphen as a literal if it appears before or after a POSIX class | |
| (see below) or before or after a character type escape such as \f(CI\(rsd\fP or \f(CI\(rsH\fP. | |
| However, unless the hyphen is the last character in the class, Perl outputs a | |
| warning in its warning mode, as this is most likely a user error. As PCRE2 has | |
| no facility for warning, an error is given in these cases. | |
| .sp | |
| It is not possible to have the literal character \f(CI]\fP as the end character of a | |
| range. A pattern such as \f(CI[W\-]46]\fP is interpreted as a class of two characters | |
| (\f(CRW\fP and \f(CR\-\fP) followed by a literal string \f(CI46]\fP, so it would match \f(CIW46]\fP or | |
| \f(CI\-46]\fP. However, if the \f(CI]\fP is escaped with a backslash it is interpreted as | |
| the end of a range, so \f(CI[W\-\(rs]46]\fP is interpreted as a class containing a range | |
| and two other characters. The octal or hexadecimal representation of \f(CI]\fP can | |
| also be used to end a range. | |
| .sp | |
| Ranges normally include all code points between the start and end characters, | |
| inclusive. They can also be used for code points specified numerically, for | |
| example \f(CI[\(rs000\-\(rs037]\fP. Ranges can include any characters that are valid for the | |
| current mode. In any UTF mode, the so\-called "surrogate" characters (those | |
| whose code points lie between \f(CR0xd800\fP and \f(CR0xdfff\fP inclusive) may not be specified | |
| explicitly by default (the \f(CBPCRE2_EXTRA_ALLOW_SURROGATE_ESCAPES\fP option disables | |
| this check). However, ranges such as \f(CI[\(rsx{d7ff}\-\(rsx{e000}]\fP, which include the | |
| surrogates, are always permitted. | |
| .sp | |
| If a range that includes letters is used when caseless matching is set, it | |
| matches the letters in either case. For example, \f(CI[W\-c]\fP is equivalent to | |
| \f(CI[][\(rs\(rs^_`wxyzabc]\fP, matched caselessly, and in a non\-UTF mode, if character | |
| tables for a French locale are in use, \f(CI[\(rsxc8\-\(rsxcb]\fP matches accented E | |
| characters in both cases. | |
| .sp | |
| A circumflex can conveniently be used with the upper case character types to | |
| specify a more restricted set of characters than the matching lower case type. | |
| For example, the class \f(CI[^\(rsW_]\fP matches any letter or digit, but not underscore, | |
| whereas \f(CI[\(rsw]\fP includes underscore. A positive character class should be read as | |
| "something OR something OR .\|.\|." and a negative class as "NOT something AND NOT | |
| something AND NOT .\|.\|.". | |
| .sp | |
| The metacharacters that are recognized in character classes are backslash, | |
| hyphen (when it can be interpreted as specifying a range), circumflex | |
| (only at the start), and the terminating closing square bracket. An opening | |
| square bracket is also special when it can be interpreted as introducing a | |
| POSIX class (see | |
| "Posix character classes" | |
| below), or a special compatibility feature (see | |
| "Compatibility feature for word boundaries" | |
| below. Escaping any non\-alphanumeric character in a class turns it into a | |
| literal, whether or not it would otherwise be a metacharacter. | |
| .SH "PERL EXTENDED CHARACTER CLASSES" | |
| .sp | |
| From release 10.45 PCRE2 supports Perl\(cqs \f(CI(?[...])\fP extended character class | |
| syntax. This can be used to perform set operations such as intersection on | |
| character classes. | |
| .sp | |
| The syntax permitted within \f(CI(?[...])\fP is quite different to ordinary character | |
| classes. Inside the extended class, there is an expression syntax consisting of | |
| "atoms", operators, and ordinary parentheses \f(CI()\fP used for grouping. Such | |
| classes always have the Perl \f(CI/xx\fP modifier (PCRE2 option \f(CBPCRE2_EXTENDED_MORE\fP) | |
| turned on within them. This means that literal space and tab characters are | |
| ignored everywhere in the class. | |
| .sp | |
| The allowed atoms are individual characters specified by escape sequences such | |
| as \f(CI\(rsn\fP or \f(CI\(rsx{123}\fP, character types such as \f(CI\(rsd\fP, POSIX classes such as | |
| \f(CI[:alpha:]\fP, and nested ordinary (non\-extended) character classes. For example, | |
| in \f(CI(?[\(rsd & [...]])\fP the nested class \f(CI[...]\fP follows the usual rules for ordinary | |
| character classes, in which parentheses are not metacharacters, and character | |
| literals and ranges are permitted. | |
| .sp | |
| Character literals and ranges may not appear outside a nested ordinary | |
| character class because they are not atoms in the extended syntax. The extended | |
| syntax does not introduce any additional escape sequences, so \f(CI(?[\(rsy])\fP is an | |
| unknown escape, as it would be in \f(CI[\(rsy]\fP. | |
| .sp | |
| In the extended syntax, \f(CI^\fP does not negate a class (except within an | |
| ordinary class nested inside an extended class); it is instead a binary | |
| operator. | |
| .sp | |
| The binary operators are \f(CI&\fP (intersection), \f(CI|\fP or \f(CI+\fP (union), \f(CI\-\fP | |
| (subtraction) and \f(CI^\fP (symmetric difference). These are left\-associative and | |
| \f(CI&\fP has higher (tighter) precedence, while the others have equal lower precedence. | |
| The one prefix unary operator is \f(CI!\fP (complement), with highest | |
| precedence. | |
| .SH "UTS#18 EXTENDED CHARACTER CLASSES" | |
| .sp | |
| The \f(CBPCRE2_ALT_EXTENDED_CLASS\fP option enables an alternative to Perl\(cqs \f(CI(?[...])\fP | |
| syntax, allowing instead extended class behaviour inside ordinary \f(CI[...]\fP | |
| character classes. This altered syntax for \f(CI[...]\fP classes is loosely described | |
| by the Unicode standard UTS#18. The \f(CBPCRE2_ALT_EXTENDED_CLASS\fP option does not | |
| prevent use of \f(CI(?[...])\fP classes; it just changes the meaning of all | |
| \f(CI[...]\fP classes that are not nested inside a Perl \f(CI(?[...])\fP class. | |
| .sp | |
| Firstly, in ordinary Perl \f(CI[...]\fP syntax, an expression such as \f(CI[a[]\fP is a | |
| character class with two literal characters \f(CIa\fP and \f(CI[\fP, but in UTS#18 extended | |
| classes the "[" character becomes an additional metacharacter within classes, | |
| denoting the start of a nested class, so a literal \f(CI[\fP must be escaped as \f(CI\(rs[\fP. | |
| .sp | |
| Secondly, within the UTS#18 extended syntax, there are operators \f(CI||\fP, \f(CI&&\fP, | |
| \f(CI\-\-\fP and \f(CI~~\fP which denote character class union, intersection, subtraction, | |
| and symmetric difference respectively. In standard Perl syntax, these would | |
| simply be needlessly\-repeated literals (except for \f(CI\-\-\fP which could be the | |
| start or end of a range). In UTS#18 extended classes these operators can be used | |
| in constructs such as \f(CI[\(rsp{L}\-\-[QW]]\fP for "Unicode letters, other than Q and W". | |
| A literal \f(CI\-\fP at the start or end of a range must be escaped, so while | |
| \f(CI[\-\-1]\fP in Perl syntax is the range from hyphen to 1, it must be | |
| escaped as \f(CI[\(rs\-\-1]\fP | |
| in UTS#18 extended classes. | |
| .sp | |
| Unlike Perl\(cqs \f(CI(?[...])\fP extended classes, the \f(CBPCRE2_EXTENDED_MORE\fP option to | |
| ignore space and tab characters is not automatically enabled for UTS#18 | |
| extended classes, but it is honoured if set. | |
| .sp | |
| Extended UTS#18 classes can be nested, and nested classes are themselves | |
| extended classes (unlike Perl, where nested classes must be simple classes). | |
| For example, \f(CI[\(rsp{L}&&[\(rsp{Thai}||\(rsp{Greek}]]\fP matches any letter that is in | |
| the Thai or Greek scripts. Note that this means that no special grouping | |
| characters (such as the parentheses used in Perl\(cqs \f(CI(?[...])\fP class syntax) are | |
| needed. | |
| .sp | |
| Individual class items (literal characters, literal ranges, properties such as | |
| \f(CI\(rsd\fP or \f(CI\(rsp{...}\fP, and nested classes) can be combined by juxtaposition or by an | |
| operator. Juxtaposition is the implicit union operator, and binds more tightly | |
| than any explicit operator. Thus a sequence of literals and/or ranges behaves | |
| as if it is enclosed in square brackets. For example, \f(CI[A\-Z0\-9&&[^E8]]\fP is the | |
| same as \f(CI[[A\-Z0\-9]&&[^E8]]\fP, which matches any upper case alphanumeric character | |
| except "E" or "8". | |
| .sp | |
| Precedence between the explicit operators is not defined, so mixing operators | |
| is a syntax error. For example, \f(CI[A&&B\-\-C]\fP is an error, but | |
| \f(CI[A&&[B\-\-C]]\fP is valid. | |
| .sp | |
| This is an emerging syntax which is being adopted gradually across the regex | |
| ecosystem: for example JavaScript adopted the \f(CI/v\fP flag in ECMAScript 2024; | |
| Python\(cqs \f(CRre\fP module reserves the syntax for future use with a FutureWarning | |
| for unescaped use of \f(CI[\fP as a literal within character classes. Due to UTS#18 | |
| providing insufficient guidance, engines interpret the syntax differently. | |
| Rust\(cqs \f(CRregex\fP crate and Python\(cqs \f(CRregex\fP PyPi module both implement UTS#18 | |
| extended classes, but with slight incompatibilities (\f(CI[A||B&&C]\fP is parsed as | |
| \f(CI[A||[B&&C]]\fP in Python\(cqs \f(CRregex\fP but as \f(CI[[A||B]&&C]\fP in Rust\(cqs \f(CRregex\fP). | |
| .sp | |
| PCRE2\(cqs syntax adds syntax restrictions similar to ECMAScript\(cqs \f(CI/v\fP flag, so | |
| that all the UTS#18 extended classes accepted as valid by PCRE2 have the | |
| property that they are interpreted either with the same behaviour, or as | |
| invalid, by all other major engines. Please file an issue if you are aware of | |
| cross\-engine differences in behaviour between PCRE2 and another major engine. | |
| .SH "POSIX CHARACTER CLASSES" | |
| .sp | |
| Perl supports the POSIX notation for character classes. This uses names | |
| enclosed by \f(CI[:\fP and \f(CI:]\fP within the enclosing square brackets. PCRE2 also supports | |
| this notation, in both ordinary and extended classes. For example, | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CI[01[:alpha:]%]\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| matches \f(CI0\fP, \f(CI1\fP, any alphabetic character, or \f(CI%\fP. The supported class names | |
| are: | |
| .sp | |
| .RS 4 | |
| .PD 0 | |
| .TP 11 | |
| \f(CI[:alnum:]\fP | |
| .ad l | |
| Letters and digits. | |
| .TP 11 | |
| \f(CI[:alpha:]\fP | |
| .ad l | |
| Letters. | |
| .TP 11 | |
| \f(CI[:ascii:]\fP | |
| .ad l | |
| Character codes 0\(en127. | |
| .TP 11 | |
| \f(CI[:blank:]\fP | |
| .ad l | |
| Space or tab only. | |
| .TP 11 | |
| \f(CI[:cntrl:]\fP | |
| .ad l | |
| Control characters. | |
| .TP 11 | |
| \f(CI[:digit:]\fP | |
| .ad l | |
| Decimal digits (same as \f(CI\(rsd\fP). | |
| .TP 11 | |
| \f(CI[:graph:]\fP | |
| .ad l | |
| Printing characters, excluding space. | |
| .TP 11 | |
| \f(CI[:lower:]\fP | |
| .ad l | |
| Lower case letters. | |
| .TP 11 | |
| \f(CI[:print:]\fP | |
| .ad l | |
| Printing characters, including space. | |
| .TP 11 | |
| \f(CI[:punct:]\fP | |
| .ad l | |
| Printing characters, excluding letters, digits, and space. | |
| .TP 11 | |
| \f(CI[:space:]\fP | |
| .ad l | |
| White space (the same as \f(CI\(rss\fP from PCRE2 8.34). | |
| .TP 11 | |
| \f(CI[:upper:]\fP | |
| .ad l | |
| Upper case letters. | |
| .TP 11 | |
| \f(CI[:word:]\fP | |
| .ad l | |
| "Word" characters (same as \f(CI\(rsw\fP). | |
| .TP 11 | |
| \f(CI[:xdigit:]\fP | |
| .ad l | |
| Hexadecimal digits. | |
| .PD | |
| .RE | |
| .PP | |
| .ad l | |
| .sp | |
| The default "space" characters are HT (9), LF (10), VT (11), FF (12), CR (13), | |
| and space (32). If locale\-specific matching is taking place, the list of space | |
| characters may be different; there may be fewer or more of them. "Space" and | |
| \f(CI\(rss\fP match the same set of characters, as do "word" and \f(CI\(rsw\fP. | |
| .sp | |
| The name "word" is a Perl extension, and "blank" is a GNU extension from Perl | |
| 5.8. Another Perl extension is negation, which is indicated by a ^ character | |
| after the colon. For example, | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CI[12[:^digit:]]\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| matches \f(CI1\fP, \f(CI2\fP, or any non\-digit. PCRE2 (and Perl) also recognize the POSIX | |
| syntax \f(CI[.ch.]\fP and \f(CI[=ch=]\fP where \f(CIch\fP is a "collating element", but these are not | |
| supported, and an error is given if they are encountered. | |
| .sp | |
| By default, characters with values greater than 127 do not match any of the | |
| POSIX character classes, although this may be different for characters in the | |
| range 128\(en255 when locale\-specific matching is happening. However, in UCP mode, | |
| unless certain options are set (see below), some of the classes are changed so | |
| that Unicode character properties are used. This is achieved by replacing | |
| POSIX classes with other sequences, as follows: | |
| .sp | |
| .RS 4 | |
| .PD 0 | |
| .TP 10 | |
| \f(CI[:alnum:]\fP | |
| .ad l | |
| Becomes \f(CI\(rsp{Xan}\fP | |
| .TP 10 | |
| \f(CI[:alpha:]\fP | |
| .ad l | |
| Becomes \f(CI\(rsp{L}\fP | |
| .TP 10 | |
| \f(CI[:blank:]\fP | |
| .ad l | |
| Becomes \f(CI\(rsh\fP | |
| .TP 10 | |
| \f(CI[:cntrl:]\fP | |
| .ad l | |
| Becomes \f(CI\(rsp{Cc}\fP | |
| .TP 10 | |
| \f(CI[:digit:]\fP | |
| .ad l | |
| Becomes \f(CI\(rsp{Nd}\fP | |
| .TP 10 | |
| \f(CI[:lower:]\fP | |
| .ad l | |
| Becomes \f(CI\(rsp{Ll}\fP | |
| .TP 10 | |
| \f(CI[:space:]\fP | |
| .ad l | |
| Becomes \f(CI\(rsp{Xps}\fP | |
| .TP 10 | |
| \f(CI[:upper:]\fP | |
| .ad l | |
| Becomes \f(CI\(rsp{Lu}\fP | |
| .TP 10 | |
| \f(CI[:word:]\fP | |
| .ad l | |
| Becomes \f(CI\(rsp{Xwd}\fP | |
| .PD | |
| .RE | |
| .PP | |
| .ad l | |
| .sp | |
| Negated versions, such as \f(CI[:^alpha:]\fP use \f(CI\(rsP\fP instead of \f(CI\(rsp\fP. | |
| .sp | |
| Four other POSIX | |
| classes are handled specially in UCP mode: | |
| .sp | |
| .RS 4 | |
| .PD | |
| .TP 11 | |
| \f(CI[:graph:]\fP | |
| .ad l | |
| This matches characters that have glyphs that mark the page when printed. In | |
| Unicode property terms, it matches all characters with the L, M, N, P, S, or Cf | |
| properties, except for: | |
| .RS 11 | |
| .sp | |
| .RS 4 | |
| .PD 0 | |
| .TP 20 | |
| \f(CRU+061C\fP | |
| .ad l | |
| Arabic Letter Mark | |
| .TP 20 | |
| \f(CRU+180E\fP | |
| .ad l | |
| Mongolian Vowel Separator | |
| .TP 20 | |
| \f(CRU+2066\fP\(en\f(CRU+2069\fP | |
| .ad l | |
| Various "isolates" | |
| .PD | |
| .RE | |
| .PP | |
| .ad l | |
| .RE | |
| .TP 11 | |
| \f(CI[:print:]\fP | |
| .ad l | |
| This matches the same characters as \f(CI[:graph:]\fP plus space characters that are | |
| not controls, that is, characters with the Zs property. | |
| .TP 11 | |
| \f(CI[:punct:]\fP | |
| .ad l | |
| This matches all characters that have the Unicode P (punctuation) property, | |
| plus those characters with code points less than 256 that have the S (Symbol) | |
| property. | |
| .TP 11 | |
| \f(CI[:xdigit:]\fP | |
| .ad l | |
| In addition to the ASCII hexadecimal digits, this also matches the "fullwidth" | |
| versions of those characters, whose Unicode code points start at \f(CRU+FF10\fP. This | |
| is a change that was made in PCRE2 release 10.43 for Perl compatibility. | |
| .PD | |
| .RE | |
| .PP | |
| .ad l | |
| .sp | |
| The other POSIX classes are unchanged by \f(CBPCRE2_UCP\fP, and match only characters | |
| with code points less than 256. | |
| .sp | |
| There are two options that can be used to restrict the POSIX classes to ASCII | |
| characters when \f(CBPCRE2_UCP\fP is set. The option \f(CBPCRE2_EXTRA_ASCII_DIGIT\fP affects | |
| just \f(CI[:digit:]\fP and \f(CI[:xdigit:]\fP. Within a pattern, this can be set and unset by | |
| \f(CI(?aT)\fP and \f(CI(?\-aT)\fP. The \f(CBPCRE2_EXTRA_ASCII_POSIX\fP option disables UCP processing | |
| for all POSIX classes, including \f(CI[:digit:]\fP and \f(CI[:xdigit:]\fP. Within a pattern, | |
| \f(CI(?aP)\fP and \f(CI(?\-aP)\fP set and unset both these options for consistency. | |
| .SH "COMPATIBILITY FEATURE FOR WORD BOUNDARIES" | |
| .sp | |
| In the POSIX.2 compliant library that was included in 4.4BSD Unix, the ugly | |
| syntax [[:<:]] and [[:>:]] is used for matching "start of word" and "end of | |
| word". PCRE2 treats these items as follows: | |
| .sp | |
| .RS 4 | |
| .PD 0 | |
| .TP 11 | |
| \f(CI[[:<:]]\fP | |
| .ad l | |
| Is converted to \f(CI\(rsb(?=\(rsw)\fP. | |
| .TP 11 | |
| \f(CI[[:>:]]\fP | |
| .ad l | |
| Is converted to \f(CI\(rsb(?<=\(rsw)\fP. | |
| .PD | |
| .RE | |
| .PP | |
| .ad l | |
| .sp | |
| Only these exact character sequences are recognized. A sequence such as | |
| [a[:<:]b] provokes error for an unrecognized POSIX class name. This support is | |
| not compatible with Perl. It is provided to help migrations from other | |
| environments, and is best not used in any new patterns. Note that \f(CI\(rsb\fP matches | |
| at the start and the end of a word (see | |
| "Simple assertions" | |
| above), and in a Perl\-style pattern the preceding or following character | |
| normally shows which is wanted, without the need for the assertions that are | |
| used above in order to give exactly the POSIX behaviour. Note also that the | |
| \f(CBPCRE2_UCP\fP option changes the meaning of \f(CI\(rsw\fP (and therefore \f(CI\(rsb\fP) by default, so | |
| it also affects these POSIX sequences. | |
| .SH "VERTICAL BAR (PIPE)" | |
| .sp | |
| Vertical bar characters are used to separate alternative patterns. For example, | |
| the pattern | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CIgilbert|sullivan\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| matches either \f(CIgilbert\fP or \f(CIsullivan\fP. Any number of alternatives may appear, | |
| and an empty alternative is permitted (matching the empty string). The matching | |
| process tries each alternative in turn, from left to right, and the first one | |
| that succeeds is used. If the alternatives are within a group | |
| (defined below), | |
| "succeeds" means matching the rest of the main pattern as well as the | |
| alternative in the group. | |
| .SH "INTERNAL OPTION SETTING" | |
| .sp | |
| The settings of several options can be changed within a pattern by a sequence | |
| of letters enclosed between \f(CI(?\fP and \f(CI)\fP. The following are Perl\-compatible, | |
| and are described in detail in the | |
| \f(CRpcre2api\fP | |
| documentation. The option letters are: | |
| .sp | |
| .RS 4 | |
| .PD 0 | |
| .TP 7 | |
| \f(CIi\fP | |
| .ad l | |
| For \f(CBPCRE2_CASELESS\fP | |
| .TP 7 | |
| \f(CIm\fP | |
| .ad l | |
| For \f(CBPCRE2_MULTILINE\fP | |
| .TP 7 | |
| \f(CIn\fP | |
| .ad l | |
| For \f(CBPCRE2_NO_AUTO_CAPTURE\fP | |
| .TP 7 | |
| \f(CIs\fP | |
| .ad l | |
| For \f(CBPCRE2_DOTALL\fP | |
| .TP 7 | |
| \f(CIx\fP | |
| .ad l | |
| For \f(CBPCRE2_EXTENDED\fP | |
| .TP 7 | |
| \f(CIxx\fP | |
| .ad l | |
| For \f(CBPCRE2_EXTENDED_MORE\fP | |
| .PD | |
| .RE | |
| .PP | |
| .ad l | |
| .sp | |
| For example, \f(CI(?im)\fP sets caseless, multiline matching. It is also possible to | |
| unset these options by preceding the relevant letters with a hyphen, for | |
| example \f(CI(?\-im)\fP. The two "extended" options are not independent; unsetting | |
| either one cancels the effects of both of them. | |
| .sp | |
| A combined setting and unsetting such as \f(CI(?im\-sx)\fP, which sets \f(CBPCRE2_CASELESS\fP | |
| and \f(CBPCRE2_MULTILINE\fP while unsetting \f(CBPCRE2_DOTALL\fP and \f(CBPCRE2_EXTENDED\fP, is also | |
| permitted. Only one hyphen may appear in the options string. If a letter | |
| appears both before and after the hyphen, the option is unset. An empty options | |
| setting \f(CI(?)\fP is allowed. Needless to say, it has no effect. | |
| .sp | |
| If the first character following \f(CI(?\fP is a circumflex, it causes all of the above | |
| options to be unset. Letters may follow the circumflex to cause some options to | |
| be re\-instated, but a hyphen may not appear. | |
| .sp | |
| Some PCRE2\-specific options can be changed by the same mechanism using these | |
| pairs or individual letters: | |
| .sp | |
| .RS 4 | |
| .PD 0 | |
| .TP 7 | |
| \f(CIaD\fP | |
| .ad l | |
| For \f(CBPCRE2_EXTRA_ASCII_BSD\fP | |
| .TP 7 | |
| \f(CIaS\fP | |
| .ad l | |
| For \f(CBPCRE2_EXTRA_ASCII_BSS\fP | |
| .TP 7 | |
| \f(CIaW\fP | |
| .ad l | |
| For \f(CBPCRE2_EXTRA_ASCII_BSW\fP | |
| .TP 7 | |
| \f(CIaP\fP | |
| .ad l | |
| For \f(CBPCRE2_EXTRA_ASCII_POSIX\fP and \f(CBPCRE2_EXTRA_ASCII_DIGIT\fP | |
| .TP 7 | |
| \f(CIaT\fP | |
| .ad l | |
| For \f(CBPCRE2_EXTRA_ASCII_DIGIT\fP | |
| .TP 7 | |
| \f(CIr\fP | |
| .ad l | |
| For \f(CBPCRE2_EXTRA_CASELESS_RESTRICT\fP | |
| .TP 7 | |
| \f(CIJ\fP | |
| .ad l | |
| For \f(CBPCRE2_DUPNAMES\fP | |
| .TP 7 | |
| \f(CIU\fP | |
| .ad l | |
| For \f(CBPCRE2_UNGREEDY\fP | |
| .PD | |
| .RE | |
| .PP | |
| .ad l | |
| .sp | |
| However, except for \f(CIr\fP, these are not unset by \f(CI(?^)\fP, which is equivalent to | |
| \f(CI(?\-imnrsx)\fP. If \f(CIa\fP is not followed by any of the upper case letters shown | |
| above, it sets (or unsets) all the ASCII options. | |
| .sp | |
| \f(CBPCRE2_EXTRA_ASCII_DIGIT\fP has no additional effect when \f(CBPCRE2_EXTRA_ASCII_POSIX\fP | |
| is set, but including it in \f(CI(?aP)\fP means that \f(CI(?\-aP)\fP suppresses all ASCII | |
| restrictions for POSIX classes. | |
| .sp | |
| When one of these option changes occurs at top level (that is, not inside group | |
| parentheses), the change applies until a subsequent change, or the end of the | |
| pattern. An option change within a group (see below for a description of | |
| groups) affects only that part of the group that follows it. At the end of the | |
| group these options are reset to the state they were before the group. For | |
| example, | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CI(a(?i)b)c\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| matches \f(CIabc\fP and \f(CIaBc\fP and no other strings (assuming \f(CBPCRE2_CASELESS\fP is not set | |
| externally). Any changes made in one alternative do carry on into subsequent | |
| branches within the same group. For example, | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CI(a(?i)b|c)\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| matches \f(CIab\fP, \f(CIaB\fP, \f(CIc\fP, and \f(CIC\fP, even though when matching \f(CIC\fP the first | |
| branch is abandoned before the option setting. This is because the effects of | |
| option settings happen at compile time. There would be some very weird | |
| behaviour otherwise. | |
| .sp | |
| As a convenient shorthand, if any option settings are required at the start of | |
| a non\-capturing group (see the section GROUPS), the option letters may | |
| appear between the \f(CI?\fP and the \f(CI:\fP. Thus the two patterns | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CI(?i:saturday|sunday) | |
| (?:(?i)saturday|sunday)\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| match exactly the same set of strings. Because alternative branches are tried | |
| from left to right, and options are not reset until the end of the group is | |
| reached, an option setting in one branch does affect subsequent branches, so | |
| the above patterns match \f(CISUNDAY\fP as well as \f(CISaturday\fP. | |
| .if n .sp | |
| .RS 4 | |
| .it 1 an-trap | |
| .nr an-no-space-flag 1 | |
| .nr an-break-flag 1 | |
| .br | |
| .ps +1 | |
| .B Note | |
| .ps -1 | |
| .br | |
| .sp | |
| There are other PCRE2\-specific options, applying to the whole | |
| pattern, which can be set by the application when the compiling function is | |
| called. In addition, the pattern can contain special leading sequences such as | |
| \f(CI(*CRLF)\fP to override what the application has set or what has been defaulted. | |
| Details are given in the section Newline sequences | |
| above. There are also the \f(CI(*UTF)\fP and \f(CI(*UCP)\fP leading sequences that can be used | |
| to set UTF and Unicode property modes; they are equivalent to setting the | |
| \f(CBPCRE2_UTF\fP and \f(CBPCRE2_UCP\fP options, respectively. However, the application can set | |
| the \f(CBPCRE2_NEVER_UTF\fP or \f(CBPCRE2_NEVER_UCP\fP options, which lock out the use of the | |
| \f(CI(*UTF)\fP and \f(CI(*UCP)\fP sequences. | |
| .sp .5v | |
| .RE | |
| .SH "GROUPS" | |
| .sp | |
| Groups are delimited by parentheses (round brackets), which can be nested. | |
| Turning part of a pattern into a group does two things: | |
| .sp | |
| .RS 4 | |
| .ie n \{\ | |
| \h'-04' 1.\h'+01'\c | |
| .\} | |
| .el \{\ | |
| . sp -1 | |
| . IP " 1." 4.2 | |
| .\} | |
| It localizes a set of alternatives. For example, the pattern | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CIcat(aract|erpillar|)\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| matches \f(CIcataract\fP, \f(CIcaterpillar\fP, or \f(CIcat\fP. Without the parentheses, it would | |
| match \f(CIcataract\fP, \f(CIerpillar\fP or an empty string. | |
| .RE | |
| .sp | |
| .RS 4 | |
| .ie n \{\ | |
| \h'-04' 2.\h'+01'\c | |
| .\} | |
| .el \{\ | |
| . sp -1 | |
| . IP " 2." 4.2 | |
| .\} | |
| It creates a "capture group". This means that, when the whole pattern | |
| matches, the portion of the subject string that matched the group is passed | |
| back to the caller, separately from the portion that matched the whole pattern. | |
| (This applies only to the traditional matching function; the DFA matching | |
| function does not support capturing.) | |
| .sp | |
| Opening parentheses are counted from left to right (starting from 1) to obtain | |
| numbers for capture groups. For example, if the string \f(CIthe red king\fP is | |
| matched against the pattern | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CIthe ((red|white) (king|queen))\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| the captured substrings are \f(CIred king\fP, \f(CIred\fP, and \f(CIking\fP, and are numbered 1, | |
| 2, and 3, respectively. | |
| .RE | |
| .sp | |
| The fact that plain parentheses fulfil two functions is not always helpful. | |
| There are often times when grouping is required without capturing. If an | |
| opening parenthesis is followed by a question mark and a colon, the group | |
| does not do any capturing, and is not counted when computing the number of any | |
| subsequent capture groups. For example, if the string \f(CIthe white queen\fP | |
| is matched against the pattern | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CIthe ((?:red|white) (king|queen))\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| the captured substrings are \f(CIwhite queen\fP and \f(CIqueen\fP, and are numbered 1 and 2. The maximum number of capture groups is 65,535. | |
| .sp | |
| As a convenient shorthand, if any option settings are required at the start of | |
| a non\-capturing group, the option letters may appear between the \f(CI?\fP and the | |
| \f(CI:\fP (see the section GROUPS). | |
| .SH "DUPLICATE GROUP NUMBERS" | |
| .sp | |
| Perl 5.10 introduced a feature whereby each alternative in a group uses the | |
| same numbers for its capturing parentheses. Such a group starts with \f(CI(?|\fP and is | |
| itself a non\-capturing group. For example, consider this pattern: | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CI(?|(Sat)ur|(Sun))day\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| Because the two alternatives are inside a \f(CI(?|\fP group, both sets of capturing | |
| parentheses are numbered one. Thus, when the pattern matches, you can look | |
| at captured substring number one, whichever alternative matched. This construct | |
| is useful when you want to capture part, but not all, of one of a number of | |
| alternatives. Inside a \f(CI(?|\fP group, parentheses are numbered as usual, but the | |
| number is reset at the start of each branch. The numbers of any capturing | |
| parentheses that follow the whole group start after the highest number used in | |
| any branch. The following example is taken from the Perl documentation. The | |
| numbers underneath show in which buffer the captured content will be stored. | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CR\&# before\& \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-branch\-reset\-\-\-\-\-\-\-\-\-\-\- after | |
| / ( a )\& (?| x ( y ) z | (p (q) r) | (t) u (v) ) ( z ) /x | |
| # 1\& 2\& 2\& 3\& 2\& 3\& 4\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| A backreference to a capture group uses the most recent value that is set for | |
| the group. The following pattern matches \f(CIabcabc\fP or \f(CIdefdef\fP: | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CI(?|(abc)|(def))\(rs1\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| In contrast, a subroutine call to a capture group always refers to the | |
| first one in the pattern with the given number. The following pattern matches | |
| \f(CIabcabc\fP or \f(CIdefabc\fP: | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CI(?|(abc)|(def))(?1)\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| A relative reference such as \f(CI(?\-1)\fP is no different: it is just a convenient way | |
| of computing an absolute group number. | |
| .sp | |
| If a | |
| condition test | |
| for a group\(cqs having matched refers to a non\-unique number, the test is | |
| true if any group with that number has matched. | |
| .sp | |
| An alternative approach to using this "branch reset" feature is to use | |
| duplicate named groups, as described in the section NAMED CAPTURE GROUPS. | |
| .SH "NAMED CAPTURE GROUPS" | |
| .sp | |
| Identifying capture groups by number is simple, but it can be very hard to keep | |
| track of the numbers in complicated patterns. Furthermore, if an expression is | |
| modified, the numbers may change. To help with this difficulty, PCRE2 supports | |
| the naming of capture groups. This feature was not added to Perl until release | |
| 5.10. Python had the feature earlier, and PCRE1 introduced it at release 4.0, | |
| using the Python syntax. PCRE2 supports both the Perl and the Python syntax. | |
| .sp | |
| In PCRE2, a capture group can be named in one of three ways: \f(CI(?<\fP\f(CIname\fP\f(CI>.\|.\|.)\fP or | |
| \f(CI(?\*(Aq\fP\f(CIname\fP\f(CI\*(Aq.\|.\|.)\fP as in Perl, or \f(CI(?P<\fP\f(CIname\fP\f(CI>.\|.\|.)\fP as in Python. Names may be up to | |
| 128 code units long. When \f(CBPCRE2_UTF\fP is not set, they may contain only ASCII | |
| alphanumeric characters and underscores, but must start with a non\-digit. When | |
| \f(CBPCRE2_UTF\fP is set, the syntax of group names is extended to allow any Unicode | |
| letter or Unicode decimal digit. In other words, group names must match one of | |
| these patterns: | |
| .sp | |
| .RS 4 | |
| .PD 0 | |
| .TP 7 | |
| \f(CI^[_A\-Za\-z][_A\-Za\-z0\-9]*\(rsz\fP | |
| .ad l | |
| when \f(CBPCRE2_UTF\fP is not set | |
| .TP 7 | |
| \f(CI^[\fP\f(CI\(rsp{L}][\fP\f(CI\(rsp{L}\(rsp{Nd}]*\(rsz\fP | |
| .ad l | |
| when \f(CBPCRE2_UTF\fP is set | |
| .PD | |
| .RE | |
| .PP | |
| .ad l | |
| .sp | |
| References to capture groups from other parts of the pattern, such as | |
| backreferences, | |
| recursion, | |
| and | |
| conditions, | |
| can all be made by name as well as by number. | |
| .sp | |
| Named capture groups are allocated numbers as well as names, exactly as | |
| if the names were not present. In both PCRE2 and Perl, capture groups | |
| are primarily identified by numbers; any names are just aliases for these | |
| numbers. The PCRE2 API provides function calls for extracting the complete | |
| name\-to\-number translation table from a compiled pattern, as well as | |
| convenience functions for extracting captured substrings by name. | |
| .sp | |
| Warning: When more than one capture group has the same number, as | |
| described in the section DUPLICATE GROUP NUMBERS, a name given to one of them applies to all | |
| of them. Perl allows identically numbered groups to have different names. | |
| Consider this pattern, where there are two capture groups, both numbered 1: | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CI(?|(?<AA>aa)|(?<BB>bb))\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| Perl allows this, with both names AA and BB as aliases of group 1. Thus, after | |
| a successful match, both names yield the same value (either \f(CIaa\fP or \f(CIbb\fP). | |
| .sp | |
| In an attempt to reduce confusion, PCRE2 does not allow the same group number | |
| to be associated with more than one name. The example above provokes a | |
| compile\-time error. However, there is still scope for confusion. Consider this | |
| pattern: | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CI(?|(?<AA>aa)|(bb))\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| Although the second group number 1 is not explicitly named, the name AA is | |
| still an alias for any group 1. Whether the pattern matches \f(CIaa\fP or \f(CIbb\fP, a | |
| reference by name to group AA yields the matched string. | |
| .sp | |
| By default, a name must be unique within a pattern, except that duplicate names | |
| are permitted for groups with the same number, for example: | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CI(?|(?<AA>aa)|(?<AA>bb))\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| The duplicate name constraint can be disabled by setting the \f(CBPCRE2_DUPNAMES\fP | |
| option at compile time, or by the use of \f(CI(?J)\fP within the pattern, as described | |
| in the section INTERNAL OPTION SETTING | |
| above. | |
| .sp | |
| Duplicate names can be useful for patterns where only one instance of the named | |
| capture group can match. Suppose you want to match the name of a weekday, | |
| either as a 3\-letter abbreviation or as the full name, and in both cases you | |
| want to extract the abbreviation. This pattern (ignoring the line breaks) does | |
| the job: | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CI(?J) | |
| (?<DN>Mon|Fri|Sun)(?:day)?| | |
| (?<DN>Tue)(?:sday)?| | |
| (?<DN>Wed)(?:nesday)?| | |
| (?<DN>Thu)(?:rsday)?| | |
| (?<DN>Sat)(?:urday)?\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| There are five capture groups, but only one is ever set after a match. The | |
| convenience functions for extracting the data by name returns the substring for | |
| the first (and in this example, the only) group of that name that matched. This | |
| saves searching to find which numbered group it was. (An alternative way of | |
| solving this problem is to use a "branch reset" group, as described in the | |
| section DUPLICATE GROUP NUMBERS.) | |
| .sp | |
| If you make a backreference to a non\-unique named group from elsewhere in the | |
| pattern, the groups to which the name refers are checked in the order in which | |
| they appear in the overall pattern. The first one that is set is used for the | |
| reference. For example, this pattern matches both \f(CIfoofoo\fP and \f(CIbarbar\fP but not | |
| \f(CIfoobar\fP or \f(CIbarfoo\fP: | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CI(?J)(?:(?<n>foo)|(?<n>bar))\(rsk<n>\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| If you make a subroutine call to a non\-unique named group, the one that | |
| corresponds to the first occurrence of the name is used. In the absence of | |
| duplicate numbers this is the one with the lowest number. | |
| .sp | |
| If you use a named reference in a condition | |
| test (see the | |
| section CONDITIONAL GROUPS | |
| below), either to check whether a capture group has matched, or to check for | |
| recursion, all groups with the same name are tested. If the condition is true | |
| for any one of them, the overall condition is true. This is the same behaviour | |
| as testing by number. For further details of the interfaces for handling named | |
| capture groups, see the | |
| \f(CRpcre2api\fP | |
| documentation. | |
| .SH "REPETITION" | |
| .sp | |
| Repetition is specified by quantifiers, which may follow any one of these | |
| items: | |
| .sp | |
| .RS 4 | |
| .ie n \{\ | |
| \h'-04'\(bu\h'+03'\c | |
| .\} | |
| .el \{\ | |
| . sp -1 | |
| . IP \(bu 2.3 | |
| .\} | |
| a literal data character | |
| .RE | |
| .RS 4 | |
| .ie n \{\ | |
| \h'-04'\(bu\h'+03'\c | |
| .\} | |
| .el \{\ | |
| . sp -1 | |
| . IP \(bu 2.3 | |
| .\} | |
| the dot metacharacter | |
| .RE | |
| .RS 4 | |
| .ie n \{\ | |
| \h'-04'\(bu\h'+03'\c | |
| .\} | |
| .el \{\ | |
| . sp -1 | |
| . IP \(bu 2.3 | |
| .\} | |
| the \f(CI\(rsC\fP escape sequence | |
| .RE | |
| .RS 4 | |
| .ie n \{\ | |
| \h'-04'\(bu\h'+03'\c | |
| .\} | |
| .el \{\ | |
| . sp -1 | |
| . IP \(bu 2.3 | |
| .\} | |
| the \f(CI\(rsR\fP escape sequence | |
| .RE | |
| .RS 4 | |
| .ie n \{\ | |
| \h'-04'\(bu\h'+03'\c | |
| .\} | |
| .el \{\ | |
| . sp -1 | |
| . IP \(bu 2.3 | |
| .\} | |
| the \f(CI\(rsX\fP escape sequence | |
| .RE | |
| .RS 4 | |
| .ie n \{\ | |
| \h'-04'\(bu\h'+03'\c | |
| .\} | |
| .el \{\ | |
| . sp -1 | |
| . IP \(bu 2.3 | |
| .\} | |
| any escape sequence that matches a single character | |
| .RE | |
| .RS 4 | |
| .ie n \{\ | |
| \h'-04'\(bu\h'+03'\c | |
| .\} | |
| .el \{\ | |
| . sp -1 | |
| . IP \(bu 2.3 | |
| .\} | |
| a character class | |
| .RE | |
| .RS 4 | |
| .ie n \{\ | |
| \h'-04'\(bu\h'+03'\c | |
| .\} | |
| .el \{\ | |
| . sp -1 | |
| . IP \(bu 2.3 | |
| .\} | |
| a backreference | |
| .RE | |
| .RS 4 | |
| .ie n \{\ | |
| \h'-04'\(bu\h'+03'\c | |
| .\} | |
| .el \{\ | |
| . sp -1 | |
| . IP \(bu 2.3 | |
| .\} | |
| a parenthesized group (including lookaround assertions) | |
| .RE | |
| .RS 4 | |
| .ie n \{\ | |
| \h'-04'\(bu\h'+03'\c | |
| .\} | |
| .el \{\ | |
| . sp -1 | |
| . IP \(bu 2.3 | |
| .\} | |
| a subroutine call (recursive or otherwise) | |
| .RE | |
| .sp | |
| If a quantifier does not follow a repeatable item, an error occurs. The | |
| general repetition quantifier specifies a minimum and maximum number of | |
| permitted matches by giving two numbers in curly brackets (braces), separated | |
| by a comma. The numbers must be no greater than 65,535, and the first must be less | |
| than or equal to the second. For example, | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CIz{2,4}\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| matches \f(CIzz\fP, \f(CIzzz\fP, or \f(CIzzzz\fP. A closing brace on its own is not a special | |
| character. If the second number is omitted, but the comma is present, there is | |
| no upper limit; if the second number and the comma are both omitted, the | |
| quantifier specifies an exact number of required matches. Thus | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CI[aeiou]{3,}\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| matches at least 3 successive vowels, but may match many more, whereas | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CI\(rsd{8}\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| matches exactly 8 digits. If the first number is omitted, the lower limit is | |
| taken as zero; in this case the upper limit must be present. | |
| .sp | |
| \f(CIX{,4}\fP is interpreted as \f(CIX{0,4}\fP. | |
| .sp | |
| This is a change in behaviour that happened in Perl 5.34.0 and PCRE2 10.43. In | |
| earlier versions such a sequence was not interpreted as a quantifier. Other | |
| regular expression engines may behave either way. | |
| .sp | |
| If the characters that follow an opening brace do not match the syntax of a | |
| quantifier, the brace is taken as a literal character. In particular, this | |
| means that \f(CI{,}\fP is a literal string of three characters. | |
| .sp | |
| Note that not every opening brace is potentially the start of a quantifier | |
| because braces are used in other items such as \f(CI\(rsN{U+345}\fP or \f(CI\(rsk{\fP\f(CIname\fP\f(CI}\fP. | |
| .sp | |
| In UTF modes, quantifiers apply to characters rather than to individual code | |
| units. Thus, for example, \f(CI\(rsx{100}{2}\fP matches two characters, each of | |
| which is represented by a two\-byte sequence in a UTF\-8 string. Similarly, | |
| \f(CI\(rsX{3}\fP matches three Unicode extended grapheme clusters, each of which may be | |
| several code units long (and they may be of different lengths). | |
| .sp | |
| The quantifier \f(CI{0}\fP is permitted, causing the expression to behave as if the | |
| previous item and the quantifier were not present. This may be useful for | |
| capture groups that are referenced as | |
| subroutines | |
| from elsewhere in the pattern (but see also the section | |
| Defining capture groups for use by reference only | |
| below). Except for parenthesized groups, items that have a \f(CI{0}\fP quantifier are | |
| omitted from the compiled pattern. | |
| .sp | |
| For convenience, the three most common quantifiers have single\-character | |
| abbreviations: | |
| .sp | |
| .RS 4 | |
| .PD 0 | |
| .TP 7 | |
| \f(CI*\fP | |
| .ad l | |
| Is equivalent to \f(CI{0,}\fP. | |
| .TP 7 | |
| \f(CI+\fP | |
| .ad l | |
| Is equivalent to \f(CI{1,}\fP. | |
| .TP 7 | |
| \f(CI?\fP | |
| .ad l | |
| Is equivalent to \f(CI{0,1}\fP. | |
| .PD | |
| .RE | |
| .PP | |
| .ad l | |
| .sp | |
| It is possible to construct infinite loops by following a group that can match | |
| no characters with a quantifier that has no upper limit, for example: | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CI(a?)*\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| Earlier versions of Perl and PCRE1 used to give an error at compile time for | |
| such patterns. However, because there are cases where this can be useful, such | |
| patterns are now accepted, but whenever an iteration of such a group matches no | |
| characters, matching moves on to the next item in the pattern instead of | |
| repeatedly matching an empty string. This does not prevent backtracking into | |
| any of the iterations if a subsequent item fails to match. | |
| .sp | |
| By default, quantifiers are "greedy", that is, they match as much as possible | |
| (up to the maximum number of permitted repetitions), without causing the rest | |
| of the pattern to fail. The classic example of where this gives problems is in | |
| trying to match comments in C programs. These appear between \f(CR/*\fP and \f(CR*/\fP and | |
| within the comment, individual \f(CR*\fP and \f(CR/\fP characters may appear. An attempt to | |
| match C comments by applying the pattern | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CI/\(rs*.*\(rs*/\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| to the string | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CR/* first comment */\& not comment\& /* second comment */\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| fails, because it matches the entire string owing to the greediness of the \f(CI.*\fP | |
| item. However, if a quantifier is followed by a question mark, it ceases to be | |
| greedy, and instead matches the minimum number of times possible, so the | |
| pattern | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CI/\(rs*.*?\(rs*/\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| does the right thing with C comments. The meaning of the various quantifiers is | |
| not otherwise changed, just the preferred number of matches. Do not confuse | |
| this use of question mark with its use as a quantifier in its own right. | |
| Because it has two uses, it can sometimes appear doubled, as in | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CI\(rsd??\(rsd\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| which matches one digit by preference, but can match two if that is the only | |
| way the rest of the pattern matches. | |
| .sp | |
| If the \f(CBPCRE2_UNGREEDY\fP option is set (an option that is not available in Perl), | |
| the quantifiers are not greedy by default, but individual ones can be made | |
| greedy by following them with a question mark. In other words, it inverts the | |
| default behaviour. | |
| .sp | |
| When a parenthesized group is quantified with a minimum repeat count that | |
| is greater than 1 or with a limited maximum, more memory is required for the | |
| compiled pattern, in proportion to the size of the minimum or maximum. | |
| .sp | |
| If a pattern starts with \f(CI.*\fP or \f(CI.{0,}\fP and the \f(CBPCRE2_DOTALL\fP option (equivalent | |
| to Perl\(cqs \f(CI/s\fP) is set, thus allowing the dot to match newlines, the pattern is | |
| implicitly anchored, because whatever follows will be tried against every | |
| character position in the subject string, so there is no point in retrying the | |
| overall match at any position after the first. PCRE2 normally treats such a | |
| pattern as though it were preceded by \f(CI\(rsA\fP. | |
| .sp | |
| In cases where it is known that the subject string contains no newlines, it is | |
| worth setting \f(CBPCRE2_DOTALL\fP in order to obtain this optimization, or | |
| alternatively, using \f(CI^\fP to indicate anchoring explicitly. | |
| .sp | |
| However, there are some cases where the optimization cannot be used. When \f(CI.*\fP | |
| is inside capturing parentheses that are the subject of a backreference | |
| elsewhere in the pattern, a match at the start may fail where a later one | |
| succeeds. Consider, for example: | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CI(.*)abc\(rs1\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| If the subject is \f(CIxyz123abc123\fP the match point is the fourth character. For | |
| this reason, such a pattern is not implicitly anchored. | |
| .sp | |
| Another case where implicit anchoring is not applied is when the leading \f(CI.*\fP is | |
| inside an atomic group. Once again, a match at the start may fail where a later | |
| one succeeds. Consider this pattern: | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CI(?>.*?a)b\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| It matches \f(CIab\fP in the subject \f(CIaab\fP. The use of the backtracking control verbs | |
| \f(CI(*PRUNE)\fP and \f(CI(*SKIP)\fP also disable this optimization. To do so explicitly, | |
| either pass the compile option \f(CBPCRE2_NO_DOTSTAR_ANCHOR\fP, or call | |
| \f(CBpcre2_set_optimize()\fP with a \f(CBPCRE2_DOTSTAR_ANCHOR_OFF\fP directive. | |
| .sp | |
| When a capture group is repeated, the value captured is the substring that | |
| matched the final iteration. For example, after | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CI(tweedle[dume]{3}\(rss*)+\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| has matched \f(CItweedledum tweedledee\fP the value of the captured substring is | |
| \f(CItweedledee\fP. However, if there are nested capture groups, the corresponding | |
| captured values may have been set in previous iterations. For example, after | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CI(a|(b))+\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| matches \f(CIaba\fP the value of the second captured substring is \f(CIb\fP. | |
| .SH "ATOMIC GROUPING AND POSSESSIVE QUANTIFIERS" | |
| .sp | |
| With both maximizing ("greedy") and minimizing ("ungreedy" or "lazy") | |
| repetition, failure of what follows normally causes the repeated item to be | |
| re\-evaluated to see if a different number of repeats allows the rest of the | |
| pattern to match. Sometimes it is useful to prevent this, either to change the | |
| nature of the match, or to cause it fail earlier than it otherwise might, when | |
| the author of the pattern knows there is no point in carrying on. | |
| .sp | |
| Consider, for example, the pattern \f(CI\(rsd+foo\fP when applied to the subject line | |
| \f(CI123456bar\fP. | |
| .sp | |
| After matching all 6 digits and then failing to match \f(CIfoo\fP, the normal | |
| action of the matcher is to try again with only 5 digits matching the \f(CI\(rsd+\fP | |
| item, and then with 4, and so on, before ultimately failing. "Atomic grouping" | |
| (a term taken from Jeffrey Friedl\(cqs book) provides the means for specifying | |
| that once a group has matched, it is not to be re\-evaluated in this way. | |
| .sp | |
| If we use atomic grouping for the previous example, the matcher gives up | |
| immediately on failing to match \f(CIfoo\fP the first time. The notation is a kind of | |
| special parenthesis, starting with \f(CI(?>\fP as in this example: | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CI(?>\(rsd+)foo\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| Perl 5.28 introduced an experimental alphabetic form starting with \f(CI(*\fP which may | |
| be easier to remember: | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CI(*atomic:\(rsd+)foo\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| This kind of parenthesized group "locks up" the part of the pattern it contains | |
| once it has matched, and a failure further into the pattern is prevented from | |
| backtracking into it. Backtracking past it to previous items, however, works as | |
| normal. | |
| .sp | |
| An alternative description is that a group of this type matches exactly the | |
| string of characters that an identical standalone pattern would match, if | |
| anchored at the current point in the subject string. | |
| .sp | |
| Atomic groups are not capture groups. Simple cases such as the above example | |
| can be thought of as a maximizing repeat that must swallow everything it can. | |
| So, while both \f(CI\(rsd+\fP and \f(CI\(rsd+?\fP are prepared to adjust the number of digits they | |
| match in order to make the rest of the pattern match, \f(CI(?>\(rsd+)\fP can only match | |
| an entire sequence of digits. | |
| .sp | |
| Atomic groups in general can of course contain arbitrarily complicated | |
| expressions, and can be nested. However, when the contents of an atomic | |
| group is just a single repeated item, as in the example above, a simpler | |
| notation, called a "possessive quantifier" can be used. This consists of an | |
| additional \f(CI+\fP character following a quantifier. Using this notation, the | |
| previous example can be rewritten as | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CI\(rsd++foo\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| Note that a possessive quantifier can be used with an entire group, for | |
| example: | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CI(abc|xyz){2,3}+\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| Possessive quantifiers are always greedy; the setting of the \f(CBPCRE2_UNGREEDY\fP | |
| option is ignored. They are a convenient notation for the simpler forms of | |
| atomic group. However, there is no difference in the meaning of a possessive | |
| quantifier and the equivalent atomic group, though there may be a performance | |
| difference; possessive quantifiers should be slightly faster. | |
| .sp | |
| The possessive quantifier syntax is an extension to the Perl 5.8 syntax. | |
| Jeffrey Friedl originated the idea (and the name) in the first edition of his | |
| book. Mike McCloskey liked it, so implemented it when he built Sun\(cqs Java | |
| package, and PCRE1 copied it from there. It found its way into Perl at release | |
| 5.10. | |
| .sp | |
| PCRE2 has an optimization that automatically "possessifies" certain simple | |
| pattern constructs. For example, the sequence \f(CIA+B\fP is treated as \f(CIA++B\fP because | |
| there is no point in backtracking into a sequence of A\(cqs when B must follow. | |
| This feature can be disabled by the \f(CBPCRE2_NO_AUTO_POSSESS\fP option, by calling | |
| \f(CBpcre2_set_optimize()\fP with a \f(CBPCRE2_AUTO_POSSESS_OFF\fP directive, or by | |
| starting the pattern with \f(CI(*NO_AUTO_POSSESS)\fP. | |
| .sp | |
| When a pattern contains an unlimited repeat inside a group that can itself be | |
| repeated an unlimited number of times, the use of an atomic group is the only | |
| way to avoid some failing matches taking a very long time indeed. The pattern | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CI(\(rsD+|<\(rsd+>)*[!?]\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| matches an unlimited number of substrings that either consist of non\-digits, or | |
| digits enclosed in <>, followed by either ! or ?. When it matches, it runs | |
| quickly. However, if it is applied to | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CRaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| it takes a long time before reporting failure. This is because the string can | |
| be divided between the internal \f(CI\(rsD+\fP repeat and the external \f(CI*\fP repeat in a | |
| large number of ways, and all have to be tried. (The example uses \f(CI[!?]\fP rather | |
| than a single character at the end, because both PCRE2 and Perl have an | |
| optimization that allows for fast failure when a single character is used. They | |
| remember the last single character that is required for a match, and fail early | |
| if it is not present in the string.) If the pattern is changed so that it uses | |
| an atomic group, like this: | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CI((?>\(rsD+)|<\(rsd+>)*[!?]\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| sequences of non\-digits cannot be broken, and failure happens quickly. | |
| .SH "BACKREFERENCES" | |
| .sp | |
| Outside a character class, a backslash followed by a digit greater than 0 (and | |
| possibly further digits) is a backreference to a capture group earlier (that | |
| is, to its left) in the pattern, provided there have been that many previous | |
| capture groups. | |
| .sp | |
| However, if the decimal number following the backslash is less than 8, it is | |
| always taken as a backreference, and causes an error only if there are not that | |
| many capture groups in the entire pattern. In other words, the group that is | |
| referenced need not be to the left of the reference for numbers less than 8. A | |
| "forward backreference" of this type can make sense when a repetition is | |
| involved and the group to the right has participated in an earlier iteration. | |
| .sp | |
| It is not possible to have a numerical "forward backreference" to a group whose | |
| number is 8 or more using this syntax because a sequence such as \f(CI\(rs50\fP is | |
| interpreted as a character defined in octal. See the subsection | |
| Non\-printing characters | |
| above | |
| for further details of the handling of digits following a backslash. Other | |
| forms of backreferencing do not suffer from this restriction. In particular, | |
| there is no problem when named capture groups are used (see below). | |
| .sp | |
| Another way of avoiding the ambiguity inherent in the use of digits following a | |
| backslash is to use the \f(CI\(rsg\fP escape sequence. This escape must be followed by a | |
| signed or unsigned number, optionally enclosed in braces. These examples are | |
| all identical ways of matching \f(CIring, ring\fP: | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CI(ring), \(rs1 | |
| (ring), \(rsg1 | |
| (ring), \(rsg{1}\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| An unsigned number specifies an absolute reference without the ambiguity that | |
| is present in the older syntax. It is also useful when literal digits follow | |
| the reference. A signed number is a relative reference. Consider this example: | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CI(abc(def)ghi)\(rsg{\-1}\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| The sequence \f(CI\(rsg{\-1}\fP is a reference to the capture group whose number is one | |
| less than the number of the next group to be started, so in this example (where | |
| the next group would be numbered 3) is it equivalent to \f(CI\(rs2\fP, and \f(CI\(rsg{\-2}\fP would | |
| be equivalent to \f(CI\(rs1\fP. Note that if this construct is inside a capture group, | |
| that group is included in the count, so in this example \f(CI\(rsg{\-2}\fP also refers to | |
| group 1: | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CI(A)(\(rsg{\-2}B)\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| The use of relative references can be helpful in long patterns, and also in | |
| patterns that are created by joining together fragments that contain references | |
| within themselves. | |
| .sp | |
| The sequence \f(CI\(rsg{+1}\fP is a reference to the next capture group that is started | |
| after this item, and \f(CI\(rsg{+2}\fP refers to the one after that, and so on. This kind | |
| of forward reference can be useful in patterns that repeat. Perl does not | |
| support the use of \f(CI+\fP in this way. | |
| .sp | |
| A backreference matches whatever actually most recently matched the capture | |
| group in the current subject string, rather than anything at all that matches | |
| the group (see | |
| "Groups as subroutines" | |
| below for a way of doing that). So the pattern | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CI(sens|respons)e and \(rs1ibility\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| matches \f(CIsense and sensibility\fP and \f(CIresponse and responsibility\fP, but not | |
| "sense and responsibility". If caseful matching is in force at the time of the | |
| backreference, the case of letters is relevant. For example, | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CI((?i)rah)\(rss+\(rs1\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| matches \f(CIrah rah\fP and \f(CIRAH RAH\fP, but not \f(CIRAH rah\fP, even though the original | |
| capture group is matched caselessly. | |
| .sp | |
| There are several different ways of writing backreferences to named capture | |
| groups. The .NET syntax is \f(CI\(rsk{\fP\f(CIname\fP\f(CI}\fP, the Python syntax is \f(CI(?=\fP\f(CIname\fP\f(CI)\fP, and the | |
| original Perl syntax is \f(CI\(rsk<\fP\f(CIname\fP\f(CI>\fP or \f(CI\(rsk\*(Aq\fP\f(CIname\fP\f(CI\*(Aq\fP. All of these are now supported | |
| by both Perl and PCRE2. Perl 5.10\(cqs unified backreference syntax, in which \f(CI\(rsg\fP | |
| can be used for both numeric and named references, is also supported by PCRE2. | |
| We could rewrite the above example in any of the following ways: | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CI(?<p1>(?i)rah)\(rss+\(rsk<p1> | |
| (?\*(Aqp1\*(Aq(?i)rah)\(rss+\(rsk{p1} | |
| (?P<p1>(?i)rah)\(rss+(?P=p1) | |
| (?<p1>(?i)rah)\(rss+\(rsg{p1}\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| A capture group that is referenced by name may appear in the pattern before or | |
| after the reference. | |
| .sp | |
| There may be more than one backreference to the same group. If a group has not | |
| actually been used in a particular match, backreferences to it always fail by | |
| default. For example, the pattern | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CI(a|(bc))\(rs2\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| always fails if it starts to match \f(CIa\fP rather than \f(CIbc\fP. However, if the | |
| \f(CBPCRE2_MATCH_UNSET_BACKREF\fP option is set at compile time, a backreference to an | |
| unset value matches an empty string. | |
| .sp | |
| Because there may be many capture groups in a pattern, all digits following a | |
| backslash are taken as part of a potential backreference number. If the pattern | |
| continues with a digit character, some delimiter must be used to terminate the | |
| backreference. If the \f(CBPCRE2_EXTENDED\fP or \f(CBPCRE2_EXTENDED_MORE\fP option is set, this | |
| can be white space. Otherwise, the \f(CI\(rsg{}\fP syntax or an empty comment (see | |
| "Comments" | |
| below) can be used. | |
| .SS "Recursive backreferences" | |
| .sp | |
| A backreference that occurs inside the group to which it refers fails when the | |
| group is first used, so, for example, (a\(rs1) never matches. However, such | |
| references can be useful inside repeated groups. For example, the pattern | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CI(a|b\(rs1)+\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| matches any number of \f(CIa\fP characters and also \f(CIaba\fP, \f(CIababbaa\fP, etc. At each iteration of | |
| the group, the backreference matches the character string corresponding to the | |
| previous iteration. In order for this to work, the pattern must be such that | |
| the first iteration does not need to match the backreference. This can be done | |
| using alternation, as in the example above, or by a quantifier with a minimum | |
| of zero. | |
| .sp | |
| For versions of PCRE2 less than 10.25, backreferences of this type used to | |
| cause the group that they reference to be treated as an | |
| atomic group. | |
| This restriction no longer applies, and backtracking into such groups can occur | |
| as normal. | |
| .SH "ASSERTIONS" | |
| .sp | |
| An assertion is a test that does not consume any characters. The test must | |
| succeed for the match to continue. The simple assertions coded as \f(CI\(rsb\fP, \f(CI\(rsB\fP, | |
| \f(CI\(rsA\fP, \f(CI\(rsG\fP, \f(CI\(rsZ\fP, \f(CI\(rsz\fP, \f(CI^\fP and \f(CI$\fP are described | |
| above. | |
| .sp | |
| More complicated assertions are coded as parenthesized groups. If matching such | |
| a group succeeds, matching continues after it, but with the matching position | |
| in the subject string reset to what it was before the assertion was processed. | |
| .sp | |
| A special kind of assertion, called a "scan substring" assertion, matches a | |
| subpattern against a previously captured substring. This is described in the | |
| section SCAN SUBSTRING ASSERTIONS | |
| below. It is a PCRE2 extension, not compatible with Perl. | |
| .sp | |
| The other goup\-based assertions are of two kinds: those that look ahead of the | |
| current position in the subject string, and those that look behind it, and in | |
| each case an assertion may be positive (must match for the assertion to be | |
| true) or negative (must not match for the assertion to be true). | |
| .sp | |
| The Perl\-compatible lookaround assertions are atomic. If an assertion is true, | |
| but there is a subsequent matching failure, there is no backtracking into the | |
| assertion. However, there are some cases where non\-atomic assertions can be | |
| useful. PCRE2 has some support for these, described in the section | |
| NON\-ATOMIC ASSERTIONS | |
| below, but they are not Perl\-compatible. | |
| .sp | |
| A lookaround assertion may appear as the condition in a | |
| conditional group | |
| (see below). In this case, the result of matching the assertion determines | |
| which branch of the condition is followed. | |
| .sp | |
| Assertion groups are not capture groups. If an assertion contains capture | |
| groups within it, these are counted for the purposes of numbering the capture | |
| groups in the whole pattern. Within each branch of an assertion, locally | |
| captured substrings may be referenced in the usual way. For example, a sequence | |
| such as \f(CI(.)\(rsg{\-1}\fP can be used to check that two adjacent characters are the | |
| same. | |
| .sp | |
| When a branch within an assertion fails to match, any substrings that were | |
| captured are discarded (as happens with any pattern branch that fails to | |
| match). A negative assertion is true only when all its branches fail to match; | |
| this means that no captured substrings are ever retained after a successful | |
| negative assertion. When an assertion contains a matching branch, what happens | |
| depends on the type of assertion. | |
| .sp | |
| For a positive assertion, internally captured substrings in the successful | |
| branch are retained, and matching continues with the next pattern item after | |
| the assertion. For a negative assertion, a matching branch means that the | |
| assertion is not true. If such an assertion is being used as a condition in a | |
| conditional group | |
| (see below), captured substrings are retained, because matching continues with | |
| the "no" branch of the condition. For other failing negative assertions, | |
| control passes to the previous backtracking point, thus discarding any captured | |
| strings within the assertion. | |
| .sp | |
| Most assertion groups may be repeated; though it makes no sense to assert the | |
| same thing several times, the side effect of capturing in positive assertions | |
| may occasionally be useful. However, an assertion that forms the condition for | |
| a conditional group may not be quantified. PCRE2 used to restrict the | |
| repetition of assertions, but from release 10.35 the only restriction is that | |
| an unlimited maximum repetition is changed to be one more than the minimum. For | |
| example, \f(CI{3,}\fP is treated as \f(CI{3,4}\fP. | |
| .SS "Alphabetic assertion names" | |
| .sp | |
| Traditionally, symbolic sequences such as \f(CI(?=\fP and \f(CI(?<=\fP have been used to | |
| specify lookaround assertions. Perl 5.28 introduced some experimental | |
| alphabetic alternatives which might be easier to remember. They all start with | |
| \f(CI(*\fP instead of \f(CI(?\fP and must be written using lower case letters. PCRE2 supports | |
| the following synonyms: | |
| .sp | |
| .RS 4 | |
| .PD | |
| .TP 23 | |
| \f(CI(*positive_lookahead:\fP | |
| .PD 0 | |
| .TP 23 | |
| \f(CI(*pla:\fP | |
| .ad l | |
| Is the same as \f(CI(?=\fP. | |
| .PD | |
| .TP 23 | |
| \f(CI(*negative_lookahead:\fP | |
| .PD 0 | |
| .TP 23 | |
| \f(CI(*nla:\fP | |
| .ad l | |
| Is the same as \f(CI(?!\fP. | |
| .PD | |
| .TP 23 | |
| \f(CI(*positive_lookbehind:\fP | |
| .PD 0 | |
| .TP 23 | |
| \f(CI(*plb:\fP | |
| .ad l | |
| Is the same as \f(CI(?<=\fP. | |
| .PD | |
| .TP 23 | |
| \f(CI(*negative_lookbehind:\fP | |
| .PD 0 | |
| .TP 23 | |
| \f(CI(*nlb:\fP | |
| .ad l | |
| Is the same as \f(CI(?<!\fP. | |
| .PD | |
| .PD | |
| .RE | |
| .PP | |
| .ad l | |
| .sp | |
| For example, \f(CI(*pla:\fP\f(CIfoo\fP\f(CI)\fP is the same assertion as \f(CI(?=\fP\f(CIfoo\fP\f(CI)\fP. In the following | |
| sections, the various assertions are described using the original symbolic | |
| forms. | |
| .SS "Lookahead assertions" | |
| .sp | |
| Lookahead assertions start with \f(CI(?=\fP for positive assertions and \f(CI(?!\fP for | |
| negative assertions. For example, | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CI\(rsw+(?=;)\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| matches a word followed by a semicolon, but does not include the semicolon in | |
| the match, and | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CIfoo(?!bar)\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| matches any occurrence of \f(CIfoo\fP that is not followed by \f(CIbar\fP. Note that the | |
| apparently similar pattern | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CI(?!foo)bar\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| does not find an occurrence of \f(CIbar\fP that is preceded by something other than | |
| \f(CIfoo\fP; it finds any occurrence of \f(CIbar\fP whatsoever, because the assertion | |
| \f(CI(?!foo)\fP is always true when the next three characters are \f(CIbar\fP. A | |
| lookbehind assertion is needed to achieve the other effect. | |
| .sp | |
| If you want to force a matching failure at some point in a pattern, the most | |
| convenient way to do it is with \f(CI(?!)\fP because an empty string always matches, so | |
| an assertion that requires there not to be an empty string must always fail. | |
| The backtracking control verb \f(CI(*FAIL)\fP or \f(CI(*F)\fP is a synonym for \f(CI(?!)\fP. | |
| .SS "Lookbehind assertions" | |
| .sp | |
| Lookbehind assertions start with \f(CI(?<=\fP for positive assertions and \f(CI(?<!\fP for | |
| negative assertions. For example, | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CI(?<!foo)bar\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| does find an occurrence of \f(CIbar\fP that is not preceded by \f(CIfoo\fP. The contents of | |
| a lookbehind assertion are restricted such that there must be a known maximum | |
| to the lengths of all the strings it matches. There are two cases: | |
| .sp | |
| If every top\-level alternative matches a fixed length, for example | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CI(?<=colour|color)\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| there is a limit of 65,535 characters to the lengths, which do not have to be | |
| the same, as this example demonstrates. This is the only kind of lookbehind | |
| supported by PCRE2 versions earlier than 10.43 and by the alternative matching | |
| function \f(CBpcre2_dfa_match()\fP. | |
| .sp | |
| In PCRE2 10.43 and later, \f(CBpcre2_match()\fP supports lookbehind assertions in | |
| which one or more top\-level alternatives can match more than one string length, | |
| for example | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CI(?<=colou?r)\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| The maximum matching length for any branch of the lookbehind is limited to a | |
| value set by the calling program (default 255 characters). Unlimited repetition | |
| (for example \f(CI\(rsd*\fP) is not supported. In some cases, the escape sequence \f(CI\(rsK\fP | |
| (see above) | |
| can be used instead of a lookbehind assertion at the start of a pattern to get | |
| round the length limit restriction. | |
| .sp | |
| In UTF\-8 and UTF\-16 modes, PCRE2 does not allow the \f(CI\(rsC\fP escape (which matches a | |
| single code unit even in a UTF mode) to appear in lookbehind assertions, | |
| because it makes it impossible to calculate the length of the lookbehind. The | |
| \f(CI\(rsX\fP and \f(CI\(rsR\fP escapes, which can match different numbers of code units, are never | |
| permitted in lookbehinds. | |
| .sp | |
| "Subroutine" | |
| calls (see below) such as \f(CI(?2)\fP or \f(CI(?&X)\fP are permitted in lookbehinds, as long | |
| as the called capture group matches a limited\-length string. However, | |
| recursion, | |
| that is, a "subroutine" call into a group that is already active, | |
| is not supported. | |
| .sp | |
| PCRE2 supports backreferences in lookbehinds, but only if certain conditions | |
| are met. The \f(CBPCRE2_MATCH_UNSET_BACKREF\fP option must not be set, there must be no | |
| use of \f(CI(?|\fP in the pattern (it creates duplicate group numbers), and if the | |
| backreference is by name, the name must be unique. Of course, the referenced | |
| group must itself match a limited length substring. The following pattern | |
| matches words containing at least two characters that begin and end with the | |
| same character: | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CI \(rsb(\(rsw)\(rsw++(?<=\(rs1)\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| Possessive quantifiers can be used in conjunction with lookbehind assertions to | |
| specify efficient matching at the end of subject strings. Consider a simple | |
| pattern such as | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CIabcd$\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| when applied to a long string that does not match. Because matching proceeds | |
| from left to right, PCRE2 will look for each \f(CIa\fP in the subject and then see if | |
| what follows matches the rest of the pattern. If the pattern is specified as | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CI^.*abcd$\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| the initial \f(CI.*\fP matches the entire string at first, but when this fails (because | |
| there is no following \f(CIa\fP), it backtracks to match all but the last character, | |
| then all but the last two characters, and so on. Once again the search for \f(CIa\fP | |
| covers the entire string, from right to left, so we are no better off. However, | |
| if the pattern is written as | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CI^.*+(?<=abcd)\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| there can be no backtracking for the \f(CI.*+\fP item because of the possessive | |
| quantifier; it can match only the entire string. The subsequent lookbehind | |
| assertion does a single test on the last four characters. If it fails, the | |
| match fails immediately. For long strings, this approach makes a significant | |
| difference to the processing time. | |
| .SS "Using multiple assertions" | |
| .sp | |
| Several assertions (of any sort) may occur in succession. For example, | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CI(?<=\(rsd{3})(?<!999)foo\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| matches \f(CIfoo\fP preceded by three digits that are not \f(CI999\fP. Notice that each of | |
| the assertions is applied independently at the same point in the subject | |
| string. First there is a check that the previous three characters are all | |
| digits, and then there is a check that the same three characters are not \f(CI999\fP. | |
| This pattern does \fInot\fP match \f(CIfoo\fP preceded by six characters, the first | |
| of which are digits and the last three of which are not \f(CI999\fP. For example, it | |
| doesn\(cqt match \f(CI123abcfoo\fP. A pattern to do that is | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CI(?<=\(rsd{3}...)(?<!999)foo\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| This time the first assertion looks at the preceding six characters, checking | |
| that the first three are digits, and then the second assertion checks that the | |
| preceding three characters are not \f(CI999\fP. | |
| .sp | |
| Assertions can be nested in any combination. For example, | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CI(?<=(?<!foo)bar)baz\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| matches an occurrence of \f(CIbaz\fP that is preceded by \f(CIbar\fP which in turn is not | |
| preceded by \f(CIfoo\fP, while | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CI(?<=\(rsd{3}(?!999)...)foo\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| is another pattern that matches \f(CIfoo\fP preceded by three digits and any three | |
| characters that are not \f(CI999\fP. | |
| .SH "NON\-ATOMIC ASSERTIONS" | |
| .sp | |
| Traditional lookaround assertions are atomic. That is, if an assertion is true, | |
| but there is a subsequent matching failure, there is no backtracking into the | |
| assertion. However, there are some cases where non\-atomic positive assertions | |
| can be useful. PCRE2 provides these using the following syntax: | |
| .sp | |
| .RS 4 | |
| .PD | |
| .TP 9 | |
| \f(CI(*non_atomic_positive_lookahead:\fP | |
| .PD 0 | |
| .TP 9 | |
| \f(CI(*napla:\fP | |
| .PD 0 | |
| .TP 9 | |
| \f(CI(?*\fP | |
| .ad l | |
| Non\-atomic positive lookahead. | |
| .PD | |
| .TP 9 | |
| \f(CI(*non_atomic_positive_lookbehind:\fP | |
| .PD 0 | |
| .TP 9 | |
| \f(CI(*naplb:\fP | |
| .PD 0 | |
| .TP 9 | |
| \f(CI(?<*\fP | |
| .ad l | |
| Non\-atomic positive lookbehind. | |
| .PD | |
| .PD | |
| .RE | |
| .PP | |
| .ad l | |
| .sp | |
| Consider the problem of finding the right\-most word in a string that also | |
| appears earlier in the string, that is, it must appear at least twice in total. | |
| This pattern returns the required result as captured substring 1: | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CI^(?x)(*napla: .* \(rsb(\(rsw++)) (?> .*? \(rsb\(rs1\(rsb ){2}\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| For a subject such as \f(CIword1 word2 word3 word2 word3 word4\fP the result is | |
| \f(CIword3\fP. How does it work? At the start, \f(CI^(?x)\fP anchors the pattern and sets the | |
| \f(CIx\fP option, which causes white space (introduced for readability) to be | |
| ignored. Inside the assertion, the greedy \f(CI.*\fP at first consumes the entire | |
| string, but then has to backtrack until the rest of the assertion can match a | |
| word, which is captured by group 1. In other words, when the assertion first | |
| succeeds, it captures the right\-most word in the string. | |
| .sp | |
| The current matching point is then reset to the start of the subject, and the | |
| rest of the pattern match checks for two occurrences of the captured word, | |
| using an ungreedy \f(CI.*?\fP to scan from the left. If this succeeds, we are done, but | |
| if the last word in the string does not occur twice, this part of the pattern | |
| fails. If a traditional atomic lookahead \f(CI(?=\fP or \f(CI(*pla:\fP had been used, the | |
| assertion could not be re\-entered, and the whole match would fail. The pattern | |
| would succeed only if the very last word in the subject was found twice. | |
| .sp | |
| Using a non\-atomic lookahead, however, means that when the last word does not | |
| occur twice in the string, the lookahead can backtrack and find the second\-last | |
| word, and so on, until either the match succeeds, or all words have been | |
| tested. | |
| .sp | |
| Two conditions must be met for a non\-atomic assertion to be useful: the | |
| contents of one or more capturing groups must change after a backtrack into the | |
| assertion, and there must be a backreference to a changed group later in the | |
| pattern. If this is not the case, the rest of the pattern match fails exactly | |
| as before because nothing has changed, so using a non\-atomic assertion just | |
| wastes resources. | |
| .sp | |
| There is one exception to backtracking into a non\-atomic assertion. If an | |
| \f(CI(*ACCEPT)\fP control verb is triggered, the assertion succeeds atomically. That | |
| is, a subsequent match failure cannot backtrack into the assertion. | |
| .sp | |
| Non\-atomic assertions are not supported by the alternative matching function | |
| \f(CBpcre2_dfa_match()\fP. They are supported by JIT, but only if they do not | |
| contain any control verbs such as \f(CI(*ACCEPT)\fP. (This may change in future). Note | |
| that assertions that appear as conditions for | |
| conditional groups | |
| (see below) must be atomic. | |
| .SH "SCAN SUBSTRING ASSERTIONS" | |
| .sp | |
| A special kind of assertion, not compatible with Perl, makes it possible to | |
| check the contents of a captured substring by matching it with a subpattern. | |
| Because this involves capturing, this feature is not supported by | |
| \f(CBpcre2_dfa_match()\fP. | |
| .sp | |
| A scan substring assertion starts with the sequence \f(CI(*scan_substring:\fP or | |
| \f(CI(*scs:\fP which is followed by a list of substring numbers (absolute or relative) | |
| and/or substring names enclosed in single quotes or angle brackets, all within | |
| parentheses. The rest of the item is the subpattern that is applied to the | |
| substring, as shown in these examples: | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CI(*scan_substring:(1)...) | |
| (*scs:(\-2)...) | |
| (*scs:(\*(AqAB\*(Aq)...) | |
| (*scs:(1,\*(AqAB\*(Aq,\-2)...)\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| The list of groups is checked in the order they are given, and it is the | |
| contents of the first one that is found to be set that are scanned. When | |
| \f(CBPCRE2_DUPNAMES\fP is set and there are ambiguous group names, all groups with the | |
| same name are checked in numerical order. A scan substring assertion fails if | |
| none of the groups it references have been set. | |
| .sp | |
| The pattern match on the substring is always anchored, that is, it must match | |
| from the start of the substring. There is no "bumpalong" if it does not match | |
| at the start. The end of the subject is temporarily reset to be the end of the | |
| substring, so \f(CI\(rsZ\fP, \f(CI\(rsz\fP, and \f(CI$\fP will match there. However, the start of the | |
| subject is \fInot\fP reset. This means that \f(CI^\fP matches only if the substring is | |
| actually at the start of the main subject, but it also means that lookbehind | |
| assertions into what precedes the substring are possible. | |
| .sp | |
| Here is a very simple example: find a word that contains the rare (in English) | |
| sequence of letters \f(CIrh\fP not at the start: | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CI\(rsb(\(rsw++)(*scs:(1).+rh)\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| The first group captures a word which is then scanned by the second group. | |
| This example does not actually need this heavyweight feature; the same match | |
| can be achieved with: | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CI\(rsb\(rsw+?rh\(rsw*\(rsb\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| When things are more complicated, however, scanning a captured substring can be | |
| a useful way to describe the required match. For exmple, there is a rather | |
| complicated pattern in the PCRE2 test data that checks an entire subject string | |
| for a palindrome, that is, the sequence of letters is the same in both | |
| directions. Suppose you want to search for individual words of two or more | |
| characters such as "level" that are palindromes: | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CI(\(rsb\(rsw{2,}+\(rsb)(*scs:(1)...palindrome\-matching\-pattern...)\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| Within a substring scanning subpattern, references to other groups work as | |
| normal. Capturing groups may appear, and will retain their values during | |
| ongoing matching if the assertion succeeds. | |
| .SH "SCRIPT RUNS" | |
| .sp | |
| In concept, a script run is a sequence of characters that are all from the same | |
| Unicode script such as Latin or Greek. However, because some scripts are | |
| commonly used together, and because some diacritical and other marks are used | |
| with multiple scripts, it is not that simple. There is a full description of | |
| the rules that PCRE2 uses in the section | |
| Script runs | |
| in the | |
| \f(CRpcre2unicode\fP | |
| documentation. | |
| .sp | |
| If part of a pattern is enclosed between \f(CI(*script_run:\fP or \f(CI(*sr:\fP and a closing | |
| parenthesis, it fails if the sequence of characters that it matches are not a | |
| script run. After a failure, normal backtracking occurs. Script runs can be | |
| used to detect spoofing attacks using characters that look the same, but are | |
| from different scripts. The string \f(CIpaypal.com\fP is an infamous example, where | |
| the letters could be a mixture of Latin and Cyrillic. This pattern ensures that | |
| the matched characters in a sequence of non\-spaces that follow white space are | |
| a script run: | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CI\(rss+(*sr:\(rsS+)\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| To be sure that they are all from the Latin script (for example), a lookahead | |
| can be used: | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CI\(rss+(?=\(rsp{Latin})(*sr:\(rsS+)\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| This works as long as the first character is expected to be a character in that | |
| script, and not (for example) punctuation, which is allowed with any script. If | |
| this is not the case, a more creative lookahead is needed. For example, if | |
| digits, underscore, and dots are permitted at the start: | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CI\(rss+(?=[0\-9_.]*\(rsp{Latin})(*sr:\(rsS+)\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| In many cases, backtracking into a script run pattern fragment is not | |
| desirable. The script run can employ an atomic group to prevent this. Because | |
| this is a common requirement, a shorthand notation is provided by | |
| \f(CI(*atomic_script_run:\fP or \f(CI(*asr:\fP | |
| .sp | |
| .RS 4 | |
| .PD 0 | |
| .TP 11 | |
| \f(CI(*asr:...)\fP | |
| .ad l | |
| Is the same as \f(CI(*sr:(?>...))\fP. | |
| .PD | |
| .RE | |
| .PP | |
| .ad l | |
| .sp | |
| Note that the atomic group is inside the script run. Putting it outside would | |
| not prevent backtracking into the script run pattern. | |
| .sp | |
| Support for script runs is not available if PCRE2 is compiled without Unicode | |
| support. A compile\-time error is given if any of the above constructs is | |
| encountered. Script runs are not supported by the alternate matching function, | |
| \f(CBpcre2_dfa_match()\fP because they use the same mechanism as capturing | |
| parentheses. | |
| .sp | |
| Warning: The \f(CI(*ACCEPT)\fP control verb | |
| (see below) | |
| should not be used within a script run group, because it causes an immediate | |
| exit from the group, bypassing the script run checking. | |
| .SH "CONDITIONAL GROUPS" | |
| .sp | |
| It is possible to cause the matching process to obey a pattern fragment | |
| conditionally or to choose between two alternative fragments, depending on | |
| the result of an assertion, or whether a specific capture group has | |
| already been matched. The two possible forms of conditional group are: | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CI(?(\fP\f(CIcondition\fP\f(CI)\fP\f(CIyes\-pattern\fP\f(CI) | |
| (?(\fP\f(CIcondition\fP\f(CI)\fP\f(CIyes\-pattern\fP\f(CI|\fP\f(CIno\-pattern\fP\f(CI)\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| If the condition is satisfied, the yes\-pattern is used; otherwise the | |
| no\-pattern (if present) is used. An absent no\-pattern is equivalent to an empty | |
| string (it always matches). If there are more than two alternatives in the | |
| group, a compile\-time error occurs. Each of the two alternatives may itself | |
| contain nested groups of any form, including conditional groups; the | |
| restriction to two alternatives applies only at the level of the condition | |
| itself. This pattern fragment is an example where the alternatives are complex: | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CI(?(1) (A|B|C) | (D | (?(2)E|F) | E) )\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| There are five kinds of condition: references to capture groups, references to | |
| recursion, two pseudo\-conditions called DEFINE and VERSION, and assertions. | |
| .SS "Checking for a used capture group by number" | |
| .sp | |
| If the text between the parentheses consists of a sequence of digits, the | |
| condition is true if a capture group of that number has previously matched. If | |
| there is more than one capture group with the same number (see the earlier | |
| section about duplicate group numbers), | |
| the condition is true if any of them have matched. An alternative notation, | |
| which is a PCRE2 extension, not supported by Perl, is to precede the digits | |
| with a plus or minus sign. In this case, the group number is relative rather | |
| than absolute. The most recently opened capture group (which could be enclosing | |
| this condition) can be referenced by \f(CI(?(\-1)\fP, the next most recent by \f(CI(?(\-2)\fP, | |
| and so on. Inside loops it can also make sense to refer to subsequent groups. | |
| The next capture group to be opened can be referenced as \f(CI(?(+1)\fP, and so on. The | |
| value zero in any of these forms is not used; it provokes a compile\-time error. | |
| .sp | |
| Consider the following pattern, which contains non\-significant white space to | |
| make it more readable (assume the \f(CBPCRE2_EXTENDED\fP option) and to divide it into | |
| three parts for ease of discussion: | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CI( \(rs( )?\& [^()]+\& (?(1) \(rs) )\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| The first part matches an optional opening parenthesis, and if that | |
| character is present, sets it as the first captured substring. The second part | |
| matches one or more characters that are not parentheses. The third part is a | |
| conditional group that tests whether or not the first capture group | |
| matched. If it did, that is, if subject started with an opening parenthesis, | |
| the condition is true, and so the yes\-pattern is executed and a closing | |
| parenthesis is required. Otherwise, since no\-pattern is not present, the | |
| conditional group matches nothing. In other words, this pattern matches a | |
| sequence of non\-parentheses, optionally enclosed in parentheses. | |
| .sp | |
| If you were embedding this pattern in a larger one, you could use a relative | |
| reference: | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CI...other stuff... ( \(rs( )?\& [^()]+\& (?(\-1) \(rs) ) ...\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| This makes the fragment independent of the parentheses in the larger pattern. | |
| .SS "Checking for a used capture group by name" | |
| .sp | |
| Perl uses the syntax \f(CI(?(<\fP\f(CIname\fP\f(CI>)...)\fP or \f(CI(?(\*(Aq\fP\f(CIname\fP\f(CI\*(Aq)...)\fP to test for a used | |
| capture group by name. For compatibility with earlier versions of PCRE1, which | |
| had this facility before Perl, the syntax \f(CI(?(\fP\f(CIname\fP\f(CI)...)\fP is also recognized. | |
| Note, however, that undelimited names consisting of the letter R followed by | |
| digits are ambiguous (see the section Checking for pattern recursion). Rewriting the above example | |
| to use a named group gives this: | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CI(?<OPEN> \(rs( )?\& [^()]+\& (?(<OPEN>) \(rs) )\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| If the name used in a condition of this kind is a duplicate, the test is | |
| applied to all groups of the same name, and is true if any one of them has | |
| matched. | |
| .SS "Checking for pattern recursion" | |
| .sp | |
| "Recursion" in this sense refers to any subroutine\-like call from one part of | |
| the pattern to another, whether or not it is actually recursive. See the | |
| sections RECURSIVE PATTERNS | |
| and | |
| Groups as subroutines | |
| below for details of recursion and subroutine calls. | |
| .sp | |
| If a condition is the string \f(CI(R)\fP, and there is no capture group with the name | |
| R, the condition is true if matching is currently in a recursion or subroutine | |
| call to the whole pattern or any capture group. If digits follow the letter R, | |
| and there is no group with that name, the condition is true if the most recent | |
| call is into a group with the given number, which must exist somewhere in the | |
| overall pattern. This is a contrived example that is equivalent to \f(CIa+b\fP: | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CI((?(R1)a+|(?1)b))\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| However, in both cases, if there is a capture group with a matching name, the | |
| condition tests for its being set, as described in the section above, instead | |
| of testing for recursion. For example, creating a group with the name R1 by | |
| adding \f(CI(?<R1>)\fP to the above pattern completely changes its meaning. | |
| .sp | |
| If a name preceded by ampersand follows the letter R, for example: | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CI(?(R&\fP\f(CIname\fP\f(CI)...)\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| the condition is true if the most recent recursion is into a group of that name | |
| (which must exist within the pattern). | |
| .sp | |
| This condition does not check the entire recursion stack. It tests only the | |
| current level. If the name used in a condition of this kind is a duplicate, the | |
| test is applied to all groups of the same name, and is true if any one of | |
| them is the most recent recursion. | |
| .sp | |
| At "top level", all these recursion test conditions are false. | |
| .SS "Defining capture groups for use by reference only" | |
| .sp | |
| If the condition is the string \f(CI(DEFINE)\fP, the condition is always false, even if | |
| there is a group with the name DEFINE. In this case, there may be only one | |
| alternative in the rest of the conditional group. It is always skipped if | |
| control reaches this point in the pattern; the idea of DEFINE is that it can be | |
| used to define subroutines that can be referenced from elsewhere. (The use of | |
| subroutines | |
| is described below.) For example, a pattern to match an IPv4 address such as | |
| \f(CI192.168.23.245\fP could be written like this (ignore white space and line | |
| breaks): | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CI(?(DEFINE) (?<byte> 2[0\-4]\(rsd | 25[0\-5] | 1\(rsd\(rsd | [1\-9]?\(rsd) ) | |
| \(rsb (?&byte) (\(rs.(?&byte)){3} \(rsb\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| The first part of the pattern is a DEFINE group inside which another group | |
| named "byte" is defined. This matches an individual component of an IPv4 | |
| address (a number less than 256). When matching takes place, this part of the | |
| pattern is skipped because DEFINE acts like a false condition. The rest of the | |
| pattern uses references to the named group to match the four dot\-separated | |
| components of an IPv4 address, insisting on a word boundary at each end. | |
| .SS "Checking the PCRE2 version" | |
| .sp | |
| Programs that link with a PCRE2 library can check the version by calling | |
| \f(CBpcre2_config()\fP with appropriate arguments. Users of applications that do | |
| not have access to the underlying code cannot do this. A special "condition" | |
| called VERSION exists to allow such users to discover which version of PCRE2 | |
| they are dealing with by using this condition to match a string such as | |
| \f(CIyesno\fP. VERSION must be followed either by \f(CI=\fP or \f(CI>=\fP and a version number. | |
| For example: | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CI(?(VERSION>=10.4)yes|no)\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| This pattern matches \f(CIyes\fP if the PCRE2 version is greater or equal to 10.4, or | |
| \f(CIno\fP otherwise. The fractional part of the version number could be ommited. | |
| .SS "Assertion conditions" | |
| .sp | |
| If the condition is not in any of the above formats, it must be a parenthesized | |
| assertion. This may be a positive or negative lookahead or lookbehind | |
| assertion. However, it must be a traditional atomic assertion, not one of the | |
| non\-atomic assertions. | |
| .sp | |
| Consider this pattern, again containing non\-significant white space, and with | |
| the two alternatives on the second line: | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CI(?(?=[^a\-z]*[a\-z]) | |
| \(rsd{2}\-[a\-z]{3}\-\(rsd{2}\& |\& \(rsd{2}\-\(rsd{2}\-\(rsd{2} )\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| The condition is a positive lookahead assertion that matches an optional | |
| sequence of non\-letters followed by a letter. In other words, it tests for the | |
| presence of at least one letter in the subject. If a letter is found, the | |
| subject is matched against the first alternative; otherwise it is matched | |
| against the second. This pattern matches strings in one of the two forms | |
| \f(CIdd\fP\f(CI\-\fP\f(CIaaa\fP\f(CI\-\fP\f(CIdd\fP or \f(CIdd\fP\f(CI\-\fP\f(CIdd\fP\f(CI\-\fP\f(CIdd\fP, where \fIaaa\fP are letters and \fIdd\fP are digits. | |
| .sp | |
| When an assertion that is a condition contains capture groups, any | |
| capturing that occurs in a matching branch is retained afterwards, for both | |
| positive and negative assertions, because matching always continues after the | |
| assertion, whether it succeeds or fails. (Compare non\-conditional assertions, | |
| for which captures are retained only for positive assertions that succeed.) | |
| .SH "COMMENTS" | |
| .sp | |
| There are two ways of including comments in patterns that are processed by | |
| PCRE2. In both cases, the start of the comment must not be in a character | |
| class, nor in the middle of any other sequence of related characters such as | |
| \f(CI(?:\fP or a group name or number or a Unicode property name. The characters that | |
| make up a comment play no part in the pattern matching. | |
| .sp | |
| The sequence \f(CI(?#\fP marks the start of a comment that continues up to the next | |
| closing parenthesis. Nested parentheses are not permitted. If the | |
| \f(CBPCRE2_EXTENDED\fP or \f(CBPCRE2_EXTENDED_MORE\fP option is set, an unescaped # character | |
| also introduces a comment, which in this case continues to immediately after | |
| the next newline character or character sequence in the pattern. Which | |
| characters are interpreted as newlines is controlled by an option passed to the | |
| compiling function or by a special sequence at the start of the pattern, as | |
| described in the section Newline conventions | |
| above. Note that the end of this type of comment is a literal newline sequence | |
| in the pattern; escape sequences that happen to represent a newline do not | |
| count. For example, consider this pattern when \f(CBPCRE2_EXTENDED\fP is set, and the | |
| default newline convention (a single linefeed character) is in force: | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CIabc #comment \(rsn still comment\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| On encountering the # character, \f(CBpcre2_compile()\fP skips along, looking for | |
| a newline in the pattern. The sequence \f(CI\(rsn\fP is still literal at this stage, so | |
| it does not terminate the comment. Only an actual character with the code value | |
| \f(CR0x0a\fP (the default newline) does so. | |
| .SH "RECURSIVE PATTERNS" | |
| .sp | |
| Consider the problem of matching a string in parentheses, allowing for | |
| unlimited nested parentheses. Without the use of recursion, the best that can | |
| be done is to use a pattern that matches up to some fixed depth of nesting. It | |
| is not possible to handle an arbitrary nesting depth. | |
| .sp | |
| For some time, Perl has provided a facility that allows regular expressions to | |
| recurse (amongst other things). It does this by interpolating Perl code in the | |
| expression at run time, and the code can refer to the expression itself. A Perl | |
| pattern using code interpolation to solve the parentheses problem can be | |
| created like this: | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CI$re\fP \f(CR= qr{\(rs( (?: (?>[^()]+) | (?p{$re}) )* \(rs)}\fP\f(CIx\fP\f(CR;\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| The \f(CI(?p{...})\fP item interpolates Perl code at run time, and in this case refers | |
| recursively to the pattern in which it appears. | |
| .sp | |
| Obviously, PCRE2 cannot support the interpolation of Perl code. Instead, it | |
| supports special syntax for recursion of the entire pattern, and also for | |
| individual capture group recursion. After its introduction in PCRE1 and Python, | |
| this kind of recursion was subsequently introduced into Perl at release 5.10. | |
| .sp | |
| A special item that consists of \f(CI(?\fP followed by a number greater than zero and a | |
| closing parenthesis is a recursive subroutine call of the capture group of the | |
| given number, provided that it occurs inside that group. (If not, it is a | |
| non\-recursive subroutine | |
| call, which is described in the section Groups as subroutines.) The special item \f(CI(?R)\fP or \f(CI(?0)\fP is | |
| a recursive call of the entire regular expression. | |
| .sp | |
| This PCRE2 pattern solves the nested parentheses problem (assume the | |
| \f(CBPCRE2_EXTENDED\fP option is set so that white space is ignored): | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CI\(rs( ( [^()]++ | (?R) )* \(rs)\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| First it matches an opening parenthesis. Then it matches any number of | |
| substrings which can either be a sequence of non\-parentheses, or a recursive | |
| match of the pattern itself (that is, a correctly parenthesized substring). | |
| Finally there is a closing parenthesis. Note the use of a possessive quantifier | |
| to avoid backtracking into sequences of non\-parentheses. | |
| .sp | |
| If this were part of a larger pattern, you would not want to recurse the entire | |
| pattern, so instead you could use this: | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CI( \(rs( ( [^()]++ | (?1) )* \(rs) )\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| We have put the pattern into parentheses, and caused the recursion to refer to | |
| them instead of the whole pattern. | |
| .sp | |
| In a larger pattern, keeping track of parenthesis numbers can be tricky. This | |
| is made easier by the use of relative references. Instead of \f(CI(?1)\fP in the | |
| pattern above you can write \f(CI(?\-2)\fP to refer to the second most recently opened | |
| parentheses preceding the recursion. In other words, a negative number counts | |
| capturing parentheses leftwards from the point at which it is encountered. | |
| .sp | |
| Be aware however, that if | |
| duplicate capture group numbers | |
| are in use, relative references refer to the earliest group with the | |
| appropriate number. Consider, for example: | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CI(?|(a)|(b)) (c) (?\-2)\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| The first two capture groups \f(CI(a)\fP and \f(CI(b)\fP are both numbered 1, and group \f(CI(c)\fP | |
| is number 2. When the reference \f(CI(?\-2)\fP is encountered, the second most recently | |
| opened parentheses has the number 1, but it is the first such group (the \f(CI(a)\fP | |
| group) to which the recursion refers. This would be the same if an absolute | |
| reference \f(CI(?1)\fP was used. In other words, relative references are just a | |
| shorthand for computing a group number. | |
| .sp | |
| It is also possible to refer to subsequent capture groups, by writing | |
| references such as \f(CI(?+2)\fP. However, these cannot be recursive because the | |
| reference is not inside the parentheses that are referenced. They are always | |
| non\-recursive subroutine | |
| calls, as described in the section Groups as subroutines. | |
| .sp | |
| An alternative approach is to use named parentheses. The Perl syntax for this | |
| is \f(CI(?&\fP\f(CIname\fP\f(CI)\fP; PCRE1\(cqs earlier syntax \f(CI(?P>\fP\f(CIname\fP\f(CI)\fP is also supported. We could | |
| rewrite the above example as follows: | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CI(?<pn> \(rs( ( [^()]++ | (?&pn) )* \(rs) )\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| If there is more than one group with the same name, the earliest one is | |
| used. | |
| .sp | |
| The example pattern that we have been looking at contains nested unlimited | |
| repeats, and so the use of a possessive quantifier for matching strings of | |
| non\-parentheses is important when applying the pattern to strings that do not | |
| match. For example, when this pattern is applied to | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CI(aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa()\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| it yields "no match" quickly. However, if a possessive quantifier is not used, | |
| the match runs for a very long time indeed because there are so many different | |
| ways the \f(CI+\fP and \f(CI*\fP repeats can carve up the subject, and all have to be tested | |
| before failure can be reported. | |
| .sp | |
| At the end of a match, the values of capturing parentheses are those from | |
| the outermost level. If you want to obtain intermediate values, a callout | |
| function can be used (see below and the | |
| \f(CRpcre2callout\fP | |
| documentation). If the pattern above is matched against | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CI(ab(cd)ef)\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| the value for the inner capturing parentheses (numbered 2) is \f(CIef\fP, which is | |
| the last value taken on at the top level. If a capture group is not matched at | |
| the top level, its final captured value is unset, even if it was (temporarily) | |
| set at a deeper level during the matching process. | |
| .sp | |
| Do not confuse the \f(CI(?R)\fP item with the condition \f(CI(R)\fP, which tests for recursion. | |
| Consider this pattern, which matches text in angle brackets, allowing for | |
| arbitrary nesting. Only digits are allowed in nested brackets (that is, when | |
| recursing), whereas any characters are permitted at the outer level. | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CI< (?: (?(R) \(rsd++\& | [^<>]*+) | (?R)) * >\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| In this pattern, \f(CI(?(R)\fP is the start of a conditional group, with two different | |
| alternatives for the recursive and non\-recursive cases. The \f(CI(?R)\fP item is the | |
| actual recursive call. | |
| .SS "Differences in recursion processing between PCRE2 and Perl" | |
| .sp | |
| Some former differences between PCRE2 and Perl no longer exist. | |
| .sp | |
| Before release 10.30, recursion processing in PCRE2 differed from Perl in that | |
| a recursive subroutine call was always treated as an atomic group. That is, | |
| once it had matched some of the subject string, it was never re\-entered, even | |
| if it contained untried alternatives and there was a subsequent matching | |
| failure. (Historical note: PCRE implemented recursion before Perl did.) | |
| .sp | |
| Starting with release 10.30, recursive subroutine calls are no longer treated | |
| as atomic. That is, they can be re\-entered to try unused alternatives if there | |
| is a matching failure later in the pattern. This is now compatible with the way | |
| Perl works. If you want a subroutine call to be atomic, you must explicitly | |
| enclose it in an atomic group. | |
| .sp | |
| Supporting backtracking into recursions simplifies certain types of recursive | |
| pattern. For example, this pattern matches palindromic strings: | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CI^((.)(?1)\(rs2|.?)$\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| The second branch in the group matches a single central character in the | |
| palindrome when there are an odd number of characters, or nothing when there | |
| are an even number of characters, but in order to work it has to be able to try | |
| the second case when the rest of the pattern match fails. If you want to match | |
| typical palindromic phrases, the pattern has to ignore all non\-word characters, | |
| which can be done like this: | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CI^\(rsW*+((.)\(rsW*+(?1)\(rsW*+\(rs2|\(rsW*+.?)\(rsW*+$\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| If run with the \f(CBPCRE2_CASELESS\fP option, this pattern matches phrases such as \f(CIA | |
| man, a plan, a canal: Panama!\fP. Note the use of the possessive quantifier \f(CI*+\fP to | |
| avoid backtracking into sequences of non\-word characters. Without this, PCRE2 | |
| takes a great deal longer (ten times or more) to match typical phrases, and | |
| Perl takes so long that you think it has gone into a loop. | |
| .sp | |
| Another way in which PCRE2 and Perl used to differ in their recursion | |
| processing is in the handling of captured values. Formerly in Perl, when a | |
| group was called recursively or as a subroutine (see the section | |
| Groups as subroutines), it | |
| had no access to any values that were captured outside the recursion, whereas | |
| in PCRE2 these values can be referenced. Consider this pattern: | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CI^(.)(\(rs1|a(?2))\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| This pattern matches \f(CIbab\fP. The first capturing parentheses match \f(CIb\fP, then in | |
| the second group, when the backreference \f(CI\(rs1\fP fails to match \f(CIb\fP, the second | |
| alternative matches \f(CIa\fP and then recurses. In the recursion, \f(CI\(rs1\fP does now match | |
| \f(CIb\fP and so the whole match succeeds. This match used to fail in Perl, but in | |
| later versions (I tried 5.024) it now works. | |
| .SS "Groups as subroutines" | |
| .sp | |
| If the syntax for a recursive group call (either by number or by name) is used | |
| outside the parentheses to which it refers, it operates a bit like a subroutine | |
| in a programming language. More accurately, PCRE2 treats the referenced group | |
| as an independent subpattern which it tries to match at the current matching | |
| position. The called group may be defined before or after the reference. A | |
| numbered reference can be absolute or relative, as in these examples: | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CI(...(absolute)...)...(?2)... | |
| (...(relative)...)...(?\-1)... | |
| (...(?+1)...(relative)...\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| An earlier example pointed out that the pattern | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CI(sens|respons)e and \(rs1ibility\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| matches \f(CIsense and sensibility\fP and \f(CIresponse and responsibility\fP, but not | |
| \f(CIsense and responsibility\fP. If instead the pattern | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CI(sens|respons)e and (?1)ibility\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| is used, it does match \f(CIsense and responsibility\fP as well as the other two | |
| strings. Another example is given in the discussion of DEFINE above. | |
| .sp | |
| Like recursions, subroutine calls used to be treated as atomic, but this | |
| changed at PCRE2 release 10.30, so backtracking into subroutine calls can now | |
| occur. However, any capturing parentheses that are set during the subroutine | |
| call revert to their previous values afterwards. | |
| .sp | |
| Processing options such as case\-independence are fixed when a group is | |
| defined, so if it is used as a subroutine, such options cannot be changed for | |
| different calls. For example, consider this pattern: | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CI(abc)(?i:(?\-1))\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| It matches \f(CIabcabc\fP. It does not match \f(CIabcABC\fP because the change of | |
| processing option does not affect the called group. | |
| .sp | |
| The behaviour of | |
| backtracking control verbs | |
| in groups when called as subroutines is described in the section | |
| Backtracking verbs in subroutines | |
| below. | |
| .SS "Recursion and subroutines with returned capture groups" | |
| .sp | |
| Since PCRE2 10.47, recursion and subroutine calls may also specify a list of | |
| capture groups to return. This is a PCRE2 syntax extension not supported by | |
| Perl. The pattern matching recurses into the referenced expression as described | |
| above, however, when the recursion returns to the calling expression the | |
| subgroups captured during the recursion can be retained when the calling | |
| expression\(cqs context is restored. | |
| .sp | |
| When used as a subroutine, this allows the subroutine\(cqs capture groups to | |
| be used as return values. | |
| .sp | |
| Only the specific capture groups listed by the caller will be retained, using | |
| the following syntax: | |
| .sp | |
| .RS 4 | |
| .PD | |
| .TP 24 | |
| \f(CI(?R(\fP\f(CIgrouplist\fP\f(CI))\fP | |
| .PD 0 | |
| .TP 24 | |
| \f(CI(?\fP\f(CIn\fP\f(CI(\fP\f(CIgrouplist\fP\f(CI))\fP | |
| .PD 0 | |
| .TP 24 | |
| \f(CI(?+\fP\f(CIn\fP\f(CI(\fP\f(CIgrouplist\fP\f(CI))\fP | |
| .ad l | |
| Recurse the whole pattern, returning capture groups. | |
| .PD | |
| .TP 24 | |
| \f(CI(?\-\fP\f(CIn\fP\f(CI(\fP\f(CIgrouplist\fP\f(CI))\fP | |
| .PD 0 | |
| .TP 24 | |
| \f(CI(?&\fP\f(CIname\fP\f(CI(\fP\f(CIgrouplist\fP\f(CI))\fP | |
| .PD 0 | |
| .TP 24 | |
| \f(CI(?P>\fP\f(CIname\fP\f(CI(\fP\f(CIgrouplist\fP\f(CI))\fP | |
| .ad l | |
| Call a subroutine, returning capture groups. | |
| .PD | |
| .PD | |
| .RE | |
| .PP | |
| .ad l | |
| .sp | |
| The list of capture groups \fIgrouplist\fP is a comma\-separated list of (absolute | |
| or relative) group numbers, and group names enclosed in single quotes or angle | |
| brackets. | |
| .sp | |
| Here is an example which first uses the DEFINE condition to create a re\-usable | |
| routine for matching a weekday, then calls that subroutine and retains the | |
| groups it captures for use later: | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CI(?x: # ignore whitespace for clarity | |
| # Define the routine "weekendday" which matches Saturday or | |
| # Sunday, and returns the Sat/Sun prefix as \(rsk<short>. | |
| (?(DEFINE) (?<weekendday> | |
| (?|(?<short>Sat)urday|(?<short>Sun)day) ) ) | |
| # Call the routine. Matches "Saturday,Sat" or "Sunday,Sun". | |
| (?&weekendday(<short>)),\(rsk<short> )\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| This feature is not available using the Oniguruma syntax \f(CI\(rsg<...>\fP or \f(CI\(rsg\*(Aq...\*(Aq\fP | |
| below. | |
| .SS "Oniguruma subroutine syntax" | |
| .sp | |
| For compatibility with Oniguruma, the non\-Perl syntax \f(CI\(rsg\fP followed by a name or | |
| a number enclosed either in angle brackets or single quotes, is an alternative | |
| syntax for calling a group as a subroutine, possibly recursively. Here are two | |
| of the examples used above, rewritten using this syntax: | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CI(?<pn> \(rs( ( (?>[^()]+) | \(rsg<pn> )* \(rs) ) | |
| (sens|respons)e and \(rsg\*(Aq1\*(Aqibility\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| PCRE2 supports an extension to Oniguruma: if a number is preceded by a | |
| plus or a minus sign it is taken as a relative reference. For example: | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CI(abc)(?i:\(rsg<\-1>)\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| Note that \f(CI\(rsg{...}\fP (Perl syntax) and \f(CI\(rsg<...>\fP (Oniguruma syntax) are \fInot\fP | |
| synonymous. The former is a backreference; the latter is a subroutine call. | |
| .SH "CALLOUTS" | |
| .sp | |
| Perl has a feature whereby using the sequence \f(CI(?{...})\fP causes arbitrary Perl | |
| code to be obeyed in the middle of matching a regular expression. This makes it | |
| possible, amongst other things, to extract different substrings that match the | |
| same pair of parentheses when there is a repetition. | |
| .sp | |
| PCRE2 provides a similar feature, but of course it cannot obey arbitrary Perl | |
| code. The feature is called "callout". The caller of PCRE2 provides an external | |
| function by putting its entry point in a match context using the function | |
| \f(CBpcre2_set_callout()\fP, and then passing that context to \f(CBpcre2_match()\fP | |
| or \f(CBpcre2_dfa_match()\fP. If no match context is passed, or if the callout | |
| entry point is set to NULL, callout points will be passed over silently during | |
| matching. To disallow callouts in the pattern syntax, you may use the | |
| \f(CBPCRE2_EXTRA_NEVER_CALLOUT\fP option. | |
| .sp | |
| Within a regular expression, \f(CI(?C\fP\f(CIarg\fP\f(CI)\fP indicates a point at which the external | |
| function is to be called. There are two kinds of callout: those with a | |
| numerical argument and those with a string argument. \f(CI(?C)\fP on its own with no | |
| argument is treated as \f(CI(?C0)\fP. A numerical argument allows the application to | |
| distinguish between different callouts. String arguments were added for release | |
| 10.20 to make it possible for script languages that use PCRE2 to embed short | |
| scripts within patterns in a similar way to Perl. | |
| .sp | |
| During matching, when PCRE2 reaches a callout point, the external function is | |
| called. It is provided with the number or string argument of the callout, the | |
| position in the pattern, and one item of data that is also set in the match | |
| block. The callout function may cause matching to proceed, to backtrack, or to | |
| fail. | |
| .sp | |
| By default, PCRE2 implements a number of optimizations at matching time, and | |
| one side\-effect is that sometimes callouts are skipped. If you need all | |
| possible callouts to happen, you need to set options that disable the relevant | |
| optimizations. More details, including a complete description of the | |
| programming interface to the callout function, are given in the | |
| \f(CRpcre2callout\fP | |
| documentation. | |
| .SS "Callouts with numerical arguments" | |
| .sp | |
| If you just want to have a means of identifying different callout points, put a | |
| number no greater than 255 after the letter C. For example, this pattern has two | |
| callout points: | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CI(?C1)abc(?C2)def\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| If the \f(CBPCRE2_AUTO_CALLOUT\fP flag is passed to \f(CBpcre2_compile()\fP, numerical | |
| callouts are automatically installed before each item in the pattern. They are | |
| all numbered 255. If there is a conditional group in the pattern whose | |
| condition is an assertion, an additional callout is inserted just before the | |
| condition. An explicit callout may also be set at this position, as in this | |
| example: | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CI(?(?C9)(?=a)abc|def)\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| Note that this applies only to assertion conditions, not to other types of | |
| condition. | |
| .SS "Callouts with string arguments" | |
| .sp | |
| A delimited string may be used instead of a number as a callout argument. The | |
| starting delimiter must be one of \f(CI`\fP, \f(CI\*(Aq\fP, \f(CI"\fP, \f(CI^\fP, \f(CI%\fP, \f(CI#\fP, \f(CI$\fP or \f(CI{\fP and the ending delimiter is | |
| the same as the start, except for \f(CI{\fP, where the ending delimiter is \f(CI}\fP. If the | |
| ending delimiter is needed within the string, it must be doubled. For | |
| example: | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CI(?C\*(Aqab \*(Aq\*(Aqc\*(Aq\*(Aq d\*(Aq)xyz(?C{any text})pqr\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| The doubling is removed before the string is passed to the callout function. | |
| .SH "BACKTRACKING CONTROL" | |
| .sp | |
| There are a number of special "Backtracking Control Verbs" (to use Perl\(cqs | |
| terminology) that modify the behaviour of backtracking during matching. They | |
| are generally of the form \f(CI(*VERB)\fP or \f(CI(*VERB:\fP\f(CINAME\fP\f(CI)\fP. Some verbs take either form, | |
| and may behave differently depending on whether or not a name argument is | |
| present. The names are not required to be unique within the pattern. | |
| .sp | |
| By default, for compatibility with Perl, a name is any sequence of characters | |
| that does not include a closing parenthesis. The name is not processed in | |
| any way, and it is not possible to include a closing parenthesis in the name. | |
| This can be changed by setting the \f(CBPCRE2_ALT_VERBNAMES\fP option, but the result | |
| is no longer Perl\-compatible. | |
| .sp | |
| When \f(CBPCRE2_ALT_VERBNAMES\fP is set, backslash processing is applied to verb names | |
| and only an unescaped closing parenthesis terminates the name. However, the | |
| only backslash items that are permitted are \f(CI\(rsQ\fP, \f(CI\(rsE\fP, and sequences such as | |
| \f(CI\(rsx{100}\fP that define character code points. Character type escapes such as \f(CI\(rsd\fP | |
| are faulted. | |
| .sp | |
| A closing parenthesis can be included in a name either as \f(CI\(rs)\fP or between \f(CI\(rsQ\fP | |
| and \f(CI\(rsE\fP. In addition to backslash processing, if the \f(CBPCRE2_EXTENDED\fP or | |
| \f(CBPCRE2_EXTENDED_MORE\fP option is also set, unescaped white space in verb names is | |
| skipped, and #\-comments are recognized, exactly as in the rest of the pattern. | |
| \f(CBPCRE2_EXTENDED\fP and \f(CBPCRE2_EXTENDED_MORE\fP do not affect verb names unless | |
| \f(CBPCRE2_ALT_VERBNAMES\fP is also set. | |
| .sp | |
| The maximum length of a name is 255 in the 8\-bit library and 65,535 in the | |
| 16\-bit and 32\-bit libraries. If the name is empty, that is, if the closing | |
| parenthesis immediately follows the colon, the effect is as if the colon were | |
| not there. Any number of these verbs may occur in a pattern. Except for | |
| \f(CI(*ACCEPT)\fP, they may not be quantified. | |
| .sp | |
| Since these verbs are specifically related to backtracking, most of them can be | |
| used only when the pattern is to be matched using the traditional matching | |
| function or JIT, because they use backtracking algorithms. With the exception | |
| of \f(CI(*FAIL)\fP, which behaves like a failing negative assertion, the backtracking | |
| control verbs cause an error if encountered by the DFA matching function. | |
| .sp | |
| The behaviour of these verbs in | |
| repeated groups, | |
| assertions, | |
| and in | |
| capture groups called as subroutines | |
| (whether or not recursively) is documented below. | |
| .SS "Optimizations that affect backtracking verbs" | |
| .sp | |
| PCRE2 contains some optimizations that are used to speed up matching by running | |
| some checks at the start of each match attempt. For example, it may know the | |
| minimum length of matching subject, or that a particular character must be | |
| present. When one of these optimizations bypasses the running of a match, any | |
| included backtracking verbs will not, of course, be processed. You can suppress | |
| the start\-of\-match optimizations by setting the \f(CBPCRE2_NO_START_OPTIMIZE\fP option | |
| when calling \f(CBpcre2_compile()\fP, by calling \f(CBpcre2_set_optimize()\fP with a | |
| \f(CBPCRE2_START_OPTIMIZE_OFF\fP directive, or by starting the pattern with | |
| \f(CI(*NO_START_OPT)\fP. There is more discussion of this option in the section | |
| Compiling a pattern | |
| in the | |
| \f(CRpcre2api\fP | |
| documentation. | |
| .sp | |
| Experiments with Perl suggest that it too has similar optimizations, and like | |
| PCRE2, turning them off can change the result of a match. | |
| .SS "Verbs that act immediately" | |
| .sp | |
| The following verbs act as soon as they are encountered. | |
| .sp | |
| .RS 4 | |
| .PD | |
| .TP 7 | |
| \f(CI(*ACCEPT)\fP or \f(CI(*ACCEPT:\fP\f(CINAME\fP\f(CI)\fP | |
| .ad l | |
| This verb causes the match to end successfully, skipping the remainder of the | |
| pattern. However, when it is inside a capture group that is called as a | |
| subroutine, only that group is ended successfully. Matching then continues | |
| at the outer level. If \f(CI(*ACCEPT)\fP in triggered in a positive assertion, the | |
| assertion succeeds; in a negative assertion, the assertion fails. | |
| .RS 7 | |
| .sp | |
| If \f(CI(*ACCEPT)\fP is inside capturing parentheses, the data so far is captured. For | |
| example: | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CIA((?:A|B(*ACCEPT)|C)D)\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| This matches \f(CIAB\fP, \f(CIAAD\fP, or \f(CIACD\fP; when it matches \f(CIAB\fP, \f(CIB\fP is captured by | |
| the outer parentheses. | |
| .sp | |
| \f(CI(*ACCEPT)\fP is the only backtracking verb that is allowed to be quantified | |
| because an ungreedy quantification with a minimum of zero acts only when a | |
| backtrack happens. Consider, for example, | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CI(A(*ACCEPT)??B)C\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| where A, B, and C may be complex expressions. After matching \f(CIA\fP, the matcher | |
| processes \f(CIBC\fP; if that fails, causing a backtrack, \f(CI(*ACCEPT)\fP is triggered and | |
| the match succeeds. In both cases, all but C is captured. Whereas \f(CI(*COMMIT)\fP | |
| (see below) means "fail on backtrack", a repeated \f(CI(*ACCEPT)\fP of this type means | |
| "succeed on backtrack". | |
| .sp | |
| Warning: \f(CI(*ACCEPT)\fP should not be used within a script run group, because | |
| it causes an immediate exit from the group, bypassing the script run checking. | |
| .RE | |
| .TP 7 | |
| \f(CI(*FAIL)\fP or \f(CI(*FAIL:\fP\f(CINAME\fP\f(CI)\fP | |
| .ad l | |
| This verb causes a matching failure, forcing backtracking to occur. It may be | |
| abbreviated to \f(CI(*F)\fP. It is equivalent to \f(CI(?!)\fP but easier to read. The Perl | |
| documentation notes that it is probably useful only when combined with \f(CI(?{})\fP or | |
| \f(CI(??{})\fP. Those are, of course, Perl features that are not present in PCRE2. The | |
| nearest equivalent is the callout feature, as for example in this pattern: | |
| .RS 7 | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CIa+(?C)(*FAIL)\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| A match with the string \f(CIaaaa\fP always fails, but the callout is taken before | |
| each backtrack happens (in this example, 10 times). | |
| .RE | |
| .PD | |
| .RE | |
| .PP | |
| .ad l | |
| .sp | |
| \f(CI(*ACCEPT:\fP\f(CINAME\fP\f(CI)\fP and \f(CI(*FAIL:\fP\f(CINAME\fP\f(CI)\fP behave the same as \f(CI(*MARK:\fP\f(CINAME\fP\f(CI)(*ACCEPT)\fP and | |
| \f(CI(*MARK:\fP\f(CINAME\fP\f(CI)(*FAIL)\fP, respectively, that is, a \f(CI(*MARK)\fP is recorded just before | |
| the verb acts. | |
| .SS "Recording which path was taken" | |
| .sp | |
| There is one verb whose main purpose is to track how a match was arrived at, | |
| though it also has a secondary use in conjunction with advancing the match | |
| starting point (see \f(CI(*SKIP)\fP below). | |
| .sp | |
| .RS 4 | |
| .PD | |
| .TP 25 | |
| \f(CI(*MARK:\fP\f(CINAME\fP\f(CI)\fP or \f(CI(*:\fP\f(CINAME\fP\f(CI)\fP | |
| .ad l | |
| A name is always required with this verb. For all the other backtracking | |
| control verbs, a \fINAME\fP argument is optional. | |
| .RS 25 | |
| .sp | |
| When a match succeeds, the name of the last\-encountered mark name on the | |
| matching path is passed back to the caller as described in the section | |
| Other information about a match | |
| in | |
| \f(CRpcre2api\fP | |
| documentation. This applies to all instances of \f(CI(*MARK)\fP and other verbs, | |
| including those inside assertions and atomic groups. However, there are | |
| differences in those cases when \f(CI(*MARK)\fP is used in conjunction with \f(CI(*SKIP)\fP as | |
| described below. | |
| .sp | |
| The mark name that was last encountered on the matching path is passed back. A | |
| verb without a \fINAME\fP argument is ignored for this purpose. Here is an example of | |
| \f(CRpcre2test\fP output, where the "mark" modifier requests the retrieval and | |
| outputting of \f(CI(*MARK)\fP data: | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CRre> /X(*MARK:A)Y|X(*MARK:B)Z/mark | |
| data> XY | |
| 0: XY | |
| MK: A | |
| XZ | |
| 0: XZ | |
| MK: B\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| The \f(CI(*MARK)\fP name is tagged with "MK:" in this output, and in this example it | |
| indicates which of the two alternatives matched. This is a more efficient way | |
| of obtaining this information than putting each alternative in its own | |
| capturing parentheses. | |
| .sp | |
| If a verb with a name is encountered in a positive assertion that is true, the | |
| name is recorded and passed back if it is the last\-encountered. This does not | |
| happen for negative assertions or failing positive assertions. | |
| .sp | |
| After a partial match or a failed match, the last encountered name in the | |
| entire match process is returned. For example: | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CRre> /X(*MARK:A)Y|X(*MARK:B)Z/mark | |
| data> XP | |
| No match, mark = B\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| Note that in this unanchored example the mark is retained from the match | |
| attempt that started at the letter "X" in the subject. Subsequent match | |
| attempts starting at "P" and then with an empty string do not get as far as the | |
| \f(CI(*MARK)\fP item, but nevertheless do not reset it. | |
| .sp | |
| If you are interested in \f(CI(*MARK)\fP values after failed matches, you should | |
| probably either set the \f(CBPCRE2_NO_START_OPTIMIZE\fP option or call | |
| \f(CBpcre2_set_optimize()\fP with a \f(CBPCRE2_START_OPTIMIZE_OFF\fP directive | |
| (see above) | |
| to ensure that the match is always attempted. | |
| .RE | |
| .PD | |
| .RE | |
| .PP | |
| .ad l | |
| .SS "Verbs that act after backtracking" | |
| .sp | |
| The following verbs do nothing when they are encountered. Matching continues | |
| with what follows, but if there is a subsequent match failure, causing a | |
| backtrack to the verb, a failure is forced. That is, backtracking cannot pass | |
| to the left of the verb. However, when one of these verbs appears inside an | |
| atomic group or in an atomic lookaround assertion that is true, its effect is | |
| confined to that group, because once the group has been matched, there is never | |
| any backtracking into it. Backtracking from beyond an atomic assertion or group | |
| ignores the entire group, and seeks a preceding backtracking point. | |
| .sp | |
| These verbs differ in exactly what kind of failure occurs when backtracking | |
| reaches them. The behaviour described below is what happens when the verb is | |
| not in a subroutine or an assertion. Subsequent sections cover these special | |
| cases. | |
| .sp | |
| .RS 4 | |
| .PD | |
| .TP 26 | |
| \f(CI(*COMMIT)\fP or \f(CI(*COMMIT:\fP\f(CINAME\fP\f(CI)\fP | |
| .ad l | |
| This verb causes the whole match to fail outright if there is a later matching | |
| failure that causes backtracking to reach it. Even if the pattern is | |
| unanchored, no further attempts to find a match by advancing the starting point | |
| take place. If \f(CI(*COMMIT)\fP is the only backtracking verb that is encountered, | |
| once it has been passed \f(CBpcre2_match()\fP is committed to finding a match at | |
| the current starting point, or not at all. For example: | |
| .RS 26 | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CIa+(*COMMIT)b\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| This matches \f(CIxxaab\fP but not \f(CIaacaab\fP. It can be thought of as a kind of | |
| dynamic anchor, or "I\(cqve started, so I must finish." | |
| .sp | |
| The behaviour of \f(CI(*COMMIT:\fP\f(CINAME\fP\f(CI)\fP is not the same as \f(CI(*MARK:\fP\f(CINAME\fP\f(CI)(*COMMIT)\fP. It is | |
| like \f(CI(*MARK:\fP\f(CINAME\fP\f(CI)\fP in that the name is remembered for passing back to the | |
| caller. However, \f(CI(*SKIP:\fP\f(CINAME\fP\f(CI)\fP searches only for names that are set with | |
| \f(CI(*MARK)\fP, ignoring those set by any of the other backtracking verbs. | |
| .sp | |
| If there is more than one backtracking verb in a pattern, a different one that | |
| follows \f(CI(*COMMIT)\fP may be triggered first, so merely passing \f(CI(*COMMIT)\fP during a | |
| match does not always guarantee that a match must be at this starting point. | |
| .sp | |
| Note that \f(CI(*COMMIT)\fP at the start of a pattern is not the same as an anchor, | |
| unless PCRE2\(cqs start\-of\-match optimizations are turned off, as shown in this | |
| output from \f(CRpcre2test\fP: | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CRre> /(*COMMIT)abc/ | |
| data> xyzabc | |
| 0: abc | |
| data> | |
| re> /(*COMMIT)abc/no_start_optimize | |
| data> xyzabc | |
| No match\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| For the first pattern, PCRE2 knows that any match must start with \f(CIa\fP, so the | |
| optimization skips along the subject to \f(CIa\fP before applying the pattern to the | |
| first set of data. The match attempt then succeeds. The second pattern disables | |
| the optimization that skips along to the first character. The pattern is now | |
| applied starting at \f(CIx\fP, and so the \f(CI(*COMMIT)\fP causes the match to fail without | |
| trying any other starting points. | |
| .RE | |
| .TP 26 | |
| \f(CI(*PRUNE)\fP or \f(CI(*PRUNE:\fP\f(CINAME\fP\f(CI)\fP | |
| .ad l | |
| This verb causes the match to fail at the current starting position in the | |
| subject if there is a later matching failure that causes backtracking to reach | |
| it. If the pattern is unanchored, the normal "bumpalong" advance to the next | |
| starting character then happens. Backtracking can occur as usual to the left of | |
| \f(CI(*PRUNE)\fP, before it is reached, or when matching to the right of \f(CI(*PRUNE)\fP, but | |
| if there is no match to the right, backtracking cannot cross \f(CI(*PRUNE)\fP. In | |
| simple cases, the use of \f(CI(*PRUNE)\fP is just an alternative to an atomic group or | |
| possessive quantifier, but there are some uses of \f(CI(*PRUNE)\fP that cannot be | |
| expressed in any other way. In an anchored pattern \f(CI(*PRUNE)\fP has the same effect | |
| as \f(CI(*COMMIT)\fP. | |
| .RS 26 | |
| .sp | |
| The behaviour of \f(CI(*PRUNE:\fP\f(CINAME\fP\f(CI)\fP is not the same as \f(CI(*MARK:\fP\f(CINAME\fP\f(CI)(*PRUNE)\fP. It is | |
| like \f(CI(*MARK:\fP\f(CINAME\fP\f(CI)\fP in that the name is remembered for passing back to the | |
| caller. However, \f(CI(*SKIP:\fP\f(CINAME\fP\f(CI)\fP searches only for names set with \f(CI(*MARK)\fP, | |
| ignoring those set by other backtracking verbs. | |
| .RE | |
| .TP 26 | |
| \f(CI(*SKIP)\fP | |
| .ad l | |
| This verb, when given without a name, is like \f(CI(*PRUNE)\fP, except that if the | |
| pattern is unanchored, the "bumpalong" advance is not to the next character, | |
| but to the position in the subject where \f(CI(*SKIP)\fP was encountered. \f(CI(*SKIP)\fP | |
| signifies that whatever text was matched leading up to it cannot be part of a | |
| successful match if there is a later mismatch. Consider: | |
| .RS 26 | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CIa+(*SKIP)b\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| If the subject is \f(CIaaaac.\|.\|.\fP, after the first match attempt fails (starting at | |
| the first character in the string), the starting point skips on to start the | |
| next attempt at \f(CIc\fP. Note that a possessive quantifier does not have the same | |
| effect as this example; although it would suppress backtracking during the | |
| first match attempt, the second attempt would start at the second character | |
| instead of skipping on to "c". | |
| .sp | |
| If \f(CI(*SKIP)\fP is used to specify a new starting position that is the same as the | |
| starting position of the current match, or (by being inside a lookbehind) | |
| earlier, the position specified by \f(CI(*SKIP)\fP is ignored, and instead the normal | |
| "bumpalong" occurs. | |
| .RE | |
| .TP 26 | |
| \f(CI(*SKIP:\fP\f(CINAME\fP\f(CI)\fP | |
| .ad l | |
| When \f(CI(*SKIP)\fP has an associated name, its behaviour is modified. When such a | |
| \f(CI(*SKIP)\fP is triggered, the previous path through the pattern is searched for the | |
| most recent \f(CI(*MARK)\fP that has the same name. If one is found, the "bumpalong" | |
| advance is to the subject position that corresponds to that \f(CI(*MARK)\fP instead of | |
| to where \f(CI(*SKIP)\fP was encountered. If no \f(CI(*MARK)\fP with a matching name is found, | |
| the \f(CI(*SKIP)\fP is ignored. | |
| .RS 26 | |
| .sp | |
| The search for a \f(CI(*MARK)\fP name uses the normal backtracking mechanism, which | |
| means that it does not see \f(CI(*MARK)\fP settings that are inside atomic groups or | |
| assertions, because they are never re\-entered by backtracking. Compare the | |
| following \f(CRpcre2test\fP examples: | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CRre> /a(?>(*MARK:X))(*SKIP:X)(*F)|(.)/ | |
| data: abc | |
| 0: a | |
| 1: a | |
| data: | |
| re> /a(?:(*MARK:X))(*SKIP:X)(*F)|(.)/ | |
| data: abc | |
| 0: b | |
| 1: b\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| In the first example, the \f(CI(*MARK)\fP setting is in an atomic group, so it is not | |
| seen when \f(CI(*SKIP:X)\fP triggers, causing the \f(CI(*SKIP)\fP to be ignored. This allows | |
| the second branch of the pattern to be tried at the first character position. | |
| In the second example, the \f(CI(*MARK)\fP setting is not in an atomic group. This | |
| allows \f(CI(*SKIP:X)\fP to find the \f(CI(*MARK)\fP when it backtracks, and this causes a new | |
| matching attempt to start at the second character. This time, the \f(CI(*MARK)\fP is | |
| never seen because \f(CIa\fP does not match \f(CIb\fP, so the matcher immediately jumps to | |
| the second branch of the pattern. | |
| .sp | |
| Note that \f(CI(*SKIP:\fP\f(CINAME\fP\f(CI)\fP searches only for names set by \f(CI(*MARK:\fP\f(CINAME\fP\f(CI)\fP. It ignores | |
| names that are set by other backtracking verbs. | |
| .RE | |
| .TP 26 | |
| \f(CI(*THEN)\fP or \f(CI(*THEN:\fP\f(CINAME\fP\f(CI)\fP | |
| .ad l | |
| This verb causes a skip to the next innermost alternative when backtracking | |
| reaches it. That is, it cancels any further backtracking within the current | |
| alternative. Its name comes from the observation that it can be used for a | |
| pattern\-based if\-then\-else block: | |
| .RS 26 | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CI( COND1 (*THEN) FOO | | |
| COND2 (*THEN) BAR | | |
| COND3 (*THEN) BAZ ) ...\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| If the COND1 pattern matches, FOO is tried (and possibly further items after | |
| the end of the group if FOO succeeds); on failure, the matcher skips to the | |
| second alternative and tries COND2, without backtracking into COND1. If that | |
| succeeds and BAR fails, COND3 is tried. If subsequently BAZ fails, there are no | |
| more alternatives, so there is a backtrack to whatever came before the entire | |
| group. If \f(CI(*THEN)\fP is not inside an alternation, it acts like \f(CI(*PRUNE)\fP. | |
| .sp | |
| The behaviour of \f(CI(*THEN:\fP\f(CINAME\fP\f(CI)\fP is not the same as \f(CI(*MARK:\fP\f(CINAME\fP\f(CI)(*THEN)\fP. It is | |
| like \f(CI(*MARK:\fP\f(CINAME\fP\f(CI)\fP in that the name is remembered for passing back to the | |
| caller. However, \f(CI(*SKIP:\fP\f(CINAME\fP\f(CI)\fP searches only for names set with \f(CI(*MARK)\fP, | |
| ignoring those set by other backtracking verbs. | |
| .sp | |
| A group that does not contain a | character is just a part of the enclosing | |
| alternative; it is not a nested alternation with only one alternative. The | |
| effect of \f(CI(*THEN)\fP extends beyond such a group to the enclosing alternative. | |
| Consider this pattern, where A, B, etc. are complex pattern fragments that do | |
| not contain any | characters at this level: | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CIA (B(*THEN)C) | D\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| If A and B are matched, but there is a failure in C, matching does not | |
| backtrack into A; instead it moves to the next alternative, that is, D. | |
| However, if the group containing \f(CI(*THEN)\fP is given an alternative, it | |
| behaves differently: | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CIA (B(*THEN)C | (*FAIL)) | D\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| The effect of \f(CI(*THEN)\fP is now confined to the inner group. After a failure in C, | |
| matching moves to \f(CI(*FAIL)\fP, which causes the whole group to fail because there | |
| are no more alternatives to try. In this case, matching does backtrack into A. | |
| .sp | |
| Note that a conditional group is not considered as having two alternatives, | |
| because only one is ever used. In other words, the | character in a conditional | |
| group has a different meaning. Ignoring white space, consider: | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CI^.*? (?(?=a) a | b(*THEN)c )\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| If the subject is \f(CIba\fP, this pattern does not match. Because \f(CI.*?\fP is ungreedy, | |
| it initially matches zero characters. The condition \f(CI(?=a)\fP then fails, the | |
| character \f(CIb\fP is matched, but \f(CIc\fP is not. At this point, matching does not | |
| backtrack to \f(CI.*?\fP as might perhaps be expected from the presence of the | | |
| character. The conditional group is part of the single alternative that | |
| comprises the whole pattern, and so the match fails. (If there was a backtrack | |
| into \f(CI.*?\fP, allowing it to match \f(CIb\fP, the match would succeed.) | |
| .RE | |
| .PD | |
| .RE | |
| .PP | |
| .ad l | |
| .sp | |
| The verbs just described provide four different "strengths" of control when | |
| subsequent matching fails. \f(CI(*THEN)\fP is the weakest, carrying on the match at the | |
| next alternative. \f(CI(*PRUNE)\fP comes next, failing the match at the current | |
| starting position, but allowing an advance to the next character (for an | |
| unanchored pattern). \f(CI(*SKIP)\fP is similar, except that the advance may be more | |
| than one character. \f(CI(*COMMIT)\fP is the strongest, causing the entire match to | |
| fail. | |
| .SS "More than one backtracking verb" | |
| .sp | |
| If more than one backtracking verb is present in a pattern, the one that is | |
| backtracked onto first acts. For example, consider this pattern, where A, B, | |
| etc. are complex pattern fragments: | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CI(A(*COMMIT)B(*THEN)C|ABD)\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| If A matches but B fails, the backtrack to \f(CI(*COMMIT)\fP causes the entire match to | |
| fail. However, if A and B match, but C fails, the backtrack to \f(CI(*THEN)\fP causes | |
| the next alternative (ABD) to be tried. This behaviour is consistent, but is | |
| not always the same as Perl\(cqs. It means that if two or more backtracking verbs | |
| appear in succession, all but the last of them has no effect. Consider this | |
| example: | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CI...(*COMMIT)(*PRUNE)...\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| If there is a matching failure to the right, backtracking onto \f(CI(*PRUNE)\fP causes | |
| it to be triggered, and its action is taken. There can never be a backtrack | |
| onto \f(CI(*COMMIT)\fP. | |
| .SS "Backtracking verbs in repeated groups" | |
| .sp | |
| PCRE2 sometimes differs from Perl in its handling of backtracking verbs in | |
| repeated groups. For example, consider: | |
| .sp | |
| .ss \n[.ss] | |
| .nf | |
| .fam C | |
| \f(CI(a(*COMMIT)b)+ac\fP | |
| .fam | |
| .fi | |
| .ss \n[.ss] 0 | |
| .sp | |
| If the subject is \f(CIabac\fP, Perl matches unless its optimizations are disabled, | |
| but PCRE2 always fails because the \f(CI(*COMMIT)\fP in the second repeat of the group | |
| acts. | |
| .SS "Backtracking verbs in assertions" | |
| .sp | |
| \f(CI(*FAIL)\fP in any assertion has its normal effect: it forces an immediate | |
| backtrack. The behaviour of the other backtracking verbs depends on whether or | |
| not the assertion is standalone or acting as the condition in a conditional | |
| group. | |
| .sp | |
| \f(CI(*ACCEPT)\fP in a standalone positive assertion causes the assertion to succeed | |
| without any further processing; captured strings and a mark name (if set) are | |
| retained. In a standalone negative assertion, \f(CI(*ACCEPT)\fP causes the assertion to | |
| fail without any further processing; captured substrings and any mark name are | |
| discarded. | |
| .sp | |
| If the assertion is a condition, \f(CI(*ACCEPT)\fP causes the condition to be true for | |
| a positive assertion and false for a negative one; captured substrings are | |
| retained in both cases. | |
| .sp | |
| The remaining verbs act only when a later failure causes a backtrack to | |
| reach them. This means that, for the Perl\-compatible assertions, their effect | |
| is confined to the assertion, because Perl lookaround assertions are atomic. A | |
| backtrack that occurs after such an assertion is complete does not jump back | |
| into the assertion. Note in particular that a \f(CI(*MARK)\fP name that is set in an | |
| assertion is not "seen" by an instance of \f(CI(*SKIP:\fP\f(CINAME\fP\f(CI)\fP later in the pattern. | |
| .sp | |
| PCRE2 now supports non\-atomic positive assertions and also "scan substring" | |
| assertions, as described in the sections NON\-ATOMIC ASSERTIONS | |
| and | |
| SCAN SUBSTRING ASSERTIONS | |
| above. These assertions must be standalone (not used as conditions). They are | |
| not Perl\-compatible. For these assertions, a later backtrack does jump back | |
| into the assertion, and therefore verbs such as \f(CI(*COMMIT)\fP can be triggered by | |
| backtracks from later in the pattern. | |
| .sp | |
| The effect of \f(CI(*THEN)\fP is not allowed to escape beyond an assertion. If there | |
| are no more branches to try, \f(CI(*THEN)\fP causes a positive assertion to be false, | |
| and a negative assertion to be true. This behaviour differs from Perl when the | |
| assertion has only one branch. | |
| .sp | |
| The other backtracking verbs are not treated specially if they appear in a | |
| standalone positive assertion. In a conditional positive assertion, | |
| backtracking (from within the assertion) into \f(CI(*COMMIT)\fP, \f(CI(*SKIP)\fP, or \f(CI(*PRUNE)\fP | |
| causes the condition to be false. However, for both standalone and conditional | |
| negative assertions, backtracking into \f(CI(*COMMIT)\fP, \f(CI(*SKIP)\fP, or \f(CI(*PRUNE)\fP causes | |
| the assertion to be true, without considering any further alternative branches. | |
| .SS "Backtracking verbs in subroutines" | |
| .sp | |
| These behaviours occur whether or not the group is called recursively. | |
| .sp | |
| \f(CI(*ACCEPT)\fP in a group called as a subroutine causes the subroutine match to | |
| succeed without any further processing. Matching then continues after the | |
| subroutine call. Perl documents this behaviour. Perl\(cqs treatment of the other | |
| verbs in subroutines is different in some cases. | |
| .sp | |
| \f(CI(*FAIL)\fP in a group called as a subroutine has its normal effect: it forces | |
| an immediate backtrack. | |
| .sp | |
| \f(CI(*COMMIT)\fP, \f(CI(*SKIP)\fP, and \f(CI(*PRUNE)\fP cause the subroutine match to fail when | |
| triggered by being backtracked to in a group called as a subroutine. There is | |
| then a backtrack at the outer level. | |
| .sp | |
| \f(CI(*THEN)\fP, when triggered, skips to the next alternative in the innermost | |
| enclosing group that has alternatives (its normal behaviour). However, if there | |
| is no such group within the subroutine\(cqs group, the subroutine match fails and | |
| there is a backtrack at the outer level. | |
| .SH "EBCDIC ENVIRONMENTS" | |
| .sp | |
| Differences in the way PCRE behaves when it is running in an EBCDIC environment | |
| are covered in this section. | |
| .SS "Escape sequences" | |
| .sp | |
| When PCRE2 is compiled in EBCDIC mode, \f(CI\(rsN{U+\fP\f(CIhhh...\fP\f(CI}\fP is not supported. \f(CI\(rsa\fP, \f(CI\(rse\fP, | |
| \f(CI\(rsf\fP, \f(CI\(rsn\fP, \f(CI\(rsr\fP, and \f(CI\(rst\fP generate the appropriate EBCDIC code values. The \f(CI\(rsc\fP | |
| escape is processed as specified for Perl in the \f(CRperlebcdic\fP document. The | |
| only characters that are allowed after \f(CI\(rsc\fP are A\(enZ, a\(enz, or one of @, [, \(rs, ], | |
| ^, _, or ?. Any other character provokes a compile\-time error. The sequence | |
| \f(CI\(rsc@\fP encodes character code 0; after \f(CI\(rsc\fP the letters (in either case) encode | |
| characters 1\(en26 (\f(CR0x01\fP to \f(CR0x1A\fP); [, \(rs, ], ^, and _ encode characters 27\(en31 | |
| (\f(CR0x1B\fP to \f(CR0x1F\fP), and \f(CI\(rsc?\fP becomes either 255 (\f(CR0xFF\fP) or 95 (\f(CR0x5F\fP). | |
| .sp | |
| Thus, apart from \f(CI\(rsc?\fP, these escapes generate the same character code values as | |
| they do in an ASCII or Unicode environment, though the meanings of the values | |
| mostly differ. For example, \f(CI\(rscG\fP always generates code value 7, which is BEL in | |
| ASCII but DEL in EBCDIC. | |
| .sp | |
| The sequence \f(CI\(rsc?\fP generates DEL (127, \f(CR0x7F\fP) in an ASCII environment, but | |
| because 127 is not a control character in EBCDIC, Perl makes it generate the | |
| APC character. Unfortunately, there are several variants of EBCDIC. In most of | |
| them the APC character has the value 255 (\f(CR0xFF\fP), but in the one Perl calls | |
| POSIX\-BC its value is 95 (\f(CR0x5F\fP). If certain other characters have POSIX\-BC | |
| values, PCRE2 makes \f(CI\(rsc?\fP generate 95; otherwise it generates 255. | |
| .SS "Character classes" | |
| .sp | |
| In character classes there is a special case in EBCDIC environments for ranges | |
| whose end points are both specified as literal letters in the same case. For | |
| compatibility with Perl, EBCDIC code points within the range that are not | |
| letters are omitted. For example, \f(CI[h\-k]\fP matches only four characters, even | |
| though the EBCDIC codes for h and k are \f(CR0x88\fP and \f(CR0x92\fP, a range of 11 code | |
| points. However, if the range is specified numerically, for example, | |
| \f(CI[\(rsx88\-\(rsx92]\fP or \f(CI[h\-\(rsx92]\fP, all code points are included. | |
| .SH "SEE ALSO" | |
| .sp | |
| \f(CRpcre2api\fP, \f(CRpcre2callout\fP, \f(CRpcre2matching\fP, | |
| \f(CRpcre2syntax\fP, \f(CRpcre2\fP. | |
| .SS "Author" | |
| .sp | |
| Philip Hazel | |
| .br | |
| Retired from University Computing Service | |
| .br | |
| Cambridge, England. | |
| .SS "Revision" | |
| .sp | |
| Last updated: 25 October 2025 | |
| .br | |
| Copyright \(co 1997\-2024 University of Cambridge. |