ChatGPT解决这个技术问题 Extra ChatGPT

为什么 HTML5 表单验证允许不带点的电子邮件?

我正在编写一个非常简单的模型来演示一些 HTML5 表单验证。但是,我注意到电子邮件验证不会检查地址中的点,也不会检查所述点后面的字符。

换句话说,“john@doe”被认为是有效的,但它显然不是一个有效的电子邮件地址; “doe”不是域。

这就是我编码我的电子邮件字段的方式:

<input type="email" required />

这还不够吗?

检查此 fiddle 以了解我的意思。

注意:我知道如何通过 RegEx 模式来实现这一点。我只是想知道如何有人可以改用电子邮件类型。

@Katana314 - 嘿,是的。大多数(配置良好的)邮件服务器会拒绝发送到与预期域不匹配的地址的邮件,因此一般来说 localhost 地址没有问题。

D
DBS

理论上,您可以有一个没有“。”的地址。在。

由于技术上的事情,例如:

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

都是有效的电子邮件。

因此标准的 HTML5 验证允许所有有效的电子邮件,包括不常见的电子邮件。

对于一些易于阅读的解释(而不是通读标准):http://en.wikipedia.org/wiki/Email_address#Examples

2013 年更新 from a comment: ICANN banned so-called "dotless" domains,但由于这并不影响上面列出的所有情况,因此允许“无点”地址仍然有效。


同意,这个答案是“为什么”,而不是“解决方案”。我也很好奇为什么。现在我知道不要“修复”。
第一种类型的示例是域 uz,它直接指向截至 2018 年 10 月的 IP。如果您执行 nslookup uz,它指向 91.212.89.8,因此应该可以在此域上拥有电子邮件也是。
A
Ali Alavi

因为 a@b 是一个有效的电子邮件地址(例如 localhost 是一个有效的域)。请参阅http://en.wikipedia.org/wiki/Email_address#Examples

另外,请记住,您应该始终在服务器中进行输入验证。客户端验证应该仅用于向用户提供反馈而不是依赖,因为它很容易被绕过。


谢谢。我只是看不到任何公司可以从这种开箱即用的电子邮件验证中受益。 Facebook 不会让某人使用 a@b 地址注册。谢谢你的信息。 (我没有否决你的答案)
对于像 Facebook 这样具有公共访问权限的网站,它是没有用的。但想想内部网站。您可能想写信给 joe@support。但我也认为它是最低限度的使用。然而,Web 浏览器是基于标准(即 RFC)实现的,而不是基于最常见的情况。
我想知道最后一次有人真正向 localhost 发送电子邮件是什么时候!
作为旁注,最短的工作电子邮件地址之一 ( recordsetter.com/world-record/shortest-email-address/4327 ) 是 au@ua
a@b 是根据 RFC822 的有效地址,但这并不是故事的结尾。 ICANN banned so-called "dotless" domains 早在 2013 年,因此它们在语法上是否有效无关紧要。
A
APAD1

尝试将此添加到输入

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

Fiddle


-1。首先,您甚至没有尝试解释这允许或限制什么,也没有尝试解释为什么有人会想要这些规则。其次,它比标准允许的限制要严格得多(我不会假装已经阅读和理解了这些标准,但是请参阅 en.wikipedia.org/wiki/Email_address#Internationalization 或 Stack Overflow 上的许多电子邮件验证问题以获取奇怪的电子邮件地址的示例) .为什么这样做?如果有人输入了一些不寻常的东西作为他们的电子邮件,请接受它 - 他们可能比你更了解。
实际上,我会说他们犯错的“机会是”。它/可能/是他们有一个非常不寻常的电子邮件地址,但我想说,大多数时候,如果您阻止它通过验证并提示用户检查。
这应该有一个 ^,表示它应该从字符串的开头开始匹配并且还接受大写:^[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]+$
O
Ortomala Lokni

第 6 章的 RFC 822 给出了扩展巴科斯-瑙尔形式 (BNF) 中的地址规范:

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

使用此规范 a@b 是一个有效的地址。

更新

为了回答 Trejkaz 的评论,我添加了以下定义。我们看到 SPACE 是允许的,但只能在带引号的字符串中。

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 还允许我在本地部分中放置空格,Chrome 至少似乎不允许这样做,所以我不确定他们是否使用 RFC 作为参考。 (即使他们应该是!)
g
gitaarik

此 MDN 页面显示正则表达式浏览器应用于验证电子邮件:

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

您可以稍微更改此正则表达式以要求域名中至少有一个点:将正则表达式末尾的星号 * 更改为加号 +。然后将该正则表达式用作 pattern 属性:


这不是完全合格的验证。例如。 “.test@test.com”和“test.@test.com”根据 RFC 无效
D
Dorian

您可以自定义电子邮件字段的模式:

输入:有效 { 边框颜色:绿色 } 输入:无效 { 边框颜色:红色 } 电子邮件:
非圆点电子邮件:<输入类型="email" 必填模式="[^.]+@[^.]+" value="a@bc" />


H
Hari Das

这是使用正则表达式模式使用 html5 的方法。您还可以包含要显示的自定义消息。


M
Michael Benjamin

没有 TLD 的主机名似乎是有效的。

我说“出现”是因为有这个 2013 ICANN prohibition on dotless domains 。 . .

在 2013 年 8 月 13 日的会议上,ICANN 董事会新 gTLD 计划委员会 (NGPC) 通过了一项决议,确认禁止“无点域名”。

. .但从现实世界的经验来看,它似乎从未被强制执行过。

无论如何,PHP 函数 FILTER_VALIDATE_EMAIL 不允许使用无点域名。

因此,这是一个简单的后端验证设置,涵盖了您的电子邮件和必填字段:

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

虽然“格式错误”的电子邮件可能会通过浏览器,但不会通过服务器。

参考:

FILTER_VALIDATE_EMAIL 定义

有效和无效电子邮件地址列表


T
TSlegaitis

这种模式总是对我有用。

文本必须小写 pattern="[a-z0-9._%+-]+@[a-z0-9.-]+\.[a-z]{2,}$" 但我认为它或多或少涵盖了大多数电子邮件。