IP & EMail Validation? Sumthin New Every Day.

[TheMadScientist]

I didn't know about this one until I was searching tonight and thought it might be a good one to share... All those stock standard regular expressions I've been using to validate e-mail addresses aren't really necessary?

PHP filter_var() [php.net]

filter_var($string, FILTER_VALIDATE_EMAIL);
filter_var($string, FILTER_VALIDATE_IP);

Not sure if it takes into account valid TLDs or not, and if it evaluates based on Internet Standards rather than 'HotMail doesn't recognize it' standards and you need to make sure an e-mail address is 'HotMail Valid', then you might want to keep using the regular expressions or double check with strpos() or something, but what a convenience it seems like I've been missing out on for times when I simply want to know if some user submitted info evaluates to a validly formatted e-mail address and not something else.

If anyone has any experience or knows of any 'goofy limitations' like there are with some things EG strip_tags() only works on properly formatted HTML and will leave tags unclosed tags in (or something like that), please share, thanks!

[Readie]

You had mention in one of your posts that for() has a lower overhead than foreach() Scientist. Can't remember which one, so I'll post here.

I will have to make note however, that foreach() is faster than it's for() equivilent when dealing with associative arrays. Allow me to demonstrate:

foreach($array as $key => $value) {
echo '<br>' . $key . ' - ' . $value;
}

Is, functionally, identicle to:

$count = count($array);
reset($array);
for($i = 0; $i < $count; $i++) {
$key = key($array);
$value = current($array);
echo '<br>' . $key . ' - ' . $value;
next($array);
}

However, as we discovered above, all the extra functions of alternatives tend to outweigh that which we are trying to avoid using.

In an array of 20 values, I found the for() method above to be on average 30 microseconds slower than the foreach() method.

[Matthew1980]

Hi there Readie,

Thanks for posting this comparison, but (maybe I miss the point?) I cannot understand what is going to be achieved by shaving uS from the operation time/script execution time, when in fact the content displayed on the browser is dependant on the connection speed to your ISP - it's the the speed in which the data is taken from the IP address you are requesting the information from, to it being 'delivered' to your browser.

Also with regards to looping data, I think that there is a time-out limit for the amount of time you can execute a loop for? I could be wrong there though.

Don't get me wrong, I am all for making a script efficient, definitely. I just can't see the point when the difference is only a few uS. Certainly from a clients perspective they would not & do not appreciate the effort that goes into this sort of performance from a program, so far as they are concerned, all they ask is "will this work, and better still, will it make money", and, "make it intuitive to use, you know how joe public are!". I'm sure that if you were to tell them, "I have just upgraded your website code, it will now run half a second quicker", you would be met with a blank stare, or a vacant look! I know I have!

I only tend to use foreach () loops anyway - I try to avaid for () loops wherever possible.

Thanks again for the comparison test though!

Cheers,
MRb

[Readie]

The point is I was interested :)

As I'm also currently working on a project that will determine whether or not I get a pretty decent job, if they know that I'm going into the uSec degrees of peformance while still getting the work done pretty fast to a good standard, it counts in my favour :)

The actual point I was trying to make was this: only use a for() loop to deal with an array when you can reference the array as $array[$i] - otherwise you're shooting yourself in the foot.

Think of the fact that I was only using an array of 20 values. When the array goes into the hundreds and thousands, I should image that the difference is quite a lot more than just a few uSec.

The timeout before a script cancels is controlled in the php.ini file I believe.

[TheMadScientist]

I cannot understand what is going to be achieved by shaving uS from the operation time/script execution time, when in fact the content displayed on the browser is dependant on the connection speed to your ISP - it's the the speed in which the data is taken from the IP address you are requesting the information from, to it being 'delivered' to your browser.

Uh, the faster the script runs the sooner the delivery starts?

It's actually not even relative to the delivery speed, because the delivery speed over a connection will remain relatively constant for any given connection, so if you speed up the running of the script the delivery of the content speeds up by the amount of time you speed the script up.

If it takes .9 seconds to run the script and 2.5 seconds to deliver the content your overall load time is 3.4 seconds. If you speed up the running of the script to .4 seconds your delivery time of the content is still 2.5 seconds for the same content, but the overall load time is only 2.9 seconds.

It's actually more directly and consistently impacting to overall load time than changing the size of a graphic or compressing content or just about anything else you do, because most things are 'connection relative' times, but the 'lag time' before the delivery starts is directly in your control and the longer it takes to begin delivery the longer it takes to load the page irrespective to the actual content on the page.

The actual point I was trying to make was this: only use a for() loop to deal with an array when you can reference the array as $array[$i] - otherwise you're shooting yourself in the foot.

Good point and I do usually try to qualify what I say with an 'unless I have to' and haven't gone back to look, but 'unless I have to' would be in the case of multidimensional arrays and there are other occasions where I've found them to be better than calling additional functions, but what I don't do is default to a foreach() when a for() will do the job.

As far as 'half a second faster' goes, I'm glad there are people who don't care, because it makes my sites look better, and Google ran a test where they intentionally slowed the results down and found slowing the load time down by as little .2 seconds decreased searches, and .4 was IMO a significant decrease in searches which IMO is one of the reasons speed is now a small part of the rankings...

Users exposed to a 200 ms delay since the beginning of the experiment did 0.22% fewer searches during the first three weeks, but 0.36% fewer searches during the second three weeks.

