SRE - adding chars to pattern produces invalid results

[PhoenixXL]

'>(.*?)</a' would not find the smallest match. (.*?) This would find the smallest and its finding it.

In Short

• The RegEx Engine finds the first char ">" at <img width="20" height="22">"
• Thereafter it tries to find the minimal number of characters after which a "</a" is present
• In your case both the greedy and lazy would give the same result because there is only one possibility of finding the full match

This is what Lazy and Greedy Quantifiers do

#include <array.au3>

Local $str = '<img width="20" height="22"> <a src="/icons/text.gif" alt="[TXT]" 2732618_readme.htm href="2790817%202732618_readme.htm"> 2790817 </a><a href = something> Hello </a>'
$aTemp = StringRegExp($str, '>(.*?)</a', 3) ; added /a to pattern
_ArrayDisplay($aTemp) ;Lazy

$aTemp = StringRegExp($str, '>(.*)</a', 3)
_ArrayDisplay($aTemp) ;Greedy

In your case its not working because a "." would match everything other than a "line-feed". Use "[^<>]" in place of "." then it would work

#include <array.au3>

Local $str = '<img width="20" height="22"> <a src="/icons/text.gif" alt="[TXT]" 2732618_readme.htm href="2790817%202732618_readme.htm"> 2790817 </a><a href = something> Hello </a>'
$aTemp = StringRegExp($str, '>([^<>]*?)</a', 3) ; added /a to pattern
_ArrayDisplay($aTemp) ;Lazy

$aTemp = StringRegExp($str, '>([^<>]*)</a', 3)
_ArrayDisplay($aTemp) ;Greedy

If still not clear, I will provide a full decode

Regards

Edited April 6, 2013 by PhoenixXL

[kylomas]

I think I understand where my misconception is.

My understanding:

1 - Find the first ">" and start capturing chars looking for a "</a".

2 - Find another ">", throw the first captured group out (because of "laziness") and start capturing chars again, looking for "</a".

3 - Find "</a" and return all chars from last ">" to "</a".

Apparently step #2 is not correct. Is that right?

[PhoenixXL]

1 - Find the first ">" and start capturing chars looking for a "</a".

2 - Find another ">", throw the first captured group out (because of "laziness") and start capturing chars again, looking for "</a". Right this is misconception.

3 - Return the Captured Chars.

[PhoenixXL]

Regarding Lazy & Greedy

Difference b/w a Lazy(*?)and Greedy(*) quantifier look here

In short

• Greedy : match everything which satisfies the pattern. After match if the next pattern matches, the engine goes on but otherwise the characters matched by the greedy operator is back-traced(given back one by one) till the next pattern is satisfied
• Lazy : match once and check if rest of the pattern satisfies. If yes don't match any more, if no, match one more and check again.

[jchd]

kylomas,

You're correct about step #2 not being PCRE behavior, nor any other RE engine.

You look at greediness considering the whole subject string and say: "look, there is a shorter substring that matches, so it should move the start of match forward.

RE don't do that: as the doc says, greediness applies to the right bound of the string but never moves the left bound to a possible "next match" in order to globally minimize the size of the matched string. Said otherwise, the left bound doesn't move once the pattern has found a match (the >) unless backtracking enters the scene, but backtracking only does IFF no match is possible.

[Melba23]

jchd,

Thanks for that explanation. Like kylomas I was expecting "(?U)>(.*)</a" to pick out the required section - now I know why it does not.

M23

[kylomas]

JCHD, PhoenixXL,

Thanks, going back to re-read the doc in your sig, under the light of these explanations.

kylomas

[Jury]

(sigh) if only pcre would become more international and have something like RegexOptions.RightToLeft as found in the .NET Framework

[jchd]

I don't see how PCRE isn't international. Can you elaborate?

Also how RegexOptions.RightToLeft is helping anything?

[PhoenixXL]

(sigh) if only pcre would become more international and have something like RegexOptions.RightToLeft as found in the .NET Framework

Rather Try _StringReverse Edited April 7, 2013 by PhoenixXL

[jchd]

_StringReverse is badly flawed for processing Unicode in general.

[PhoenixXL]

Would this work in that case,

#include <Array.au3>

Func _StringReverse_($String)
Local $S_Ret
If $String Then
Local $aChars = StringSplit($String, "", 2)
_ArrayReverse($aChars)
$S_Ret = _ArrayToString($aChars, "")
EndIf
Return $S_Ret
EndFunc ;==>_StringReverse_

MsgBox( 0, 0, _StringReverse_("Hello"))

I don't have that good knowledge regarding those DllCalls.

Edited April 7, 2013 by PhoenixXL

[jchd]

To see the top of the problem iceberg, try running that on "Hello, " & @CRLF & "World!"

[guinness]

Would this work in that case

There are more appropriate ways located around the Forum.

[jchd]

In my post explains a bit more.

[PhoenixXL]

What is the problem, is it that the @LF now comes before @CR ?

#include <Array.au3>

Func _StringReverse_($String)
Local $S_Ret
If $String Then
Local $aChars = StringSplit($String, "", 2)
_ArrayReverse($aChars)
$S_Ret = _ArrayToString($aChars, "")
EndIf
Return $S_Ret
EndFunc   ;==>_StringReverse_

MsgBox( 0, 0, _StringReverse_("Hello, " & @CRLF & "World!" ))

[guinness]

I never really thought about that jchd, thanks.

[jchd]

Yes, for instance. The reverted LFCR sequence doesn't match any standard line break sequence. Matching LF will leave CR as a prefix to the remaining part, Matching to CR will leave LF as a suffix to the previous part and matching CRLF won't work.

[PhoenixXL]

Got it. Learnt a new thing today

Thanks

[guinness]

Yes, for instance. The reverted LFCR sequence doesn't match any standard line break sequence. Matching LF will leave CR as a prefix to the remaining part, Matching to CR will leave LF as a suffix to the previous part and matching CRLF won't work.

What would be an appropriate workaround? Replace all instances of LF and CR to RC before reversing?