src/external/pcre2-10.32/doc/html/pcre2partial.html

   1 <html>
   2 <head>
   3 <title>pcre2partial specification</title>
   4 </head>
   5 <body bgcolor="#FFFFFF" text="#00005A" link="#0066FF" alink="#3399FF" vlink="#2222BB">
   6 <h1>pcre2partial man page</h1>
   7 <p>
   8 Return to the <a href="index.html">PCRE2 index page</a>.
   9 </p>
  10 <p>
  11 This page is part of the PCRE2 HTML documentation. It was generated
  12 automatically from the original man page. If there is any nonsense in it,
  13 please consult the man page, in case the conversion went wrong.
  14 <br>
  15 <ul>
  16 <li><a name="TOC1" href="#SEC1">PARTIAL MATCHING IN PCRE2</a>
  17 <li><a name="TOC2" href="#SEC2">PARTIAL MATCHING USING pcre2_match()</a>
  18 <li><a name="TOC3" href="#SEC3">PARTIAL MATCHING USING pcre2_dfa_match()</a>
  19 <li><a name="TOC4" href="#SEC4">PARTIAL MATCHING AND WORD BOUNDARIES</a>
  20 <li><a name="TOC5" href="#SEC5">EXAMPLE OF PARTIAL MATCHING USING PCRE2TEST</a>
  21 <li><a name="TOC6" href="#SEC6">MULTI-SEGMENT MATCHING WITH pcre2_dfa_match()</a>
  22 <li><a name="TOC7" href="#SEC7">MULTI-SEGMENT MATCHING WITH pcre2_match()</a>
  23 <li><a name="TOC8" href="#SEC8">ISSUES WITH MULTI-SEGMENT MATCHING</a>
  24 <li><a name="TOC9" href="#SEC9">AUTHOR</a>
  25 <li><a name="TOC10" href="#SEC10">REVISION</a>
  26 </ul>
  27 <br><a name="SEC1" href="#TOC1">PARTIAL MATCHING IN PCRE2</a><br>
  28 <P>
  29 In normal use of PCRE2, if the subject string that is passed to a matching
  30 function matches as far as it goes, but is too short to match the entire
  31 pattern, PCRE2_ERROR_NOMATCH is returned. There are circumstances where it
  32 might be helpful to distinguish this case from other cases in which there is no
  33 match.
  34 </P>
  35 <P>
  36 Consider, for example, an application where a human is required to type in data
  37 for a field with specific formatting requirements. An example might be a date
  38 in the form <i>ddmmmyy</i>, defined by this pattern:
  39 <pre>
  40   ^\d?\d(jan|feb|mar|apr|may|jun|jul|aug|sep|oct|nov|dec)\d\d$
  41 </pre>
  42 If the application sees the user's keystrokes one by one, and can check that
  43 what has been typed so far is potentially valid, it is able to raise an error
  44 as soon as a mistake is made, by beeping and not reflecting the character that
  45 has been typed, for example. This immediate feedback is likely to be a better
  46 user interface than a check that is delayed until the entire string has been
  47 entered. Partial matching can also be useful when the subject string is very
  48 long and is not all available at once.
  49 </P>
  50 <P>
  51 PCRE2 supports partial matching by means of the PCRE2_PARTIAL_SOFT and
  52 PCRE2_PARTIAL_HARD options, which can be set when calling a matching function.
  53 The difference between the two options is whether or not a partial match is
  54 preferred to an alternative complete match, though the details differ between
  55 the two types of matching function. If both options are set, PCRE2_PARTIAL_HARD
  56 takes precedence.
  57 </P>
  58 <P>
  59 If you want to use partial matching with just-in-time optimized code, you must
  60 call <b>pcre2_jit_compile()</b> with one or both of these options:
  61 <pre>
  62   PCRE2_JIT_PARTIAL_SOFT
  63   PCRE2_JIT_PARTIAL_HARD
  64 </pre>
  65 PCRE2_JIT_COMPLETE should also be set if you are going to run non-partial
  66 matches on the same pattern. If the appropriate JIT mode has not been compiled,
  67 interpretive matching code is used.
  68 </P>
  69 <P>
  70 Setting a partial matching option disables two of PCRE2's standard
  71 optimizations. PCRE2 remembers the last literal code unit in a pattern, and
  72 abandons matching immediately if it is not present in the subject string. This
  73 optimization cannot be used for a subject string that might match only
  74 partially. PCRE2 also knows the minimum length of a matching string, and does
  75 not bother to run the matching function on shorter strings. This optimization
  76 is also disabled for partial matching.
  77 </P>
  78 <br><a name="SEC2" href="#TOC1">PARTIAL MATCHING USING pcre2_match()</a><br>
  79 <P>
  80 A partial match occurs during a call to <b>pcre2_match()</b> when the end of the
  81 subject string is reached successfully, but matching cannot continue because
  82 more characters are needed. However, at least one character in the subject must
  83 have been inspected. This character need not form part of the final matched
  84 string; lookbehind assertions and the \K escape sequence provide ways of
  85 inspecting characters before the start of a matched string. The requirement for
  86 inspecting at least one character exists because an empty string can always be
  87 matched; without such a restriction there would always be a partial match of an
  88 empty string at the end of the subject.
  89 </P>
  90 <P>
  91 When a partial match is returned, the first two elements in the ovector point
  92 to the portion of the subject that was matched, but the values in the rest of
  93 the ovector are undefined. The appearance of \K in the pattern has no effect
  94 for a partial match. Consider this pattern:
  95 <pre>
  96   /abc\K123/
  97 </pre>
  98 If it is matched against "456abc123xyz" the result is a complete match, and the
  99 ovector defines the matched string as "123", because \K resets the "start of
 100 match" point. However, if a partial match is requested and the subject string
 101 is "456abc12", a partial match is found for the string "abc12", because all
 102 these characters are needed for a subsequent re-match with additional
 103 characters.
 104 </P>
 105 <P>
 106 What happens when a partial match is identified depends on which of the two
 107 partial matching options are set.
 108 </P>
 109 <br><b>
 110 PCRE2_PARTIAL_SOFT WITH pcre2_match()
 111 </b><br>
 112 <P>
 113 If PCRE2_PARTIAL_SOFT is set when <b>pcre2_match()</b> identifies a partial
 114 match, the partial match is remembered, but matching continues as normal, and
 115 other alternatives in the pattern are tried. If no complete match can be found,
 116 PCRE2_ERROR_PARTIAL is returned instead of PCRE2_ERROR_NOMATCH.
 117 </P>
 118 <P>
 119 This option is "soft" because it prefers a complete match over a partial match.
 120 All the various matching items in a pattern behave as if the subject string is
 121 potentially complete. For example, \z, \Z, and $ match at the end of the
 122 subject, as normal, and for \b and \B the end of the subject is treated as a
 123 non-alphanumeric.
 124 </P>
 125 <P>
 126 If there is more than one partial match, the first one that was found provides
 127 the data that is returned. Consider this pattern:
 128 <pre>
 129   /123\w+X|dogY/
 130 </pre>
 131 If this is matched against the subject string "abc123dog", both
 132 alternatives fail to match, but the end of the subject is reached during
 133 matching, so PCRE2_ERROR_PARTIAL is returned. The offsets are set to 3 and 9,
 134 identifying "123dog" as the first partial match that was found. (In this
 135 example, there are two partial matches, because "dog" on its own partially
 136 matches the second alternative.)
 137 </P>
 138 <br><b>
 139 PCRE2_PARTIAL_HARD WITH pcre2_match()
 140 </b><br>
 141 <P>
 142 If PCRE2_PARTIAL_HARD is set for <b>pcre2_match()</b>, PCRE2_ERROR_PARTIAL is
 143 returned as soon as a partial match is found, without continuing to search for
 144 possible complete matches. This option is "hard" because it prefers an earlier
 145 partial match over a later complete match. For this reason, the assumption is
 146 made that the end of the supplied subject string may not be the true end of the
 147 available data, and so, if \z, \Z, \b, \B, or $ are encountered at the end
 148 of the subject, the result is PCRE2_ERROR_PARTIAL, provided that at least one
 149 character in the subject has been inspected.
 150 </P>
 151 <br><b>
 152 Comparing hard and soft partial matching
 153 </b><br>
 154 <P>
 155 The difference between the two partial matching options can be illustrated by a
 156 pattern such as:
 157 <pre>
 158   /dog(sbody)?/
 159 </pre>
 160 This matches either "dog" or "dogsbody", greedily (that is, it prefers the
 161 longer string if possible). If it is matched against the string "dog" with
 162 PCRE2_PARTIAL_SOFT, it yields a complete match for "dog". However, if
 163 PCRE2_PARTIAL_HARD is set, the result is PCRE2_ERROR_PARTIAL. On the other
 164 hand, if the pattern is made ungreedy the result is different:
 165 <pre>
 166   /dog(sbody)??/
 167 </pre>
 168 In this case the result is always a complete match because that is found first,
 169 and matching never continues after finding a complete match. It might be easier
 170 to follow this explanation by thinking of the two patterns like this:
 171 <pre>
 172   /dog(sbody)?/    is the same as  /dogsbody|dog/
 173   /dog(sbody)??/   is the same as  /dog|dogsbody/
 174 </pre>
 175 The second pattern will never match "dogsbody", because it will always find the
 176 shorter match first.
 177 </P>
 178 <br><a name="SEC3" href="#TOC1">PARTIAL MATCHING USING pcre2_dfa_match()</a><br>
 179 <P>
 180 The DFA functions move along the subject string character by character, without
 181 backtracking, searching for all possible matches simultaneously. If the end of
 182 the subject is reached before the end of the pattern, there is the possibility
 183 of a partial match, again provided that at least one character has been
 184 inspected.
 185 </P>
 186 <P>
 187 When PCRE2_PARTIAL_SOFT is set, PCRE2_ERROR_PARTIAL is returned only if there
 188 have been no complete matches. Otherwise, the complete matches are returned.
 189 However, if PCRE2_PARTIAL_HARD is set, a partial match takes precedence over
 190 any complete matches. The portion of the string that was matched when the
 191 longest partial match was found is set as the first matching string.
 192 </P>
 193 <P>
 194 Because the DFA functions always search for all possible matches, and there is
 195 no difference between greedy and ungreedy repetition, their behaviour is
 196 different from the standard functions when PCRE2_PARTIAL_HARD is set. Consider
 197 the string "dog" matched against the ungreedy pattern shown above:
 198 <pre>
 199   /dog(sbody)??/
 200 </pre>
 201 Whereas the standard function stops as soon as it finds the complete match for
 202 "dog", the DFA function also finds the partial match for "dogsbody", and so
 203 returns that when PCRE2_PARTIAL_HARD is set.
 204 </P>
 205 <br><a name="SEC4" href="#TOC1">PARTIAL MATCHING AND WORD BOUNDARIES</a><br>
 206 <P>
 207 If a pattern ends with one of sequences \b or \B, which test for word
 208 boundaries, partial matching with PCRE2_PARTIAL_SOFT can give counter-intuitive
 209 results. Consider this pattern:
 210 <pre>
 211   /\bcat\b/
 212 </pre>
 213 This matches "cat", provided there is a word boundary at either end. If the
 214 subject string is "the cat", the comparison of the final "t" with a following
 215 character cannot take place, so a partial match is found. However, normal
 216 matching carries on, and \b matches at the end of the subject when the last
 217 character is a letter, so a complete match is found. The result, therefore, is
 218 <i>not</i> PCRE2_ERROR_PARTIAL. Using PCRE2_PARTIAL_HARD in this case does yield
 219 PCRE2_ERROR_PARTIAL, because then the partial match takes precedence.
 220 </P>
 221 <br><a name="SEC5" href="#TOC1">EXAMPLE OF PARTIAL MATCHING USING PCRE2TEST</a><br>
 222 <P>
 223 If the <b>partial_soft</b> (or <b>ps</b>) modifier is present on a
 224 <b>pcre2test</b> data line, the PCRE2_PARTIAL_SOFT option is used for the match.
 225 Here is a run of <b>pcre2test</b> that uses the date example quoted above:
 226 <pre>
 227     re&#62; /^\d?\d(jan|feb|mar|apr|may|jun|jul|aug|sep|oct|nov|dec)\d\d$/
 228   data&#62; 25jun04\=ps
 229    0: 25jun04
 230    1: jun
 231   data&#62; 25dec3\=ps
 232   Partial match: 23dec3
 233   data&#62; 3ju\=ps
 234   Partial match: 3ju
 235   data&#62; 3juj\=ps
 236   No match
 237   data&#62; j\=ps
 238   No match
 239 </pre>
 240 The first data string is matched completely, so <b>pcre2test</b> shows the
 241 matched substrings. The remaining four strings do not match the complete
 242 pattern, but the first two are partial matches. Similar output is obtained
 243 if DFA matching is used.
 244 </P>
 245 <P>
 246 If the <b>partial_hard</b> (or <b>ph</b>) modifier is present on a
 247 <b>pcre2test</b> data line, the PCRE2_PARTIAL_HARD option is set for the match.
 248 </P>
 249 <br><a name="SEC6" href="#TOC1">MULTI-SEGMENT MATCHING WITH pcre2_dfa_match()</a><br>
 250 <P>
 251 When a partial match has been found using a DFA matching function, it is
 252 possible to continue the match by providing additional subject data and calling
 253 the function again with the same compiled regular expression, this time setting
 254 the PCRE2_DFA_RESTART option. You must pass the same working space as before,
 255 because this is where details of the previous partial match are stored. Here is
 256 an example using <b>pcre2test</b>:
 257 <pre>
 258     re&#62; /^\d?\d(jan|feb|mar|apr|may|jun|jul|aug|sep|oct|nov|dec)\d\d$/
 259   data&#62; 23ja\=dfa,ps
 260   Partial match: 23ja
 261   data&#62; n05\=dfa,dfa_restart
 262    0: n05
 263 </pre>
 264 The first call has "23ja" as the subject, and requests partial matching; the
 265 second call has "n05" as the subject for the continued (restarted) match.
 266 Notice that when the match is complete, only the last part is shown; PCRE2 does
 267 not retain the previously partially-matched string. It is up to the calling
 268 program to do that if it needs to.
 269 </P>
 270 <P>
 271 That means that, for an unanchored pattern, if a continued match fails, it is
 272 not possible to try again at a new starting point. All this facility is capable
 273 of doing is continuing with the previous match attempt. In the previous
 274 example, if the second set of data is "ug23" the result is no match, even
 275 though there would be a match for "aug23" if the entire string were given at
 276 once. Depending on the application, this may or may not be what you want.
 277 The only way to allow for starting again at the next character is to retain the
 278 matched part of the subject and try a new complete match.
 279 </P>
 280 <P>
 281 You can set the PCRE2_PARTIAL_SOFT or PCRE2_PARTIAL_HARD options with
 282 PCRE2_DFA_RESTART to continue partial matching over multiple segments. This
 283 facility can be used to pass very long subject strings to the DFA matching
 284 functions.
 285 </P>
 286 <br><a name="SEC7" href="#TOC1">MULTI-SEGMENT MATCHING WITH pcre2_match()</a><br>
 287 <P>
 288 Unlike the DFA function, it is not possible to restart the previous match with
 289 a new segment of data when using <b>pcre2_match()</b>. Instead, new data must be
 290 added to the previous subject string, and the entire match re-run, starting
 291 from the point where the partial match occurred. Earlier data can be discarded.
 292 </P>
 293 <P>
 294 It is best to use PCRE2_PARTIAL_HARD in this situation, because it does not
 295 treat the end of a segment as the end of the subject when matching \z, \Z,
 296 \b, \B, and $. Consider an unanchored pattern that matches dates:
 297 <pre>
 298     re&#62; /\d?\d(jan|feb|mar|apr|may|jun|jul|aug|sep|oct|nov|dec)\d\d/
 299   data&#62; The date is 23ja\=ph
 300   Partial match: 23ja
 301 </pre>
 302 At this stage, an application could discard the text preceding "23ja", add on
 303 text from the next segment, and call the matching function again. Unlike the
 304 DFA matching function, the entire matching string must always be available,
 305 and the complete matching process occurs for each call, so more memory and more
 306 processing time is needed.
 307 </P>
 308 <br><a name="SEC8" href="#TOC1">ISSUES WITH MULTI-SEGMENT MATCHING</a><br>
 309 <P>
 310 Certain types of pattern may give problems with multi-segment matching,
 311 whichever matching function is used.
 312 </P>
 313 <P>
 314 1. If the pattern contains a test for the beginning of a line, you need to pass
 315 the PCRE2_NOTBOL option when the subject string for any call does start at the
 316 beginning of a line. There is also a PCRE2_NOTEOL option, but in practice when
 317 doing multi-segment matching you should be using PCRE2_PARTIAL_HARD, which
 318 includes the effect of PCRE2_NOTEOL.
 319 </P>
 320 <P>
 321 2. If a pattern contains a lookbehind assertion, characters that precede the
 322 start of the partial match may have been inspected during the matching process.
 323 When using <b>pcre2_match()</b>, sufficient characters must be retained for the
 324 next match attempt. You can ensure that enough characters are retained by doing
 325 the following:
 326 </P>
 327 <P>
 328 Before doing any matching, find the length of the longest lookbehind in the
 329 pattern by calling <b>pcre2_pattern_info()</b> with the PCRE2_INFO_MAXLOOKBEHIND
 330 option. Note that the resulting count is in characters, not code units. After a
 331 partial match, moving back from the ovector[0] offset in the subject by the
 332 number of characters given for the maximum lookbehind gets you to the earliest
 333 character that must be retained. In a non-UTF or a 32-bit situation, moving
 334 back is just a subtraction, but in UTF-8 or UTF-16 you have to count characters
 335 while moving back through the code units.
 336 </P>
 337 <P>
 338 Characters before the point you have now reached can be discarded, and after
 339 the next segment has been added to what is retained, you should run the next
 340 match with the <b>startoffset</b> argument set so that the match begins at the
 341 same point as before.
 342 </P>
 343 <P>
 344 For example, if the pattern "(?&#60;=123)abc" is partially matched against the
 345 string "xx123ab", the ovector offsets are 5 and 7 ("ab"). The maximum
 346 lookbehind count is 3, so all characters before offset 2 can be discarded. The
 347 value of <b>startoffset</b> for the next match should be 3. When <b>pcre2test</b>
 348 displays a partial match, it indicates the lookbehind characters with '&#60;'
 349 characters:
 350 <pre>
 351     re&#62; "(?&#60;=123)abc"
 352   data&#62; xx123ab\=ph
 353   Partial match: 123ab
 354                  &#60;&#60;&#60;
 355 </PRE>
 356 </P>
 357 <P>
 358 3. Because a partial match must always contain at least one character, what
 359 might be considered a partial match of an empty string actually gives a "no
 360 match" result. For example:
 361 <pre>
 362     re&#62; /c(?&#60;=abc)x/
 363   data&#62; ab\=ps
 364   No match
 365 </pre>
 366 If the next segment begins "cx", a match should be found, but this will only
 367 happen if characters from the previous segment are retained. For this reason, a
 368 "no match" result should be interpreted as "partial match of an empty string"
 369 when the pattern contains lookbehinds.
 370 </P>
 371 <P>
 372 4. Matching a subject string that is split into multiple segments may not
 373 always produce exactly the same result as matching over one single long string,
 374 especially when PCRE2_PARTIAL_SOFT is used. The section "Partial Matching and
 375 Word Boundaries" above describes an issue that arises if the pattern ends with
 376 \b or \B. Another kind of difference may occur when there are multiple
 377 matching possibilities, because (for PCRE2_PARTIAL_SOFT) a partial match result
 378 is given only when there are no completed matches. This means that as soon as
 379 the shortest match has been found, continuation to a new subject segment is no
 380 longer possible. Consider this <b>pcre2test</b> example:
 381 <pre>
 382     re&#62; /dog(sbody)?/
 383   data&#62; dogsb\=ps
 384    0: dog
 385   data&#62; do\=ps,dfa
 386   Partial match: do
 387   data&#62; gsb\=ps,dfa,dfa_restart
 388    0: g
 389   data&#62; dogsbody\=dfa
 390    0: dogsbody
 391    1: dog
 392 </pre>
 393 The first data line passes the string "dogsb" to a standard matching function,
 394 setting the PCRE2_PARTIAL_SOFT option. Although the string is a partial match
 395 for "dogsbody", the result is not PCRE2_ERROR_PARTIAL, because the shorter
 396 string "dog" is a complete match. Similarly, when the subject is presented to
 397 a DFA matching function in several parts ("do" and "gsb" being the first two)
 398 the match stops when "dog" has been found, and it is not possible to continue.
 399 On the other hand, if "dogsbody" is presented as a single string, a DFA
 400 matching function finds both matches.
 401 </P>
 402 <P>
 403 Because of these problems, it is best to use PCRE2_PARTIAL_HARD when matching
 404 multi-segment data. The example above then behaves differently:
 405 <pre>
 406     re&#62; /dog(sbody)?/
 407   data&#62; dogsb\=ph
 408   Partial match: dogsb
 409   data&#62; do\=ps,dfa
 410   Partial match: do
 411   data&#62; gsb\=ph,dfa,dfa_restart
 412   Partial match: gsb
 413 </pre>
 414 5. Patterns that contain alternatives at the top level which do not all start
 415 with the same pattern item may not work as expected when PCRE2_DFA_RESTART is
 416 used. For example, consider this pattern:
 417 <pre>
 418   1234|3789
 419 </pre>
 420 If the first part of the subject is "ABC123", a partial match of the first
 421 alternative is found at offset 3. There is no partial match for the second
 422 alternative, because such a match does not start at the same point in the
 423 subject string. Attempting to continue with the string "7890" does not yield a
 424 match because only those alternatives that match at one point in the subject
 425 are remembered. The problem arises because the start of the second alternative
 426 matches within the first alternative. There is no problem with anchored
 427 patterns or patterns such as:
 428 <pre>
 429   1234|ABCD
 430 </pre>
 431 where no string can be a partial match for both alternatives. This is not a
 432 problem if a standard matching function is used, because the entire match has
 433 to be rerun each time:
 434 <pre>
 435     re&#62; /1234|3789/
 436   data&#62; ABC123\=ph
 437   Partial match: 123
 438   data&#62; 1237890
 439    0: 3789
 440 </pre>
 441 Of course, instead of using PCRE2_DFA_RESTART, the same technique of re-running
 442 the entire match can also be used with the DFA matching function. Another
 443 possibility is to work with two buffers. If a partial match at offset <i>n</i>
 444 in the first buffer is followed by "no match" when PCRE2_DFA_RESTART is used on
 445 the second buffer, you can then try a new match starting at offset <i>n+1</i> in
 446 the first buffer.
 447 </P>
 448 <br><a name="SEC9" href="#TOC1">AUTHOR</a><br>
 449 <P>
 450 Philip Hazel
 451 <br>
 452 University Computing Service
 453 <br>
 454 Cambridge, England.
 455 <br>
 456 </P>
 457 <br><a name="SEC10" href="#TOC1">REVISION</a><br>
 458 <P>
 459 Last updated: 22 December 2014
 460 <br>
 461 Copyright &copy; 1997-2014 University of Cambridge.
 462 <br>
 463 <p>
 464 Return to the <a href="index.html">PCRE2 index page</a>.
 465 </p>