## Greedy vs. Ungreedy

Before I start explaining this concept, I would like to show an example first. Let's say we are looking to find anchor tags in an html text:

The result will be as expected:

Let's change the input and add a second anchor tag:

Again, it seems to be fine so far. But don't let this trick you. The only reason it works is because the anchor tags are on separate lines, and by default PCRE matches patterns only one line at a time (more info on: 'm' modifier). If we encounter two anchor tags on the same line, it will no longer work as expected:

This time the pattern matches the first opening tag, and last opening tag, and everything in between as a single match, instead of making two separate matches. This is due to the default behavior being "greedy".

"When greedy, the quantifiers (such as * or +) match as many character as possible."

If you add a question mark after the quantifier (.*?) it becomes "ungreedy":

Now the result is correct. Another way to trigger the ungreedy behavior is to use the U pattern modifier.

## Lookahead and Lookbehind Assertions

A lookahead assertion searches for a pattern match that follows the current match. This might be explained easier through an example.

The following pattern first matches for 'foo', and then it checks to see if it is followed by 'bar':

It may not seem very useful, as we could have simply checked for 'foobar' instead. However, it is also possible to use lookaheads for making negative assertions. The following example matches 'foo', only if it is NOT followed by 'bar'.

Lookbehind assertions work similarly, but they look for patterns before the current match. You may use (?< for positive assertions, and (?<! for negative assertions.

The following pattern matches if there is a 'bar' and it is not following 'foo'.

## Conditional (If-Then-Else) Patterns

Regular expressions provide the functionality for checking certain conditions. The format is as follows:

The condition can be a number. In which case it refers to a previously captured subpattern.

For example we can use this to check for opening and closing angle brackets:

In the example above, '1' refers to the subpattern (<), which is also optional since it is followed by a question mark. Only if that condition is true, it matches for a closing bracket.

The condition can also be an assertion:

## Filtering Patterns

There are various reasons for input filtering when developing web applications. We filter data before inserting it into a database, or outputting it to the browser. Similarly, it is necessary to filter any arbitrary string before including it in a regular expression. PHP provides a function named preg_quote to do the job.

In the following example we use a string that contains a special character (*).

Same thing can be accomplished also by enclosing the string between \Q and \E. Any special character after \Q is ignored until \E.

However, this second method is not 100% safe, as the string itself can contain \E.

## Non-capturing Subpatterns

Subpatterns, enclosed by parentheses, get captured into an array so that we can use them later if needed. But there is a way to NOT capture them also.

Let's start with a very simple example:

Now let's make a small change by adding another subpattern (H.*) to the front:

The $matches array was changed, which could cause the script to stop working properly, depending on what we do with those variables in the code. Now we have to find every occurence of the$matches array in the code, and adjust the index number accordingly.

If we are not really interested in the contents of the new subpattern we just added, we can make it 'non-capturing' like this:

## Don't Reinvent the Wheel

Perhaps it's most important to know when NOT to use regular expressions. There are many situations where you can find existing utilities than you can use instead.

### Parsing [X]HTML

A poster at Stackoverflow has a brilliant explanation on why we should not use regular expressions to parse [X]HTML.

...dear lord help us how can anyone survive this scourge using regex to parse HTML has doomed humanity to an eternity of dread torture and security holes using regex as a tool to process HTML establishes a breach between this world and the dread realm of corrupt entities...

Joking aside, it is a good idea to take some time and figure out what kind of XML or HTML parsers are available, and how they work. For example, PHP offers multiple extensions related to XML (and HTML).

Example: Getting the second link url in an HTML page

### Validating Form Input

Again, you can use existing functions to validate user inputs, such as form submissions.