Verification: a143cc29221c9be0

Php array unique array of arrays

Содержание

1. JIT

Как говорят сами разработчики, они выжали максимум производительности в 7 версии (тем самым сделав PHP наиболее шустрым среди динамических ЯПов). Для дальнейшего ускорения, без JIT-компилятора не обойтись. Справедливости ради, стоит сказать, что для веб-приложений использование JIT не сильно улучшает скорость обработки запросов (в некоторых случаях скорость будет даже меньше, чем без него). А вот, где нужно выполнять много математических операций — там прирост скорости очень даже значительный. Например, теперь можно делать такие безумные вещи, как ИИ на PHP.
Включить JIT можно в настройках opcache в файле php.ini.
Подробнее 1 | Подробнее 2 | Подробнее 3


2. Аннотации/Атрибуты (Attributes)

Все мы помним, как раньше на Symfony код писался на языке комментариев. Очень радует, что такое теперь прекратится, и можно будет использовать подсказки любимой IDE, функция "Find usages", и даже рефакторинг!


Забавно, что символ # также можно было использовать для создания комментариев. Так что ничего не меняется в этом мире.

Было очень много споров о синтаксисе для атрибутов, но приняли Rust-like синтаксис:


#[ORM\Entity]
#[ORM\Table("user")]
class User
{
    #[ORM\Id, ORM\Column("integer"), ORM\GeneratedValue]
    private $id;

    #[ORM\Column("string", ORM\Column::UNIQUE)]
    #[Assert\Email(["message" => "The email '{{ value }}' is not a valid email."])]
    private $email;
}

Подробнее 1 | Атрибуты в Symfony


3. Именованные параметры (Named Arguments)

Если вы когда-либо видели код, где есть булевы параметры, то понимаете насколько он ужасен. Ещё хуже, когда этих параметров 8 штук, 6 из которых имеют значение по умолчанию, а вам нужно изменить значение последнего параметра.

К примеру, код для использования библиотеки phpamqplib:


$channel->queue_declare($queue, false, true, false, false);
// ...
$channel->basic_consume($queue, '', false, false, false, false, [$this, 'consume']);

С использованием именованных параметров, код становится намного легче читать:


$channel->queue_declare($queue, durable: true, auto_delete: false);
// ...
$channel->basic_consume($queue, callback: [$this, 'consume']);

Ещё несколько примеров:


htmlspecialchars($string, default, default, false);
// vs
htmlspecialchars($string, double_encode: false);

Внимание! Можно также использовать ассоциативные массивы для именованных параметров (и наоборот).


$params = ['start_index' => 0, 'num' => 100, 'value' => 50];
$arr = array_fill(...$params);

function test(...$args) { var_dump($args); }

test(1, 2, 3, a: 'a', b: 'b');
// [1, 2, 3, "a" => "a", "b" => "b"]

Подробнее


4. Оператор безопасного null (Nullsafe operator)

Null — сам по себе не очень хорошая штука (даже очень плохая). Когда функция возвращает null, то в каждом месте, где идёт её вызов, программист обязан проверить на null. И это приводит к ужасным последствиям.


$session = Session::find(123);

if ($session !== null) {
    $user = $session->user;

    if ($user !== null) {
        $address = $user->getAddress();

        if ($address !== null) {
            $country = $address->country;
        }
    }
}

По хорошему, должен быть метод Session::findOrFail, который будет кидать исключение в случае отсутствия результата. Но когда эти методы диктует фреймворк, то мы не можем ничего сделать. Единственное, это проверять каждый раз на null либо, где это уместно, использовать ?->.


$country = $session?->user?->getAddress()?->country;

Этот код более чистый, чем предыдущий. Но он не идеален. Для идеально чистого кода, нужно использовать шаблон Null Object, либо выбрасывать exception. Тогда нам не нужно будет держать в голове возможность null на каждом шагу.

Более правильный вариант:


$country = $session->user->getAddress()->country;

Интересным моментом в использовании nullsafe есть то, что при вызове метода с помощью ?->, параметры будут обработаны только если объект не null:


function expensive_function() {
    var_dump('will not be executed');
}

$foo = null;
$foo?->bar(expensive_function()); // won't be called

5. Оператор выбора match (Match expression v2)

Для начала покажу код до и после:


$v = 1;
switch ($v) {
    case 0:
        $result = 'Foo';
        break;
    case 1:
        $result = 'Bar';
        break;
    case 2:
        $result = 'Baz';
        break;
}

echo $result; // Bar

VS


$v = 1;
echo match ($v) {
    0 => 'Foo',
    1 => 'Bar',
    2 => 'Baz',
};  // Bar

Как видим, это очень приятный оператор для выбора значений, который удобно заменяет switch.
Но есть очень важное отличие switch от match: первый сравнивает нестрого ==, а во втором производится строгое === сравнение.

Наглядный пример различия:


switch ('foo') {
    case 0:
      $result = "Oh no!\n";
      break;
    case 'foo':
      $result = "This is what I expected\n";
      break;
}
echo $result; 
// Oh no!

VS


echo match ('foo') {
    0 => "Oh no!\n",
    'foo' => "This is what I expected\n",
}; 
// This is what I expected

В PHP8 этот пример со switch работает по другому, далее рассмотрим это.

Также, сравниваемыми значениями оператора match могут быть выражения. При этом, будут выполнены только те, пока не будет найден первый совпадающий вариант:


$result = match ($x) {
    foo() => ...,
    $this->bar() => ..., // bar() isn't called if foo() matched with $x
    $this->baz => ...,
    // etc.
};

6. Адекватное приведение строки в число (Saner string to number comparisons)

Проблема


$validValues = ["foo", "bar", "baz"];
$value = 0;
var_dump(in_array($value, $validValues));
// bool(true) ???

Это происходит потому, что при нестрогом == сравнении строки с числом, строка приводится к числу, то есть, например (int)"foobar" даёт 0.

В PHP8, напротив, сравнивает строку и число как числа только если строка представляет собой число. Иначе, число будет конвертировано в строку, и будет производится строковое сравнение.



Стоит отметить, что теперь выражение 0 == "" даёт false. Если у вас из базы пришло значение пустой строки и обрабатывалось как число 0, то теперь это не будет работать. Нужно вручную приводить типы.

Эти изменения относятся ко всем операциям, которые производят нестрогое сравнение:


  • Операторы , ==, !=, >, >=, , .
  • Функции in_array(), array_search(), array_keys() с параметром strict: false (то есть по умолчанию).
  • Сотрировочные функции sort(), rsort(), asort(), arsort(), array_multisort() с флагом sort_flags: SORT_REGULAR (то есть по умолчанию).

Также, есть специальные значения которые при нестрогом сравнении дают true:



Изначально идея позаимствована в языка-брата Hack. Она состоит в том, чтобы упростить инициализацию полей класса в конструкторе.

Вместо прописания полей класса, параметров конструктора, инициализации полей с помощью параметров, можно просто прописать поля параметрами конструктора:


class Point {
    public function __construct(
        public float $x = 0.0,
        public float $y = 0.0,
        public float $z = 0.0,
    ) {}
}

Это эквивалентно:


class Point {
    public float $x;
    public float $y;
    public float $z;

    public function __construct(
        float $x = 0.0,
        float $y = 0.0,
        float $z = 0.0,
    ) {
        $this->x = $x;
        $this->y = $y;
        $this->z = $z;
    }
}

С этим всё просто, так как это синтаксический сахар. Но интересный момент возникает при использовании вариативных параметров (их нельзя объявлять таким образом). Для них нужно по-старинке вручную прописать поля и установить их в конструкторе:


class Test extends FooBar {
    private array $integers;

    public function __construct(
        private int $promotedProp, 
        Bar $bar,
        int ...$integers,
    ) {
        parent::__construct($bar);
        $this->integers = $integers;
    }
}

8. Новые функции для работы со строками (str_contains, str_starts_with, str_ends_with)

Функция str_contains проверяет, содержит ли строка $haystack строку $needle:


str_contains("abc", "a"); // true
str_contains("abc", "d"); // false
str_contains("abc", "B"); // false 

// $needle is an empty string
str_contains("abc", "");  // true
str_contains("", "");     // true

Функция str_starts_with проверяет, начинается ли строка $haystack строкой $needle:


$str = "beginningMiddleEnd";
var_dump(str_starts_with($str, "beg")); // true
var_dump(str_starts_with($str, "Beg")); // false

Функция str_ends_with проверяет, кончается ли строка $haystack строкой $needle:


$str = "beginningMiddleEnd";
var_dump(str_ends_with($str, "End")); // true
var_dump(str_ends_with($str, "end")); // false

Вариантов mb_str_ends_with, mb_str_starts_with, mb_str_contains нету, так как эти функции уже хорошо работают с мутльтибайтовыми символами.


