4 ms·

Your email regex is wrong. There are some obscure email address that will not work. For example my.email domain+plus@some.weird3.com For more see http://en.wik

Your email regex is wrong. There are some obscure email address that will not work. For example my.email domain+plus@some.weird3.com For more see http://en.wikipedia.org/wiki/Email_address#Valid_email_addresses http://en.wikipedia.org/wiki/Email_address#Valid_email_addre...

deleted 13y ago
[deleted]
AdrianRossouw 13y ago
apparently this is the correct fully rfc-compliant email validation regex: http://www.ex-parrot.com/pdw/Mail-RFC822-Address.html http://www.ex-parrot.com/pdw/Mail-RFC822-Address.html
- btilly 13y ago
  Only if you do not add comments. There was a fun proposal to avoid spam by adding comments inside your email address. Any true emailer should handle it. And regex should break. Unfortunately Microsoft Exchange breaks. And that case is important enough that the idea never caught on.
- vacri 13y ago
  These guys say that a 430-character regex does the same trick as that 6k-character one (down in the RFC 2822 section) http://www.regular-expressions.info/email.html http://www.regular-expressions.info/email.html
- simpleigh 13y ago
  I might be wrong, but ISTR that no longer works 'cause RFC822 has been superseded (the new RFC extends the domain of valid addresses). The term "works" is relative of course - I don't suppose anyone actually uses that regex!
zeckalpha 13y ago
> validates an email adress (something you should never do with Regex, because you won't get it right, but anyway) I think it is clear that this isn't the point.
joe_the_user 13y ago
I think that actually says a lot about regexes as code. The more corner cases you have to consider, the more unreadable the code gets, after a while by seemingly exponential degree. And if you have a tool to build the regex, why not just use the tool's code as your source so the final result is readable. Basically, pasting a big regex into your code hardly seems more desirable than pasting a bunch of assembler there. But assembler can unavoidable. This isn't. Regex are cool as CS constructs though.
- cheald 13y ago
  Email addresses are specified by standard with a context-free grammar. While it may be possible to express certain CF grammars as regular grammars, you rapidly run into issues (such as optional bounding delimiter matching, or escaped delimiters) which are trivial to express with a stack, and frickin' hard to express without one. (This is, incidentally, the heart of the "don't try to parse XML with regexp" sentiment, because XML is (at least) a context-free grammar that cannot be properly expressed by a regular grammar) If you are having severe problems with a regex, the issue might be that you need to use an actual parser rather than a simple pattern matcher.
  - joe_the_user 13y ago
    At that rate, I can't see any good reason to use regexes for email ever. If you know context-free language, recursive-descent parsers are fairly simple to write and maintain without any special tools.
    - cheald 13y ago
      Well, if you want a spec-compliant email validator, then yeah, you probably want an actual parser. Most people are happy enough with a good-enough pattern match, though, which is substantially less code.

deleted 13y ago

[deleted]

AdrianRossouw 13y ago

apparently this is the correct fully rfc-compliant email validation regex: http://www.ex-parrot.com/pdw/Mail-RFC822-Address.html http://www.ex-parrot.com/pdw/Mail-RFC822-Address.html

btilly 13y ago
Only if you do not add comments. There was a fun proposal to avoid spam by adding comments inside your email address. Any true emailer should handle it. And regex should break. Unfortunately Microsoft Exchange breaks. And that case is important enough that the idea never caught on.
vacri 13y ago
These guys say that a 430-character regex does the same trick as that 6k-character one (down in the RFC 2822 section) http://www.regular-expressions.info/email.html http://www.regular-expressions.info/email.html
simpleigh 13y ago
I might be wrong, but ISTR that no longer works 'cause RFC822 has been superseded (the new RFC extends the domain of valid addresses). The term "works" is relative of course - I don't suppose anyone actually uses that regex!

zeckalpha 13y ago

> validates an email adress (something you should never do with Regex, because you won't get it right, but anyway) I think it is clear that this isn't the point.

joe_the_user 13y ago

I think that actually says a lot about regexes as code. The more corner cases you have to consider, the more unreadable the code gets, after a while by seemingly exponential degree. And if you have a tool to build the regex, why not just use the tool's code as your source so the final result is readable. Basically, pasting a big regex into your code hardly seems more desirable than pasting a bunch of assembler there. But assembler can unavoidable. This isn't. Regex are cool as CS constructs though.

cheald 13y ago
Email addresses are specified by standard with a context-free grammar. While it may be possible to express certain CF grammars as regular grammars, you rapidly run into issues (such as optional bounding delimiter matching, or escaped delimiters) which are trivial to express with a stack, and frickin' hard to express without one. (This is, incidentally, the heart of the "don't try to parse XML with regexp" sentiment, because XML is (at least) a context-free grammar that cannot be properly expressed by a regular grammar) If you are having severe problems with a regex, the issue might be that you need to use an actual parser rather than a simple pattern matcher.
- joe_the_user 13y ago
  At that rate, I can't see any good reason to use regexes for email ever. If you know context-free language, recursive-descent parsers are fairly simple to write and maintain without any special tools.
  - cheald 13y ago
    Well, if you want a spec-compliant email validator, then yeah, you probably want an actual parser. Most people are happy enough with a good-enough pattern match, though, which is substantially less code.