匹配无效电子邮件地址的javax.validation.constraints.Email [英] javax.validation.constraints.Email matching invalid email address

查看:1394
本文介绍了匹配无效电子邮件地址的javax.validation.constraints.Email的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我有一个User实体,该实体具有用@Email

I have a User entity having email property annotated with @Email

@Email
private String email;

我在我的Controller类上使用了@Valid(javax.validation.Valid)批注.问题是控制器验证程序正在传递无效的电子邮件.示例:
pusp @ 1 -显然这是一个无效的电子邮件地址
pusp @ fake
我注意到的模式是,@Email只需要 sometext @ text ,它不需要扩展名(.com/org等).这是预期的行为吗?我需要为@Email(regex="")

I am using @Valid (javax.validation.Valid) annotation on my Controller class. The issue is that the controller validator is passing the invalid emails. Example:
pusp@1 - obviously this is an invalid email address
pusp@fake
The pattern I noticed is, the @Email only want sometext@text, it don't care for the extensions(.com/org etc). Is it the expected behaviour? Do I need to pass my own regex implementation for @Email(regex="")

推荐答案

根据验证者,不带.的电子邮件可能被视为有效.
一般来说,验证程序的实现(这里可能是Hibernate Validator)对电子邮件的限制不是很严格.
例如, org.hibernate.validator.internal.constraintvalidators.AbstractEmailValidator javadoc状态:

A email without . may be considered as valid according to the validators.
In a general way, validator implementations (here it is probably the Hibernate Validator) are not very restrictive about emails.
For example the org.hibernate.validator.internal.constraintvalidators.AbstractEmailValidator javadoc states :

有效电子邮件的规范可以在 RFC 2822 <中找到/a>和一个 可以提出匹配所有有效电子邮件的正则表达式 按照规范的地址. 但是,正如本文讨论的那样 实施100%兼容的电子邮件不一定实用 验证器.此实现是一个权衡,试图匹配大多数 电子邮件,而忽略例如带有双引号的电子邮件或 评论.

The specification of a valid email can be found in RFC 2822 and one can come up with a regular expression matching all valid email addresses as per specification. However, as this article discusses it is not necessarily practical to implement a 100% compliant email validator. This implementation is a trade-off trying to match most email while ignoring for example emails with double quotes or comments.

此外,我注意到HTML验证程序在电子邮件中也有类似的情况.

And as a side note, I noticed similarly things with HTML Validator for emails.

因此,我认为您实际遇到的行为是预期的行为.
关于您的问题:

So I think that the behavior that you encounter actually is which one expected.
And about your question :

我需要为@Email(regex =")传递自己的正则表达式实现吗?

的确.如果要使验证更具限制性,您别无选择.
作为替代方案,通过约束组合创建 answer 创建自己的验证器非常有趣,因为它很干燥(您可以重复使用自定义ConstraintValidator每次都没有指定要包含的模式),它会重用@Email ConstraintValidator的好部分":

Indeed. You don't have any other choice if you want to make the validation more restrictive.
As alternative, this answer creating its own validator via a constraints composition is really interesting as it is DRY (you can reuse your custom ConstraintValidator without specified at each time the pattern as it will be included in) and it reuses the "good part" of the @Email ConstraintValidator :

@Email(message="Please provide a valid email address")
@Pattern(regexp=".+@.+\\..+", message="Please provide a valid email address")
@Target( { METHOD, FIELD, ANNOTATION_TYPE })
@Retention(RUNTIME)
@Constraint(validatedBy = {})
@Documented
public @interface ExtendedEmailValidator {
    String message() default "Please provide a valid email address";
    Class<?>[] groups() default {};
    Class<? extends Payload>[] payload() default {};
}

这篇关于匹配无效电子邮件地址的javax.validation.constraints.Email的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