Hacker News new | past | comments | ask | show | jobs | submit login

I believe this falls under the category of "things that may be fun to play around with but should never be used in a real system".

Unfortunately, I bet there are thousands of "real systems" employing regexes like this... How many problems does this solve? Probably zero. How many does (/will) it cause? Probably much more than zero.




Not sure why this has been downvoted, but yes these sort of things do cause more problems than they solve.

Case in point, at work the other day I found a bug in a service I manage. It consists of a front end form (built by one team), which submits data to another system (built by my team), which then passes the data to a third party. The third party was rejecting the data we were trying to send them as the email addresses were apparently invalid. The validation they were doing didn't match the validation the front end form did, so to the user everything seemed fine.


So what caused the problem, wasn't that front end and 3rd party was checking if email is valid, but the fact that there is no standard way of checking it.

I'm not saying that checking email address with regex is good way of doing it, but there is countless examples of people doing it and it would help a lot if everyone would use one standardized regex for that.


As others have suggested, the best "standardised regex" solution would just be something like:

    /.*@.*/
Some people aren't happy with this because it allows invalid emails to be entered. But the alternative - such as what's being attempted here - is a nightmare!

Even if there was a standardised regex for all emails, which would not break when new TLDs are released, or new unicode characters are supported, or whatever, there would still be no guarantee that someemailaddress@domain.com is actually valid!

Your best bet is to simply allow users to enter anything (with perhaps some minor regex check like I did above), perhaps ask them to enter it twice, and perhaps send an account validation email.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: