无人谈论的问题
说实话：电子邮件验证听起来很简单，但它是一个技术陷阱，即使是经验丰富的开发人员也会陷入困境。
到底发生了什么？
假设您正在构建一个注册表单。你的第一直觉？在电子邮件字段中添加正则表达式。糟糕的举动。
实际有效的奇怪电子邮件
# these are all technically valid emails!
valid_emails = [
'"very.unusual.@.unusual.com"',
'admin@mailserver1',
'user+tag@gmail.com',
'postmaster@[123.123.123.123]'
]
大多数正则表达式引擎都会因这些而窒息。
为什么？
电子邮件标准太疯狂了。
大多数开发人员会惊讶地发现，根据 rfc 5322，这些实际上是技术上有效的电子邮件地址。该规范允许：
- 引用本地部分
- 括号内的评论
- 嵌套评论
- 当地的特殊字符
- 多个域标签
错误验证的隐性成本
1. 失去真实用户
严格的正则表达式可能会拒绝完美的电子邮件地址。想象一下因为潜在客户的电子邮件看起来“奇怪”而拒绝他们，就像有：
- 加上地址 (user tags@gmail.com)
- 非常规的域结构
- 国际字符集
- 合法但复杂的命名约定
你的产品团队会非常不高兴，更重要的是；销售真的会很生气。
2.redos攻击
使用回溯的正则表达式引擎容易受到正则表达式拒绝服务 (redos) 攻击。
def dangerous_regex_check(user_input):
# this regex can destroy your server's performance
evil_pattern = r'^(a+)+b$'
return re.match(evil_pattern, user_input)
# just 30 characters can crash your system
malicious_input = 'a' * 30 + 'b'
攻击者可以精心设计输入，使您的验证函数陷入停顿。
更明智的方法
实际有效的基本验证
def smart_email_check(email):
"""quick and dirty email sanity check"""
return (
email and
'@' in email and
'.' in email.split('@')[1] and
len(email) <= 254 # email length limit
)
真正的解决方案：验证
- 基本语法检查
- 发送验证链接
- 让用户证明电子邮件有效
def validate_email(email):
if not basic_email_check(email):
return false
# send verification token
token = generate_unique_token()
send_verification_email(email, token)
return true
面向真正开发人员的 pro tools
不要编写自己的正则表达式，而是使用经过测试的库：
更好的验证类
class EmailValidator:
@staticmethod
def validate(email):
"""
Smart email validation
- Quick syntax check
- Verify deliverability
"""
try:
# Use a smart library
validate_email(
email,
check_deliverability=True
)
return True
except EmailInvalidError:
return False
底线
电子邮件验证并不是要创建一个牢不可破的堡垒。这是关于：
- 让真实用户进入
- 确保您的系统安全
- 不要让事情变得复杂
要点
- 忘记复杂的正则表达式
- 使用经过验证的库
- 发送验证邮件
- 用户友好
正确做到这一点的开发人员可以避免无数的麻烦。
想要我进一步分解其中的任何部分吗？
顺便说一句，我正在开发一个无限制的上下文工具，您可以在其中使用您喜欢的法学硕士，而无需一次又一次地提供上下文。
请检查一下，它对开发者完全免费。
