【问题标题】:Did the Symfony validation rules change with the update?Symfony 验证规则是否随着更新而改变?
【发布时间】:2021-07-04 05:03:10
【问题描述】:

从 Symfony 2.x 更新到 Symfony 4.x 并检查运行后,电子邮件地址的验证规则发生了变化。
在 Symfony 2.x 中,像 "あ@test.co.jp" 这样的非字母数字词被 Symfony 验证排斥,但在 Symfony 4.x 中没有。规则是否随着更新而改变?
另外,有没有办法撤销规则?
使用我自己的验证规则,我担心我以前使用的电子邮件地址可能会在验证中被捕获。
此外,如果您删除“@”,您将收到验证错误消息“不是有效的电子邮件地址”,因此认为验证本身正在工作。

Symfony 2.x 和 Symfony 4.x 通用的验证规范代码

        Mail:
            - NotBlank: ~
            - Email: ~

【问题讨论】:

标签: php symfony validation


【解决方案1】:

基本上 2.1 只是验证您的邮件,没有选择如何验证。

2.5 引入strict 模式 - here is the commit

如您所见,在此更改之前,Symfony 将使用filter_var()FILTER_VALIDATE_EMAIL。更改后,它使用EmailValidator 进行严格模式。

4.1 然后replaced that 使用mode 选项以获得更多粒度。

电子邮件地址的验证是开发人员之间永无止境的争论之一。有些人认为您无法真正以编程方式验证它们,并且您必须始终发送确认电子邮件。其他人则认为,符合 RFC 5322 的编程验证对于实际应用程序来说已经足够了。

Symfony 总是通过电子邮件验证约束的严格选项做出这个选择。如果为 false,则根据简单的正则表达式验证电子邮件地址。如果为 true,则使用 egulias/email-validator 第三方库完成符合 RFC 的验证。

但是,用于验证电子邮件地址的正则表达式过于简单。这就是为什么在 Symfony 4.1 中我们决定开始使用与 HTML5 相同的电子邮件验证。在实践中,我们弃用了 strict 选项,转而使用新的模式选项

我会假设严格模式和使用filter_var 的pre 2.5 方法之间存在一些差异。

如果您需要保留确切的功能,我认为您需要添加一个使用 filter_varcustom constraint - 像这样:

# src/Validator/FilterVarEmail.php
namespace App\Validator;

use Symfony\Component\Validator\Constraint;

/**
 * @Annotation
 */
class FilterVarEmail extends Constraint
{
    public $message = 'Email invalid.';
}

# src/Validator/FilterVarEmailValidator.php
namespace App\Validator;

use Symfony\Component\Validator\Constraint;
use Symfony\Component\Validator\ConstraintValidator;

class FilterVarEmailValidator extends ConstraintValidator
{
    public function validate($value, Constraint $constraint)
    {
        /* @var $constraint \App\Validator\FilterVarEmail */

        if (null === $value || '' === $value) {
            return;
        }

        if (false === filter_var($value, FILTER_VALIDATE_EMAIL)) {
            $this->context
                ->buildViolation($constraint->message)
                ->addViolation()
            ;
        }
    }
}

编辑:也就是说,值得注意的是,电子邮件地址和域名中允许使用特殊字符,因此为了让您的系统能够适应未来,您可能需要对其进行更改以支持这一点。

【讨论】:

  • 感谢您的回答。毕竟发生了变化。是否承认 strict 应该设置为 true 以使其类似于 2.3?
  • @scottie320 不,不幸的是,这不一样。我更新了我的答案,为您提供了更多信息。
  • 谢谢。我很好理解。自定义验证也有效,这正是我想要的。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2023-03-08
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多