<?xml version="1.0"?>
<rss version="2.0">
  <channel>
    <title>PHPDeveloper.org</title>
    <link>http://www.phpdeveloper.org</link>
    <description>Up-to-the Minute PHP News, views and community</description>
    <language>en-us</language>
    <pubDate>Wed, 19 Jun 2013 10:34:19 -0500</pubDate>
    <ttl>30</ttl>
    <item>
      <title><![CDATA[Stoimen Popov's Blog: preg_match Give Names to the Matches]]></title>
      <guid>http://www.phpdeveloper.org/news/14750</guid>
      <link>http://www.phpdeveloper.org/news/14750</link>
      <description><![CDATA[<p>
In <a href="http://www.stoimen.com/blog/2010/07/03/php-preg_match-give-names-to-the-matches/">a quick post</a> to hos blog today <i>Stoimen Popov</i> points out a handy feature of the <a href="http://php.net/preg_match">preg_match</a> function in PHP (in PHP 5.2.2 and higher) to be able to name the results of the regular expression match.
</p>
<blockquote>
In PHP 5.2.2+ you can name the sub patterns returned from preg_match  with a specific syntax. [...] This is extremely helpful, when dealing with long patterns. [...] Although it may look difficult to maintain, now you can simply name the sub patterns of preg_match and to call them with their associative array keys. This is more clear when writing code and it's definitely more maintainable.
</blockquote>
<p>
The key is to use a special syntax as a part of the expression's pattern. This replaces the numeric keys of the matches with values you define, making it simpler to use the results (instead of having to work with numbers that don't match much of anything). Code and expression examples are included.
</p>]]></description>
      <pubDate>Tue, 06 Jul 2010 11:01:48 -0500</pubDate>
    </item>
    <item>
      <title><![CDATA[PHP Security Blog: Holes in most preg_match() filters]]></title>
      <guid>http://www.phpdeveloper.org/news/7558</guid>
      <link>http://www.phpdeveloper.org/news/7558</link>
      <description><![CDATA[<p>
On the PHP Security Log today, <i>Stefan Esser</i> points out <a href="http://blog.php-security.org/archives/76-Holes-in-most-preg_match-filters.html">some holes</a> in most of the filters using preg_match that he's seen in examples and the like all around the web. Some of these things could cause issues that could breach the security of your application.
</p>
<blockquote>
<p>
During the last week I was performing some audits and like so often it contained preg_match() filters that were not correct. Most PHP developers use ^ and $ within their regular expressions without actually reading the documentation about what they really achieve.
</p>
<p>
However the problem is, that the author of such a regular expression did not correctly read the documentation and mistakes the $ character for the definitive end of the subject.
</p>
</blockquote>
<p>
According to <i>Stefan</i>, the actual documentation for the $ character in a regular expression isn't quite used that way. It does mean "the end" of the match but it can also match against a newline as well. His suggestions? Use the /D modifier on the end of the expression to match the real "the end" and not how it might match otherwise.
<p>]]></description>
      <pubDate>Wed, 04 Apr 2007 07:15:50 -0500</pubDate>
    </item>
  </channel>
</rss>
