ChatGPT解决这个技术问题 Extra ChatGPT

Why does HTML5 form-validation allow emails without a dot?

I'm writing a very simple mock-up to demonstrate some HTML5 form-validation. However, I noticed the email validation doesn't check for a dot in the address, nor does it check for characters following said dot.

In other words, "john@doe" is considered valid, when it's clearly not a valid email address; "doe" isn't a domain.

This is how I'm coding my email field:

<input type="email" required />

Is that not enough?

Check this fiddle to see what I mean.

Note: I know how to accomplish this via a RegEx pattern instead. I'm just wondering how someone could get away with using the email type instead.

@Katana314 - heh, yup. Most (well-configured) mailservers will reject messages being sent to addresses that don't match an expected domain, so generally speaking there isn't an issue with localhost addresses.

D
DBS

You can theoretically have an address without a "." in.

Since technically things such as:

user@com
user@localserver
user@[IPv6:2001:db8::1]

Are all valid emails.

So the standard HTML5 validation allows for all valid E-mails, including the uncommon ones.

For some easy to read explanations (Instead of reading through the standards): http://en.wikipedia.org/wiki/Email_address#Examples

Update from a comment: ICANN banned so-called "dotless" domains in 2013, but since that doesn't affect every case listed above, allowing "dotless" addresses is still valid.


Agreed, this one answers the 'why', not the 'solution'. I was also curious about the why. Now I know not to "fix".
An example of the first type is the domain uz, which directly points to an IP as of Oct 2018. If you do an nslookup uz, it points to 91.212.89.8, so it should be possible to have email on this domain as well.
A
Ali Alavi

Because a@b is a valid email address (eg localhost is a valid domain). See http://en.wikipedia.org/wiki/Email_address#Examples

Also, keep in mind that you should always do the input validation in server. The client side validation should be only for giving feedback to the user and not be relied on, since it can be easily bypassed.


Thanks. I just don't see how any company could benefit from this out-of-box email validation. Facebook wouldn't let someone sign-up w/ an a@b address. Thanks for the info though. (I didn't downvote your answer)
In case of websites like Facebook with public access it is of no use. But think of internal websites. You might want to write to joe@support. But I also think that it is of minimum use. Nevertheless, the web browsers are to implement based on standards (i.e. RFCs), not based on the most common cases.
I wonder when the last time someone actually sent an email to localhost!
As a sidenote one of the shortest working email addresses ( recordsetter.com/world-record/shortest-email-address/4327 ) is au@ua
a@b is a valid address according to RFC822, but that's not the end of the story. ICANN banned so-called "dotless" domains back in 2013, so whether they are syntactically valid is irrelevant.
A
APAD1

Try adding this to the input

pattern="[a-z0-9._%+-]+@[a-z0-9.-]+\.[a-z]{2,63}$"

Fiddle


-1. Firstly, you haven't even tried to explain what this does permits or restricts, nor why somebody would want those rules. Secondly, it is far more restrictive than the standards permit (I won't pretend to have read and grokked the standards, but see, for example, en.wikipedia.org/wiki/Email_address#Internationalization or the many email validation questions on Stack Overflow for examples of weird email addresses). Why do it? If somebody is entering something unusual as their email, just accept it - chances are they know better than you.
Actually, I'd say that the "chances are" that they are making a mistake. It /may/ be that they have a very unusual email address, but I'd say the majority of times you'd simply be getting a correct email address in place of an incorrect one if you were to stop it passing validation and prompt the user to check.
This should have a ^, denoting it should start matching from the beginning of the string and also accept upper case: ^[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]+$
O
Ortomala Lokni

The RFC 822, chapter 6, gives the specification of an address in augmented Backus-Naur Form (BNF):

addr-spec   =  local-part "@" domain
local-part  =  word *("." word)
domain      =  sub-domain *("." sub-domain)

Using this specification a@b is a valid address.

UPDATE

To answer the comment of Trejkaz, I add the following definitions. We see that SPACE are allowed but only in quoted string.

word          =  atom / quoted-string
atom          =  1*<any CHAR except specials, SPACE and CTLs>
quoted-string = <"> *(qtext/quoted-pair) <">
SPACE         =  <ASCII SP, space>
CTL           =  <any ASCII control character and DEL> 
qtext         =  <any CHAR excepting <">, "\" & CR, and including linear-white-space>
quoted-pair   =  "\" CHAR  

OTOH, RFC 822 also permits me to put spaces in the local-part, which Chrome at least doesn't appear to be permitting, so I'm not sure they use the RFC as a reference. (Even though they should be!)
g
gitaarik

This MDN page shows the regex browsers should use to validate the email:

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/email#Validation

You can slightly change this regex to require at least one dot in the domain name: change the star * at the end of the regex to a plus +. Then use that regex as the pattern attribute:


This is not fully qualified validation. Eg. ".test@test.com" and "test.@test.com" is invalid according to RFC
D
Dorian

You can customize the pattern of the email field:

input:valid { border-color: green } input:invalid { border-color: red } Email:
Non-dots Email:


H
Hari Das

Here is how you can do it with html5 using regex pattern. You can also include a custom message to display.


M
Michael Benjamin

Hostnames without a TLD appear to be valid.

I say "appear" because there is this 2013 ICANN prohibition on dotless domains . . .

At its meeting on 13 August 2013, the ICANN Board New gTLD Program Committee (NGPC) adopted a resolution affirming that "dotless domain names" are prohibited.

. . . but judging from real world experience, it appears to have never been enforced.

Regardless, the PHP function FILTER_VALIDATE_EMAIL doesn't allow for dotless domain names.

So here's a simple back-end validation set-up that covers both your email and required fields:

if (empty($required_field) OR empty($another_required_field) OR
    !filter_var($email_field, FILTER_VALIDATE_EMAIL)) {
    // error handling here
    exit;
    }

While the "malformed" email may get passed the browser, it won't get passed the server.

References:

FILTER_VALIDATE_EMAIL definition

List of valid and invalid email addresses


T
TSlegaitis

This pattern always works for me.

Text must in lowercase pattern="[a-z0-9._%+-]+@[a-z0-9.-]+\.[a-z]{2,}$" but I think it covers more or less most emails.