Last night, on my way to the gym, I was rolling some regular expressions around in my head when suddenly it occurred to me that I have no idea what actually gets captured by a group that is repeated within a single pattern. Let me explain; assume we wanted to match a query string - not just a name-value pair, but the whole string of name-value pairs. To do so, we might use a pattern like this:
Here we are matching three groups. The first group is the entire match. The second group is the name-value pair followed by an optional amphersand. The third group is the actual name-value pair. Of course, when I say "actual" name-value pair, I am not 100% what that means. See, if we have a string of name-value pairs that get matched by the single pattern, what actually shows up in that name-value matched group?
I did a little testing:
- <!--- Define target string. --->
- <cfset strQuery = "ben=nice&maria+bello=sexy!&lori+petty=cool" />
- <!--- Create pattern object. --->
- <cfset objPattern = CreateObject(
- ) />
- Compile regular expression pattern. In this case
- our pattern consists of one or more name-value pairs
- separated by the & symbol.
- <cfset objPattern = objPattern.Compile(
- ) />
- <!--- Get matcher for target string with the given pattern. --->
- <cfset objMatcher = objPattern.Matcher(
- ) />
- <!--- Keep looping over matches. --->
- <cfloop condition="objMatcher.Find()">
- 1) #objMatcher.Group( JavaCast( "int", 1 ) )#<br />
- 2) #objMatcher.Group( JavaCast( "int", 2 ) )#<br />
- 3) #objMatcher.Group( JavaCast( "int", 3 ) )#<br />
- <br />
Here we create a string of three name-value pairs. We then use the pattern above, which will match the entire string, and loop over the matcher for that pattern (which will loop once since our pattern matches the entire string). Running the above code, we get the following output:
Interesting. It looks like the repeated group just captures the last possible group matched as part of the sub-expression. That makes sense, I guess; it's not like it could return an array of matched groups. Not even an issue, since you would never need to access this information. And, if you did, you could just match on individual name-value pairs rather than the entire string.
Ben, I like the regex example but more importantly I like the way you used Java to do it. Thanks for posting this.
No problem. The regular expression itself does not require Java; however, being able to access the matched groups is only available via the Java Pattern / Matcher as far as I know.
"Last night, on my way to the gym, I was rolling some regular expressions around in my head"
I don't now about you, but on the way to yoga class the only thing I thinking about is: "Jesus, I beg of you, please there be a hot chick be front of me tonight."
Ha ha ha :) There's usually a few hot girls at my gym. I like to wait till I get there, pick one out, and then hope she gives me the time of day :)
> being able to access the matched groups is only available via the Java Pattern / Matcher as far as I know
There's the returnsubexpressions option for reFind(). That does what you're suggesting, dunnit? It's not as nice as your approach, that said.
Thanks for the education! I didn't ever know that sub expressions were captured that way. When it comes to REFind(), I've only ever seen the results with one array element.
.NET actually gives you access to all the values captured by repeated groups, as does the just-released Perl 5.10 (when using named capture). I wish this feature were more common.
Is that like what reMatch() does?
REMatch() just returns an array in which each array index contains the entire pattern match (one array index for each complete pattern match in the target string). I don't believe that it deals with individual captured groups.
You can sort of think of it like this:
REMatch() is to the target string what "captured group" is to the matched pattern.
You're dead right, that's exactly what reMatch() does. I misread/mistook "repeated group" for "repeated match".
Cheers for pulling me up on that one... it lead to some interesting reading. Well: as interesting as regexes get, anyways ;-)
Whilst on the subject, I was initially quietly hopeful about the possibilities of reMatch(), expecting it somehow to - as you suggest - capture/extract/return the subexpressions (repeated groups/subexpressions are not something that'd occurred to me one way or the other, to be honest) as well. But unlike reFind(), there is no "returnsubexpressions" switch. This is a significant shortcoming in my view. But it's a start, anyhow.
I agree. A while back, I fooled around with a ColdFusion custom tag that could loop over regular expressions and return sub expressions:
I thought it was pretty bad ass, but got some push back on it. I still like it :)
@Ben: Yet again you saved me a hell of a lot of time with this post! Thanks.
Not sure how it helped, but awesome!
http://www.regular-expressions.info/captureall.html gives a very good explanation of what is going on under the hood while capturing a repeating group.
That is a good explanation. Thanks for pointing that out.