9. Использование ::class на объектах (Allow ::class on objects)

Раньше, чтобы получить название класса, к которому принадлежит объект, нужно было использовать get_class:


$object = new stdClass;
$className = get_class($object); // "stdClass"

Теперь же, можно использовать такую же нотацию, как и ClassName::class:


$object = new stdClass;
var_dump($object::class); // "stdClass"

10. Возвращаемый тип static (Static return type)

Тип static был добавлен для более явного указания, что используется позднее статическое связывание (Late Static Binding) при возвращении результата:


class Foo {
    public static function createFromWhatever(...$whatever): static {
        return new static(...$whatever);
    }
}

Также, для возвращения $this, стоит указывать static вместо self:


abstract class Bar {
    public function doWhatever(): static {
        // Do whatever.
        return $this;
    }
}

11. Weak Map

Это специальная структура данных для хранения значений, ключами которых являются объекты, в основном используемая для кеширования.

Интерфейс класса выглядит следующим образом:


WeakMap implements Countable , ArrayAccess , Iterator {
    public __construct ( )
    public count ( ) : int
    public current ( ) : mixed
    public key ( ) : object
    public next ( ) : void
    public offsetExists ( object $object ) : bool
    public offsetGet ( object $object ) : mixed
    public offsetSet ( object $object , mixed $value ) : void
    public offsetUnset ( object $object ) : void
    public rewind ( ) : void
    public valid ( ) : bool
}

Особенностью есть то, что объекты, используемые как ключи, подвержены сборке мусора. Поэтому, WeakMaps особенно пригодны для долгоживущих процессов.


class FooBar {
    private WeakMap $cache;

    public function getSomethingWithCaching(object $obj) {
        return $this->cache[$obj] ??= $this->decorated->getSomething($obj);
    }

    // ...
}

Подробнее можно почитать в документации.


12. Исключена возможность использовать левоассоциативный оператор (Deprecate left-associative ternary operator)

Рассмотрим код:


return $a == 1 ? 'one'
     : $a == 2 ? 'two'
     : $a == 3 ? 'three'
     : $a == 4 ? 'four'
              : 'other';

Вот как он всегда работал:


В 7.4 код как прежде, отрабатывал, но выдавался Deprecated Warning.
Теперь же, в 8 версии, код упадёт с Fatal error.


13. Изменение приоритета оператора конкатенации (Change the precedence of the concatenation operator)

Раньше, приоритет оператора конкатенации . был на равне с + и -, поэтому они исполнялись поочерёдно слева направо, что приводило к ошибкам. Теперь же, его приоритет ниже:



14. Возможность оставить запятую в конце списка параметров (Allow trailing comma in parameter list)

Это относится к методам:


public function whatever(
    string $s,
    float $f, // Allowed
) {
    // ...
}

Обычным функциям:


function whatever(
    string $s,
    float $f, // Allowed
) {
    // ...
}

Анонимным функциям:


$f = function(
    string $s,
    float $f, // Allowed
) {
    // ...
};

А также стрелочным функциям:


$f = fn(
    string $s,
    float $f, // Allowed
) => $s . $f;

15. Новый интерфейс Stringable

Объекты, которые реализуют метод __toString, неявно реализуют этот интерфейс. Сделано это в большей мере для гарантии типобезопасности. С приходом union-типов, можно писать string|Stringable, что буквально означает "строка" или "объект, который можно преобразовать в строку". В таком случае, объект будет преобразован в строку только когда уже не будет куда оттягивать.


interface Stringable
{
    public function __toString(): string;
}

Рассмотрим такой код:


class A{
    public function __toString(): string 
    {
        return 'hello';
    }
}

function acceptString(string $whatever) {
    var_dump($whatever);
}

acceptString(123.45); // string(6) "123.45"
acceptString(new A()); // string(5) "hello"

Здесь функция acceptString принимает строку, но что если нам нужно конкретно объект, что может быть преобразован в строку, а не что-либо иное. Вот тут нам поможет интерфейс Stringable:


function acceptString(Stringable $whatever) {
    var_dump($whatever);
    var_dump((string)$whatever);
}

// acceptString(123.45); 
/*
TypeError
*/

acceptString(new A()); 
/*
object(A)#1 (0) {
}
string(5) "hello"
*/

16. Теперь throw — это выражение

Примеры использования:


// This was previously not possible since arrow functions only accept a single expression while throw was a statement.
$callable = fn() => throw new Exception();

// $value is non-nullable.
$value = $nullableValue ?? throw new InvalidArgumentException();

// $value is truthy.
$value = $falsableValue ?: throw new InvalidArgumentException();

// $value is only set if the array is not empty.
$value = !empty($array)
    ? reset($array)
    : throw new InvalidArgumentException();

Подробнее можно почитать здесь.


17. Стабильная сортировка

Теперь все сортировки в php стабильные. Это означает, что равные элементы будут оставаться в том же порядке, что и были до сортировки.

Сюда входят sort, rsort, usort, asort, arsort, uasort, ksort, krsort, uksort, array_multisort, а также соответствующие методы в ArrayObject.


18. Возможность опустить переменную исключения (non-capturing catches)

Раньше, даже если переменная исключения не использовалась в блоке catch, её всё равно нужно быто объявлять (и IDE подсвечивала ошибку, что переменная нигде не используется):


try {
    changeImportantData();
} catch (PermissionException $ex) {
    echo "You don't have permission to do this";
}

Теперь же, можно опустить переменную, если никакая дополнительная информация не нужна:


try {
    changeImportantData();
} catch (PermissionException) { // The intention is clear: exception details are irrelevant
    echo "You don't have permission to do this";
}

19. Обеспечение правильной сигнатуры магических методов (Ensure correct signatures of magic methods):

Когда были добавлены type-hints в php, оставалась возможность непавильно написать сигнатуру для магических методов.
К примеру:


class Test {
    public function __isset(string $propertyName): float {
        return 123.45;
    }
}

$t = new Test();

var_dump(isset($t)); // true

Теперь же, всё жёстко контролируется, и допустить ошибку сложнее.


Foo::__call(string $name, array $arguments): mixed;

Foo::__callStatic(string $name, array $arguments): mixed;

Foo::__clone(): void;

Foo::__debugInfo(): ?array;

Foo::__get(string $name): mixed;

Foo::__invoke(mixed $arguments): mixed;

Foo::__isset(string $name): bool;

Foo::__serialize(): array;

Foo::__set(string $name, mixed $value): void;

Foo::__set_state(array $properties): object;

Foo::__sleep(): array;

Foo::__unserialize(array $data): void;

Foo::__unset(string $name): void;

Foo::__wakeup(): void;

20. Включить расширение json по умолчанию (Always available JSON extension)

Так как функции для работы с json постоянно используются, и нужны чуть ли не в каждом приложении, то было принято решение включить ext-json в PHP по умолчанию.


21. Более строгие проверки типов при для арифметических и побитовых операторов (Stricter type checks for arithmetic/bitwise operators)

Проблема, которую разработчики здесь решили представлена кодом ниже:


var_dump([] % [42]);

Что должен вывести этот код? Здесь непредсказуемое поведение (будет 0). Всё потому, что большинство арифметических операторов не должны применятся на массивах.

Теперь, при использовании операторов +, -, *, /, **, %, , >>, &, |, ^, ~, ++, -- будет вызывать исключение TypeError для операндов array, resource и object.
Но сложение двух массивов по прежнему является корректным вариантом использования.


22. Валидация абстрактных методов в трейтах (Validation for abstract trait methods)

До восьмой версии, можно было писать что-то вроде:


trait T {
    abstract public function test(int $x);
}

class C {
    use T;

    // Allowed, but shouldn't be due to invalid type.
    public function test(string $x) {}
}

Начиная с восьмой версии, такой код будет падать с ошибкой. Да, и теперь есть возможность в трейте сделать приватный абстрактный метод, который будет реализован в использующем трейт классе.


trait MyTrait {
    abstract private function neededByTheTrait(): string;

    public function doSomething() {
        return strlen($this->neededByTheTrait());
    }
}

class TraitUser {
    use MyTrait;

    // This is allowed:
    private function neededByTheTrait(): string { }

    // This is forbidden (incorrect return type)
    private function neededByTheTrait(): stdClass { }

    // This is forbidden (non-static changed to static)
    private static function neededByTheTrait(): string { }
}

Случаи, когда реализация приходит из родительского класса, или трейт применён в родительском классе, также проверяются.


23. Объединения типов (Union Types 2.0)

Рассмотрим код:


class Number {
    /**
     * @var int|float $number
     */
    private $number;

    /**
     * @param int|float $number
     */
    public function setNumber($number) {
        $this->number = $number;
    }

    /**
     * @return int|float
     */
    public function getNumber() {
        return $this->number;
    }
}

Здесь тип переменной $number контролируется только соглашениями программистов. На самом деле, туда может попасть что угодно, и выйти отсюда может также что угодно, так как проверки на тип не обеспечиваются ядром языка.

Теперь же, можно прописать тип int|float (или любой другой) явно, чтобы обеспечить корректность работы модуля:


class Number {
    private int|float $number;

    public function setNumber(int|float $number): void {
        $this->number = $number;
    }

    public function getNumber(): int|float {
        return $this->number;
    }
}

А также, код становится немного чище, так как мы можем избавится от излишних комментариев.

Типы-объединения имеют синтаксис T1|T2|... и могут быть использованы во всех местах, где можно прописать type-hints с некоторыми оговорками:


  • Тип void не может быть частью объединения.
  • Чтобы обозначить отсутствие результата, можно объявить "Nullable union type", который имеет следующий синтаксис: T1|T2|null.
  • Тип null не может быть использован вне объединения. Вместо него стоит использовать void.
  • Существует также псевдотип false, который по историческим причинам уже используется некоторыми функциями в php. С другой стороны, не существует тип true, так как он нигде не использовался ранее.

Типы полей класса инвариантны, и не могут быть изменены при наследовании.
А вот с методами всё немного интересней:


  1. Параметры методов можно расширить, но нельзя сузить.
  2. Возвращаемые типы можно сузить, но нельзя расширить.

Вот как это выглядит в коде:


class Test {
    public function param1(int $param) {}
    public function param2(int|float $param) {}

    public function return1(): int|float {}
    public function return2(): int {}
}

class Test2 extends Test {
    public function param1(int|float $param) {} // Allowed: Adding extra param type
    public function param2(int $param) {} // FORBIDDEN: Removing param type

    public function return1(): int {} // Allowed: Removing return type
    public function return2(): int|float {} // FORBIDDEN: Adding extra return type
}

То же самое происходит при типах, которые получились как результат наследования:


class A {}
class B extends A {}

class Test {
    public function param1(B|string $param) {}
    public function param2(A|string $param) {}

    public function return1(): A|string {}
    public function return2(): B|string {}
}

class Test2 extends Test {
    public function param1(A|string $param) {} // Allowed: Widening union member B -> A
    public function param2(B|string $param) {} // FORBIDDEN: Restricting union member A -> B

    public function return1(): B|string {} // Allowed: Restricting union member A -> B
    public function return2(): A|string {} // FORBIDDEN: Widening union member B -> A
}

Интереснее становится когда strict_types установлен в 0, то есть по умолчанию. Например, функция принимает int|string, а мы передали ей bool. Что в результате должно быть в переменной? Пустая строка, или ноль? Есть набор правил, по которым будет производиться приведение типов.

Так, если переданный тип не является частью объединения, то действуют следующие приоритеты:


  1. int;
  2. float;
  3. string;
  4. bool;

Так вот, будет перебираться этот список с типами, и для каждого проверяться: Если тип существует в объединении, и значение может быть приведёно к нему в соответствии с семантикой PHP, то так и будет сделано. Иначе пробуем следующий тип.

Как исключение, если string должен быть приведён к int|float, то сравнение идёт в первую очередь в соответствии с семантикой "числовых строк". К примеру, "123" станет int(123), в то время как "123.0" станет float(123.0).


К типам null и false не происходит неявного преобразования.

Таблица неявного приведения типов:



Типы полей и ссылки


class Test {
    public int|string $x;
    public float|string $y;
}
$test = new Test;
$r = "foobar";
$test->x =& $r;
$test->y =& $r;

// Reference set: { $r, $test->x, $test->y }
// Types: { mixed, int|string, float|string }

$r = 42; // TypeError

Здесь проблема в том, что тип устанавливаемого значения не совместим с объявленными в полях класса. Для Test::$x — это могло быть int(42), а для Test::$yfloat(42.0). Так как эти значения не эквивалентны, то невозможно обеспечить единую ссылку, и TypeError будет сгенерирован.


Введение

Laravel предлагает несколько подходов для проверки входящих данных вашего приложения. Например, метод validate, доступен для всех входящих HTTP-запросов. Однако мы обсудим и другие подходы к валидации.

Laravel содержит удобные правила валидации, применяемые к данным, включая валидацию на уникальность значения в конкретной таблице базы данных. Мы подробно рассмотрим каждое из этих правил валидации, чтобы вы были знакомы со всеми особенностями валидации Laravel.

Быстрый старт

Чтобы узнать о мощных функциях валидации Laravel, давайте рассмотрим полный пример валидации формы и отображения сообщений об ошибках конечному пользователю. Прочитав этот общий обзор, вы сможете получить представление о том, как проверять данные входящего запроса с помощью Laravel:

Определение маршрутов

Во-первых, предположим, что в нашем файле routes/web.php определены следующие маршруты:

use App\Http\Controllers\PostController;

Route::get('/post/create', [PostController::class, 'create']);
Route::post('/post', [PostController::class, 'store']);

Маршрут GET отобразит форму для пользователя для создания нового сообщения в блоге, а маршрут POST сохранит новое сообщение в базе данных.

Создание контроллера

Затем, давайте взглянем на простой контроллер, который обрабатывает входящие запросы на эти маршруты. Пока оставим метод store пустым:

Написание логики валидации

Теперь мы готовы заполнить наш метод store логикой для валидации нового сообщения в блоге. Для этого мы будем использовать метод validate, предоставляемый объектом Illuminate\Http\Request. Если правила валидации будут пройдены, то ваш код продолжит нормально выполняться; однако, если проверка не пройдена, то будет создано исключение, и соответствующий ответ об ошибке будет автоматически отправлен обратно пользователю.

Если валидации не пройдена во время традиционного HTTP-запроса, то будет сгенерирован ответ-перенаправление на предыдущий URL-адрес. Если входящий запрос является XHR-запросом, то будет возвращен JSON-ответ, содержащий сообщения об ошибках валидации.

Чтобы лучше понять метод validate, давайте вернемся к методу store:

/**
 * Сохранить новую запись в блоге.
 *
 * @param  \Illuminate\Http\Request  $request
 * @return \Illuminate\Http\Response
 */
public function store(Request $request)
{
    $validated = $request->validate([
        'title' => 'required|unique:posts|max:255',
        'body' => 'required',
    ]);

    // Запись блога корректна ...
}

Как видите, правила валидации передаются в метод validate. Не волнуйтесь – все доступные правила валидации задокументированы. Опять же, если проверка не пройдена, то будет автоматически сгенерирован корректный ответ. Если проверка пройдет успешно, то наш контроллер продолжит нормальную работу.

В качестве альтернативы правила валидации могут быть указаны как массивы правил вместо одной строки с разделителями |:

$validatedData = $request->validate([
    'title' => ['required', 'unique:posts', 'max:255'],
    'body' => ['required'],
]);

Кроме того, вы можете использовать метод validateWithBag для валидации запроса и сохранения любых сообщений об ошибках в именованную коллекцию ошибок:

$validatedData = $request->validateWithBag('post', [
    'title' => ['required', 'unique:posts', 'max:255'],
    'body' => ['required'],
]);

Прекращение валидации при возникновении первой ошибки

По желанию можно прекратить выполнение правил валидации для атрибута после первой ошибки. Для этого присвойте атрибуту правило bail:

$request->validate([
    'title' => 'bail|required|unique:posts|max:255',
    'body' => 'required',
]);

В этом примере, если правило unique для атрибута title не будет пройдено, то правило max не будет выполняться. Правила будут проверяться в порядке их назначения.

Примечание о вложенных атрибутах

Если входящий HTTP-запрос содержит данные «вложенных» полей, то вы можете указать эти поля в своих правилах валидации, используя «точечную нотацию»:

$request->validate([
    'title' => 'required|unique:posts|max:255',
    'author.name' => 'required',
    'author.description' => 'required',
]);

С другой стороны, если имя вашего поля буквально содержит точку, то вы можете явно запретить ее интерпретацию как часть «точечной нотации», экранировав точку с помощью обратной косой черты:

$request->validate([
    'title' => 'required|unique:posts|max:255',
    'v1\.0' => 'required',
]);

Отображение ошибок валидации

Итак, что, если поля входящего запроса не проходят указанные правила валидации? Как упоминалось ранее, Laravel автоматически перенаправит пользователя обратно в его предыдущее местоположение. Кроме того, все ошибки валидации и входящие данные запроса будут автоматически записаны в сессию.

Переменная $errors используется во всех шаблонах вашего приложения благодаря посреднику Illuminate\View\Middleware\ShareErrorsFromSession, который включен в группу посредников web. Пока применяется этот посредник, в ваших шаблонах всегда будет доступна переменная $errors, что позволяет вам предполагать, что переменная $errors всегда определена и может безопасно использоваться. Переменная $errors будет экземпляром Illuminate\Support\MessageBag. Для получения дополнительной информации о работе с этим объектом ознакомьтесь с его документацией.

Итак, в нашем примере пользователь будет перенаправлен на метод нашего контроллера create, в случае, если валидация завершится неудачно, что позволит нам отобразить сообщения об ошибках в шаблоне:



Создание поста блога

@if ($errors->any())
    @foreach ($errors->all() as $error)
  • {{ $error }}
  • @endforeach
@endif

Корректировка сообщений об ошибках

Каждое встроенное правило валидации Laravel содержит сообщение об ошибке, которое находится в файле resources/lang/en/validation.php вашего приложения. В этом файле вы найдете запись о переводе для каждого правила валидации. Вы можете изменять или модифицировать эти сообщения в зависимости от потребностей вашего приложения.

Кроме того, вы можете скопировать этот файл в каталог перевода другого языка, чтобы перевести сообщения на язык вашего приложения. Чтобы узнать больше о локализации Laravel, ознакомьтесь с полной документацией по локализации.

XHR-запросы и валидация

В этом примере мы использовали традиционную форму для отправки данных в приложение. Однако, многие приложения получают запросы XHR с фронтенда с использованием JavaScript. При использовании метода validate, во время выполнения XHR-запроса, Laravel не будет генерировать ответ-перенаправление. Вместо этого Laravel генерирует JSON-ответ, содержащий все ошибки валидации. Этот ответ JSON будет отправлен с кодом 422 состояния HTTP.

Директива @error

Вы можете использовать директиву @error Blade, чтобы быстро определить, существуют ли сообщения об ошибках валидации для конкретного атрибута, включая сообщения об ошибках в именованной коллекции ошибок. В директиве @error вы можете вывести содержимое переменной $message для отображения сообщения об ошибке:







@error('title')
    
{{ $message }}
@enderror

Повторное заполнение форм

Когда Laravel генерирует ответ-перенаправление из-за ошибки валидации, фреймворк автоматически краткосрочно записывает все входные данные запроса в сессию. Это сделано для того, чтобы вы могли удобно получить доступ к входным данным во время следующего запроса и повторно заполнить форму, которую пользователь попытался отправить.

Чтобы получить входные данные предыдущего запроса, вызовите метод old экземпляра Illuminate\Http\Request. Метод old извлечет ранее записанные входные данные из сессии:

$title = $request->old('title');

Laravel также содержит глобального помощника old. Если вы показываете входные данные прошлого запроса в шаблоне Blade, то удобнее использовать помощник old для повторного заполнения формы. Если для какого-то поля не были предоставлены данные в прошлом запросе, то будет возвращен null:

Примечание о необязательных полях

По умолчанию Laravel содержит посредников App\Http\Middleware\TrimStrings и App\Http\Middleware\ConvertEmptyStringsToNull в глобальном стеке посредников вашего приложения. Эти посредники перечислены в классе App\Http\Kernel. Первый из упомянутых посредников будет автоматически обрезать все входящие строковые поля запроса, а второй – конвертировать любые пустые строковые поля в null. Из-за этого вам часто нужно будет помечать ваши «необязательные» поля запроса как nullable, если вы не хотите, чтобы валидатор не считал такие поля недействительными. Например:

$request->validate([
    'title' => 'required|unique:posts|max:255',
    'body' => 'required',
    'publish_at' => 'nullable|date',
]);

В этом примере мы указываем, что поле publish_at может быть либо null, либо допустимым представлением даты. Если модификатор nullable не добавлен в определение правила, валидатор сочтет null недопустимой датой.

Валидация запроса формы

Создание запросов формы

Для более сложных сценариев валидации вы можете создать «запрос формы». Запрос формы – это ваш класс запроса, который инкапсулирует свою собственную логику валидации и авторизации. Чтобы сгенерировать новый запрос формы, используйте команду make:request Artisan:

php artisan make:request StorePostRequest

Эта команда поместит новый класс запроса формы в каталог app/Http/Requests вашего приложения. Если этот каталог не существует в вашем приложении, то Laravel предварительно создаст его, когда вы запустите команду make:request. Каждый запрос формы, созданный Laravel, имеет два метода: authorize иrules.

Как вы могли догадаться, метод authorize отвечает за определение того, может ли текущий аутентифицированный пользователь выполнить действие, представленное запросом, в то время как метод rules возвращает правила валидации, которые должны применяться к данным запроса:

/**
 * Получить массив правил валидации, которые будут применены к запросу.
 *
 * @return array
 */
public function rules()
{
    return [
        'title' => 'required|unique:posts|max:255',
        'body' => 'required',
    ];
}

{tip} Вы можете объявить любые зависимости, которые вам нужны, в сигнатуре метода rules. Они будут автоматически извлечены через контейнер служб Laravel.

Итак, как анализируются правила валидации? Все, что вам нужно сделать, это объявить зависимость от запроса в методе вашего контроллера. Входящий запрос формы проверяется до вызова метода контроллера, что означает, что вам не нужно загромождать контроллер какой-либо логикой валидации:

/**
 * Сохранить новую запись в блоге.
 *
 * @param  \App\Http\Requests\StorePostRequest  $request
 * @return Illuminate\Http\Response
 */
public function store(StorePostRequest $request)
{
    // Входящий запрос прошел валидацию ...

    // Получить провалидированные входные данные ...
    $validated = $request->validated();
}

При неуспешной валидации будет сгенерирован ответ-перенаправление, чтобы отправить пользователя обратно в его предыдущее местоположение. Ошибки также будут краткосрочно записаны в сессию, чтобы они были доступны для отображения. Если запрос был XHR-запросом, то пользователю будет возвращен HTTP-ответ с кодом состояния 422, включая JSON-представление ошибок валидации.

Добавление хуков after для запросов форм

Если вы хотите добавить хук валидации after для запроса формы, то вы можете использовать метод withValidator. Этот метод получает полностью инициированный валидатор, что позволяет вам вызвать любой из его методов до того, как правила валидации будут фактически проанализированы:

/**
 * Надстройка экземпляра валидатора.
 *
 * @param  \Illuminate\Validation\Validator  $validator
 * @return void
 */
public function withValidator($validator)
{
    $validator->after(function ($validator) {
        if ($this->somethingElseIsInvalid()) {
            $validator->errors()->add('field', 'Что-то не так с этим полем!');
        }
    });
}

Прекращение валидации после первой неуспешной проверки

Добавив свойство $stopOnFirstFailure вашему классу запроса, вы можете сообщить валидатору, что он должен прекратить валидацию всех атрибутов после возникновения первой ошибки валидации:

/**
 * Остановить валидацию после первой неуспешной проверки.
 *
 * @var bool
 */
protected $stopOnFirstFailure = true;

Авторизация запросов

Класс запроса формы также содержит метод authorize. В рамках этого метода вы можете определить, действительно ли аутентифицированный пользователь имеет право изменять текущий ресурс. Например, вы можете определить, действительно ли пользователь владеет комментарием в блоге, который он пытается обновить. Скорее всего, вы будете взаимодействовать с вашими шлюзами и политиками авторизации в этом методе:

use App\Models\Comment;

/**
 * Определить, уполномочен ли пользователь выполнить этот запрос.
 *
 * @return bool
 */
public function authorize()
{
    $comment = Comment::find($this->route('comment'));

    return $comment && $this->user()->can('update', $comment);
}

Поскольку все запросы формы расширяют базовый класс запросов Laravel, мы можем использовать метод user для доступа к текущему аутентифицированному пользователю. Также обратите внимание на вызов метода route в приведенном выше примере. Этот метод обеспечивает вам доступ к параметрам URI, определенным для вызываемого маршрута, таким как параметр {comment} в приведенном ниже примере:

Route::post('/comment/{comment}');

Если метод authorize возвращает false, то будет автоматически возвращен HTTP-ответ с кодом состояния 403, и метод вашего контроллера не будет выполнен.

Если вы планируете обрабатывать логику авторизации для запроса в другой части вашего приложения, то вы можете просто вернуть true из метода authorize:

/**
 * Определить, уполномочен ли пользователь выполнить этот запрос.
 *
 * @return bool
 */
public function authorize()
{
    return true;
}

{tip} Вы можете объявить любые зависимости, которые вам нужны, в сигнатуре метода authorize. Они будут автоматически извлечены через контейнер служб Laravel.

Корректировка сообщений об ошибках

Вы можете изменить сообщения об ошибках, используемые в запросе формы, переопределив метод messages. Этот метод должен возвращать массив пар атрибут / правило и соответствующие им сообщения об ошибках:

