Not really. There are two things at work here:

1.) the internet email addressing standard
2.) the use of regular expressions to implement the standard.

Second first. regex’s (as fondly known) are complex and arcane even for simple things. Basically they are a tiny programming language, but one that lacks of lot of basic facilities – loops and selection – that otherwise have to be simulated.

In short, if you have anything more than moderately complex, regex’s are not the most understandable implementation and should be avoided unless you really, really need the performance.

As to the internet email addressing standard. Sendmail – which is the mail server that pretty much established the standard – was developed at a time when there was a great deal of uncertainty about which way the addressing standard would evolve. At the time X.400 (an OSI standard) was all the rage, but it is just about backwards from what we know and love today (but you can see remnants of it in Active Directory/LDAP) and was in competition with the looser standards that evolved in small Unix environments.

As a result, Sendmail is extremely flexible and tolerant of how email addresses are formed and can be configured to handle just about anything.

The result was that a formulation of the email address standard ended up incorporating a lot of unnecessary complexity largely facilitated by the Sendmail implementation that attempted (and unfortunately succeeded) to allow any arbitrary format you wanted.

So short answer:

complex problem + impoverished implementation “language” = WTF is that???

Hence the long regex Jacques has posted.

But …. meh. What’s done is done.

which is subtle and complex

What ever happened to the KISS principle? It’s been a little while since I’ve used regular expressions, but aren’t all those \r \n and \t place holders for carriage returns, new lines and horizontal tabs. The complexity is insane.

The fact that

this regular expression was generated programmatically

suggests that the system has been over-engineered.

http://www.regular-expressions.info/email.html

Another trade-off is that my regex only allows English letters, digits and a few special symbols. The main reason is that I don’t trust all my email software to be able to handle much else. Even though John.O’Hara@theoharas.com is a syntactically valid email address, there’s a risk that some software will misinterpret the apostrophe as a delimiting quote. E.g. blindly inserting this email address into a SQL will cause it to fail if strings are delimited with single quotes. And of course, it’s been many years already that domain names can include non-English characters. Most software and even domain name registrars, however, still stick to the 37 characters they’re used to.

He has a point though, does Mail::RFC822::Address handle the full UTF-8 DNS options? Should we test Chinese email addresses inside a Chinese domain? Full language support does substantially increase the complexity of the software. Only my opinion but ASCII was one of the main reason English-speaking nations got a huge headstart in computing education over the Asian nations (and personally, I’m glad to keep that edge as long as possible).

That’s another example. The Wordpress project have consistently refused to either use an existing PHP DBI-alike (there are several) and to roll their own. It’s following the lifecycle I outlined.

Naturally every plugin is quite used to having total access to any and all database tables and can insert its data any old way it likes.

There are of course, well known workarounds for preventing SQL insertion. Perl’s DBI/DBD system knows how to do it properly. I think it’s probably a fair comment to say the overall Perl has much better designed libraries than PHP. Perl is also quite fast for WWW processing but only if you embed it into your webserver (e.g. use Apache’s modperl).