Live data from Hacker News

Perfect email regex finally found

fightingforalostcause.net

21–30 of 118 posts

Re: Perfect email regex finally found

#21
I've accepted email validation is like security, better left to libraries by people smarter than I am...TMail with over 2000 test cases.

But we know a valid email address when we see it, right?

--

Edit: Nicely done, HTML5.

Re: Perfect email regex finally found

#22
I never understood the purposes of the "perfectly valid by the RFC" email regex. You may be able to with 100% accuracy say that something should be an email address, but you'll never be able to tell if it's a valid account on the server, or if the server even exists.

Re: Perfect email regex finally found

#23

It does not look like any of these can detect or were tested against quoted-local-part addresses. As I understand it, the local part can be quoted to allow illegal characters to be used, e.g. "John Doe"@example.com I fully understand that these are not in common use, but they are part of the RFC and may be in use somewhere.

His test also considers the % sign invalid, yet I've both sent and received email that required the % for the mail to be routed/relayed correctly (think "in care of" or c/o).

Granted, that was 17 years ago, but who's to say it's not in use somewhere?

Re: Perfect email regex finally found

#24
As a typical optimizer, I was always trying to reduce my source code a few more bytes or speed up my processes a few nanaseconds here and there. I was so proud of myself. Until I tried to maintain my own slickness.

There's a fine line between clever and practical. Why do I have a gut feeling that this approach is way over that line?

Re: Perfect email regex finally found

#25
post #6

&*=?^+{}'~@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 :)

What's the deal with using a port number in an e-mail address? I can't imagine many systems supporting that. Anyone got any more info on it that doesn't involve me digging through 101 pages of RFCs? :-)

I don't think that's valid. I think they misread the RFC. First of all, an IP address (address-literal) is supposed to be enclosed in [square brackets]. The colon is only allowed to designate address family, as in "foo@[IPv6:XXXXXX]".

Re: Perfect email regex finally found

#26
post #7
post #3

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.

Especially when the spec itself is in EBNF.

Re: Perfect email regex finally found

#27
It's certainly more concise than my previous favorite,

      qtext = '[^\\x0d\\x22\\x5c\\x80-\\xff]'
      dtext = '[^\\x0d\\x5b-\\x5d\\x80-\\xff]'
      atom = '[^\\x00-\\x20\\x22\\x28\\x29\\x2c\\x2e\\x3a-' +
        '\\x3c\\x3e\\x40\\x5b-\\x5d\\x7f-\\xff]+'
      quoted_pair = '\\x5c[\\x00-\\x7f]'
      domain_literal = "\\x5b(?:#{dtext}|#{quoted_pair})*\\x5d"
      quoted_string = "\\x22(?:#{qtext}|#{quoted_pair})*\\x22"
      domain_ref = atom
      sub_domain = "(?:#{domain_ref}|#{domain_literal})"
      word = "(?:#{atom}|#{quoted_string})"
      domain = "#{sub_domain}(?:\\x2e#{sub_domain})*"
      local_part = "#{word}(?:\\x2e#{word})*"
      addr_spec = "#{local_part}\\x40#{domain}"
      pattern = Regexp.new "\\A#{addr_spec}\\z", nil, 'n'

Re: Perfect email regex finally found

#28
post #14

I've accepted that it's best to treat people like grown-ups and if there's '@' and '.' and it's retyped then it passes. Someone can easily submit a fake name or phone number or street address, and e-mail's no different. 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 r…

Along those lines, I've settled on the following overly permissive regex: /^[^\s@]+@[^\s@]+\.[^\s@]{2,}$/ -- it makes sure it looks something like an email address (a@b.cd)

Re: Perfect email regex finally found

#29
post #26
post #7

Earlier quoted context omitted.

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.

Especially when the spec itself is in EBNF.

True, though it's EBNF with a bunch of explanatory text and annotations.

What would be interesting, but I can't find with some googling: Has someone implemented a parser-generator based on the spec? The ideal would be that the parser specification looks a lot like the RFC, since then you'd have more confidence it was actually correct (and it'd be easier to maintain for future changes).

Post reply on HN