/**
 * Получить сообщения об ошибках для определенных правил валидации.
 *
 * @return array
 */
public function messages()
{
    return [
        'title.required' => 'A title is required',
        'body.required' => 'A message is required',
    ];
}

Корректировка атрибутов валидации

Многие сообщения об ошибках встроенных правил валидации Laravel содержат заполнитель :attribute. Если вы хотите, чтобы заполнитель :attribute вашего сообщения валидации был заменен другим именем атрибута, то вы можете указать собственные имена, переопределив метод attributes. Этот метод должен возвращать массив пар атрибут / имя:

/**
 * Получить пользовательские имена атрибутов для формирования ошибок валидатора.
 *
 * @return array
 */
public function attributes()
{
    return [
        'email' => 'email address',
    ];
}

Подготовка входящих данных для валидации

Если вам необходимо подготовить или обработать какие-либо данные из запроса перед применением правил валидации, то вы можете использовать метод prepareForValidation:

use Illuminate\Support\Str;

/**
 * Подготовить данные для валидации.
 *
 * @return void
 */
protected function prepareForValidation()
{
    $this->merge([
        'slug' => Str::slug($this->slug),
    ]);
}

Создание валидатора по требованию

Если вы не хотите использовать метод validate запроса, то вы можете создать экземпляр валидатора вручную, используя фасад Validator. Метод make фасада генерирует новый экземпляр валидатора:

all(), [
            'title' => 'required|unique:posts|max:255',
            'body' => 'required',
        ]);

        if ($validator->fails()) {
            return redirect('post/create')
                        ->withErrors($validator)
                        ->withInput();
        }

        // Сохранить сообщение блога ...
    }
}

Первым аргументом, переданным методу make, являются проверяемые данные. Второй аргумент – это массив правил валидации, которые должны применяться к данным.

После определения того, что запрос не прошел валидацию с помощью метода fails, вы можете использовать метод withErrors для передачи сообщений об ошибках в сессию. При использовании этого метода переменная $errors будет автоматически передана вашим шаблонам после перенаправления, что позволит вам легко отобразить их обратно пользователю. Метод withErrors принимает экземпляр валидатора, экземпляр MessageBag или обычный массив PHP.

Прекращение валидации после первой неуспешной проверки

Метод stopOnFirstFailure проинформирует валидатор о том, что он должен прекратить валидацию всех атрибутов после возникновения первой ошибки валидации:

if ($validator->stopOnFirstFailure()->fails()) {
    // ...
}

Автоматическое перенаправление

Если вы хотите создать экземпляр валидатора вручную, но по-прежнему воспользоваться преимуществами автоматического перенаправления, предлагаемого методом validate HTTP-запроса, вы можете вызвать метод validate созданного экземпляра валидатора. Пользователь будет автоматически перенаправлен или, в случае запроса XHR, будет возвращен ответ JSON, если валидация будет не успешной:

Validator::make($request->all(), [
    'title' => 'required|unique:posts|max:255',
    'body' => 'required',
])->validate();

Вы можете использовать метод validateWithBag для сохранения сообщений об ошибках в именованной коллекции ошибок, если валидация будет не успешной:

Validator::make($request->all(), [
    'title' => 'required|unique:posts|max:255',
    'body' => 'required',
])->validateWithBag('post');

Именованные коллекции ошибок

Если у вас есть несколько форм на одной странице, то вы можете задать имя экземпляру MessageBag, содержащий ошибки валидации, что позволит вам получать сообщения об ошибках для конкретной формы. Чтобы добиться этого, передайте имя в качестве второго аргумента в метод withErrors:

return redirect('register')->withErrors($validator, 'login');

Затем, вы можете получить доступ к именованному экземпляру MessageBag из переменной $errors:

{{ $errors->login->first('email') }}

Корректировка сообщений об ошибках

При необходимости вы можете предоставить собственные сообщения об ошибках, которые должен использовать экземпляр валидатора вместо сообщений об ошибках по умолчанию, предоставляемых Laravel. Есть несколько способов указать собственные сообщения. Во-первых, вы можете передать собственные сообщения в качестве третьего аргумента методу Validator::make:

$validator = Validator::make($input, $rules, $messages = [
    'required' => 'The :attribute field is required.',
]);

В этом примере заполнитель :attribute будет заменен фактическим именем проверяемого поля. Вы также можете использовать другие заполнители в сообщениях валидатора. Например:

$messages = [
    'same' => 'The :attribute and :other must match.',
    'size' => 'The :attribute must be exactly :size.',
    'between' => 'The :attribute value :input is not between :min - :max.',
    'in' => 'The :attribute must be one of the following types: :values',
];

Указание пользовательского сообщения для конкретного атрибута

По желанию можно указать собственное сообщение об ошибке только для определенного атрибута. Вы можете сделать это, используя «точечную нотацию». Сначала укажите имя атрибута, а затем правило:

$messages = [
    'email.required' => 'We need to know your email address!',
];

Указание пользовательских имен для атрибутов

Многие сообщения об ошибках встроенных правил валидации Laravel содержат заполнитель :attribute, который заменяется именем проверяемого поля или атрибута. Чтобы указать собственные значения, используемые для замены этих заполнителей для конкретных полей, вы можете передать массив ваших атрибутов в качестве четвертого аргумента методу Validator::make:

$validator = Validator::make($input, $rules, $messages, [
    'email' => 'email address',
]);

Хук валидатора After

Вы также можете определить замыкания, которые будут запускаться после завершения валидации. Это позволяет легко выполнять дальнейшую валидацию и даже добавлять сообщения об ошибках в коллекцию сообщений. Вызовите метод after на экземпляре валидатора:

$validator = Validator::make(...);

$validator->after(function ($validator) {
    if ($this->somethingElseIsInvalid()) {
        $validator->errors()->add(
            'field', 'Something is wrong with this field!'
        );
    }
});

if ($validator->fails()) {
    //
}

Работа с сообщениями об ошибках

После вызова метода errors экземпляр Validator, вы получите экземпляр Illuminate\Support\MessageBag, который имеет множество удобных методов для работы с сообщениями об ошибках. Переменная $errors, которая автоматически становится доступной для всех шаблонов, также является экземпляром класса MessageBag.

Получение первого сообщения об ошибке для поля

Чтобы получить первое сообщение об ошибке для указанного поля, используйте метод first:

$errors = $validator->errors();

echo $errors->first('email');

Получение всех сообщений об ошибках для поля

Если вам нужно получить массив всех сообщений для указанного поля, используйте метод get:

foreach ($errors->get('email') as $message) {
    //
}

Если вы проверяете массив полей формы, то вы можете получить все сообщения для каждого из элементов массива, используя символ *:

foreach ($errors->get('attachments.*') as $message) {
    //
}

Получение всех сообщений об ошибках для всех полей

Чтобы получить массив всех сообщений для всех полей, используйте метод all:

foreach ($errors->all() as $message) {
    //
}

Определение наличия сообщений для поля

Метод has используется для определения наличия сообщений об ошибках для указанного поля:

if ($errors->has('email')) {
    //
}

Указание пользовательских сообщений в языковых файлах

Каждое встроенное правило валидации Laravel содержит сообщение об ошибке, которое находится в файле resources/lang/en/validation.php вашего приложения. В этом файле вы найдете запись о переводе для каждого правила валидации. Вы можете изменять или модифицировать эти сообщения в зависимости от потребностей вашего приложения.

Кроме того, вы можете скопировать этот файл в каталог перевода другого языка, чтобы перевести сообщения на язык вашего приложения. Чтобы узнать больше о локализации Laravel, ознакомьтесь с полной документацией по локализации.

Указание пользовательского сообщения для конкретного атрибута

Вы можете изменить сообщения об ошибках, используемые для указанных комбинаций атрибутов и правил в языковых файлах валидации вашего приложения. Для этого добавьте собственные сообщения в массив custom языкового файла resources/lang/xx/validation.php вашего приложения:

'custom' => [
    'email' => [
        'required' => 'We need to know your email address!',
        'max' => 'Your email address is too long!'
    ],
],

Указание атрибутов в языковых файлах

Многие сообщения об ошибках встроенных правил валидации Laravel содержат заполнитель :attribute, который заменяется именем проверяемого поля или атрибута. Если вы хотите, чтобы часть :attribute вашего сообщения валидации была заменена собственным значением, то вы можете указать имя настраиваемого атрибута в массиве attributes вашего языкового файла resources/lang/xx/validation.php:

'attributes' => [
    'email' => 'email address',
],

Указание пользовательских имен для атрибутов в языковых файлах

Некоторые сообщения об ошибках встроенных правил валидации Laravel содержат заполнитель :value, который заменяется текущим значением атрибута запроса. Однако, иногда вам может понадобиться заменить часть :value вашего сообщения валидации на собственное значение. Например, рассмотрим следующее правило, которое указывает, что номер кредитной карты требуется обязательно, если для параметра payment_type установлено значение cc:

