Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Stop Validating Email Addresses With Your Complex Regex

davidcel.is

Post reply on HN
Print view View original

31–40 of 211 posts

Re: Stop Validating Email Addresses With Your Complex Regex

#31

Post by MattBearman »

MichaelApproved wrote: post #19
MattBearman wrote: post #12

My goto for email validation is /^.+?@.+?\..+?$/ Incase I've typed it wrong, that should basically work for anything that contains at least one @ and one dot, in that order, as well as at least one character at beginning, middle and end. It's served me well thusfar. Edit for clarification: The reason I prefer this over just checking for an @ is that if you're just checking for @ a common mistake like "me@hotmail,com"…

I thought new TLD being worked on didn't need to have dots in them. Why not just check for x@x?

As far as I know the new tlds will still have a dot between tld and actual domain (I could be wrong though) but it's just been pointed out that IPv6 emails addresses could fail on my regex. The reason I don't currently use x@y is just to have a better shot at catching typos without being too restrictive.

Re: Stop Validating Email Addresses With Your Complex Regex

#33

Post by sirn »

MattBearman wrote: post #12

My goto for email validation is /^.+?@.+?\..+?$/ Incase I've typed it wrong, that should basically work for anything that contains at least one @ and one dot, in that order, as well as at least one character at beginning, middle and end. It's served me well thusfar. Edit for clarification: The reason I prefer this over just checking for an @ is that if you're just checking for @ a common mistake like "me@hotmail,com"…

My favorite: /.\@.*\../

It should be similar to your version, but only matches just enough parts that require for email validation (i.e. "o@example.c" part of foo@example.com).

Re: Stop Validating Email Addresses With Your Complex Regex

#34

Post by smackfu »

The question is why people are validating the email in the first place.

* to ensure it is deliverable? Well, then you better send them an email.

* to let people know when they misread the labels and put something that was clearly not an email in the email field? A simple check for an at-sign is usually sufficient.

* because some tester opens a ticket saying you can enter an invalid email in the email field? Yeah, that's where most of the complicated regexps come from.

Re: Stop Validating Email Addresses With Your Complex Regex

#35

Post by jiggy2011 »

ScottWhigham wrote: post #13

Don't bother even reading it. His solution is to "Just send your users an email. The activation email is a practice that’s been in use for years, but it’s often paired with complex validations that the email is formatted correctly. If you’re going to send an activation email to users, why bother using a gigantic regular expression?" Want to know why it's not more common than the regex "method"? His method has its own…

People are far far more likely to get their email address wrong by misspelling their own name or putting @hotmail.com when they meant to put @gmail.com; regex will not protect you from either of these things.

We actually had an email list of ~50k people that had been validated within nothing other than "check there are at least 3 characters in the string" and when we looked at which addresses were bouncing when we sent to them there were approximately zero that failed because they had ommited the @ or because they were using some weird invalid unicode.

Even the spam bots were submitting valid email addresses.

Re: Stop Validating Email Addresses With Your Complex Regex

#37

Post by baby »

wodow wrote: post #30
onemorepassword wrote: post #15

This has been an issue since the day I started programming for the web, back somewhere in '95. It has regularly come up on HN, and pretty much any programming related forum I've used since the mid-90's. As an industry at the heart of the information society you have to wonder what the hell we are doing wrong if we cannot stop this constant regression into well known bad practices.

I understand the argument re validating email addresses passively (regex, no regex, etc.) vs actively (send an email by SMTP). What I don't understand with this ever-repeating discussion is why the complexity has to be visible. e.g. > > Yeesh. Is something that complex really necessary? Many functions are complex - we put those in libraries, pushing them under the hood, and move on. What is so special about parsing e…

Plus a Large Regex for mail validation is not supposed to be heavily used. It's supposed to be used once at registration for example. So why would it matter if it's slow/heavy/...

Re: Stop Validating Email Addresses With Your Complex Regex

#38

Post by cthackers »

So what's wrong if you do a full validation (http://www.ex-parrot.com/pdw/Mail-RFC822-Address.html) ? You as developer or site owner or user don't need to do it by hand or in your head. It is done in a fraction of a second by the computer even if benefits are not the greatest like validating the strength of a password but still. Complaining about it because you don't like it and telling other people not to do it because of your reasons and spending time writing a blog post about it is overkill - like validating the email address with a regexp :)

Re: Stop Validating Email Addresses With Your Complex Regex

#39

Post by arkitaip »

joshuahedlund wrote: post #20

Assuming that running the regex is much faster than sending an email, it would probably be much less server load to check the regex and never send X% of emails, unless X is extremely small. (Looking up and implementing a regex) * 1 + (running the regex) * (every email) + (sending email) * (every valid email) Also, this post only considers the signup/activation use case. If you're getting an email for ecommerce to sen…

You still need to confirm the validity of the email request by sending an confirmation email, so you might as well just check for '@' and let your confirmation system handle the rest.
Post reply on HN