Using a regex for RFC 822 isn't a very good idea. To start off, it's
an ARPA standard from 1982. RFC 2822 replaced it in 2001. But even
just following that isn't good enough because of the reasons you've
stated about UTF-8 and domain names. The RFC for IRI's (RFC 3987)
wasn't released until 20
Scott González wrote on 6/27/2008 6:51 AM:
No problem. The interesting thing is that the more you comply with
the RFC, the more likely you are to allow someone to accidentally
enter an incorrect email address.
Jan Goyvaerts does a great job of explaining the issues surrounding validating
em
No problem. The interesting thing is that the more you comply with
the RFC, the more likely you are to allow someone to accidentally
enter an incorrect email address. The webforms plugin addresses this
by following the spec as closely as possible and just ensuring that
the form of the address is
Sounds great Scott. First my apologies, as it seems my post was a
little pre-emptive. The specific case I got in a bug report was that
+ signs were not being allowed by the client validation. This is
incorrect as I've double tested it after looking at your test cases,
and it looks like you guys
As Jörn has stated, we have intentionally gone against the RFC a bit
to go for a more practical approach. The original regex was written
to the spec (as much as possible). I seem to recall that while I was
writing the regex I thought it was actually impossible to follow the
spec because I had to
Can you give me a concrete example of a false positive or false
negative in the validation plugin?
Those are what we test against:
http://dev.jquery.com/view/trunk/plugins/validate/test/methods.js
(scroll down to test("email"...)
In addition, the validation implemented a mostly correct regex, wi
6 matches
Mail list logo