Validator::make($request->all(), [
    'credit_card_number' => 'required_if:payment_type,cc'
]);

Если это правило валидации не будет пройдено, то будет выдано следующее сообщение об ошибке:

The credit card number field is required when payment type is cc.

Вместо того, чтобы отображать cc в качестве значения типа платежа, вы можете указать более удобное для пользователя представление значения в вашем языковом файле resources/lang/xx/validation.php, определив массив values:

'values' => [
    'payment_type' => [
        'cc' => 'credit card'
    ],
],

После определения этого значения правило валидации выдаст следующее сообщение об ошибке:

The credit card number field is required when payment type is credit card.

Доступные правила валидации

Ниже приведен список всех доступных правил валидации и их функций:

  • Accepted
  • Active URL
  • After (Date)
  • After Or Equal (Date)
  • Alpha
  • Alpha Dash
  • Alpha Numeric
  • Array
  • Bail
  • Before (Date)
  • Before Or Equal (Date)
  • Between
  • Boolean
  • Confirmed
  • Date
  • Date Equals
  • Date Format
  • Different
  • Digits
  • Digits Between
  • Dimensions (Image Files)
  • Distinct
  • Email
  • Ends With
  • Exclude If
  • Exclude Unless
  • Exists (Database)
  • File
  • Filled
  • Greater Than
  • Greater Than Or Equal
  • Image (File)
  • In
  • In Array
  • Integer
  • IP Address
  • JSON
  • Less Than
  • Less Than Or Equal
  • Max
  • MIME Types
  • MIME Type By File Extension
  • Min
  • Multiple Of
  • Not In
  • Not Regex
  • Nullable
  • Numeric
  • Password
  • Present
  • Prohibited
  • Prohibited If
  • Prohibited Unless
  • Regex (regular expression)
  • Required
  • Required If
  • Required Unless
  • Required With
  • Required With All
  • Required Without
  • Required Without All
  • Same
  • Size
  • Sometimes
  • Starts With
  • String
  • Timezone
  • Unique (Database)
  • URL
  • UUID

accepted

Проверяемое поле должно иметь значение "yes", "on", 1, или true. Применяется для валидации принятия «Условий использования» или аналогичных полей.

active_url

Проверяемое поле должно иметь допустимую запись A или AAAA в соответствии с функцией dns_get_record PHP. Имя хоста указанного URL извлекается с помощью PHP-функции parse_url перед передачей в dns_get_record.

after:date

Проверяемое поле должно иметь значение после указанной даты. Даты будут переданы в функцию strtotime PHP для преобразования в действительный экземпляр DateTime:

'start_date' => 'required|date|after:tomorrow'

Вместо передачи строки даты, которая будет проанализирована с помощью strtotime, вы можете указать другое поле для сравнения с датой:

'finish_date' => 'required|date|after:start_date'

after_or_equal:date

Проверяемое поле должно иметь значение после указанной даты или равное ей. Для получения дополнительной информации см. правило after.

alpha

Проверяемое поле должно состоять полностью из букв.

alpha_dash

Проверяемое поле может содержать буквенно-цифровые символы, а также дефисы и подчеркивания.

alpha_num

Проверяемое поле должно состоять полностью из буквенно-цифровых символов.

array

Проверяемое поле должно быть массивом PHP.

bail

Остановить дальнейшее применение правил валидации атрибута после первой неуспешной проверки.

В отличии от правила bail, которое прекращает дальнейшую валидацию только конкретного поля, метод stopOnFirstFailure сообщит валидатору, что он должен прекратить дальнейшую валидацию всех атрибутов при возникновении первой ошибке:

if ($validator->stopOnFirstFailure()->fails()) {
    // ...
}

before:date

Проверяемое поле должно быть значением, предшествующим указанной дате. Даты будут переданы в функцию PHP strtotime для преобразования в действительный экземпляр DateTime. Кроме того, как и в правиле after, имя другого проверяемого поля может быть указано в качестве значения date.

before_or_equal:date

Проверяемое поле должно иметь значение, предшествующее указанной дате или равное ей. Даты будут переданы в функцию PHP strtotime для преобразования в действительный экземпляр DateTime. Кроме того, как и в правиле after, имя другого проверяемого поля может быть указано в качестве значения date.

between:min,max

Проверяемое поле должно иметь размер между указанными min и max. Строки, числа, массивы и файлы оцениваются так же, как и в правиле size.

boolean

Проверяемое поле должно иметь возможность преобразования в логическое значение. Допустимые значения: true, false, 1, 0, "1", и "0".

confirmed

Проверяемое поле должно иметь совпадающее поле {field}_confirmation. Например, если проверяемое поле – password, то поле password_confirmation также должно присутствовать во входящих данных.

date

Проверяемое поле должно быть действительной, не относительной датой в соответствии с функцией strtotime PHP.

date_equals:date

Проверяемое поле должно быть равно указанной дате. Даты будут переданы в функцию strtotime PHP для преобразования в действительный экземпляр DateTime.

date_format:format

Проверяемое поле должно соответствовать переданному format. При валидации поля следует использовать либо date, либо date_format, а не то и другое вместе. Это правило валидации поддерживает все форматы, поддерживаемые классом DateTime PHP.

different:field

Проверяемое поле должно иметь значение, отличное от field.

digits:value

Проверяемое поле должно быть числовым и иметь точную длину value.

digits_between:min,max

Проверяемое поле должно быть числовым и иметь длину между переданными min и max.

dimensions

Проверяемый файл должен быть изображением, отвечающим ограничениям размеров, указанным в параметрах правила:

'avatar' => 'dimensions:min_width=100,min_height=200'

Доступные ограничения: min_width, max_width, min_height, max_height, width, height, ratio.

Ограничение ratio должно быть представлено как ширина, разделенная на высоту. Это может быть указано дробью вроде 3/2 или числом с плавающей запятой, например 1.5:

'avatar' => 'dimensions:ratio=3/2'

Поскольку это правило требует нескольких аргументов, вы можете использовать метод Rule::dimensions для гибкости составления правила:

use Illuminate\Support\Facades\Validator;
use Illuminate\Validation\Rule;

Validator::make($data, [
    'avatar' => [
        'required',
        Rule::dimensions()->maxWidth(1000)->maxHeight(500)->ratio(3 / 2),
    ],
]);

distinct

При валидации массивов проверяемое поле не должно иметь повторяющихся значений:

'foo.*.id' => 'distinct'

По умолчанию правило distinct использует гибкое сравнение переменных. Чтобы использовать жесткое сравнение, вы можете добавить параметр strict в определение правила валидации:

'foo.*.id' => 'distinct:strict'

Вы можете добавить ignore_case к аргументам правила валидации, чтобы правило игнорировало различия в использовании регистра букв:

'foo.*.id' => 'distinct:ignore_case'

email

Проверяемое поле должно быть отформатировано как адрес электронной почты. Это правило валидации использует пакет egulias/email-validator для проверки адреса электронной почты. По умолчанию применяется валидатор RFCValidation, но вы также можете применить другие стили валидации:

'email' => 'email:rfc,dns'

В приведенном выше примере будут применяться проверки RFCValidation и DNSCheckValidation. Вот полный список стилей проверки, которые вы можете применить:

  • rfc: RFCValidation
  • strict: NoRFCWarningsValidation
  • dns: DNSCheckValidation
  • spoof: SpoofCheckValidation
  • filter: FilterEmailValidation

Валидатор filter, который использует функцию filter_var PHP, поставляется с Laravel и применялся по умолчанию до Laravel версии 5.8.

{note} Валидаторы dns и spoof требуют расширения intl PHP.

ends_with:foo,bar,...

Проверяемое поле должно заканчиваться одним из указанных значений.

exclude_if:anotherfield,value

Проверяемое поле будет исключено из данных запроса, возвращаемых методами validate и validated, если поле anotherfield равно value.

exclude_unless:anotherfield,value

Проверяемое поле будет исключено из данных запроса, возвращаемых методами validate и validated, если поле anotherfield не равно value.

exists:table,column

Проверяемое поле должно существовать в указанной таблице базы данных.

Основы использования правила Exists

'state' => 'exists:states'

Если параметр column не указан, будет использоваться имя поля. Таким образом, в этом случае правило будет проверять, что таблица базы данных states содержит запись со значением столбца state, соответствующим значению атрибута state запроса.

Указание пользовательского имени столбца

Вы можете явно указать имя столбца базы данных, которое должно использоваться правилом валидации, поместив его после имени таблицы базы данных:

'state' => 'exists:states,abbreviation'

