我有。我对这个主题一直很安静了很长时间。现在，我感到不得不终于抓住这个愤怒的腹泻。如果您是网络开发人员（并且阅读本文的大多数人都是网络开发人员），那么为了爱的所有圣洁，请 stahhp 筛选电子邮件字段相对于一组“批准”的顶级域（TLDS）。

您可能会认为您的超级发音电子邮件验证非常聪明。您可能会认为您正在强迫用户输入“有效”电子邮件地址。但是我已经看到这是错误的 SOOOOOO 很多次，至此，我敢打赌，您很有可能会搞砸它 - 并惹恼您的某些用户。<<<<<<<<<<<< br>

历史

几乎一旦您开始学习Web开发，您还会了解到应该验证用户输入。理想情况下，您正在验证后端和前端的这些输入。 （因为向服务器提交表单很笨拙，所以只是把所有东西都吐给您，因为某些东西看起来“正确”。）

，即使前端验证仅是方程式的一半，是 可以通过在浏览器中立即提供有关don'的字段的立即反馈来提供给用户的价值。 T通过召集。要警告用户所需的字段是空的，或者给定输入太短/很长，这很重要。但是，只要我一直这样做（四分之一世纪），正确验证电子邮件字段一直是一个挑战。

最初，电子邮件验证非常简单。有时是用正则表达式完成的。有时是通过更多的“手动”检查完成的。但是基本验证是这样的：

1. 确保电子邮件地址中没有无效字符。 （例如：版权标记-©。没有包含©的有效电子邮件地址。）
   

2. 确保即使允许的“特殊”字符也不会重复。 （例如：.在电子邮件地址中是可以接受的，并且常用 - 但是没有有效的电子邮件地址包含..。）
   

3. 确保电子邮件地址中有一个 - 和 一个-@字符 - 并且@字符的两边都有非空字符串。
   

4. 确保@字符右侧的部分至少包含一个.字符。 （之后的最后一个.字符右侧的部分假定为tld。）
   

5. 确保电子邮件地址的TLD为“有效”。
   

但是，正是最后引起了各种问题...

我记得我在电子邮件验证中看到的早期正则表达式。他们通常在最后一个.之后拿走了所有内容，并根据“已知” tlds的列表对其进行了检查。而且，至少有一段时间，这是……可行的。因为有一个有限的静态 - 有效tlds的列表。

在“早期”中，几乎所有有效的电子邮件以.com或.net或.edu或.gov或.gov或.org或任何特定国家特定的TLD（例如.uk）结束。因此，大多数电子邮件验证脚本都试图检查电子邮件地址的最后一部分，以这些“已知良好” TLDS。

TLD繁荣

但是，如今，有效的，工作 tlds的巨大扩散与像.com或.net这样的旧坚定者无关。您的网站可以具有完美的有效/功能性TLD，例如.pizza或.health或.voyage。当然，如果您的网络存在可以使用这些tld，那么您的电子邮件地址也可能使用这些TLD。

授予的所有网站中的绝大多数（因此，所有电子邮件地址）仍然以“ common” tld之类的结尾，例如.com或.net或.org。但是每天都有新的网站 - 和新的电子邮件地址 - 上网 使用这些常见的tlds。

仍然有许多网站试图严格验证您的电子邮件地址 - 他们试图通过根据“已知良好” TLD列表来检查TLD来做到这一点。出现问题是因为这些网站的几乎无对确保其“已知善良” tld的列表确实与真实的实际列表真正最新 ，可用的实时tld。

我自己的私人地狱

我的简历网站位于https://adamdavis.codes。我的电子邮件地址也由Adamdavis€Codes托管。显然，它没有“常见” tld。我这样做的原因有两个：

1. 当我第一次设置网站时，Adamdavis.com根本不可用。
   

2. 即使Adamdavis.com 可用，我也对adamdavis.codes感到非常满意。我是一个编码器。 .codes TLD是我简历的理想选择。因此，只有在同一tld下有一个电子邮件地址才有意义。
   

