glib-regex-syntax.html

最新gtk中文资料集

</p>
<p>
By default, the quantifiers are "greedy", that is, they match as much
as possible (up to the maximum number of permitted times), 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 /* and */ and within the comment, individual * and /
characters may appear. An attempt to match C comments by applying the
pattern
</p>
<pre class="programlisting">
/\*.*\*/
</pre>
<p>
to the string
</p>
<pre class="programlisting">
/* first comment */  not comment  /* second comment */
</pre>
<p>
fails, because it matches the entire string owing to the greediness of
the .* item.
</p>
<p>
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
</p>
<pre class="programlisting">
/\*.*?\*/
</pre>
<p>
does the right thing with the 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
</p>
<pre class="programlisting">
\d??\d
</pre>
<p>
which matches one digit by preference, but can match two if that is the
only way the rest of the pattern matches.
</p>
<p>
If the <code class="varname">G_REGEX_UNGREEDY</code> flag is set, 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.
</p>
<p>
When a parenthesized subpattern 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.
</p>
<p>
If a pattern starts with .* or .{0,} and the <code class="varname">G_REGEX_DOTALL</code> flag
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 string, so there is no
point in retrying the overall match at any position after the first.
GRegex normally treats such a pattern as though it were preceded by \A.
</p>
<p>
In cases where it is known that the string contains no newlines, it
is worth setting <code class="varname">G_REGEX_DOTALL</code> in order to obtain this optimization,
or alternatively using ^ to indicate anchoring explicitly.
</p>
<p>
However, there is one situation where the optimization cannot be used.
When .* 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:
</p>
<pre class="programlisting">
(.*)abc\1
</pre>
<p>
If the string is "xyz123abc123" the match point is the fourth character.
For this reason, such a pattern is not implicitly anchored.
</p>
<p>
When a capturing subpattern is repeated, the value captured is the
substring that matched the final iteration. For example, after
</p>
<pre class="programlisting">
(tweedle[dume]{3}\s*)+
</pre>
<p>
has matched "tweedledum tweedledee" the value of the captured substring
is "tweedledee". However, if there are nested capturing subpatterns,
the corresponding captured values may have been set in previous iterations.
For example, after
</p>
<pre class="programlisting">
/(a|(b))+/
</pre>
<p>
matches "aba" the value of the second captured substring is "b".
</p>
</div>
<div class="refsect1" lang="en">
<a name="id2816195"></a><h2>Atomic grouping and possessive quantifiers</h2>
<p>
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.
</p>
<p>
Consider, for example, the pattern \d+foo when applied to the string
</p>
<pre class="programlisting">
123456bar
</pre>
<p>
After matching all 6 digits and then failing to match "foo", the normal
action of the matcher is to try again with only 5 digits matching the
\d+ item, and then with 4, and so on, before ultimately failing.
"Atomic grouping" (a term taken from Jeffrey Friedl&#8217;s book) provides
the means for specifying that once a subpattern has matched, it is not
to be re-evaluated in this way.
</p>
<p>
If we use atomic grouping for the previous example, the matcher
give up immediately on failing to match "foo" the first time. The notation
is a kind of special parenthesis, starting with (?&gt; as in this
example:
</p>
<pre class="programlisting">
(?&gt;\d+)foo
</pre>
<p>
This kind of parenthesis "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.
</p>
<p>
An alternative description is that a subpattern of this type matches
the string of characters that an identical standalone pattern would
match, if anchored at the current point in the string.
</p>
<p>
Atomic grouping subpatterns are not capturing subpatterns. Simple cases
such as the above example can be thought of as a maximizing repeat that
must swallow everything it can. So, while both \d+ and \d+? are prepared
to adjust the number of digits they match in order to make the
rest of the pattern match, (?&gt;\d+) can only match an entire sequence of
digits.
</p>
<p>
Atomic groups in general can of course contain arbitrarily complicated
subpatterns, and can be nested. However, when the subpattern for 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 + character following a quantifier. Using
this notation, the previous example can be rewritten as
</p>
<pre class="programlisting">
\d++foo
</pre>
<p>
Possessive quantifiers are always greedy; the setting of the
<code class="varname">G_REGEX_UNGREEDY</code> 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.
</p>
<p>
The possessive quantifier syntax is an extension to the Perl syntax.
It was invented by Jeffrey Friedl in the first edition of his book and
then implemented by Mike McCloskey in Sun's Java package.
It ultimately found its way into Perl at release 5.10.
</p>
<p>
GRegex has an optimization that automatically "possessifies" certain simple
pattern constructs. For example, the sequence A+B is treated as A++B because
there is no point in backtracking into a sequence of A's when B must follow.
</p>
<p>
When a pattern contains an unlimited repeat inside a subpattern 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
</p>
<pre class="programlisting">
(\D+|&lt;\d+&gt;)*[!?]
</pre>
<p>
matches an unlimited number of substrings that either consist of non-
digits, or digits enclosed in &lt;&gt;, followed by either ! or ?. When it
matches, it runs quickly. However, if it is applied to
</p>
<pre class="programlisting">
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
</pre>
<p>
it takes a long time before reporting failure. This is because the
string can be divided between the internal \D+ repeat and the external
* repeat in a large number of ways, and all have to be tried. (The
example uses [!?] rather than a single character at the end, because
GRegex has an optimization that allows for fast failure
when a single character is used. It 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:
</p>
<pre class="programlisting">
((?&gt;\D+)|&lt;\d+&gt;)*[!?]
</pre>
<p>
sequences of non-digits cannot be broken, and failure happens quickly.
</p>
</div>
<div class="refsect1" lang="en">
<a name="id2816369"></a><h2>Back references</h2>
<p>
Outside a character class, a backslash followed by a digit greater than
0 (and possibly further digits) is a back reference to a capturing subpattern
earlier (that is, to its left) in the pattern, provided there have been that
many previous capturing left parentheses.
</p>
<p>
However, if the decimal number following the backslash is less than 10,
it is always taken as a back reference, and causes an error only if
there are not that many capturing left parentheses in the entire pattern.
In other words, the parentheses that are referenced need not be
to the left of the reference for numbers less than 10. A "forward back
reference" of this type can make sense when a repetition is involved and
the subpattern to the right has participated in an earlier iteration.
</p>
<p>
It is not possible to have a numerical "forward back reference" to subpattern
whose number is 10 or more using this syntax because a sequence such as \e50 is
interpreted as a character defined in octal. See the subsection entitled
"Non-printing characters" above for further details of the handling of digits
following a backslash. There is no such problem when named parentheses are used.
A back reference to any subpattern is possible using named parentheses (see below).
</p>
<p>
Another way of avoiding the ambiguity inherent in the use of digits following a
backslash is to use the \g escape sequence (introduced in Perl 5.10.)
This escape must be followed by a positive or a negative number,
optionally enclosed in braces.
</p>
<p>
A positive 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 negative number is a relative reference. Consider "(abc(def)ghi)\g{-1}",
the sequence \g{-1} is a reference to the most recently started capturing
subpattern before \g, that is, is it equivalent to \2. Similarly, \g{-2}
would be equivalent to \1. 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.
</p>
<p>
A back reference matches whatever actually matched the capturing subpattern
in the current string, rather than anything matching
the subpattern itself (see "Subpatterns as subroutines" below for a way
of doing that). So the pattern
</p>
<pre class="programlisting">
(sens|respons)e and \1ibility
</pre>
<p>
matches "sense and sensibility" and "response and responsibility", but
not "sense and responsibility". If caseful matching is in force at the
time of the back reference, the case of letters is relevant. For example,
</p>
<pre class="programlisting">
((?i)rah)\s+\1
</pre>
<p>
matches "rah rah" and "RAH RAH", but not "RAH rah", even though the
original capturing subpattern is matched caselessly.
</p>
<p>
Back references to named subpatterns use the Perl syntax \k&lt;name&gt; or \k'name'
or the Python syntax (?P=name). We could rewrite the above example in either of
the following ways:
</p>
<pre class="programlisting">
(?&lt;p1&gt;(?i)rah)\s+\k&lt;p1&gt;
(?P&lt;p1&gt;(?i)rah)\s+(?P=p1)
</pre>
<p>
A subpattern that is referenced by name may appear in the pattern before or
after the reference.
</p>
<p>
There may be more than one back reference to the same subpattern. If a
subpattern has not actually been used in a particular match, any back
references to it always fail. For example, the pattern
</p>
<pre class="programlisting">
(a|(bc))\2
</pre>
<p>
always fails if it starts to match "a" rather than "bc". Because there
may be many capturing parentheses in a pattern, all digits following
the backslash are taken as part of a potential back reference number.
If the pattern continues with a digit character, some delimiter must be
used to terminate the back reference. If the <code class="varname">G_REGEX_EXTENDED</code> flag is
set, this can be whitespace. Otherwise an empty comment (see "Comments" below) can be used.
</p>
<p>
A back reference that occurs inside the parentheses to which it refers
fails when the subpattern is first used, so, for example, (a\1) never
matches. However, such references can be useful inside repeated subpatterns.
For example, the pattern
</p>
<pre class="programlisting">
(a|b\1)+
</pre>
<p>
matches any number of "a"s and also "aba", "ababbaa" etc. At each iteration
of the subpattern, the back reference 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 back reference. This can be done using alternation, as in
the example above, or by a quantifier with a minimum of zero.
</p>
</div>
<div class="refsect1" lang="en">
<a name="id2813022"></a><h2>Assertions</h2>
<p>
An assertion is a test on the characters following or preceding the
current matching point that does not actually consume any characters.
The simple assertions coded as \b, \B, \A, \G, \Z, \z, ^ and $ are
described above.
</p>
<p>
More complicated assertions are coded as subpatterns. There are two
kinds: those that look ahead of the current position in the
string, and those that look behind it. An assertion subpattern is
matched in the normal way, except that it does not cause the current
matching position to be changed.
</p>
<p>
Assertion subpatterns are not capturing subpatterns, and may not be
repeated, because it makes no sense to assert the same thing several
times. If any kind of assertion contains capturing subpatterns within
it, these are counted for the purposes of numbering the capturing
subpatterns in the whole pattern. However, substring capturing is carried
out only for positive assertions, because it does not make sense for
negative assertions.
</p>
<div class="refsect2" lang="en">
<a name="id2813046"></a><h3>Lookahead assertions</h3>
<p>
Lookahead assertions start with (?= for positive assertions and (?! for
negative assertions. For example,
</p>
<pre class="programlisting">
\w+(?=;)
</pre>
<p>
matches a word followed by a semicolon, but does not include the semicolon
in the match, and
</p>
<pre class="programlisting">
foo(?!bar)
</pre>
<p>
matches any occurrence of "foo" that is not followed by "bar". Note
that the apparently similar pattern
</p>
<pre class="programlisting">
(?!foo)bar
</pre>
<p>
doe