Иногда требуется указать конкретное соединение с базой данных, которое будет использоваться для запроса exists. Вы можете сделать это, добавив имя подключения к имени таблицы:

'email' => 'exists:connection.staff,email'

Вместо того, чтобы указывать имя таблицы напрямую, вы можете указать модель Eloquent, которая должна использоваться для определения имени таблицы:

'user_id' => 'exists:App\Models\User,id'

Если вы хотите использовать свой запрос, выполняемый правилом валидации, то вы можете использовать класс Rule для гибкости определения правила. В этом примере мы также укажем правила валидации в виде массива вместо использования символа | для их разделения:

use Illuminate\Support\Facades\Validator;
use Illuminate\Validation\Rule;

Validator::make($data, [
    'email' => [
        'required',
        Rule::exists('staff')->where(function ($query) {
            return $query->where('account_id', 1);
        }),
    ],
]);

file

Проверяемое поле должно быть успешно загруженным на сервер файлом.

filled

Проверяемое поле не должно быть пустым, если оно присутствует.

gt:field

Проверяемое поле должно быть больше указанного field. Два поля должны быть одного типа. Строки, числа, массивы и файлы оцениваются с использованием тех же соглашений, что и в правиле size.

gte:field

Проверяемое поле должно быть больше или равно указанному field. Два поля должны быть одного типа. Строки, числа, массивы и файлы оцениваются с использованием тех же соглашений, что и в правиле size.

image

Проверяемый файл должен быть изображением (jpg, jpeg, png, bmp, gif, svg или webp).

in:foo,bar,...

Проверяемое поле должно быть включено в указанный список значений. Поскольку это правило часто требует, чтобы вы «объединяли» массив, то метод Rule::in можно использовать для гибкого построения правила:

use Illuminate\Support\Facades\Validator;
use Illuminate\Validation\Rule;

Validator::make($data, [
    'zones' => [
        'required',
        Rule::in(['first-zone', 'second-zone']),
    ],
]);

in_array:anotherfield.*

Проверяемое поле должно существовать в значениях anotherfield.

integer

Проверяемое поле должно быть целым числом.

{note} Это правило валидации не проверяет, что значение поля относится к типу переменной integer, а только что значение поля относится к типу, принятому правилом FILTER_VALIDATE_INT PHP. Если вам нужно проверить значение поля в качестве числа, используйте это правило в сочетании с правилом валидации numeric.

ip

Проверяемое поле должно быть IP-адресом.

ipv4

Проверяемое поле должно быть адресом IPv4.

ipv6

Проверяемое поле должно быть адресом IPv6.

json

Проверяемое поле должно быть допустимой строкой JSON.

lt:field

Проверяемое поле должно быть меньше переданного field. Два поля должны быть одного типа. Строки, числа, массивы и файлы оцениваются с использованием тех же соглашений, что и в правиле size.

lte:field

Проверяемое поле должно быть меньше или равно переданному field. Два поля должны быть одного типа. Строки, числа, массивы и файлы оцениваются с использованием тех же соглашений, что и в правиле size.

max:value

Проверяемое поле должно быть меньше или равно максимальному value. Строки, числа, массивы и файлы оцениваются с использованием тех же соглашений, что и в правиле size.

mimetypes:text/plain,...

Проверяемый файл должен соответствовать одному из указанных MIME-типов:

'video' => 'mimetypes:video/avi,video/mpeg,video/quicktime'

Чтобы определить MIME-тип загруженного файла, содержимое файла будет прочитано, и фреймворк попытается угадать MIME-тип, который может отличаться от типа, предоставленного клиентом.

mimes:foo,bar,...

Проверяемый файл должен иметь MIME-тип, соответствующий одному из перечисленных расширений.

Основы использования правила MIME

'photo' => 'mimes:jpg,bmp,png'

Несмотря на то, что вам нужно только указать расширения, это правило фактически проверяет MIME-тип файла, читая содержимое файла и угадывая его MIME-тип. Полный список типов MIME и соответствующих им расширений можно найти по следующему адресу:

https://svn.apache.org/repos/asf/httpd/httpd/trunk/docs/conf/mime.types

min:value

Проверяемое поле должно иметь минимальное значение value. Строки, числа, массивы и файлы оцениваются с использованием тех же соглашений, что и в правиле size.

multiple_of:value

Проверяемое поле должно быть кратным value.

not_in:foo,bar,...

Проверяемое поле не должно быть включено в переданный список значений. Метод Rule::notIn используется для гибкого построения правила:

use Illuminate\Validation\Rule;

Validator::make($data, [
    'toppings' => [
        'required',
        Rule::notIn(['sprinkles', 'cherries']),
    ],
]);

not_regex:pattern

Проверяемое поле не должно соответствовать переданному регулярному выражению.

Внутренне это правило использует функцию preg_match PHP. Указанный шаблон должен подчиняться тому же форматированию, требуемому preg_match, и, следовательно, также включать допустимые разделители. Например: 'email' => 'not_regex:/^.+$/i'.

{note} При использовании шаблонов regex / not_regex может потребоваться указать ваши правила валидации с использованием массива вместо использования разделителей |, особенно если регулярное выражение содержит символ |.

nullable

Проверяемое поле может быть null.

numeric

Проверяемое поле должно быть числовым.

password

Проверяемое поле должно соответствовать паролю аутентифицированного пользователя. Вы можете указать охранника аутентификации, используя первый параметр правила:

'password' => 'password:api'

present

Проверяемое поле должно присутствовать во входных данных, но может быть пустым.

prohibited

Проверяемое поле должно быть пустым или отсутствовать.

prohibited_if:anotherfield,value,...

Проверяемое поле должно быть пустым или отсутствовать, если поле anotherfield равно любому value.

prohibited_unless:anotherfield,value,...

Проверяемое поле должно быть пустым или отсутствовать, если поле anotherfield не равно какому-либо value.

regex:pattern

Проверяемое поле должно соответствовать переданному регулярному выражению.

Внутренне это правило использует функцию preg_match PHP. Указанный шаблон должен подчиняться тому же форматированию, требуемому preg_match, и, следовательно, также включать допустимые разделители. Например: 'email' => 'regex:/^.+@.+$/i'.

{note} При использовании шаблонов regex / not_regex может потребоваться указать ваши правила валидации с использованием массива вместо использования разделителей |, особенно если регулярное выражение содержит символ |.

required

Проверяемое поле должно присутствовать во входных данных и не быть пустым. Поле считается «пустым», если выполняется одно из следующих условий:

  • Значение поля равно null.
  • Значение поля – пустая строка.
  • Значение поля представляет собой пустой массив или пустой объект, реализующий интерфейс Countable.
  • Значение поля – загружаемый файл, но без пути.

required_if:anotherfield,value,...

Проверяемое поле должно присутствовать и не быть пустым, если поле anotherfield равно любому value.

Если вы хотите создать более сложное условие для правила required_if, вы можете использовать метод Rule::requiredIf. Этот метод принимает логическое значение или замыкание. При выполнении замыкания оно должно возвращать true или false, чтобы указать, обязательно ли проверяемое поле:

use Illuminate\Support\Facades\Validator;
use Illuminate\Validation\Rule;

Validator::make($request->all(), [
    'role_id' => Rule::requiredIf($request->user()->is_admin),
]);

Validator::make($request->all(), [
    'role_id' => Rule::requiredIf(function () use ($request) {
        return $request->user()->is_admin;
    }),
]);

required_unless:anotherfield,value,...

Проверяемое поле должно присутствовать и не быть пустым, если поле anotherfield не равно какому-либо value.

required_with:foo,bar,...

Проверяемое поле должно присутствовать и не быть пустым, только если любое из других указанных полей присутствует и не является пустым.

required_with_all:foo,bar,...

Проверяемое поле должно присутствовать и не быть пустым, только если все другие указанные поля присутствуют и не являются пустыми.

required_without:foo,bar,...

Проверяемое поле должно присутствовать и не быть пустым, только когда любое из других указанных полей является пустым или отсутствует.

required_without_all:foo,bar,...

Проверяемое поле должно присутствовать и не быть пустым, только когда все другие указанные поля являются пустыми или отсутствуют.

same:field

Переданное field должно соответствовать проверяемому полю.

size:value

Проверяемое поле должно иметь размер, соответствующий переданному value. Для строковых данных value соответствует количеству символов. Для числовых данных value соответствует переданному целочисленному значению (атрибут также должен иметь правило numeric или integer). Для массива size соответствует count массива. Для файлов size соответствует размеру файла в килобайтах. Давайте посмотрим на несколько примеров:

// Проверяем, что строка содержит ровно 12 символов ...
'title' => 'size:12';

// Проверяем, что передано целое число, равно 10 ...
'seats' => 'integer|size:10';

