SRE: how to find '12' and '23' from $sString = '123'

[guinness]

Interesting

[jguinch]

kylomas's regexp seemed to be so obvious... Excellent !

[jchd]

Looks like kylomas spoiled the game.

[guinness]

Well earlier I tried on regexp101 (?=d)(d{2}), so close.

[mikell]

kylomas,

Very very nice 

[kylomas]

kylomas,

Very very nice 

 

Thank you...glad jchd was at dinner...

[mikell]

Don't be so humble, it's very nicely found

I will carefully store this one for later uses/ adaptations 

Edit

Strangely this one works too ...

local $aRET = stringregexp($sSourceString,'(?<=(\d{' & $cnt & '}))', 3)

Edited September 10, 2014 by mikell

[jchd]

Yes one can achieve "strange" things with assertions. Of course look-ahead is nicer than look-behind because the former allows unbounded lengths, but K can also enter into play.

We don't enjoy callbacks, nor hard or soft partial matches since we don't have access to the internal structures resulting from the match engine, but still what we have right now goes a long way to cover a range of unsuspected uses.

[mLipok]

Don't be so humble, it's very nicely found

I will carefully store this one for later uses/ adaptations 

You have right.

 

How you think: Why do I need it ?

 

---

 

1.

I extracts the PDF file from MS SQL Blob,

2.

I extract (using Debenu) text from PDF

3.

I search in the text for 11 digits

4.

I check the checksum.

5.

comparing text in the correct data from the database.

 

wondering what is the text?

PIN (personal ID - please do not be confused with the payment card)

 

 

I missed that point #3

Now the script is ready.

EDIT:

Summary: I assigns, PDF documents to the correct location in the database based on these 11 digits.

Edited September 10, 2014 by mLipok

[jchd]

I must add that I feel very happy to see more and more power users producing non-trivial regexps regularly. While boilling down everything to regexp is obviously wrong, there is still plenty of legitimate, elegant and efficient uses waiting for them.

[mikell]

 we don't have access to the internal structures resulting from the match engine ...

 

So sad... I still can't understand how kylomas' find works 

A long time to come reading the original documentation 

[jchd]

Easy explanation: use http://regex101.com/ paste the regexp (?=(d{5})) option g (same as our flag 3), subject ab1234567890cd and hit "regexp debugger" to see the engine working just in front of you.

By using such a look-ahead the engine walks until what follows is 5 digits. Since there are capturing parenthesis around d{5} they are captured, yet the matching point in NOT bumped at this point. After the match is recorded, the engine continues from there, well not exactly: it has to skip to the next point in subject for the next match attempt (or else it would enter an endless loop).

The following matches in debugger show how things works as well.

[mLipok]

Easy explanation: use http://regex101.com/ paste the regexp (?=(d{5})) option g (same as our flag 3), subject ab1234567890cd and hit "regexp debugger" to see the engine working just in front of you.

 

very nice debugger

[jchd]

Despite it offers options not available to flat PCRE it is AFAIK completely compatible with our implementation. Option u is the same as prepending (*UCP) at the head of our patterns. Option A has no equivalent unless I've missed it.

[guinness]

I would have read that expression as check if 5 digits are preceding and then capture, the same as just d{5}. I never would have dreamt that the matching point would increase by only one and not 5. I am with mikell on this one, I have to read the documentation a little closer.

[jchd]

It's a side-effect of look-ahead assertions not being capturing groups themselves. While scanning for 5 digits ahead, it just happens that we capture them. Yet the matching point is still the point where the look-ahead was. After matching (and capturing under the cover), the matching point simply increases by 1, just like it does when a match doesn't occur.

Within a look-ahead assertion we can do a lot of things: other assertions, subroutines and subroutines calls, recursion, whatever. Look-behind can do the same provided top-level alternatives have the same fixed length, which means that we can also capture "after the fact", i.e. capture from characters before the matching point. But of course that is of little use since that can be rewritten as nested look-aheads.

Watching the regexp debugger at works neatly shows that "thieve capture" while matching point doesn't move.

Edited September 11, 2014 by jchd

[guinness]

Very sneaking and something I will not forget.

[mikell]

jc,
Yes, shame on me, I knew but forgot this essential feature : lookaround assertions are able to match a position in the string (like anchors do)
And when no string/char is specified, then when searching a lookaround will check any "between-chars" position increasing by 1

Msgbox(0,"", StringRegExpReplace("abcd", '(?<=\w)(?=\w)', "#") )

[mLipok]

On 9/10/2014 at 10:40 PM, kylomas said:

Ha, I got it...

#include <array.au3>

Local $sSourceString = 'ab1234567890cd'
local $cnt = 4

local $aRET = stringregexp($sSourceString,'(?=(\d{' & $cnt & '}))',3)
ConsoleWrite($aRET & @CRLF)
_arraydisplay($aRET)

uff finally found this one
Again thanks @kylomas

here is my current variation:

#include <array.au3>

Local $sSourceString = '01234567890123456789'
local $aRET1 = stringregexp($sSourceString,'(?=(\d{9}))',3)
local $aRET2 = stringregexp($sSourceString,'(?=(\d{14}))',3)
_ArrayConcatenate($aRET1, $aRET2)
_arraydisplay($aRET1)

and results:

Quote

012345678
123456789
234567890
345678901
456789012
567890123
678901234
789012345
890123456
901234567
012345678
123456789
01234567890123
12345678901234
23456789012345
34567890123456
45678901234567
56789012345678
67890123456789