这并不是我唯一涉足“罕见” tlds的时间。我的最新项目是https://paintmap.studio。我以前也有一个带有.voyage TLD的电子邮件地址。

当我第一次开始使用这些“罕见” tlds时，我会发现我的电子邮件地址经常被各种在线表格拒绝。该表格会给我带来验证错误，指出我的电子邮件地址不是“有效的”。但是...它绝对 是 有效！

公平地说，i 发现，像我的个人Adamdavis€Codes地址一样，电子邮件地址确实正在“通过”如今的更多表单验证。但是，我正试图提交在线表格仍然非常快 - 但是当网站告诉我我完美的电子邮件地址是……“无效”。

您知道网站拒绝我的完美播放电子邮件地址时会发生什么？好吧，如果我要完成的活动以任何方式可选，我简单地退出了该过程。我放弃的购物车只有数百美元，仅仅是因为Jank-Ass网站声称我的电子邮件地址无效。我出于相同的原因放弃了工作申请。

是的，我确实有一个Gmail帐户。在那些我感到被迫完成过程的情况下，我用我的Gmail地址切换了我喜欢的.codes电子邮件地址。但是，除非我觉得我只是必须完成该过程，否则我不会这样做。无论我是放弃该过程还是切换到我的Gmail地址，整个失败的验证过程都使我感到不安。

当“新” TLD首次开始推出时，我发现这个过程很烦人 - 但可以理解。很容易看出如何支持这些功能的Web团队根本无法与最新的TLD规格保持最新状态。但今天？在2023年??对不起，但这是完全不可接受的。

您认为您正在取得什么成就？

frontend（即JavaScript）表单验证在大多数情况下是a good 的东西。您要做的最后一件事是给用户一份表格，该表格几乎允许提交任何完全鲜艳的价值。但是，严格验证会破坏用户体验。在某些情况下，它可以完全疏远您的用户。

以电子邮件验证为例。当我以表格实施电子邮件地址验证时，我倾向于使用此NPM软件包：https://www.npmjs.com/package/@toolz/looks-like-email。 （提示：i word 此软件包。）它确实做标题所暗示的：它告诉我给定的值看起来像 一个电子邮件地址。

不，这不是旨在严格过滤 可能是虚假电子邮件的任何潜在字符串的酸性测试。它不会试图与所有已知良好的TLD相匹配。当我使用此软件包时，某人 May 仍然可能会输入无效的电子邮件地址。你知道吗？在大多数情况下，我不在乎。

我知道我们通常将第一和last名称字段设置为所需 - 这意味着它们必须包含某种的值类型。但是，如果有人只说出他们在名字领域中的第一个缩写，那真的是受伤有人吗？真的会崩溃吗？或者只是一个过于经常的前端开发人员（单独决定），每个用户必须 输入一个超过一定长度的姓氏？

另一个很好的例子是电话字段。我已经看到越来越多的电话字段试图严格限制您可以输入的纯数值。但是，如果您没有 Direct 电话线会怎样？如果您的电话号码看起来像这样，会发生什么：

+1 904-555-1234 ext. 42

是的，我已经看过一些在线表单，这些表格提供了一个单独的扩展字段。但大多数都不。因此，如果接触此人的唯一方法是输入延长，而则不让他们输入扩展名，则强迫他们只输入”主要“数字 - 可能将呼叫者连接到公司的主线 - 答案的人甚至可能不知道如何将呼叫转发给填写在线表格的用户。

+1 904-555-1234 (ONLY BEFORE 5PM)

这里的主要教训是：不要可爱。是的，您应该努力提供有用的表单验证。但是，如果您因为确定自己已经阻止了每个可能的边缘案例 ...很有可能您也阻止了一些有效的输入。当您阻止有效输入时，您会承担疏远用户的严重风险。

另外，如果某人在给定字段中输入“不良”数据，请尝试现实地存在什么风险。当然，您可能会相信电话号码只能是数字。但是，如果您允许在该字段中允许字母并将其存储在后端时，这真的是 吗？