7 ms·
My favorite regex is the E-Mail Regex[1]. Works 99.99% of the time, is unreadable/unmaintainable, makes you understand that the only true way to verify an e-ma
by linkdd 6y ago
My favorite regex is the E-Mail Regex[1].
Works 99.99% of the time, is unreadable/unmaintainable, makes you understand that the only true way to verify an e-mail is to send an e-mail to that address.
[1] - https://emailregex.com/ https://emailregex.com/
PS: Gotta love the Perl / Ruby version
- madsohm 6y agoThe only way you should ever "validate" an email address with a regex is like this: /@/
- oneeyedpigeon 6y agoSurely that should be /.+@.+/
- linkdd 6y agoYour regex would validate: this-is-not-a-valid-address@ @this-is-not-valid-either @
- wongarsu 6y agoBut allowing too much is better than allowing too little, as usually you have to send an actual email to verify ownership anyways. Any regex more complex than /.+@.+/ fails some valid email address
- linkdd 6y agoWhich was the point of my first message.
- PeterWhittaker 6y agoSurely that should be /^[^@]+@[^@]+$/ ?
- jameshart 6y agoAccording to the RFC compliant email regex, “\@“@example.com is a valid email address, which your simplified test would reject.
- linkdd 6y agoExactly. The worst regex would be: /^[a-zA-Z0-9\-_]+@[a-zA-Z0-9\-_]+\.[a-zA-Z0-9\-_]+$/ Because it would invalidates `my-email+custom-inbox@example.com`. And that's a pattern I use to automatically sort incoming mails. Many websites use such a regex :(
- tyingq 6y agoI suppose it depends on what we mean by validate. Running an ecommerce site, I got a lot of mileage out of prompting the customer to fix emails that "looked wrong". We allowed them to proceed if they wanted. A really common one was "user@gnail.com" when "user@gmail.com" was wanted. We used a slightly modified version of https://github.com/mailcheck/mailcheck https://github.com/mailcheck/mailcheck and found it to be really useful.
- eyelidlessness 6y agoThe one I use for anything that might take user input from a browser is the one defined in the HTML5 spec for input[type=email]: /^[a-zA-Z0-9.!#$%&'*+\/=?^_`{|}~-]+@[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?(?:\.[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?)*$/ There’s no sense being less permissive, if it’s good enough for browsers it’s the baseline expected by browser users. But there’s no sense being more permissive for the same reason.
- deleted 6y ago[deleted]
- anoncake 6y agoYes, there is. HTML does not define what email addresses look like. If input [type=email] rejects valid addresses, it's harmful garbage.
- eyelidlessness 6y agoHuh? My point is that if you expect user input from a browser’s input[type=email], you have little choice but to accept that it will reject emails not matching that pattern. Harmful garbage or not, a more permissive pattern won’t mitigate that.
- toomanybeersies 6y agoThe correct way would be to implement a parser off the ABNF defined in whatever the current RFC is for email addresses.
- linkdd 6y agoAnd yet, the successfully parsed e-mail can still be inexistant and therefore invalid :)
- morelisp 6y agoOr, more insidiously, the address can exist, its recipient can receive mail there, your form can validate it, but your SMTP server can't handle the character to send any in the first place.
- marcosdumay 6y agoWhat exactly is the current RFC for email addresses? Do you go with 2822/2823 or do you read all the extension ones?