if the filename has dots as separators in it the regexp won’t work

It would still work : /^.*\.jpe?g$/i – all I’m doing there is requiring the filename ends with .jpg or .jpeg (case insenstive). otherwise you’re allowed anything you like including . characters.

What’s interesting is str_replace performs better in this case, but only significantly so if the “replace” target is a string—not an array

Great article, and thanks for the bit on eval()—I never knew of its security flaws over and above the obvious injection attacks.

By the way, the link to sprintf() on php.net is incorrect here—it links to http://php.nett/sprintf.

Thanks and thanks – now fixed at last.

By the way, the link to sprintf() on php.net is incorrect here – it links to http://php.nett/sprintf.

Harry, didn’t you mean str_replace?

Well I meant strtr() (the example works) based on the unconfirmed theory that it would offer better performance than str_replace(). But looking at this (see str_replace vs. strtr later on) reminds me it’s best always to question “accepted performance wisdom” with benchmarks.

What’s interesting is str_replace performs better in this case, but only significantly so if the “replace” target is a string – not an array

Fastest:

About the same:

Even more excitement – doing two seperate strtr’s seems to match the performance of the fastest str_replace above;

…but used pretty short $str’s so that may not scale to bigger documents.

Side note: additional confusion is being caused in these examples by the comment feature adding slashes to quotes :(

  
str_replace(array("\r\n", "\r"), array("\n", "\n"), $input)

Is there an easy way to explicitly match linebreaks, no matter whether they’re unix/windows/mac style?

Don’t have a generic solution off-hand so if you’ve got one, feel free to blow my mind ;)

Somehow think it’s probably best to normalize to \n before starting to use regexs, given this is what the . metacharacter “understands” (controlled by the /s pattern modifier).

But if you wanted to split a string into lines, without caring what kind of linebreaks you’re dealing with, this should work;

To normalize up front, using strtr should be pretty efficient;

But to call it evil because it’s “insecure” is inaccurate.

Agreed – it’s just another tool. The “eval() is evil” mantra is much like the “you must normalize your dbs to the nth form” – for starters is saves the need for long discussion and it’s also encouraging certain practices – what’s less often discussed is when you’d want to denormalize your db schemas, often for efficiency, but “denormalize your tables!” or “eval is OK sometimes” is not something you hear.

Think the particular danger here is the /e modifier helps you write a neat one-liner while preg_replace_callback is less “elegant” (relative term) – that might catch out people who’d no better otherwise.

I believe more accurately, the moment you hear eval() the words “poor programmers” should be on the tip of your tongue. While I believe in this case, and really any case where smarter alternative exist, the use of eval() should be avoided (more for performance reasons than security reasons imho), it’s become tiresome to constantly hear about the “evils of eval”. Using that logic, mysql_query() is nearly as evil as eval() because it allows malicious code to be inserted into a script.

In general, are there better choices than eval() for a given situation? Yes. Is eval() often a lazy way out? Yes. Does it have poor performance? Yes. But to call it evil because it’s “insecure” is inaccurate. In the wrong person’s hands most anything can be considered “evil” because using unsanitized input opens the door wide open for any number of attacks. Avoiding the use of eval() is generally good practice on a number of levels, but a competent developer should have no fears of using it because they should already be assured of the security of their user input.