11–20 of 118 posts
In particular, one of the evaluation tests used here is wrong: it requires failure-to-match on a TLD with a digit in it:
numbersInTLD@domain.c0m
In fact, IDN TLDs will have digits in them. An internet-draft is in the works to replace RFC1123's IDN-unfriendly implication that digits in TLDs are illegal:
How ugly do non-regex based email validation functions look? I've never seen one, but I've always wondered if that was a more elegant solution.
One nice looking trick I've seen is checking the domain of the email address for an MX record. (e.g. http://php.dzone.com/news/php-email-validator-email-mx-d ) Possibly this approach is too slow to use by itself without a regex. Also maybe there are other problems with this method I'm not aware of?
Earlier quoted context omitted.
One nice looking trick I've seen is checking the domain of the email address for an MX record. (e.g. http://php.dzone.com/news/php-email-validator-email-mx-d ) Possibly this approach is too slow to use by itself without a regex. Also maybe there are other problems with this method I'm not aware of?
I suggested that a while back but was told that due to spam, you can get lots of false negatives from this technique and others. The best way to validate an email remains to be a test email apparently.
If they get it wrong, intentionally or not, then they don't get their receipt, confirmation, validation link, etc. and I believe in most cases the incentive is there for them to get it right.
In the rare case where there's some incentive to circumvent the system and this has some measurable impact on a site, then more validation may be warranted. Otherwise, why worry about it?
Also: HTML5. ;)
&*=?^+{}'~@12.34.56.78:2000 really looks strange, even though its a valid email. Good luck trying to register on any site with it though :)
I fully understand that these are not in common use, but they are part of the RFC and may be in use somewhere.
Earlier quoted context omitted.
One nice looking trick I've seen is checking the domain of the email address for an MX record. (e.g. http://php.dzone.com/news/php-email-validator-email-mx-d ) Possibly this approach is too slow to use by itself without a regex. Also maybe there are other problems with this method I'm not aware of?
I suggested that a while back but was told that due to spam, you can get lots of false negatives from this technique and others. The best way to validate an email remains to be a test email apparently.
Merely looking up MX records is something you do for a _domain_ and it's no different than the DNS requests your computer makes when you go to a website.
Earlier quoted context omitted.
Regex is the only real sensible way to validate strings until something better is found. Even if you just wrote code to do it manually, you'd really just be writing a verbose and poorly implemented finite state machine that globbed symbols together, which in the end, would just be inferior to writing a well tested Regex string. Regex can be easier to read if you have something do a graphical expansion for you. Otherw…
That's just silly. Depending on what's in the string, writing a parser might be much better than a regex. Lots of parser libraries already out there, too.