如何更正拼写错误的电子邮件地址域？
Sometimes users misspelled their email domain and hence they enter wrong email address.
Eg. [email protected] rather than [email protected]
Has anybody thought about this before? Can anybody suggest how to handle this type of mistakes?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（11）
2023更新
@hashim-aziz指出MailCheck已被放弃一段时间，并建议EmailSpellChecker.js。
（链接到他们的答案）
我仍然相信Javascript“你确定吗？”解决方案是为用户提供最佳体验，然后是确认电子邮件。当您发送确认电子邮件时，请附上“不，不是我！”选项也。使用您的网站分析来自定义您的建议列表。
上一个答案
当这个问题被问到时它并不存在，但我推荐 MailCheck 它会自动建议更正输入的电子邮件。它已被大公司成功使用。
2023 Update
@hashim-aziz points out that MailCheck has been abandoned for some time, and recommends EmailSpellChecker.js.
(Link to their answer)
I still believe a Javascript "Are you sure?" solution is the best experience for the user, followed by a confirmation email. When you send a confirmation email, please include a "Nope, not me!" option too. Use your site analytics to customize your suggestion list.
Previous Answer
It didn't exist when this question was asked, but I recommend MailCheck which auto-suggests corrections to entered emails. It's used successfully by large companies.
您通常会向给定的地址发送一封确认电子邮件，并且仅在单击该电子邮件中的链接后才继续。
没有其他好的方法来处理这个问题 - 无法确定
gmial.com是否是一个拼写错误，因为它是一个有效的域。You would usually send a confirmation E-Mail to the address given, and proceed only if a link in that E-Mail has been clicked.
There is no other good way to deal with this - it's impossible to tell for sure whether
gmial.comis a typo or not, seeing as it's a valid domain.创建常见电子邮件域名列表：
当用户输入电子邮件地址时，取输入地址的域名并取列表之间的 Levenstein 距离。如果距离为 1（或可能最大为 2），则要求用户确认这就是他们想要的电子邮件地址。
Create a list of common email domain names:
When a user enters an email address, take the domain name of the entered address and take the Levenstein distance between your list. If the distance is 1 (or maybe up to 2) then ask the user to confirm that's the email address they meant.
在我看来，针对一般情况提出通用解决方案几乎是不可能的。
话虽这么说，最常见的拼写错误是互换两个相邻的字母。
因此，您可能想要检查最大的网站 gmail、yahoo 等的字符内容；在此基础上，如果原始名称与 gmail 等不匹配，则建议使用替代拼写
您不能假设您发现的拼写错误，这就是确认邮件的用途。
In my opinion it is bordering on impossible to come up with a generic solution for the generic case.
That being said, the most common typo is to interchange two adajcent letters.
So you might want to check for character content for the largest sites gmail, yahoo and what have you; Based on that suggest an alternative spelling if the original does not match gmail etc.
You cannot assume the spelling you find is in error, that is what confirmation mails are for.
有趣的是，该网址确实存在 http://www.gmial.com
事实上，您很难知道这是一个错误还是只是一个“奇怪”的域。看看 Google API，因为当你在 Google 中输入错误的内容时，他们会建议你“你的意思是……”
祝你好运
阿诺
The funny thing is that the url does exist http://www.gmial.com
In fact it would be very difficult for you to know if it's a mistake or just a "strange" domain. Look at the Google API's because when you type something wrong in Google they propose you "did you mean...."
good luck
Arnaud
在我们的表单中，我们使用了多种技术的组合。虽然不良数据仍然可能被漏掉，但几率大大降低。
首先是做一个常用的简单格式化正则表达式 - 只要确保它符合 RFC 即可。如果失败，此时最好向用户提供确认表单，因为他们可能会在修复此问题时为您捕获其他错误。
下一部分是检查域的 TLD 部分。由于所有 TLD 都是已知的，因此使用一些正则表达式测试来扫描拼写错误相对容易。只需将所有当前 TLD 的列表保存在某个表中，并根据需要不时更新（请注意，在处理国际 TLD 时，此列表可能会变得复杂。如果您只处理美国流量，则规则会很复杂）更容易，这是您可以过滤掉的其他内容，例如，如果您销售仅在美国提供的服务，则在表单提交时过滤掉国际电子邮件是有意义的，所以这对我们有用）。 。
第三是执行 @npclaudiu 建议的操作 - 扫描域部分中大牌邮件主机（gmail、hotmail、yahoo 等）的常见拼写错误，如果检测到可能的命中，则向用户提供确认表单。 （您输入的[email protected]，您是指hotmail.com吗？）
如果您完成了这些步骤，那么您可以执行以下建议的 MX 查找@symcbean。
最后，如果所有这些都成功，那么有一种方法（但我还没有测试过）可以与远程 SMTP 主机进行通信以查看邮箱是否存在。我们即将开始自己测试这一点。我在这里找到了这样的操作方法：
http://www.webdigi.co.uk/blog/2009/how-to-check-if-an-email-address-exists-without-sending-an-email/
In our forms we're using a combination of techniques. While bad data can still slip through, the chances are vastly reduced.
First is to do a simple formatting regex that is commonly available - just be sure it's RFC-compliant. If this fails, it's good to offer the user a confirmation form at this point, because they may catch other errors for you while fixing this problem.
The next part is to check the TLD part of the domain. Since all TLDs can be known, these are relatively easy to scan for misspellings using some regex tests. Just keep a list of all current TLDs in a table somewhere and update it form time to time as needed (mind you, this list can get complex when dealing with international TLDs. If you're only dealing with US traffic, the rules are much easier, and that's something else you can filter out. For example, if you're selling a service only available in the US, it would make sense to filter out international emails at form submission time. We are, so this works for us).
Third is to do something like what @npclaudiu suggested - scan for common misspellings of big-name mail hosts (gmail, hotmail, yahoo, etc) in the domain part and if a possible hit is detected, offer a confirmation form to the user. (You entered [email protected], did you mean hotmail.com?)
If you get through those steps, then you can do the MX lookup suggested by @symcbean.
Finally, if all of that succeeds, there is a method (but I've not yet tested it) for communicating with the remote SMTP host to see if the mailbox exists. We're about to begin testing this ourselves. I found the how-to for such here:
http://www.webdigi.co.uk/blog/2009/how-to-check-if-an-email-address-exists-without-sending-an-email/
电子邮件拼写检查器是alttag中提到的Mail Check JavaScript库的继承者 2013 年的答案。MailCheck 现在是 放弃并且有几个重大错误：
甚至自述文件中链接的域名也已即将过期。
据 Email Spell Checker 的开发者介绍，相对于 mailcheck.js 的改进包括：
Email Spell Checker is the successor to the Mail Check JavaScript library mentioned in alttag's answer from 2013. MailCheck is now abandoned and has several significant bugs in it:
Even the domain name linked on the README has been left to expire.
According to the developer of Email Spell Checker, improvements over mailcheck.js include:
您无法以自动更正拼写错误的电子邮件域名的方式提供此功能，因为您假设无效的名称实际上是有效的。您应该期望任何内容都作为电子邮件地址域名输入。
我建议，如果您要创建注册表单，请为用户提供一个下拉列表，其中包含您知道的所有可能的域名，以便他可以从中进行选择。
希望这有帮助。
You can not provide this functionality in a way that you auto correct the misspelled email domain names, because the name which you are assuming to be invalid, would be valid. you should expect anything to be entered as a email address domain name.
I would suggest, if you are creating a signup form, you provide user with a dropdown having all possible domain names which you are aware of so that he can make a selection from that.
Hope this helps.
您可以在数据库中创建流行电子邮件域（gmail.com、yahoo.com、ymail.com 等）的列表，并验证用户根据此列表输入的电子邮件地址，以及该域是否类似于对于这些域之一，您应该显示警告并允许用户在必要时更正它，而不是自动更正它。为了将输入的域与列表中的域进行比较，您可以使用一种类似于 SQL Server 中
soundex函数中使用的算法，该算法根据一个单词是否发音来匹配单词就像第二个一样。编辑：您可以在此处找到 SOUNDEX 函数的更多详细信息。
You could create a list of popular e-mail domains (gmail.com, yahoo.com, ymail.com, etc) in your db and validate the e-mail address that the user inputs against this list, and if the domain resembles with one of these domains, you should show a warning and allow the user to correct it if necessary, not auto correct it. And to compare the domain entered with the domains in your list, you might use an algorithm like the the one used in the
soundexfunction in SQL Server, that matches words based on if one word sounds like the second.Edit: you can find more details the SOUNDEX function here.
如前所述，自动假设某人输错了电子邮件并不是一个好主意。更好的方法是实现一个小的 JavaScript 函数，检查电子邮件的域是否可能输入错误并警告用户，而不是从一开始就假设他们是错误的。
给我一点时间来创建一个小模型。
编辑：好的，所以可能超过一分钟了。看看 http://jsbin.com/iyaxuq/8/edit并亲自了解 javascript 如何帮助防止常见的输入错误。尝试使用以下电子邮件：[电子邮件受保护]、[电子邮件受保护]，[电子邮件受保护]（hotmail 拼写错误），以及 [电子邮件受保护]。
注意：我使用了惰性正则表达式来验证电子邮件。不要依赖它（或者就此而言，大多数正则表达式）来构建真正的应用程序。
As mentioned before, it is not a good idea to automatically assume that someone has mistyped an email. A better approach would be to implement a little javascript function that checks if the domain of the email was possibly mistyped and alert the user instead of assuming they were wrong from the start.
Give me a minute to create a little mockup.
EDIT: OK, so maybe it was more than a minute. Take a look at http://jsbin.com/iyaxuq/8/edit and see for yourself how javascript can help prevent common typing errors. Try emails like: [email protected], [email protected], [email protected] (typo of hotmail), and [email protected].
Note: I used a lazy regex to validate the email. Don't rely on it (or for that matter, most regexes) for a real app.
尝试自动纠正不良数据是一种非常危险的做法。最终，只有用户才能提供正确的数据。然而，关于格式化电子邮件地址有严格的规则 - 正则表达式检查可以在 javascript 中运行（或使用具有相同正则表达式语法的 preg 函数） - 但请注意，互联网上有很多声称可以解决问题的正则表达式的不良示例问题。
这应该是 RFC2822 ADDR_SPEC 验证器的相当完整的实现：
但是在实践中我发现这已经足够了：
然后，在服务器端，您可以执行 MX 查找，以验证提供的域不仅满足格式要求，而且作为电子邮件接收站点存在。
这并不能证明指定的邮箱存在于该站点，也不能证明它正在接受电子邮件 - 最终您需要向该地址发送一封电子邮件，其中包括点击返回链接/密码，以确定该电子邮件地址是否有效。
更新
虽然，正如此处投票最高的答案所说，验证 ADDR_SPEC 的最佳方法是将令牌发送到要通过网络提交回来的地址，但这并没有多大帮助，如果数据不是来自控制邮箱的人，即使他们这样做，该操作也与主要交互无关。进一步考虑的是，今天有效的电子邮件地址明天可能就不再有效。
使用正则表达式（和 MX 查找）仍然是向用户提供即时反馈的好主意，但对于完整的解决方案，您还需要 监控退回邮件。
Trying to automate correction of bad data is a very dangerous practice. Ultimately, only the user can provide the correct data. However there are strict rules about formatting an email address - a regex check can be run in javascript (or using the preg functions with the same regex syntax) - but note that there are a lot of bad examples on the internet of regexes claiming to solve the problem.
This should be a fairly complete implementation of an RFC2822 ADDR_SPEC validator:
However in practice I find this to be adequate:
Then, serverside, you can do an MX lookup to verify that the domain provided not only meets the formatting requirements but exists as an email receiving site.
This does not prove that the named mailbox exists at that site, nor that it is accepting emails - ultimately you'd need to send an email to that address including a click back link / password to establish whether the email address is valid.
Update
While, as the top voted answer here says, the best way to validate an ADDR_SPEC is to send a token to the address to be submitted back via the web, this is not of much help if the data is not coming from the person whom controls the mailbox, and the action is dissociated from the primary interaction even when they do. A further consideration is that an email address which is valid today might not be tomorrow.
Using a regex (and an MX lookup) is still a good idea to provide immediate feedback to the user, but for a complete solution you also need to monitor the bounces.