JQuery.validate() 将域格式无效的电子邮件地址传递为有效
JQuery.validate() passes email addresses with invalid domain format as valid
JQuery.Validate 用于验证电子邮件地址的内置方法如下所示:
return this.optional( element ) || /^[a-zA-Z0-9.!#$%&'*+\/=?^_`{|}~-]+@[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?(?:\.[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?)*$/.test( value );
此正则表达式将如下所示的电子邮件地址传递为有效
testMail@test
在我的模型中,我使用数据类型属性 [EmailAddress]
生成以下正则表达式:
^((([a-z]|\d|[!#$%&'\*\+\-\/=\?\^_`{\|}~]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])+(\.([a-z]|\d|[!#$%&'\*\+\-\/=\?\^_`{\|}~]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])+)*)|((\x22)((((\x20|\x09)*(\x0d\x0a))?(\x20|\x09)+)?(([\x01-\x08\x0b\x0c\x0e-\x1f\x7f]|\x21|[\x23-\x5b]|[\x5d-\x7e]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])|(\([\x01-\x09\x0b\x0c\x0d-\x7f]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF]))))*(((\x20|\x09)*(\x0d\x0a))?(\x20|\x09)+)?(\x22)))@((([a-z]|\d|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])|(([a-z]|\d|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])([a-z]|\d|-|\.|_|~|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])*([a-z]|\d|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])))\.)+(([a-z]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])|(([a-z]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])([a-z]|\d|-|\.|_|~|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])*([a-z]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])))\.?$
这是正确的正则表达式,它还验证了电子邮件地址的域部分,例如:
testMail@test.correct
将有效,像第一个示例一样格式的电子邮件地址现在将无效。
发生的事情是,当使用 jQuery.validate 的正则表达式(默认的)发布表单时,它会将表单设置为有效,即使电子邮件地址格式为第一个示例。发布的表单数据被传递到服务器端,服务器端检测到无效的电子邮件格式并抛出错误。这是 validate() 插件的已知错误吗?因为我似乎无法在 bugreport 部分 (http://bugs.jquery.com/search?ticket=on&q=validate+email&page=3&noquickjump=1) 中找到与此相关的票证。我还尝试将 jQuery.validate 从 1.13 更新到 1.14,但两个版本的正则表达式相同。
无论如何,我找到的解决方案是通过添加自定义规则来扩展验证插件:
var validCustomRegex = /^((([a-z]|\d|[!#$%&'\*\+\-\/=\?\^_`{\|}~]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])+(\.([a-z]|\d|[!#$%&'\*\+\-\/=\?\^_`{\|}~]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])+)*)|((\x22)((((\x20|\x09)*(\x0d\x0a))?(\x20|\x09)+)?(([\x01-\x08\x0b\x0c\x0e-\x1f\x7f]|\x21|[\x23-\x5b]|[\x5d-\x7e]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])|(\([\x01-\x09\x0b\x0c\x0d-\x7f]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF]))))*(((\x20|\x09)*(\x0d\x0a))?(\x20|\x09)+)?(\x22)))@((([a-z]|\d|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])|(([a-z]|\d|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])([a-z]|\d|-|\.|_|~|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])*([a-z]|\d|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])))\.)+(([a-z]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])|(([a-z]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])([a-z]|\d|-|\.|_|~|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])*([a-z]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])))\.?$/;
var custEmailValidationMessage;
$.validator.addMethod('customemail', function (value, element) {
custEmailValidationMessage = $(element).data("val-regex");
return this.optional(element) || validCustomRegex.test(value);
}, custEmailValidationMessage);
然后调用我的自定义函数而不是默认电子邮件:
$(form).validate({somecode});
$(form).find("input[type='email']").each(function () {
var requiredMessage = $(this).data("validationmessage");
var invalidFormatMessage = $(this).data("val-regex");
var $self = $(this);
$self.rules('add', {
customemail: true,
messages: {
required: requiredMessage,
email: invalidFormatMessage
}
});
});
对于这个问题,这是一个可以接受的解决方案吗?我问的原因是我检查了这个问题:override jquery validate plugin email address validation
在汤姆接受的回答中,他说他不会这样做,但没有说明为什么他不会这样做。那么为什么要避免这样的解决方案呢?我只是想知道这里的 "best practice" 是什么。
Is this a known bug for the validate() plugin?
没有.
这不是错误。
jQuery Validate v1.12.0 Changelog : "方法:更新电子邮件以使用HTML5
正则表达式,删除 email2 方法
Validate Format of an Email Address using Jquery.validate.js
How does HTML5 input type email works without top level domain name
参见 http://en.wikipedia.org/wiki/Email_address#Domain_part
有效电子邮件地址的示例。
Is this an acceptable solution for this problem? The reason why I'm asking is that I checked this question : override jquery validate plugin email address validation and in the accepted answer by Tom, he says that he would'nt do this, but not why he would'nt. So why should one avoid a solution like this? I'm just curious regarding whats the "best practice" here.
是.
每当插件内置的方法无法按您的意愿执行时,您只需创建自己的自定义方法并使用它即可。这样做绝对没有错,这正是您可以使用 .addMethod()
方法的原因。
我的猜测是 Tom 只是意味着他会坚持使用插件中内置的电子邮件验证(就像我一样)而不是创建一个新的;我几乎可以肯定他并不是说一般来说创建新 rules/methods 有什么问题。
JQuery.Validate 用于验证电子邮件地址的内置方法如下所示:
return this.optional( element ) || /^[a-zA-Z0-9.!#$%&'*+\/=?^_`{|}~-]+@[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?(?:\.[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?)*$/.test( value );
此正则表达式将如下所示的电子邮件地址传递为有效
testMail@test
在我的模型中,我使用数据类型属性 [EmailAddress]
生成以下正则表达式:
^((([a-z]|\d|[!#$%&'\*\+\-\/=\?\^_`{\|}~]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])+(\.([a-z]|\d|[!#$%&'\*\+\-\/=\?\^_`{\|}~]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])+)*)|((\x22)((((\x20|\x09)*(\x0d\x0a))?(\x20|\x09)+)?(([\x01-\x08\x0b\x0c\x0e-\x1f\x7f]|\x21|[\x23-\x5b]|[\x5d-\x7e]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])|(\([\x01-\x09\x0b\x0c\x0d-\x7f]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF]))))*(((\x20|\x09)*(\x0d\x0a))?(\x20|\x09)+)?(\x22)))@((([a-z]|\d|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])|(([a-z]|\d|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])([a-z]|\d|-|\.|_|~|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])*([a-z]|\d|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])))\.)+(([a-z]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])|(([a-z]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])([a-z]|\d|-|\.|_|~|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])*([a-z]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])))\.?$
这是正确的正则表达式,它还验证了电子邮件地址的域部分,例如:
testMail@test.correct
将有效,像第一个示例一样格式的电子邮件地址现在将无效。
发生的事情是,当使用 jQuery.validate 的正则表达式(默认的)发布表单时,它会将表单设置为有效,即使电子邮件地址格式为第一个示例。发布的表单数据被传递到服务器端,服务器端检测到无效的电子邮件格式并抛出错误。这是 validate() 插件的已知错误吗?因为我似乎无法在 bugreport 部分 (http://bugs.jquery.com/search?ticket=on&q=validate+email&page=3&noquickjump=1) 中找到与此相关的票证。我还尝试将 jQuery.validate 从 1.13 更新到 1.14,但两个版本的正则表达式相同。
无论如何,我找到的解决方案是通过添加自定义规则来扩展验证插件:
var validCustomRegex = /^((([a-z]|\d|[!#$%&'\*\+\-\/=\?\^_`{\|}~]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])+(\.([a-z]|\d|[!#$%&'\*\+\-\/=\?\^_`{\|}~]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])+)*)|((\x22)((((\x20|\x09)*(\x0d\x0a))?(\x20|\x09)+)?(([\x01-\x08\x0b\x0c\x0e-\x1f\x7f]|\x21|[\x23-\x5b]|[\x5d-\x7e]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])|(\([\x01-\x09\x0b\x0c\x0d-\x7f]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF]))))*(((\x20|\x09)*(\x0d\x0a))?(\x20|\x09)+)?(\x22)))@((([a-z]|\d|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])|(([a-z]|\d|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])([a-z]|\d|-|\.|_|~|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])*([a-z]|\d|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])))\.)+(([a-z]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])|(([a-z]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])([a-z]|\d|-|\.|_|~|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])*([a-z]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])))\.?$/;
var custEmailValidationMessage;
$.validator.addMethod('customemail', function (value, element) {
custEmailValidationMessage = $(element).data("val-regex");
return this.optional(element) || validCustomRegex.test(value);
}, custEmailValidationMessage);
然后调用我的自定义函数而不是默认电子邮件:
$(form).validate({somecode});
$(form).find("input[type='email']").each(function () {
var requiredMessage = $(this).data("validationmessage");
var invalidFormatMessage = $(this).data("val-regex");
var $self = $(this);
$self.rules('add', {
customemail: true,
messages: {
required: requiredMessage,
email: invalidFormatMessage
}
});
});
对于这个问题,这是一个可以接受的解决方案吗?我问的原因是我检查了这个问题:override jquery validate plugin email address validation 在汤姆接受的回答中,他说他不会这样做,但没有说明为什么他不会这样做。那么为什么要避免这样的解决方案呢?我只是想知道这里的 "best practice" 是什么。
Is this a known bug for the validate() plugin?
没有.
这不是错误。
jQuery Validate v1.12.0 Changelog : "方法:更新电子邮件以使用HTML5 正则表达式,删除 email2 方法
Validate Format of an Email Address using Jquery.validate.js
How does HTML5 input type email works without top level domain name
参见 http://en.wikipedia.org/wiki/Email_address#Domain_part 有效电子邮件地址的示例。
Is this an acceptable solution for this problem? The reason why I'm asking is that I checked this question : override jquery validate plugin email address validation and in the accepted answer by Tom, he says that he would'nt do this, but not why he would'nt. So why should one avoid a solution like this? I'm just curious regarding whats the "best practice" here.
是.
每当插件内置的方法无法按您的意愿执行时,您只需创建自己的自定义方法并使用它即可。这样做绝对没有错,这正是您可以使用 .addMethod()
方法的原因。
我的猜测是 Tom 只是意味着他会坚持使用插件中内置的电子邮件验证(就像我一样)而不是创建一个新的;我几乎可以肯定他并不是说一般来说创建新 rules/methods 有什么问题。