Just-in-time compiler support The
just-in-time compiler can be enabled when the PCRE2 library is built. Large performance benefits are possible when (for example) the calling program utilizes the feature with compatible patterns that are executed repeatedly. The just-in-time compiler support was written by Zoltan Herczeg and is not addressed in the POSIX wrapper.
Flexible memory management The use of the system stack for backtracking can be problematic in PCRE1, which is why this feature of the implementation was changed in PCRE2. The heap is now used for this purpose, and the total amount can be limited. The problem of
stack overflow, which came up regularly with PCRE1, is no longer an issue with PCRE2 from release 10.30 (2017).
Consistent escaping rules Like Perl, PCRE2 has consistent escaping rules: any non-alpha-numeric character may be escaped to mean its literal value by prefixing a \ (backslash) before the character. Any alpha-numeric character preceded by a backslash typically gives it a special meaning. In the case where the sequence has not been defined to be special, an error occurs. This is different to Perl, which gives an error only if it is in warning mode (PCRE2 does not have a warning mode). In basic POSIX regular expressions, sometimes backslashes escaped non-alpha-numerics (e.g. \.), and sometimes they introduced a special feature (e.g. \(\)).
Extended character classes Single-letter
character classes are supported in addition to the longer POSIX names. For example, \d matches any digit exactly as
:digit: would in POSIX regular expressions.
Minimal matching (a.k.a. "ungreedy") A ? may be placed after any repetition quantifier to indicate that the shortest match should be used. The default is to attempt the
longest match first and backtrack through shorter matches: e.g. a.*?b would match first "ab" in "ababab", where a.*b would match the entire string. If the U flag is set, then quantifiers are ungreedy (lazy) by default, while ? makes them greedy.
Unicode character properties Unicode defines several properties for each character. Patterns in PCRE2 can match these properties: e.g. \p{Ps}.*?\p{Pe} would match a string beginning with any "opening punctuation" and ending with any "close punctuation" such as [abc]. Matching of certain "normal" metacharacters can be driven by Unicode properties when the compile option PCRE2_UCP is set. The option can be set for a pattern by including (*UCP) at the start of pattern. The option alters behavior of the following metacharacters: \B, \b, \D, \d, \S, \s, \W, \w, and some of the POSIX character classes. For example, the set of characters matched by \w (word characters) is expanded to include letters and accented letters as defined by Unicode properties. Such matching is slower than the normal (
ASCII-only) non-UCP alternative. Note that the UCP option requires the library to have been built to include Unicode support (this is the default for PCRE2). Very early versions of PCRE1 supported only ASCII code. Later,
UTF-8 support was added. Support for
UTF-16 was added in version 8.30, and support for UTF-32 in version 8.32. PCRE2 has always supported all three UTF encodings.
Multiline matching ^ and $ can match at the beginning and end of a string only, or at the start and end of each "line" within the string, depending on what options are set.
Newline/linebreak options When PCRE is compiled, a newline default is selected. Which newline/linebreak is in effect affects where PCRE detects ^ line beginnings and $ ends (in multiline mode), as well as what matches dot (regardless of multiline mode, unless the dotall option (?s) is set). It also affects PCRE matching procedure (since version 7.0): when an unanchored pattern fails to match at the start of a newline sequence, PCRE advances past the entire newline sequence before retrying the match. If the newline option alternative in effect includes CRLF as one of the valid linebreaks, it does not skip the \n in a CRLF if the pattern contains specific \r or \n references (since version 7.3). Since version 8.10, the metacharacter \N always matches any character other than linebreak characters. It has the same behavior as . when the dotall option aka (?s) is not in effect. The newline option can be altered with external options when PCRE is compiled and when it is run. Some applications using PCRE provide users with the means to apply this setting through an external option. So the newline option can also be stated at the start of the pattern using one of the following: • (*LF) Newline is a linefeed character. Corresponding linebreaks can be matched with \n. • (*CR) Newline is a
carriage return. Corresponding linebreaks can be matched with \r. • (*CRLF) Newline/linebreak is a carriage return followed by a linefeed. Corresponding linebreaks can be matched with \r\n. • (*ANYCRLF) Any of the above encountered in the data will trigger newline processing. Corresponding linebreaks can be matched with (?:\r\n?|\n) or with \R. See below for configuration and options concerning what matches backslash-R. • (*ANY) Any of the above plus special Unicode linebreaks. When not in UTF-8 mode, corresponding linebreaks can be matched with (?:\r\n?|\n|\x0B|\f|\x85) or \R. In UTF-8 mode, two additional characters are recognized as line breaks with (*ANY): • LS (line separator, U+2028), • PS (paragraph separator, U+2029). On Windows, in non-Unicode data, some of the ANY linebreak characters have other meanings. For example, \x85 can match a horizontal ellipsis, and if encountered while the ANY newline is in effect, it would trigger newline processing. See below for configuration and options concerning what matches backslash-R.
Backslash-R options When PCRE is compiled, a default is selected for what matches \R. The default can be either to match the linebreaks corresponding to ANYCRLF or those corresponding to ANY. The default can be overridden when necessary by including (*BSR_UNICODE) or (*BSR_ANYCRLF) at the start of the pattern. A (*
newline) option can be provided in addition to a (*BSR..) option, e.g., (*BSR_UNICODE)(*ANY)
rest-of-pattern. The backslash-R options also can be changed with external options by the application calling PCRE2, when a pattern is compiled.
Beginning of pattern options Linebreak options such as (*LF) documented above; backslash-R options such as (*BSR_ANYCRLF) documented above; Unicode Character Properties option (*UCP) documented above; (*UTF8) option documented as follows: if PCRE2 has been compiled with
UTF support, the (*UTF) option at the beginning of a pattern can be used instead of setting an external option to invoke UTF-8, UTF-16, or UTF-32 mode.
Backreferences A pattern may refer back to the results of a previous match. For example, (a|b)c\1 would match either "aca" or "bcb" and would not match, for example, "acb".
Named subpatterns A sub-pattern (surrounded by parentheses, like (...)) may be named by including a leading ?P after the opening parenthesis. Named subpatterns are a feature that PCRE adopted from
Python regular expressions. This feature was subsequently adopted by Perl, so now named groups can also be defined using (?...) or (?'name'...), as well as (?P...). Named groups can be backreferenced with, for example: (?P=name) (Python syntax) or \k'name' (Perl syntax).
Subroutines While a backreference provides a mechanism to refer to that part of the subject that has previously matched a subpattern, a subroutine provides a mechanism to reuse an underlying previously defined subpattern. The subpattern's options, such as case independence, are fixed when the subpattern is defined. (a.c)(?1) would match "aacabc" or "abcadc", whereas using a backreference (a.c)\1 would not, though both would match "aacaac" or "abcabc". PCRE also supports a non-Perl
Oniguruma construct for subroutines. They are specified using \g or \g.
Atomic grouping Atomic grouping is a way of preventing
backtracking in a pattern. For example, a++bc will match as many "a"s as possible and never back up to try one less.
Look-ahead and look-behind assertions Patterns may assert that previous text or subsequent text contains a pattern without consuming matched text (zero-width assertion). For example, /\w+(?=\t)/ matches a word followed by a
tab, without including the tab itself. Look-behind assertions cannot be of uncertain length though (unlike Perl) each branch can be a different fixed length. \K can be used in a pattern to reset the start of the current whole match. This provides a flexible alternative approach to look-behind assertions because the discarded part of the match (the part that precedes \K) need not be fixed in length.
Escape sequences for zero-width assertions E.g. \b for matching zero-width "word boundaries", similar to (?.
Comments A comment begins with (?# and ends at the next closing parenthesis.
Recursive patterns A pattern can refer back to itself recursively or to any subpattern. For example, the pattern \((a*|(?R))*\) will match any combination of balanced parentheses and "a"s.
Generic callouts PCRE expressions can embed (?C
n), where
n is some number. This will call out to an external user-defined function through the PCRE API and can be used to embed arbitrary code in a pattern. == Differences from Perl ==