【问题标题】:What can we assume is an invalid email address?我们可以假设什么是无效的电子邮件地址?
【发布时间】:2013-08-12 10:54:55
【问题描述】:

我正在尝试验证电子邮件地址,但是我想要尽可能宽松的验证,因为我打算通过向用户发送验证电子邮件来支持这一点(我知道这被问了很多,但其他问题集中在尽可能严格,而我试图确定可能的最宽松的检查)。

我仍然认为进行某种程度的验证以删除不可能是电子邮件地址的内容很重要...我不希望 "this is not @n email. fool" 沾沾自喜地坐在我的数据库中假装是电子邮件。虽然我很高兴有"this.is.not.an.email@fool.com"

到目前为止,这是我的功能:

function validate(email) {
  var atIndex = email.lastIndexOf('@');
  // Make sure email contains an '@' character and that it is neither the first or last character
  if (atIndex > 0 && atIndex < email.length -1) {
    // Everything before the last '@' character
    var local = email.substring(0, atIndex);
    // Everything after the last '@' character
    var domain = email.substring(atIndex + 1, email.length);
    var dotIndex = domain.lastIndexOf('.');

    // Make sure domain contains a '.' character and that it is neither the first or last character
    if (dotIndex > 0 && dotIndex < domain.length - 1) {
      // Array of strings that aren't allowed to appear in a domain
      var domainRestrictions = [
        "..",
        " "
      ];
      var i = domainRestrictions.length;
      while (i-- > -1) {
        if (domain.indexOf(domainRestrictions[i]) > -1) {
          return false;
        }
      }
      // Array of strings that the local portion can neither start or end with
      var localRestrictions = [
        ".",
        " "
      ];
      i = localRestrictions.length;
      while (i-- > -1) {
        var string = localRestrictions[i];
        if (local.indexOf(string) == 0 || local.lastIndexOf(string) == local.length - 1) {
          return false;
        }
      }

      return true;
    }

  }
  return false;
}

目前我不允许以下行为:

  • 任何不带“@”符号的内容。
  • 任何不包含“.”的域或包含它作为第一个或最后一个字符。
  • 任何包含空格或“..”的域 任何以“.”开头或结尾的本地部分或空格

其他所有内容都被视为有效并继续传递。

我的问题是,是否有任何有效的电子邮件地址会阻塞?有没有更安全的假设我可以做出一个电子邮件地址不能包含的假设?

【问题讨论】:

  • RFC 中没有要求域包含“.”。
  • 这不是问题的答案,但我个人认为“这不是@n 电子邮件,愚蠢的”和“not.a.real@email-address”之间没有区别。哈哈”。如果有人不想提供真实的电子邮件地址,他们只会编造一个。电子邮件验证的唯一好处是它可能会捕捉到用户可能犯的不需要的拼写错误。
  • @AdrianWragg 如何向这样的域发送电子邮件?我假设这只能发生在localhost?
  • @NabilKadimi 过于严格,作者本人承认它会阻塞某些有效的电子邮件地址。如果它可以存在,我会让他们使用它。

标签: javascript regex email-validation


【解决方案1】:

如果您绝对希望拥有一个 100% 有效的电子邮件地址,那么对于初学者,我建议您阅读 RFC 2822,它可以在 https://www.rfc-editor.org/rfc/rfc2822#section-3.4.1 找到。此规范的完整实现将确保输入的所有电子邮件地址都是完全有效的格式。这远远超出了除了最复杂的正则表达式之外的所有内容 - 例如,您可能会发现您需要处理西里尔文、希腊文或 Unicode 字符集。

然而……

与您节省的时间相比,实施此规范需要大量时间。即使电子邮件地址的格式仍然有效,仍然存在一些问题,包括:

  • 域名可能未注册;
  • 域可能没有 MX 记录;
  • 域可能没有 A 记录,作为后备;或者,
  • 用户可能实际上并不存在。

坦率地说,与其花时间确保电子邮件地址严格遵循正确的格式,不如花时间确保它“足够好”并专注于验证过程的其他方面。

【讨论】:

    【解决方案2】:

    请查看详尽的规则集 -

    http://rumkin.com/software/email/rules.php

    【讨论】:

      【解决方案3】:

      如果您使用正则表达式,您的麻烦会少很多。有一些电子邮件验证模式可以验证您的电子邮件地址。

      Pattern pattern = Pattern.compile("([A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\\.[A-Za-z]{2,4})?");
      Matcher matcher = pattern.matcher(yourEmailAddress);
      if(matcher.matches()){
        //do something
      }else {
        //tell the user it didn't match
      }
      

      【讨论】:

      • 尽管据我所知我无法读/写正则表达式,但这些限制大多过于严格。如果需要,我也更喜欢使用我自己可以维护的代码 sn-ps。
      • @rouce 自 ICANN 开始为通用 TLD 发放许可证以来,顶级域不再限于 2-4 个字符。
      • @GeorgeReith 你真的应该学习如何读写正则表达式。这是一项非常有用的技能,即使对于有经验的人来说也很难阅读。
      • 问题是(除非你达到非常复杂的水平)每个正则表达式都有例外。 test@sample..com 在此表达式下是“有效的”。
      • @Philipp 确实它在我的待办事项清单上,每次我对一个新项目有想法时,它都会被推得更远。我有一个非常基本的理解,例如[],+,* 是什么意思,仅此而已。
      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2017-01-10
      • 2013-02-28
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多