Extract a long group of strings

[christo16]

This should be pretty easy, I tried some things I saw on this forum but I just couldn't get it to work, I gotta get better with regex.

Here is the data I am trying to extract from:

 

HTTP/1.1 200 OK

Content-Length: 408

Accept-Ranges: bytes

Vary: accept-encoding

Server: Twisted/2.5.0 TwistedWeb/[twisted.web2, version 0.2.0] TwistedCalDAV/2.0 (unknown)

Last-Modified: Sun, 22 Jun 2008 06:40:29 GMT

DAV: 1, access-control, calendar-access, calendar-schedule, calendar-availability, inbox-availability, calendar-proxy, calendarserver-private-events

ETag: "3DA7C8-BB0-485DDDD"

Date: Sun, 22 Jun 2008 06:47:32 GMT

Content-Type: text/calendar;charset=utf-8

Connection: close

 

BEGIN:VCALENDAR

VERSION:2.0

PRODID:-//CALENDARSERVER.ORG//NONSGML Version 1//EN

BEGIN:VFREEBUSY

UID:da987db656f77a5c73c73857ecbbfd60

DTSTART:20080620T070000Z

DTEND:20080621T070000Z

DTSTAMP:20080622T064732Z

FREEBUSY;FBTYPE=BUSY:20080620T163000Z/20080620T173000Z,20080620T191500Z/20

080620T201500Z,20080620T213000Z/20080620T220000Z,20080620T233000Z/20080621

T000000Z

END:VFREEBUSY

END:VCALENDAR

 

The only data that I want is the "FREEBUSY;FBTYPE=BUSY:20080620T163000Z/20080620T173000Z,20080620T191500Z/20

080620T201500Z,20080620T213000Z/20080620T220000Z,20080620T233000Z/20080621

T000000Z".

 

Thank you for any help!

[Orio]

This should do.

 

<?php

$data = "...";

preg_match("/(FREEBUSY;.*?)END:/is", $data, $match);
echo $match[1];

?>

 

Orio.

[dsaba]

/(FREEBUSY;.+?)END:/is

[effigy]

/FREEBUSY;.+?(?=END:)/is

[dsaba]

Because its a lookahead, you won't sacrifice speed right? If it were a lookbehind, it would be faster to use subgroups right?

[effigy]

Because its a lookahead, you won't sacrifice speed right?

 

I don't think it matters in this context; the engine is going to putter along any way since .+? is lazy. However, since the lookahead prevents "END:" from being matched, it allows us to remove the set of capturing parentheses.

 

If it were a lookbehind, it would be faster to use subgroups right?

 

I don't follow you. Do you have an example?

[dsaba]

I don't think it matters in this context; the engine is going to putter along any way since .+? is lazy. However, since the lookahead prevents "END:" from being matched, it allows us to remove the set of capturing parentheses.

 

Yes I noticed you removed the subgroup and replaced it with a lookahead to remove the need of the subgroup. I was probing whether the removal of subgroups for a lookahead would be faster or slower in a fixed situation (don't have one at the moment..)

 

If it were a lookbehind, it would be faster to use subgroups right?

 

I don't follow you. Do you have an example?

No, but you're welcome to make one. I read somewhere or got the idea that when the regex engine has to 'backtrack' or look behind in some sense it will sacrifice speed. That's why I was making distinction with speed and lookbehind vs. lookahead.

[effigy]

From Mastering Regular Expressions:

 

...if the regex engine doesn't need to keep track of the text matched for capturing purposes, it can work faster and use less memory.

 

As a subexpression within one of the lookaround constructs is being tested, it's as if it's in its own little world. It saves states as needed, and backtracks as necessary. .... What about when the subexpression within the lookaround can't match? Since it's being applied in its "own little world," only states created within the current lookaround construct are available. That is, if the regex finds that it needs to backtrack further, beyond where the lookaround construct started, it's found that the current subexpression cannot match. For positive lookahead, this means failure, while for negative lookahead, it means success. In either case, there are no saved states left over (had there been, the subexpression match would not have finished), so there's no "little world" left to throw away.

 

---

 

I read somewhere or got the idea that when the regex engine has to 'backtrack' or look behind in some sense it will sacrifice speed. That's why I was making distinction with speed and lookbehind vs. lookahead.

 

Backtracking is not the same as a lookbehind. Backtracking is moving backwards in order to attempt a match, while a lookbehind is an assertion of "does this precede this position?" Backtracking can occur within lookaheads, which is covered above.