的Python和PHP实现 正确验证任何电子邮件地址，即 邮件服务器确认是真的 域是实的。

在GPL-3.0许可下发布。

就是这样:

https://lja.fi/index.php/github-stuff/

--李雅

检查电子邮件地址是否格式良好的最简单和最安全的方法是使用filter_var()函数:

if (!filter_var($email, FILTER_VALIDATE_EMAIL)) {
    // invalid emailaddress
}

此外，您可以检查域是否定义了MX记录:

if (!checkdnsrr($domain, 'MX')) {
    // domain is not valid
}

但这仍然不能保证邮件存在。唯一的办法就是发送确认邮件。

现在你已经有了简单的答案，如果你想学习，可以继续阅读关于电子邮件地址验证的内容，或者只是使用快速答案并继续前进。别见怪不怪。

尝试使用正则表达式验证电子邮件地址是一项“不可能”的任务。我想说的是，你所做的正则表达式是无用的。关于电子邮件地址有三个rfc，编写一个正则表达式来捕获错误的电子邮件地址，同时避免误报，这是没有人能做到的。查看PHP的filter_var()函数所使用的正则表达式的测试列表(包括失败和成功)。

即使是内置的PHP函数，电子邮件客户端或服务器也没有做到这一点。在大多数情况下，filter_var仍然是最好的选择。

如果你想知道PHP(目前)使用哪种正则表达式模式来验证电子邮件地址，请参阅PHP源代码。

如果你想了解更多关于电子邮件地址的信息，我建议你开始阅读说明书，但我必须警告你，无论如何，这都不是一个简单的阅读:

rfc5322 rfc5321 rfc3696 Rfc6531(允许unicode字符，尽管许多客户端/服务器不接受它)

如果你想检查电子邮件地址提供的域名是否有效，可以使用如下方法:

/*
* Check for valid MX record for given email domain
*/
if(!function_exists('check_email_domain')){
    function check_email_domain($email) {
        //Get host name from email and check if it is valid
        $email_host = explode("@", $email);     
        //Add a dot to the end of the host name to make a fully qualified domain name and get last array element because an escaped @ is allowed in the local part (RFC 5322)
        $host = end($email_host) . "."; 
        //Convert to ascii (http://us.php.net/manual/en/function.idn-to-ascii.php)
        return checkdnsrr(idn_to_ascii($host), "MX"); //(bool)       
    }
}

这是一种方便的方式来过滤大量无效的电子邮件地址，以及标准的电子邮件验证，因为有效的电子邮件格式并不意味着有效的电子邮件。

请注意，idn_to_ascii()(或它的姐妹函数idn_to_utf8())函数在PHP安装中可能不可用，它需要扩展PECL intl >= 1.0.2和PECL idn >= 0.1。

还要记住，IPv4或IPv6作为电子邮件中的域部分(例如user@[IPv6:2001:db8::1])不能被验证，只有命名主机可以。

点击这里查看更多信息。

的Python和PHP实现 正确验证任何电子邮件地址，即 邮件服务器确认是真的 域是实的。

在GPL-3.0许可下发布。

就是这样:

https://lja.fi/index.php/github-stuff/

--李雅

如果你只是在寻找一个实际的正则表达式，允许各种点，下划线和破折号，它如下:[a-zA-z0-9.-]+\@[a-zA-z0-9.-]+.[a-zA-Z]+。这将允许像tom_anderson.1-neo@my-mail_matrix.com这样看起来相当愚蠢的电子邮件被验证。

有三个rfc奠定了“Internet消息格式”的基础。

RFC 822 RFC 2822(取代RFC 822) RFC 5322(取代RFC 2822)

然而，RFC 5322以最专业的方式定义了电子邮件id及其命名结构。这更适合于为一个互联网标准奠定基础，这个标准足够自由，可以允许所有的用例，也足够保守，可以用某种形式主义来约束它。

然而，来自软件开发人员社区的电子邮件验证需求，有以下需求——

避免不必要的垃圾邮件发送者 确保用户不会因疏忽而出错 以确保电子邮件ID属于实际输入它的人

They are not exactly interested in implementing a technically all-encompassing definition that allows all the forms (IP addresses, including port IDs and all) of e-mail id. The solution suitable for their use-case is expected to solely ensure that all the legitimate e-mail holders should be able to get through. The definition of "legitimate" differs vastly from technical stand-point (RFC 5322 way) to usability stand-point(this solution). The usability aspect of the validation aims to ensure that all the e-mail IDs validated by the validation mechanism belong to actual people, using them for their communication purposes. This, thus introduces another angle to the validation process, ensuring an actually "in-use" e-mail ID, a requirement for which RFC-5322 definition is clearly not sufficient.

因此，在实际的基础上，实际的要求归结为这一点

以确保一些非常基本的验证检查 确保输入的电子邮件正在使用

第二个需求通常包括向输入的电子邮件ID发送标准响应，并根据响应机制中描述的操作对用户进行身份验证。这是用于确保验证“使用中”电子邮件ID的第二个需求的最广泛使用的机制。这确实涉及到从后端服务器实现的往返，并且不是一个直接的单屏幕实现，但是，我们不能放弃这一点。

The first requirement, stems from the need that the developers do not want totally "non e-mail like" strings to pass as an e-mail. This typically involves blanks, strings without "@" sign or without a domain name. Given the punycode representations of the domain names, if one needs to enable domain validation, they need to engage in full-fledged implementation that ensures a valid domain name. Thus, given the basic nature of requirement in this regard, validating for "<something>@<something>.<something>" is the only apt way of satisfying the requirement.

一个典型的正则表达式可以满足这个要求: ^ ^ @ \ [s] + @ ^ @ \ [s] + [^ @ \ s]。+ $ 上面的正则表达式遵循大多数编程语言都广泛遵循的标准Perl正则表达式标准。验证语句是: <除空格和“@”符号>之外的任何东西@<除空格和“@”符号>之外的任何东西。<除空格、@符号和点>之外的任何东西

对于那些想要更深入地了解更相关的实现的人，他们可以遵循以下验证方法。 <电子邮件本地部分>@<域名>

对于<电子邮件本地部分> -遵循“通用验收指导小组”- UASG-026的指导方针 对于<域名>，您可以使用标准库遵循任何域验证方法，这取决于您的编程语言。关于该主题的最新研究，请参考文档UASG-018A。

那些有兴趣了解在实施国际化电子邮件解决方案时可能遇到的整体流程、挑战和问题的人，也可以通过以下rfc:

RFC 6530(国际化电子邮件概述和框架) RFC 6531(国际化电子邮件的SMTP扩展名) RFC 6532(国际化邮件头) RFC 6533(国际化交付状态和处置通知) RFC 6855 (IMAP支持UTF-8) RFC 6856(邮局协议版本3 (POP3)支持UTF-8) RFC 6857(国际化电子邮件消息的发送后消息降级) RFC 6858(简化POP和IMAP降级国际化电子邮件)。