无人谈论的问题
说实话：电子邮件验证听起来很简单，但它是一个技术陷阱，即使是经验丰富的开发人员也会陷入困境。
到底发生了什么？
假设您正在构建一个注册表单。你的第一直觉？在电子邮件字段中添加正则表达式。糟糕的举动。
实际有效的奇怪电子邮件
1
2
3
4
5
6
7
# 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) 攻击。
1
2
3
4
5
6
7
def dangerous_regex_check(user_input):
# this regex can destroy your servers 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
攻击者可以精心设计输入，使您的验证函数陷入停顿。
更明智的方法
实际有效的基本验证
1
2
3
4
5
6
7
8
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
)
真正的解决方案：验证
基本语法检查 发送验证链接 让用户证明电子邮件有效1
2
3
4
5
6
7
8
9
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
不要编写自己的正则表达式，而是使用经过测试的库：
python：电子邮件验证器 javascript：validator.js java：apache commons 验证器更好的验证类
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
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
底线
电子邮件验证并不是要创建一个牢不可破的堡垒。这是关于：
让真实用户进入 确保您的系统安全 不要让事情变得复杂要点
忘记复杂的正则表达式 使用经过验证的库 发送验证邮件 用户友好想要我进一步分解其中的任何部分吗？
顺便说一句，我正在开发一个无限制的上下文工具，您可以在其中使用您喜欢的法学硕士，而无需一次又一次地提供上下文。
请检查一下，它对开发者完全免费。
以上就是为什么经验丰富的开发人员从不使用正则表达式进行电子邮件验证？的详细内容，更多请关注php中文网其它相关文章！