...

Similarly, users exposed to a 400 ms delay since the beginning of the experiment did 0.44% fewer searches during the first three weeks, but 0.76% fewer searches during the second three weeks.

Google Speed Experiment Thread [webmasterworld.com]

Nearly 1 out of every 100 searches were lost when the load time was slowed by .4 seconds... Personally, I'll keep looking for speed not for ranking purposes, but for visitors. I usually only code my own sites and those of a few good, repeat customer's so if others get paid based on the code they write and don't care about those sites losing a few visitors to the competition that may be a bit faster, then obviously it's best for them to keep doing what they do.

[Readie]

Nearly 1 out of every 100 searches were lost when the load time was slowed by .4 seconds

My growing paranoia about load times is not entirely unfounded then :)

[TheMadScientist]

No, Readie, not at all IMO... I've been after speed for years, because whether it's part of rankings or not I know it's been important to me when I visit a site for most of my surfing days, which led me to believe (years ago) speed is important and directly related to visits & use of a site, so I personally try to 'pull out all the stops' when it comes to speed. *

Usually when I get a site done and working I go through everything and optimize for speed... It's something I've been doing for years, and I think it's one of the reasons some of the sites I've built that aren't 'overly fancy' are very sticky and well visited by repeat visitors.

* To the extent it's reasonable anyway, so while I would probably not recode an entire block for .001, I might recode two blocks to pick up .05, because if I do that twice I've gained .1 and 3 or 4 times makes the site 'significantly faster' IMO. It might even go unnoticed 'consciously' by visitors and others, but since even .2 can have an impact (based on the numbers posted by G) it seems the 'unconscious perception' of the site changes in some way.

[Readie]

Right, after just having implemented a rather crude hack on my current project I think I should share this. This won't be a problem 99% of the time, but it took me the better part of 25 minutes to work out why my script wasn't working properly :)

$_POST['something'] = 'Blah';

if(filter_has_var(INPUT_POST, 'something')) {
  echo 'A';
} elseif(isset($_POST['something'])) {
  echo 'B';
} else {
  echo 'C';
}

The above would echo out "B". filter_has_var() only works with $_POST data that actually has come from a form.

[Matthew1980]

Hi there readie,

That makes sense though. I've not used this new method yet but shall do in the next few days, i'm just getting to that part of my class now where this style of checking could be useful to try out.

Cheers,
MRb

[Readie]

Courtesy of php.net [svn.php.net] I found the regular expression used in the filter_var($string, FILTER_VALIDATE_EMAIL);

/^(?!(?:(?:\\x22?\\x5C[\\x00-\\x7E]\\x22?)|(?:\\x22?[^\\x5C
\\x22]\\x22?)){255,})(?!(?:(?:\\x22?\\x5C[\\x00-\\x7E]\\x22?)|(?:\\x22?[^\\x5C
\\x22]\\x22?)){65,}@)(?:(?:[\\x21\\x23-\\x27\\x2A\\x2B\\x2D\\x2F-\\x39\\x3D
\\x3F\\x5E-\\x7E]+)|(?:\\x22(?:[\\x01-\\x08\\x0B\\x0C\\x0E-\\x1F\\x21\\x23-
\\x5B\\x5D-\\x7F]|(?:\\x5C[\\x00-\\x7F]))*\\x22))(?:\\.(?:(?:[\\x21\\x23-
\\x27\\x2A\\x2B\\x2D\\x2F-\\x39\\x3D\\x3F\\x5E-\\x7E]+)|(?:\\x22(?:[\\x01-
\\x08\\x0B\\x0C\\x0E-\\x1F\\x21\\x23-\\x5B\\x5D-\\x7F]|(?:\\x5C[\\x00-\\x7F]))*
\\x22)))*@(?:(?:(?!.*[^.]{64,})(?:(?:(?:xn--)?[a-z0-9]+(?:-[a-z0-9]+)*\\.){1,126})
{1,}(?:(?:[a-z][a-z0-9]*)|(?:(?:xn--)[a-z0-9]+))(?:-[a-z0-9]+)*)|(?:\\[(?:(?:IPv6:
(?:(?:[a-f0-9]{1,4}(?::[a-f0-9]{1,4}){7})|(?:(?!(?:.*[a-f0-9][:\\]]){7,})(?:
[a-f0-9]{1,4}(?::[a-f0-9]{1,4}){0,5})?::(?:[a-f0-9]{1,4}(?::[a-f0-9]{1,4})
{0,5})?)))|(?:(?:IPv6:(?:(?:[a-f0-9]{1,4}(?::[a-f0-9]{1,4}){5}:)|(?:(?!(?:.*[a-
f0-9]:){5,})(?:[a-f0-9]{1,4}(?::[a-f0-9]{1,4}){0,3})?::(?:[a-f0-9]{1,4}(?::[a-
f0-9]{1,4}){0,3}:)?)))?(?:(?:25[0-5])|(?:2[0-4][0-9])|(?:1[0-9]{2})|(?:[1-9]?
[0-9]))(?:\\.(?:(?:25[0-5])|(?:2[0-4][0-9])|(?:1[0-9]{2})|(?:[1-9]?[0-9])))
{3}))\\]))$/i

You'll need to delete the line breaks I've put in there, they are merely to maintain the forum width