// Проверяем, что в массиве ровно 5 элементов ...
'tags' => 'array|size:5';

// Проверяем, что размер загружаемого файла составляет ровно 512 килобайт ...
'image' => 'file|size:512';

starts_with:foo,bar,...

Проверяемое поле должно начинаться с одного из указанных значений.

string

Проверяемое поле должно быть строкой. Если вы хотите, чтобы поле также могло быть null, вы должны назначить этому полю правило nullable.

timezone

Проверяемое поле должно быть допустимым идентификатором часового пояса в соответствии с функцией timezone_identifiers_list PHP.

unique:table,column,except,idColumn

Проверяемое поле не должно существовать в указанной таблице базы данных.

Указание пользовательского имени таблицы / имени столбца:

Вместо того, чтобы указывать имя таблицы напрямую, вы можете указать модель Eloquent, которая должна использоваться для определения имени таблицы:

'email' => 'unique:App\Models\User,email_address'

Параметр column используется для указания соответствующего столбца базы данных поля. Если опция column не указана, будет использоваться имя проверяемого поля.

'email' => 'unique:users,email_address'

Указание пользовательского соединения базы данных

Иногда требуется указать конкретное соединение для запросов к базе данных, выполняемых валидатором. Для этого вы можете добавить имя подключения к имени таблицы:

'email' => 'unique:connection.users,email_address'

Принудительное игнорирование правилом Unique конкретного идентификатора:

Иногда вы можете проигнорировать конкретный идентификатор во время валидации unique. Например, рассмотрим страницу «Обновления профиля», которая включает имя пользователя, адрес электронной почты и местоположение. Вероятно, вы захотите убедиться, что адрес электронной почты уникален. Однако, если пользователь изменяет только поле имени, а не поле электронной почты, то вы не захотите, чтобы выдавалась ошибка валидация, поскольку пользователь уже является владельцем рассматриваемого адреса электронной почты.

Чтобы указать валидатору игнорировать идентификатор пользователя, мы воспользуемся классом Rule для гибкого определения правила. В этом примере мы также укажем правила валидации в виде массива вместо использования символа | для их разделения:

use Illuminate\Support\Facades\Validator;
use Illuminate\Validation\Rule;

Validator::make($data, [
    'email' => [
        'required',
        Rule::unique('users')->ignore($user->id),
    ],
]);

{note} Вы никогда не должны передавать какое-либо введенное пользователем значение из запроса в метод ignore. Вместо этого вы должны передавать только сгенерированный системой уникальный идентификатор, такой как автоинкрементный идентификатор или UUID экземпляра модели Eloquent. В противном случае ваше приложение будет уязвимо для атаки с использованием SQL-инъекции.

Вместо того, чтобы передавать значение ключа модели методу ignore, вы также можете передать весь экземпляр модели. Laravel автоматически извлечет ключ из модели:

Rule::unique('users')->ignore($user)

Если ваша таблица использует имя столбца с первичным ключом, отличное от id, то вы можете указать имя столбца при вызове метода ignore:

Rule::unique('users')->ignore($user->id, 'user_id')

По умолчанию правило unique проверяет уникальность столбца, совпадающего с именем проверяемого атрибута. Однако вы можете передать другое имя столбца в качестве второго аргумента метода unique:

Rule::unique('users', 'email_address')->ignore($user->id),

Добавление дополнительных выражений Where:

Вы можете указать дополнительные условия запроса, изменив запрос с помощью метода where. Например, давайте добавим условие запроса, которое ограничивает область запроса только поиском записями, у которых значение столбца account_id равно 1:

'email' => Rule::unique('users')->where(function ($query) {
    return $query->where('account_id', 1);
})

url

Проверяемое поле должно быть действительным URL.

uuid

Проверяемое поле должно быть действительным универсальным уникальным идентификатором (UUID) RFC 4122 (версии 1, 3, 4 или 5).

Условное добавление правил

Пропуск валидации при определенных значениях полей

По желанию можно не проверять конкретное поле, если другое поле имеет указанное значение. Вы можете сделать это, используя правило валидации exclude_if. В этом примере поля appointment_date и doctor_name не будут проверяться, если поле has_appointment имеет значение false:

use Illuminate\Support\Facades\Validator;

$validator = Validator::make($data, [
    'has_appointment' => 'required|boolean',
    'appointment_date' => 'exclude_if:has_appointment,false|required|date',
    'doctor_name' => 'exclude_if:has_appointment,false|required|string',
]);

В качестве альтернативы вы можете использовать правило exclude_unless, чтобы не проверять конкретное поле, если другое поле не имеет указанного значения:

$validator = Validator::make($data, [
    'has_appointment' => 'required|boolean',
    'appointment_date' => 'exclude_unless:has_appointment,true|required|date',
    'doctor_name' => 'exclude_unless:has_appointment,true|required|string',
]);

Валидация при условии наличия

По желанию можно выполнить валидацию поля, только если это поле присутствует в проверяемых данных. Чтобы этого добиться, добавьте правило sometimes в свой список правил:

$v = Validator::make($request->all(), [
    'email' => 'sometimes|required|email',
]);

В приведенном выше примере поле email будет проверено, только если оно присутствует в массиве $request->all().

{tip} Если вы пытаетесь проверить поле, которое всегда должно присутствовать, но может быть пустым, ознакомьтесь с этим примечанием о необязательных полях.

Комплексная условная проверка

Иногда вы можете добавить правила валидации, основанные на более сложной условной логике. Например, вы можете потребовать обязательного присутствия переданного поля только в том случае, если другое поле имеет значение больше 100. Или вам может потребоваться, чтобы два поля имели указанное значение только при наличии другого поля. Добавление этих правил валидации не должно вызывать затруднений. Сначала создайте экземпляр Validator со своими статическими правилами, которые будут неизменными:

use Illuminate\Support\Facades\Validator;

$validator = Validator::make($request->all(), [
    'email' => 'required|email',
    'games' => 'required|numeric',
]);

Предположим, что наше веб-приложение предназначено для коллекционеров игр. Если коллекционер игр регистрируется в нашем приложении и у него есть более 100 игр, мы хотим, чтобы он объяснил, почему у него так много игр. Например, возможно, они владеют магазином по перепродаже игр или, может быть, им просто нравится коллекционировать игры. Чтобы условно добавить это требование, мы можем использовать метод sometimes экземпляра Validator:

$v->sometimes('reason', 'required|max:500', function ($input) {
    return $input->games >= 100;
});

Первый аргумент, переданный методу sometimes – это имя поля, которое мы условно проверяем. Второй аргумент – это список правил, которые мы хотим добавить. Если замыкание, переданное в качестве третьего аргумента, возвращает true, то правила будут добавлены. Этот метод упрощает создание сложных условных проверок. Вы даже можете добавить условные проверки сразу для нескольких полей:

$v->sometimes(['reason', 'cost'], 'required', function ($input) {
    return $input->games >= 100;
});

{tip} Параметр $input, переданный вашему замыканию, будет экземпляром Illuminate\Support\Fluent и может использоваться при валидации для доступа к вашим входящим данным и файлам запроса.

Валидация массивов

Проверка полей ввода формы на основе массива не должна быть проблемой. Вы можете использовать «точечную нотацию» для валидации атрибутов в массиве. Например, если входящий HTTP-запрос содержит поле photos[profile], вы можете проверить его следующим образом:

use Illuminate\Support\Facades\Validator;

$validator = Validator::make($request->all(), [
    'photos.profile' => 'required|image',
]);

Вы также можете проверить каждый элемент массива. Например, чтобы убедиться, что каждое электронное письмо в переданном поле ввода массива уникально, вы можете сделать следующее:

$validator = Validator::make($request->all(), [
    'person.*.email' => 'email|unique:users',
    'person.*.first_name' => 'required_with:person.*.last_name',
]);

Точно так же вы можете использовать символ * при указании пользовательских сообщений в ваших языковых файлах, что упрощает использование одного сообщения валидации для полей на основе массива:

'custom' => [
    'person.*.email' => [
        'unique' => 'Each person must have a unique email address',
    ]
],

Определение и использование

Функция array_column() возвращает значения из одного столбца входного массива.


Синтаксис

array_column(array, column_key, index_key)

Параметр значений

Параметр Описание
array Требуемый. Задает используемый многомерный массив (набор записей). Начиная с PHP 7.0, это также может быть массив объектов.
column_key Требуемый. Целочисленный ключ или строковое имя возвращаемого столбца значений. Этот параметр также может быть NULL для возврата полных массивов (полезно вместе с index_key переиндексировать массив)
index_key Необязательный. Столбец, используемый в качестве индекса/ключей для возвращаемого массива


Технические подробности

Возврат значения: Возвращает массив значений, представляющий один столбец из входного массива
PHP Версия: 5.5+