Validation

Introduction

Laravel は、application の受け取った data を validate するためのいくつかの異なるアプローチを提供しています。最も一般的なのは、すべての受信された HTTP requests で利用可能なvalidate method を使用することです。ただし、他の validation に関するアプローチについても検討します。

Laravel には、あなたが data に適用できる、便利な validation ルールが多数含まれています。さらに、database テーブル内で values が unique であるかどうかをバリデートする能力も提供しています。私たちは、あなたが Laravel の全てのバリデーション機能に精通するように、これらのバリデーションルールを詳細に説明します。

Validation Quickstart

Laravel の強力な validation features について学ぶために、フォームの validating の完全な例と、error メッセージを user に表示する方法を見てみましょう。この高レベルの概要を読むことで、Laravel を使用して、request data を validate する方法について、一般的な理解を得ることができます。

Routes の定義

まず、以下のような routes が私たちの routes/web.php ファイルに定義されていると仮定しましょう:

use App\Http\Controllers\PostController;

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

GET route は、 user が新しいブ log 投稿を作成するためのフォームを表示しますが、POST route は新しいブ log 投稿を database に保存します。

Controller の作成

次に、これらの routes への入力要求を処理するシンプルな controller を見てみましょう。現時点ではstoreの method は空のままにしておきます：

<?php

namespace App\Http\Controllers;

use Illuminate\Http\RedirectResponse;
use Illuminate\Http\Request;
use Illuminate\View\View;

class PostController extends Controller
{
    /**
     * Show the form to create a new blog post.
     */
    public function create(): View
    {
        return view('post.create');
    }

    /**
     * Store a new blog post.
     */
    public function store(Request $request): RedirectResponse
    {
        // Validate and store the blog post...

        $post = /** ... */

        return to_route('post.show', ['post' => $post->id]);
    }
}

Validation ロジックの作成

さあ、新しいブ log ポストの検証に必要なロジックを store method に埋め込む準備ができました。これを行うため、Illuminate\Http\Request object が提供する validate method を使用します。検証ルールが通過すれば、あなたのコードは正常に実行を続けます。しかし、検証が失敗すると、Illuminate\Validation\ValidationException 例外が throw され、適切な errorresponse が自動的に user に戻されます。

伝統的な HTTP request の間に validation が失敗すると、前の URL への redirect response が生成されます。入ってくる request が XHR request である場合、validation error メッセージを含む JSON responseが返されます。

validate method の理解を深めるために、store method に戻ってみましょう。

/**
 * Store a new blog post.
 */
public function store(Request $request): RedirectResponse
{
    $validated = $request->validate([
        'title' => 'required|unique:posts|max:255',
        'body' => 'required',
    ]);

    // The blog post is valid...

    return redirect('/posts');
}

ご覧の通り、 validation ルールはvalidate method に渡されます。心配しないでください - 利用可能なすべての validation ルールはドキュメント化されています。再度、 validation が失敗すると、適切な response は自動的に生成されます。 validation が通過すると、私たちの controller は通常通りに実行を続けます。

代わりに、 validation ルールは single |で区切られた string ではなく、ルールの配列として指定することもできます：

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

また、validateWithBag method を使用して request を validate し、任意の error メッセージをnamed error bagに保存することもできます。

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

最初の Validation 失敗で停止

場合によっては、最初の validation 失敗後に attribute の validation ルールの実行を停止したい場合があるかもしれません。それを行うには、bail ルールを attribute に割り当てます。

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

この例では、title attribute のuniqueルールが失敗すると、maxルールはチェックされません。ルールは割り当てられた順序で検証されます。

ネストされた Attributes についての注意点

着信する HTTP request にネストされたフィールドの data が含まれている場合、これらのフィールドを dot syntax を使用して、 validation ルールで指定することができます。

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

一方、フィールド名にリテラルなピリオドが含まれている場合、バックスラッシュでピリオドをエスケープすることで、これが "dot" syntax として解釈されるのを明示的に防ぐことができます:

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

Validation Errors の表示

それでは、着信の request フィールドが与えられた validation ルールをパスしない場合はどうなるでしょうか？以前に述べたように、 Laravel は自動的に user を前の場所に redirect します。さらに、すべての validation errors とrequest inputは自動的にsession へフラッシュされます。

$errorsvariable は、Illuminate\View\Middleware\ShareErrorsFromSession middleware によって、application のすべての views と共有されます。これはweb middleware グループによって提供されています。この middleware が適用されると、$errorsvariable は常に views で利用可能になり、$errorsvariable が常に定義されており、安全に使用できると便利に想定することができます。$errorsvariable はIlluminate\Support\MessageBagのインスタンスになります。この object の操作に関する詳細情報は、こちらのドキュメンテーションをチェックしてください。

したがって、私たちの例では、 user は、create method に validation が失敗した際にリダイレクトされ、 view の中で error メッセージを表示することが可能になります。

<!-- /resources/views/post/create.blade.php -->

<h1>Create Post</h1>

@if ($errors->any())
    <div class="alert alert-danger">
        <ul>
            @foreach ($errors->all() as $error)
                <li>{{ $error }}</li>
            @endforeach
        </ul>
    </div>
@endif

<!-- Create Post Form -->

Error メッセージのカスタマイズ

Laravel に組み込まれている validation ルールはそれぞれ、あなたの application のlang/en/validation.phpファイルに error メッセージを持っています。もし、あなたの application にlangディレクトリがない場合、lang:publish Artisan command を使って Laravel に生成させることができます。

lang/en/validation.phpファイルの中には、各 validation ルールに対する翻訳エントリーが見つかります。これらのメッセージは、あなたの application のニーズに基づいて自由に変更または修正することができます。

また、このファイルを別の言語ディレクトリにコピーして、アプリケーションの言語のメッセージを翻訳することもできます。 Laravel localization について詳しく知りたい場合は、完全なlocalization documentationをご覧ください。

WARNING

default では、Laravel application のスケルトンにはlangディレクトリが含まれていません。Laravel の言語ファイルをカスタマイズしたい場合、 lang:publish Artisan command を使って公開できます。

XHR リクエストと Validation

この例では、従来のフォームを使用して data を application に送信しました。しかし、多くの application は JavaScript で動作するフロントエンドから XHR requests を受信します。XHR request の間にvalidate method を使用すると、Laravel は redirect response を生成しません。代わりに、Laravel はすべての validation errors を含む JSON response を生成します。この JSON response は 422 HTTP status code と共に送信されます。

@error ディレクティブ

@error Blade ディレクティブを使用して、指定した attribute に対する validation error メッセージが存在するかどうかを迅速に判断することができます。@error ディレクティブ内で、$message 変数をエコーして error メッセージを表示することができます：

<!-- /resources/views/post/create.blade.php -->

<label for="title">Post Title</label>

<input id="title"
    type="text"
    name="title"
    class="@error('title') is-invalid @enderror">

@error('title')
    <div class="alert alert-danger">{{ $message }}</div>
@enderror

名前付きの error バッグを使用している場合、@error ディレクティブの第 2 引数として error バッグの名前を渡すことができます。

<input ... class="@error('title', 'post') is-invalid @enderror">

フォームの再入力

Laravel が validation error により redirect response を生成するとき、フレームワークは自動的にリクエストの input 全てを session にフラッシュします。これは、次の request で input に便利にアクセスして、 user が submit しようとしたフォームを再度入力するためです。

以前の request からフラッシュされた input を取得するには、Illuminate\\Http\\Requestのインスタンスでold method を呼び出します。old method は、sessionから以前にフラッシュされた input data を引き出します。

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

Laravel はグローバルなoldヘルパーも提供しています。古い input をBlade テンプレートで表示している場合、フォームを再入力するためにoldヘルパーを使用する方が便利です。指定されたフィールドに対して古い input が存在しない場合、nullが返されます：

<input type="text" name="title" value="{{ old('title') }}">

任意のフィールドに関する注意

default"として、"Laravel"はTrimStringsとConvertEmptyStringsToNull "middleware"を application のグローバル"middlewarestack"に含めています。したがって、null "values"を"無効"と見なさない"validator"によってnullableとしてマークする"option"の"request"フィールドが必要になることがよくあります。例えば:

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

この例では、publish_at フィールドが null または有効な日付表現のいずれかであることを指定しています。nullable モディファイヤがルール定義に追加されていない場合、 validator は null を invalid な日付とみなします。

Validation Error Response 形式

あなたの application が Illuminate\Validation\ValidationException という例外をスローし、来たる HTTP request が JSON response を期待している場合には Laravel が自動的に error メッセージを整形し、422 Unprocessable Entity という HTTP response を返します。

以下では、" validation errors "のための" JSON response "フォーマットの例を見ることができます。ネストされた" error keys " が "dot" 表記法にフラット化されることに注意してください：

{
  "message": "The team name must be a string. (and 4 more errors)",
  "errors": {
    "team_name": [
      "The team name must be a string.",
      "The team name must be at least 1 characters."
    ],
    "authorization.role": ["The selected authorization.role is invalid."],
    "users.0.email": ["The users.0.email field is required."],
    "users.2.email": ["The users.2.email must be a valid email address."]
  }
}

Form Request Validation

フォームリクエストの作成

もっと複雑な validation のシナリオについては、"form request"を作成することを検討してみてください。Form request は、独自の validation と authorization ロジックをカプセル化する custom request クラスです。 form request class を作成するには、make:request Artisan CLI command を使用します:

php artisan make:request StorePostRequest

生成される form request class は app/Http/Requests ディレクトリに配置されます。このディレクトリが存在しない場合、make:request command を実行すると作成されます。 Laravel によって生成される各 form request には、authorize と rules の 2 つのメソッドがあります。

推測された通り、authorize method は、現在 authentication されている user が request で表される action を実行できるかどうかを判断する責任があります。一方、rules method は、リクエストの data に適用すべき validation のルールを返します。

/**
 * Get the validation rules that apply to the request.
 *
 * @return array<string, \Illuminate\Contracts\Validation\Rule|array|string>
 */
public function rules(): array
{
    return [
        'title' => 'required|unique:posts|max:255',
        'body' => 'required',
    ];
}

NOTE

rules メソッドの signature 内で必要な依存関係を型ヒントとして指定することができます。それらは自動的に Laravel の service containerを通じて解決されます。

では、 validation ルールはどのように評価されますか？やることは、 controller method に request をタイプヒントするだけです。送信される form request は、 controller method が呼び出される前に検証されます。つまり、 controller を validation ロジックで混乱させる必要はありません：

/**
 * Store a new blog post.
 */
public function store(StorePostRequest $request): RedirectResponse
{
    // The incoming request is valid...

    // Retrieve the validated input data...
    $validated = $request->validated();

    // Retrieve a portion of the validated input data...
    $validated = $request->safe()->only(['name', 'email']);
    $validated = $request->safe()->except(['name', 'email']);

    // Store the blog post...

    return redirect('/posts');
}

validation が失敗した場合、 redirect response が生成され、 user を前の位置に戻します。 errors も session にフラッシュされて表示できるようになります。 request が XHR の request だった場合、 422 の status code の HTTP response が user に返されます。これにはvalidation errors の JSON 表現が含まれます。

NOTE

Inertia を駆動させる Laravel フロントエンドに、リアルタイムの form request validation を追加する必要がありますか？Laravel Precognitionをご覧ください。

追加の Validation の実行

時々、初期の validation が完了した後に追加の validation を実行する必要があります。これは、フォームリクエストのafter method を使用して達成することができます。

after method は、 validation が完了した後に呼び出されるコールバックまたはクロージャの array を返すべきです。与えられたコールバックはIlluminate\Validation\Validatorインスタンスを受け取ることができ、必要に応じて追加の error メッセージを発生させることができます。

use Illuminate\Validation\Validator;

/**
 * Get the "after" validation callables for the request.
 */
public function after(): array
{
    return [
        function (Validator $validator) {
            if ($this->somethingElseIsInvalid()) {
                $validator->errors()->add(
                    'field',
                    'Something is wrong with this field!'
                );
            }
        }
    ];
}

ご覧の通り、after method が返す array は、呼び出し可能なクラスも含むことがあります。これらのクラスの__invoke method はIlluminate\Validation\Validator インスタンスを受け取ります：

use App\Validation\ValidateShippingTime;
use App\Validation\ValidateUserStatus;
use Illuminate\Validation\Validator;

/**
 * Get the "after" validation callables for the request.
 */
public function after(): array
{
    return [
        new ValidateUserStatus,
        new ValidateShippingTime,
        function (Validator $validator) {
            //
        }
    ];
}

初回の Validation 失敗時に停止する

stopOnFirstFailureプロパティを request class に追加することで、 validator に対して、 single validation の失敗が発生した時点ですべての attributes の validating を停止するよう通知することができます。

/**
 * Indicates if the validator should stop on the first rule failure.
 *
 * @var bool
 */
protected $stopOnFirstFailure = true;

Redirect の場所をカスタマイズする

以前に話したように、 form request validation が失敗したときに user を以前の位置に戻すための redirect response が生成されます。 しかし、この動作はカスタマイズすることが自由です。 そのためには、 form request に$redirectプロパティを定義してください。

/**
 * The URI that users should be redirected to if validation fails.
 *
 * @var string
 */
protected $redirect = '/dashboard';

または、もし redirect users を名前付きの route へリダイレクトしたい場合は、代わりに $redirectRoute プロパティを定義することもできます:

/**
 * The route that users should be redirected to if validation fails.
 *
 * @var string
 */
protected $redirectRoute = 'dashboard';

フォームリクエストの認証

form request class には、authorizeという method も含まれています。この method 内で、認証された user が実際に指定された resource を update する権限を持っているかどうかを判断することができます。たとえば、 user が自身が update しようとしているブログの comment を実際に所有しているかどうかを判断することができます。最も可能性が高いのは、この method 内でauthorization gates と policiesと対話することでしょう。

use App\Models\Comment;

/**
 * Determine if the user is authorized to make this request.
 */
public function authorize(): bool
{
    $comment = Comment::find($this->route('comment'));

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

すべての form request は基本的な Laravel request class を拡張しているため、現在 authentication されている user にアクセスするためにuser method を使用することができます。また、上記の例でroute method を呼び出すことに注目してください。この method は、呼び出される route 上で定義された URI パラメータにアクセスする権限を与えます。例えば、以下の例の{comment}パラメータなどです:

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

したがって、あなたの application がroute model bindingを利用している場合、解決された model を request のプロパティとしてアクセスすることで、あなたの code をさらに簡潔にすることができます:

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

authorize method がfalseを返す場合、自動的に 403 の status code を持つ HTTP response が返され、 controller method は実行されません。

もしあなたが request に対する handle authorization のロジックを application の他の部分で計画しているなら, authorize method 全体を削除してもよいし, 単にtrueを返すだけでも構いません：

/**
 * Determine if the user is authorized to make this request.
 */
public function authorize(): bool
{
    return true;
}

NOTE

authorizeメソッドの signature 内で必要な依存関係を型ヒントとして指定することができます。それらは自動的に Laravel のservice containerを通じて解決されます。

Error メッセージのカスタマイズ

form request によって使用される error メッセージをカスタマイズすることができます。これは、messages method をオーバーライドすることにより行います。この method は、 attribute /ルールのペアとそれに対応する error メッセージの array を返すべきです：

/**
 * Get the error messages for the defined validation rules.
 *
 * @return array<string, string>
 */
public function messages(): array
{
    return [
        'title.required' => 'A title is required',
        'body.required' => 'A message is required',
    ];
}

Validation Attributes のカスタマイズ

Laravel の組み込みの validation ルールの error メッセージの多くには、 :attributeプレースホルダーが含まれています。もし、あなたが validation メッセージの :attribute プレースホルダーを custom attribute の名前に置き換えたい場合は、attributes method をオーバーライドすることで custom の名前を指定できます。この method は、 attribute / 名前のペアの array を返すべきです：

/**
 * Get custom attributes for validator errors.
 *
 * @return array<string, string>
 */
public function attributes(): array
{
    return [
        'email' => 'email address',
    ];
}

Input の Validation のための準備

あなたが validation ルールを適用する前に、 request から の任意の data を準備したり、消毒する必要がある場合は、prepareForValidation method を使用することができます:

use Illuminate\Support\Str;

/**
 * Prepare the data for validation.
 */
protected function prepareForValidation(): void
{
    $this->merge([
        'slug' => Str::slug($this->slug),
    ]);
}

同様に、 validation が完了した後で request data を正規化する必要がある場合は、 passedValidation method を使用することができます。

/**
 * Handle a passed validation attempt.
 */
protected function passedValidation(): void
{
    $this->replace(['name' => 'Taylor']);
}

Manually Creating Validators

validate method を request で使用したくない場合は、Validator facadeを使って手動で validator のインスタンスを作成することができます。 facade 上のmake method は新しい validator インスタンスを生成します：

<?php

namespace App\Http\Controllers;

use Illuminate\Http\RedirectResponse;
use Illuminate\Http\Request;
use Illuminate\Support\Facades\Validator;

class PostController extends Controller
{
    /**
     * Store a new blog post.
     */
    public function store(Request $request): RedirectResponse
    {
        $validator = Validator::make($request->all(), [
            'title' => 'required|unique:posts|max:255',
            'body' => 'required',
        ]);

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

        // Retrieve the validated input...
        $validated = $validator->validated();

        // Retrieve a portion of the validated input...
        $validated = $validator->safe()->only(['name', 'email']);
        $validated = $validator->safe()->except(['name', 'email']);

        // Store the blog post...

        return redirect('/posts');
    }
}

makeの method に渡される最初の引数は、 validation の下の data です。第二の引数は、 data に適用すべき validation ルールの array です。

request validation が失敗したかどうかを判断した後、withErrors method を使用して error メッセージを session にフラッシュすることができます。この method を使用すると、リダイレクト後に$errors変数が自動的にあなたの views と共有され、それらを簡単に user に表示することができます。withErrors method は validator 、MessageBag、または PHP のarrayを受け入れます。

最初の Validation 失敗で停止

stopOnFirstFailuremethod は、一度でも単一の validation 失敗が発生した場合、すべての属性の検証を停止するようにバリ data に通知します：

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

自動リダイレクション

手動で validator インスタンスを作成するが、 HTTP リクエストの validate method による自動リダイレクト機能を利用したい場合は、存在する validator インスタンスに対して validate method を呼び出すことができます。 validation が失敗した場合、 user は自動的にリダイレクトされ、または XHR の request の場合、JSON response が返されます:

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

validateWithBag '' method ''を使用して、'' validation ''が失敗した場合に、名前付きの'' error '' bagに'' error ''メッセージを保存することができます。

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

名前付き Error バッグ

単一のページに複数のフォームがある場合、MessageBagに名前を付けて validation エラーを格納し、特定のフォームの error メッセージを取得することが望ましいかもしれません。これを実現するには、withErrorsへの第二引数として名前を渡します。

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

その後、$errors変数から名前付きのMessageBagインスタンスにアクセスできます：

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

Error メッセージのカスタマイズ

必要に応じて、validator インスタンスが Laravel によって提供される default の error メッセージの代わりに使用する customerror メッージを提供することができます。custom メッセージを指定する方法はいくつかあります。まず、Validator::make method の第三引数として custom メッセージを渡すことができます。

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

この例では、:attributeプレースホルダーは validation の下のフィールドの実際の名前に置き換えられます。また、 validation メッセージで他のプレースホルダーを利用することもできます。例えば：

$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',
];

特定の Attribute に対して Custom メッセージを指定する

時には、特定の「 attribute 」に対してだけ「 custom error 」メッセージを指定したいことがあるかもしれません。その場合は"dot"記法を使用して指定できます。先に属性名を指定し、次にルールを指定します：

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

Custom Attribute Values の指定

Laravel の組み込みの error メッセージの多くには、:attributeというプレースホルダが含まれており、これはフィールド名または validation 下の attribute に置き換えられます。これらのプレースホルダを特定のフィールドに対して置き換えるための values をカスタマイズするには、Validator::make method の第 4 引数として custom attributes の array を渡すことができます：

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

追加の Validation を実行する

時には、初期の validation が完了した後に、追加の validation を行う必要があります。これは、validator の after method を使用して達成できます。 after method は、クロージャまたは validation が完了した後に呼び出される array の呼び出し可能なものを受け入れます。与えられた呼び出し可能なものは、 Illuminate\Validation\Validatorインスタンスを受け取り、必要に応じて追加の error メッセージを出します。

use Illuminate\Support\Facades\Validator;

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

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

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

前述のように、after method は、array 型のコールバックも受け取ることができます。これは、バリデーション後のロジックが __invoke method で Illuminate\Validation\Validator インスタンスを受け取る呼び出し可能なクラスにカプセル化されている場合に特に便利です。

use App\Validation\ValidateShippingTime;
use App\Validation\ValidateUserStatus;

$validator->after([
    new ValidateUserStatus,
    new ValidateShippingTime,
    function ($validator) {
        // ...
    },
]);

Working With Validated Input

form request または手動で作成したバリ data インスタンスを使用して、着信する requestdata の validation を行ったあと、実際に validation を受けた requestdata を取得したい場合があるでしょう。これはいくつかの方法で実現できます。まず、validatedmethod を form request またはバリ data インスタンスに呼び出すことができます。この method は validation が行われた data の array を返します：

$validated = $request->validated();

$validated = $validator->validated();

あるいは、safe method を form request や validator インスタンスで呼び出すこともできます。この method は Illuminate\Support\ValidatedInput のインスタンスを返します。この object は、検証済みの data の一部または検証済みの data の全ての array を取得するための only, except, all メソッドを公開します。

$validated = $request->safe()->only(['name', 'email']);

$validated = $request->safe()->except(['name', 'email']);

$validated = $request->safe()->all();

また、Illuminate\Support\ValidatedInputインスタンスは、 array のように繰り返しアクセスすることができます：

// Validated data may be iterated...
foreach ($request->safe() as $key => $value) {
    // ...
}

// Validated data may be accessed as an array...
$validated = $request->safe();

$email = $validated['email'];

検証済みの data に追加のフィールドを追加したい場合は、merge method を呼び出すことができます：

$validated = $request->safe()->merge(['name' => 'Taylor Otwell']);

承認済みの data をcollectionインスタンスとして取得したい場合、collect method を呼び出すことができます：

$collection = $request->safe()->collect();

Working With Error Messages

Validatorインスタンス上のerrorsの method を呼び出した後、便利なメソッドが揃ったIlluminate\Support\MessageBagインスタンスを受け取ります。これらのメソッドは error メッセージを操作するためのものです。すべての views で自動的に利用可能となる$errorsvariable も、MessageBagの class のインスタンスでもあります。

フィールドの最初の Error メッセージを取得する

指定されたフィールドの最初の error メッセージを取得するには、first method を使用してください。

$errors = $validator->errors();

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

フィールドのすべての Error メッセージを取得する

特定のフィールドのすべてのメッセージの array を取得する必要がある場合は、get method を使用してください:

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

array のフォームフィールドを validating する場合、* 文字を使用して各 array elements のメッセージをすべて取得することができます。

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

すべてのフィールドのすべての Error メッセージを取得する

すべてのフィールドのすべてのメッセージの array を取得するには、all method を使用します:

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

フィールドにメッセージが存在するかどうかの判定

has method は、指定されたフィールドに対して何かしらの error メッセージが存在するかどうかを判断するために使用することができます：

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

言語ファイルでの Custom メッセージの指定

Laravel の組み込みの validation ルールは、それぞれがあなたの application のlang/en/validation.phpファイルに位置する error メッセージを持っています。あなたの application がlangディレクトリを持っていない場合、lang:publishの Artisan command を使用して Laravel にそれを作成するよう指示することができます。

lang/en/validation.php ファイル内には、それぞれの validation ルールに対する翻訳エントリが存在します。これらのメッセージは、あなたの application の要件に基づいて変更または修正することが自由です。

また、このファイルを別の言語ディレクトリにコピーして、アプリケーションの言語のメッセージを翻訳することもできます。 Laravel localization について詳しく知るために、完全なlocalization documentationをご覧ください。

WARNING

default では、Laravel application のスケルトンにはlangディレクトリが含まれていません。Laravel の言語ファイルをカスタマイズしたい場合、 lang:publish Artisan command を使って公開できます。

特定の Attributes 向けの Custom メッセージ

アプリケーションの validation 言語ファイル内で、特定の attribute およびルールの組み合わせに使用される error メッセージをカスタマイズできます。これを行うには、メッセージのカスタマイズをアプリケーションの lang/xx/validation.php 言語ファイルの custom array に追加します：

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

言語ファイルでの Attributes の指定

Laravel の組み込みの error メッセージの多くには、:attributeプレースホルダーが含まれており、これは、検証の対象となるフィールド名または属性に置き換えられます。もしあなたが検証メッセージの中の:attribute部分を customvalues に置き換えたい場合は、lang/xx/validation.php言語ファイルのattributesarray に custom 属性名を指定することができます。

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

WARNING

default では、Laravel application のスケルトンにはlangディレクトリが含まれていません。Laravel の言語ファイルをカスタマイズしたい場合、 lang:publish Artisan command を使って公開できます。

言語ファイルでの Values の指定

Laravel の組み込み validation ルール error メッセージには、request attribute の現在の value に置き換えられる :value プレースホルダーが含まれているものがあります。しかし、validation メッセージの :value 部分を value のカスタム表現に置き換える必要がある場合もあります。例えば、次のルールは、payment_type が cc の値を持つ場合にクレジットカード番号が必須であることを指定します。

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

この validation ルールが失敗すると、次のような error メッセージが表示されます：

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

lang/xx/validation.phpを支払いの type value として表示する代わりに、values array を定義することで、あなたの**TERMcc**言語ファイルでよりユーザーフレンドリーな value 表現を指定することができます。

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

WARNING

default では、Laravel application のスケルトンにはlangディレクトリが含まれていません。Laravel の言語ファイルをカスタマイズしたい場合、 lang:publish Artisan command を使って公開できます。

この value を定義した後、 validation ルールは次の error メッセージを生成します：

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

Available Validation Rules

以下は、利用可能な全ての validation ルールとその機能の一覧です：

accepted

validation の下のフィールドは、"yes"、"on"、1、"1"、true、または"true"でなければなりません。これは、利用規約の承認または同様のフィールドの検証に役立ちます。

accepted_if:anotherfield,value

バリデーション中のフィールドは、別のバリデーション中のフィールドが特定の値に等しい場合に、"yes", "on", 1, "1", true, または "true" でなければなりません。これは、 "Terms of Service" の受諾や同様のフィールドのバリデーションに便利です。

active_url

validation フィールドは、dns_get_record PHP 関数に従って、有効な A レコードまたは AAAA レコードを持つ必要があります。提供された URL のホスト名は、dns_get_recordに渡す前に、parse_url PHP 関数を使用して抽出されます。

after:date

validation の下のフィールドは、指定された日付以降の value でなければなりません。日付は、有効なDateTimeインスタンスに変換するためにstrtotime PHP 関数に渡されます。

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

strtotimeで評価するための日付 string を渡す代わりに、日付と比較するための別のフィールドを指定することもできます：

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

afteror_equal:_date

validation のフィールドは、指定された日付以降、またはそれと同じ value でなければなりません。詳細は、afterルールを参照してください。

alpha

validation フィールドは、完全に Unicode アルファベット文字である必要があり、これらは\p{L} と\p{M} に含まれていなければなりません。

この validation ルールを ASCII 範囲内の文字 (a-z および A-Z) に制限するには、 validation ルールに ascii オプションを指定できます。

'username' => 'alpha:ascii',

alpha_dash

validation 中のフィールドは、Unicode アルファベット・数字キャラクター \p{L} , \p{M} , \p{N} および ASCII ダッシュ (-) と ASCII アンダースコア (_) で構成されている必要があります。

この validation ルールを ASCII 範囲内の文字 (a-z および A-Z) に制限するには、バリデーションルールに ascii オプションを指定できます。

'username' => 'alpha_dash:ascii',

alpha_num

validation の下のフィールドは、\p{L} 、\p{M} 、および\p{N} に含まれる Unicode の英数字の文字でなければなりません。

この validation ルールを ASCII 範囲内の文字 (a-z および A-Z) に制限するには、バリデーションルールに ascii オプションを指定できます。

'username' => 'alpha_num:ascii',

array

validation の下のフィールドは PHP のarrayでなければなりません。

arrayルールに追加の values が提供されると、 input array の各キーは、ルールに提供された values のリスト内に存在しなければなりません。次の例では、 input array のadminキーは、arrayルールに提供された values のリストに含まれていないため、 invalid です。

use Illuminate\Support\Facades\Validator;

$input = [
    'user' => [
        'name' => 'Taylor Otwell',
        'username' => 'taylorotwell',
        'admin' => true,
    ],
];

Validator::make($input, [
    'user' => 'array:name,username',
]);

一般的には、常に array 内に存在しても良い array keys を指定すべきです。

ascii

validation の下のフィールドは、完全に 7 ビットの ASCII 文字でなければなりません。

bail

最初の validation の失敗後、フィールドに対する validation ルールの実行を停止します。

bailルールは、 validation エラーが発生した場合に特定のフィールドの validating を停止するだけですが、stopOnFirstFailure method は、 validator に対して、 single validation エラーが発生した時点で全ての attributes の validating を停止すべきであることを通知します：

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

before:date

validation の下のフィールドは、指定された日付より前の value でなければなりません。日付は、有効なDateTimeインスタンスに変換するために PHP のstrtotime関数に渡されます。さらに、afterルールと同様に、 validation の下の別のフィールドの名前がdateの value として指定されることもあります。

beforeor_equal:_date

validation の下のフィールドは、指定された日付より前またはそれと同じ value でなければなりません。日付は PHP の strtotime 関数に渡されて有効な DateTime インスタンスに変換されます。さらに、afterルールと同様に、 validation の下の別のフィールド名が dateの value として提供されることもあります。

between:min,max

validation のフィールドは、与えられたminとmax(含む)の間のサイズを持つ必要があります。文字列、数値、配列、ファイルは、sizeルールと同じ方法で評価されます。

boolean

「" validation "」の下のフィールドは、「" boolean "」としてキャストできる必要があります。受け入れられる「" input "」は、true、false、1、0、"1"、および"0"です。

confirmed

validation の下のフィールドは、{field}_confirmationと一致するフィールドを持つ必要があります。たとえば、 validation の下のフィールドがpasswordの場合、一致するpassword_confirmationフィールドが input 内に存在しなければなりません。

contains:foo,bar

validation の下のフィールドは、指定されたパラメータの values を全て含む array でなければなりません。

current_password

validation フィールドは認証されたユーザーの password と match しなければなりません。ルールの最初のパラメータを使用して、authentication ガードを指定することもできます。

'password' => 'current_password:api'

date

strtotime PHP 関数に従って、 validation の下のフィールドは有効で相対的でない日付でなければなりません。

dateequals:_date

validation フィールドは、指定された日付と等しくなければなりません。日付は PHP のstrtotime関数に渡され、有効なDateTimeインスタンスに変換されます。

dateformat:_format

validation の下のフィールドは、指定されたformatsのいずれかと match した必要があります。フィールドを validating する時に、dateとdate_formatのどちらか一方を使用すべきであり、両方を使用するべきではありません。この validation ルールは、PHP のDateTime class がサポートしている全てのフォーマットをサポートしています。

decimal:min,max

validation の下のフィールドは数値でなければならず、指定された数の小数位を含んでいなければなりません：

// Must have exactly two decimal places (9.99)...
'price' => 'decimal:2'

// Must have between 2 and 4 decimal places...
'price' => 'decimal:2,4'

declined

「" validation "」の下のフィールドは、"no"、"off"、0、"0"、false、または"false"でなければなりません。

declined_if:anotherfield,value

「 validation 」の下のフィールドは、別の「 validation 」の下のフィールドが指定の「 value 」に等しい場合、"no"、"off"、0、"0"、false、または"false"でなければなりません。

different:field

validation の下のフィールドは、fieldとは異なる value を持つ必要があります。

digits:value

validation の下の integer は、正確な length を _ value _ でなければなりません。

digitsbetween:_min,max

integer validation は指定されたminとmaxの間の length を持たなければなりません。

dimensions

validation という項目の下にあるファイルは、ルールのパラメータで指定された寸法制約を満たす image でなければなりません:

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

利用可能な制約は次の通りです：min_width、max_width、min_height、max_height、width、height、ratio。

比率 制約は、幅を高さで割ったものとして表現する必要があります。これは 3/2 のような分数または 1.5 のような浮動小数点数で指定できます：

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

このルールはいくつかの引数が必要なため、Rule::dimensions method を用いて流暢にルールを作成することができます。

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

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

distinct

array を検証する際、検証の下のフィールドには、重複する values が存在してはなりません：

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

Distinct はデフォルトで default の緩い変数比較を使用します。 厳密な比較を使用するには、 validation ルールの定義にstrictパラメータを追加することができます。

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

ルールの引数に ignore_case を追加して、そのルールが ignore 大文字と小文字の違いを無視するようにすることができます：

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

doesntstart_with:_foo,bar

validation の下のフィールドは、指定された values のいずれかで始まってはなりません。

doesntend_with:_foo,bar

validation の下のフィールドは、与えられた values のいずれかで終わってはなりません。

email

validation フィールドは email アドレスとしてフォーマットされていなければなりません。この validation ルールは、 email アドレスの validating にegulias/email-validator パッケージを使用します。 default では、RFCValidation validator が適用されますが、他の validation スタイルも適用することができます:

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

上記の例では、RFCValidationとDNSCheckValidationの検証が適用されます。以下は、適用できる validation スタイルの完全なリストです。

filtervalidator は、PHP のfilter_var関数を使用し、Laravel に付属しています。これは、Laravelversion5.8 より前の Laravel の default の mail 検証動作でした。

WARNING

dnsおよびspoofバリデーターは、PHP のintl拡張が必要です。

endswith:_foo,bar

validation の下のフィールドは、指定された values のいずれかで終わらなければなりません。

enum

Enumルールは、 validation 対象のフィールドが有効な enum value を含むかどうかを検証する、 class ベースのルールです。Enumルールは、その唯一のコンストラクター引数として Enum の名前を受け入れます。 values について validating する際には、バックアップされた enum をEnumルールへ提供すべきです。

use App\Enums\ServerStatus;
use Illuminate\Validation\Rule;

$request->validate([
    'status' => [Rule::enum(ServerStatus::class)],
]);

Enum ルールの only メソッドと except メソッドは、どの enum ケースを有効とみなすべきかを制限するために使われることができます：

Rule::enum(ServerStatus::class)
    ->only([ServerStatus::Pending, ServerStatus::Active]);

Rule::enum(ServerStatus::class)
    ->except([ServerStatus::Pending, ServerStatus::Active]);

when method は、条件付きでEnumルールを変更するために使用することができます：

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

Rule::enum(ServerStatus::class)
    ->when(
        Auth::user()->isAdmin(),
        fn ($rule) => $rule->only(...),
        fn ($rule) => $rule->only(...),
    );

exclude

validateとvalidatedメソッドが返す request data から、 validation の下のフィールドは除外されます。

excludeif:_anotherfield,value

もしanotherfieldフィールドが* value *に等しい場合、validateおよびvalidatedメソッドによって返される request data から validation の下のフィールドは除外されます。

複雑な条件付き排除ロジックが必要な場合は、Rule::excludeIf method を利用できます。この method は、ブール values またはクロージャを受け入れます。クロージャが指定された場合、そのクロージャは、検証対象のフィールドが除外されるべきかどうかを示すためにtrueまたはfalseを返す必要があります：

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

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

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

excludeunless:_anotherfield,value

validateとvalidatedmethods が返す requestdata から validation の下のフィールドは、anotherfieldのフィールドが value に等しくない場合、除外されます。もし value がnullである場合(exclude_unless:name,null)、validation の下のフィールドは、requestdata からの比較フィールドがnullである場合や比較フィールドが欠けている場合を除き、除外されます。

excludewith:_anotherfield

validate と validated メソッドによって返される request data から、 anotherfield フィールドが存在する場合、 validation の下のフィールドが除外されます。

excludewithout:_anotherfield

validate および validated メソッドにより返される request data から、anotherfield フィールドが存在しない場合、 validation の下のフィールドは除外されます。

exists:table,column

validation フィールドは、指定された database テーブル内に存在しなければなりません。

Exists ルールの基本的な使い方

'state' => 'exists:states'

column option が指定されていない場合、フィールド名が使用されます。したがって、この場合、ルールは states database テーブルに、request の state attribute value に一致する state column value を持つレコードが含まれていることを validate します。

Custom Column の名前を指定する

database column の column 名を指定して、 validation ルールに使用するよう明示的に指示することができます。それを database のテーブル名の後に配置します：

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

たまに、特定の database 接続をexistsの query で使用するよう指定する必要があるかもしれません。これは、テーブル名の前に接続名を追加することで実現できます：

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

テーブル名を直接指定する代わりに、テーブル名を決定するために用いるべき Eloquent model を指定することもできます：

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

validation ルールによって実行される query をカスタマイズしたい場合は、Rule class を使用して直感的にルールを定義することができます。この例では、|文字を使用してデリミットする代わりに validation ルールを array として指定します：

use Illuminate\Database\Query\Builder;
use Illuminate\Support\Facades\Validator;
use Illuminate\Validation\Rule;

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

existsルールを生成するRule::existsmethod によって使用されるべき database の列の名前を明示的に指定することができます。これは、existsmethod の第 2 引数として列の名前を提供することによって行います。

'state' => Rule::exists('states', 'abbreviation'),

extensions:foo,bar

validation の下のファイルには、リストされた extensions のいずれかに対応するユーザーが割り当てた拡張子が必要です：

'photo' => ['required', 'extensions:jpg,png'],

WARNING

user が割り当てた拡張子だけでファイルを検証することには決して頼るべきではありません。このルールは通常、mimesまたはmimetypesのルールと組み合わせて使用するべきです。

file

validation のフィールドは、正常にアップロードされたファイルでなければなりません。

filled

validation フィールドは存在する場合、空にしてはなりません。

gt:field

validation の下のフィールドは、指定されたフィールドまたはvalueより大きくなければなりません。 2 つのフィールドは同じ type でなければなりません。 string、数 value、array、ファイルは、 size ルールと同じ規則を使用して評価されます。

gte:field

validation の下のフィールドは、指定されたfieldまたは * value *以上でなければなりません。2 つのフィールドは同じ type でなければなりません。文字列、数値、配列、ファイルは、size ルールと同じ規則を使用して評価されます。

hex_color

validation フィールドには16 進数 形式で有効な色の value が含まれていなければなりません。

image

validation の下のファイルは image (jpg、jpeg、png、bmp、gif、svg、または webp)でなければなりません。

in:foo,bar

validation の下のフィールドは、 values の指定されたリストに含まれていなければなりません。このルールは、しばしば array を implode することを要求しますので、ルールの構築には Rule::in method を流暢に使用することができます。

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

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

inルールがarrayルールと組み合わされると、 input array の各 value は、inルールに提供された values のリスト内に存在しなければなりません。次の例では、 input array の中のLAS空港の code は、inルールに提供された空港のリストに含まれていないため、 invalid です。

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

$input = [
    'airports' => ['NYC', 'LAS'],
];

Validator::make($input, [
    'airports' => [
        'required',
        'array',
    ],
    'airports.*' => Rule::in(['NYC', 'LIT']),
]);

inarray:_anotherfield.*

validation の下のフィールドは、anotherfieldの values に存在しなければならない。

integer

validation の下のフィールドは integer でなければなりません。

WARNING

この validation ルールは、入力が"integer"variable の type であることを検証するものではなく、入力が PHP のFILTER_VALIDATE_INTルールが受け付ける type であることだけを検証します。入力が数 values であることを validate する必要がある場合は、このルールを数 values のnumeric validation ルールと併用してください。

ip

validation の下のフィールドは IP アドレスでなければなりません。

ipv4

validation の下のフィールドは IPv4 アドレスでなければなりません。

ipv6

validation の下のフィールドは IPv6 アドレスでなければなりません。

json

validation の下のフィールドは、有効な JSON string でなければなりません。

lt:field

validation の下のフィールドは、指定されたfieldより小さい必要があります。これら 2 つのフィールドは同じ type でなければなりません。文字列、数値、配列、ファイルは、sizeルールと同じ規則で評価されます。

lte:field

フィールドは validation 以下でなければならず、特定のfieldと等しくなければなりません。2 つのフィールドは同じ type でなければなりません。文字列、数値、配列、およびファイルは、sizeルールと同じ規則を使用して評価されます。

lowercase

validation の下のフィールドは小文字でなければなりません。

list

validation の下のフィールドは、リストである array でなければなりません。 array は、その keys が 0 からcount($array) - 1までの連続した数字で構成されている場合にリストと見なされます。

mac_address

validation の下のフィールドは MAC アドレスでなければなりません。

max:value

validation というフィールドは最大* value *以下でなければなりません。文字列、数値、配列、ファイルはsizeルールと同様の方法で評価されます。

maxdigits:_value

validation の下にある integer は、最大 length が* value *である必要があります。

mimetypes:text/plain

validation の下のファイルは、指定された MIME タイプのいずれかと match でなければなりません：

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

アップロードされたファイルの MIME type を決定するために、ファイルの内容が読み込まれ、フレームワークは MIME type を試みるでしょう。これは、client が提供した MIME type とは異なる場合があります。

mimes:foo,bar

validation の下のファイルは、リストされた extensions のいずれかに対応する MIME type を持っていなければなりません：

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

extensions を指定するだけで十分なのに、このルールでは実際にはファイルの内容を読み取ってその MIME type を推測し、ファイルの MIME type を検証します。MIME タイプと対応する extensions の完全なリストは、以下の場所で見つけることができます:

MIME タイプと Extensions

この validation ルールは、MIME type と、 user がファイルに割り当てた拡張子との間の一致を確認しません。たとえば、mimes:png の validation ルールは、有効な PNG content を含むファイルを有効な PNG image であるとみなします。たとえそのファイルが photo.txt と名付けられていてもです。ファイルのユーザーが割り当てた拡張子を validate したい場合は、extensionsルールを使用できます。

min:value

validation の下のフィールドは、最小の value を持つ必要があります。文字列、数値、配列、ファイルは、sizeルールと同じ方法で評価されます。

mindigits:_value

validation の下の integer は、 length が最小 value でなければなりません。

multipleof:_value

validation の下のフィールドは、* value *の倍数でなければなりません。

missing

input data に validation のフィールドは存在してはなりません。

missingif:_anotherfield,value

validation のフィールドは、anotherfield フィールドが任意の value と等しい場合に存在してはなりません。

missingunless:_anotherfield,value

anotherfield フィールドが任意の value に等しい unless 場合を除き、 validation フィールドは存在してはなりません。

missingwith:_foo,bar

validation というフィールドは、指定された他のフィールドが存在する場合のみ存在してはならない。

missingwith_all:_foo,bar

validation のフィールドは、指定された他の全てのフィールドが存在する場合にのみ、存在してはならない。

notin:_foo,bar

validation フィールドは、 values の指定リストに含まれてはなりません。Rule::notIn method を使用して、ルールを流暢に構築することが可能です。

use Illuminate\Validation\Rule;

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

notregex:_pattern

validation の下のフィールドは、指定された正規表現と match してはいけません。

このルールは内部で PHP のpreg_match関数を使用しています。指定すべきパターンはpreg_matchが required としているフォーマットに従い、有効なデリミタも含むべきです。例えば: 'email' => 'not_regex:/^.+$/i'となります。

WARNING

regex / not_regex パターンを使用する際には、特に正規表現に | 文字が含まれている場合、| デリミタの代わりに array を使用して validation 規則を指定する必要があるかもしれません。

nullable

validation の下のフィールドは、nullになる可能性があります。

numeric

validation の下のフィールドはnumeric でなければなりません。

present

input data に validation フィールドが存在しなければなりません。

presentif:_anotherfield,value

anotherfield フィールドが value のいずれかと等しい場合、 validation フィールドが存在しなければなりません。

presentunless:_anotherfield,value

validation の下のフィールドは、anotherfield フィールドが value のいずれかと等しい場合を除き、必ず存在しなければなりません。

presentwith:_foo,bar

validation の下のフィールドは、指定された他のフィールドのいずれかが存在する場合にのみ存在しなければならない。

presentwith_all:_foo,bar

validation のフィールドは、指定された他の全てのフィールドが存在する場合にのみ存在 していなければなりません 。

prohibited

validation の下のフィールドは存在しないか、もしくは空でなければなりません。フィールドが empty であるとは、以下の基準のいずれかを満たしている場合を指します：

prohibitedif:_anotherfield,value

「 validation の下のフィールドは、anotherfieldフィールドが* value *のいずれかと等しい場合、欠落しているか空でなければなりません。フィールドが「空」であるとは、次の基準のいずれかを満たしている場合を指します：

複雑な条件付き禁止ロジックが required である場合、Rule::prohibitedIf method を利用することができます。この method は、 boolean またはクロージャを受け入れます。クロージャが与えられた場合、そのクロージャは、 validation の下でフィールドが禁止されるべきかどうかを示すためにtrueまたはfalseを返すべきです：

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

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

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

prohibitedunless:_anotherfield,value

「 validation 」フィールドは、「 unless 」anotherfieldフィールドが「" value "」のいずれかと等しい場合を除き、欠落または空でなければなりません。フィールドが「empty」であるとは、以下の基準のいずれかを満たす場合を指します：

prohibits:anotherfield

validation のフィールドが欠落していないか空でない場合、anotherfieldの全てのフィールドは欠落しているか空でなければなりません。フィールドが「空」であるとは、次の基準の一つを満たす場合を指します：

regex:pattern

validation と記されたフィールドは、与えられた正規表現と match しなければなりません。

内部的には、この規則は PHP の preg_match 関数を使用します。指定されるパターンは preg_match が required フォーマットを守る必要があり、有効な区切り記号も含める必要があります。例えば：'email' => 'regex:/^.+@.+$/i'。

WARNING

regex / not_regex パターンを使用する場合、特に正規表現に | 文字が含まれている場合、| デリミタを使用する代わりに array でルールを指定する必要がある場合があります。

required

validation の下のフィールドは、 input data に存在し、空でなければなりません。 フィールドが"empty"である場合、次の基準のいずれかを満たします:

requiredif:_anotherfield,value

anotherfieldフィールドが任意の value と等しければ、 validation の下のフィールドは存在し、空でなければなりません。

required_ifルールに対してより複雑な条件を構築したい場合、Rule::requiredIf method を使用できます。この method は、ブール values またはクロージャを受け入れます。クロージャが渡された場合、そのクロージャはtrueまたはfalseを返すべきで、それは validation 対象のフィールドが必要かどうかを示します:

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(fn () => $request->user()->is_admin),
]);

requiredif_accepted:_anotherfield

validation の欄は、anotherfieldのフィールドが"yes"、"on"、1、"1"、true、または"true"に等しい場合、存在し、空でない必要があります。

requiredif_declined:_anotherfield

validation フィールドは、もしanotherfield フィールドが"no"、"off"、0、"0"、false、または"false"に等しい場合、存在し、空でなければなりません。

requiredunless:_anotherfield,value

validation フィールドは、 unless の anotherfieldフィールドが _ value _ に等しい場合を除き、存在し、空でない必要があります。これはまた、anotherfield が request data unless の _ value _ が nullでない限り存在しなければならないことを意味します。もし* value *が null(required_unless:name,null)だった場合、比較フィールドがnullである、または request data から比較フィールドが欠落している場合、 validation 下のフィールドは required unless が適用されます。

requiredwith:_foo,bar

validation のフィールドは、他の指定されたフィールドのいずれかが存在し、空ではない 場合のみ 存在し、空でない必要があります。

requiredwith_all:_foo,bar

validation フィールドは、他のすべての指定されたフィールドが存在し、空でない場合にのみ存在し、空でない必要があります。

requiredwithout:_foo,bar

validation フィールドは、他の指定されたフィールドが空または存在しない 場合に限り、存在し、空でなければなりません。

requiredwithout_all:_foo,bar

validation の下のフィールドは、他のすべての指定されたフィールドが空か存在しない場合にのみ、存在しなければならず空であってはなりません。

requiredarray_keys:_foo,bar

validation の下のフィールドは array でなければならず、少なくとも指定された keys を含む必要があります。

same:field

指定された field は、 validation 下のフィールドと match しなければなりません。

size:value

validation と記載されたフィールドは、指定された value と一致するサイズを持たなければなりません。 string data の場合、 value は文字数に対応します。 data が数値の場合、 value は指定された integer value ( attribute もまた、numeric または integer ルールを持たなければなりません)に対応します。 array の場合、size は array の count に対応します。ファイルの場合、size はキロバイト単位のファイルサイズに対応します。いくつかの例を見てみましょう：

// Validate that a string is exactly 12 characters long...
'title' => 'size:12';

// Validate that a provided integer equals 10...
'seats' => 'integer|size:10';

// Validate that an array has exactly 5 elements...
'tags' => 'array|size:5';

// Validate that an uploaded file is exactly 512 kilobytes...
'image' => 'file|size:512';

startswith:_foo,bar

validation の下のフィールドは、指定された values のいずれかで始まる必要があります。

string

validation 項目は string でなければなりません。フィールドをnullにも許可したい場合は、そのフィールドにnullableルールを割り当てるべきです。

timezone

validation のフィールドは、DateTimeZone::listIdentifiers method に従った有効な timezone 識別子でなければなりません。

この validation ルールにも、DateTimeZone::listIdentifiers method によって受け入れられる引数 を提供することができます：

'timezone' => 'required|timezone:all';

'timezone' => 'required|timezone:Africa';

'timezone' => 'required|timezone:per_country,US';

unique:table,column

validation というフィールドは与えられた database テーブル内に存在してはなりません。

Custom テーブル / Column 名の指定:

テーブル名を直接指定する代わりに、テーブル名を決定するために使用すべき Eloquent model を指定することができます：

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

column オプションは、フィールドの対応する database column を指定するために使用することができます。column オプションが指定されていない場合、 validation 下のフィールドの名前が使用されます。

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

Custom Database Connection の指定

時折、 Validator によって行われる database のクエリに対して custom connection を設定する必要があるかもしれません。これを達成するためには、テーブル名の前に connection の名前を追加することができます：

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

特定の ID を Ignore する Unique ルールの強制:

時として、特定の ID を「 ignore 」として unique validation 中に無視したい場合があるかもしれません。例えば、「プロフィールを更新」画面があり、そこにはユーザーの名前、 email アドレス、および位置情報が含まれています。 email アドレスが unique であることを確認したくなるでしょう。しかし、もし user が名前欄だけを変更し、 email 欄を変更しない場合、問題の email アドレスの既存の所有者が user であるため、 validation error をスローしたくないでしょう。

user の ID を無視するようにバリ data に指示するために、Ruleclass を流暢に規定するルールを使用します。この例では、validation ルールを|文字で規則を区切る代わりに array として指定します：

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

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

WARNING

あなたは決して、ignore method に、user が制御する request 入力を渡すべきではありません。代わりに、自動インクリメント ID や、Eloquent model インスタンスからの UUID のようなシステムが生成した unique な ID のみを渡すべきです。そうしないと、あなたの application は SQL インジェクション攻撃に対して脆弱となります。

ignore method への model キーの value の渡す代わりに、 model の全インスタンスを渡すこともできます。 Laravel は自動的に model からキーを抽出します。

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

あなたのテーブルがid以外の primary キーの column 名を使用している場合、ignoreの method を呼び出すときにその column の名前を指定することができます：

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

default では、uniqueルールは、検証されている attribute の名前に一致する column の一意性をチェックします。ただし、unique method の第 2 引数として別の column 名を指定することもできます。

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

追加の Where 句の追加:

where method を使用して、query をカスタマイズすることにより、追加の query 条件を指定できます。例えば、account_idcolumn の value が1であるレコードだけを検索する query 条件を追加しましょう。

'email' => Rule::unique('users')->where(fn (Builder $query) => $query->where('account_id', 1))

uppercase

validation の下のフィールドは大文字でなければなりません。

url

validation の下のフィールドは有効な URL でなければなりません。

有効とみなすべき URL プロトコルを指定したい場合は、 validation ルールパラメータとしてプロトコルを渡すことができます：

'url' => 'url:http,https',

'game' => 'url:minecraft,steam',

ulid

validation の項目は、有効なUniversally Unique Lexicographically Sortable Identifier ( ULID )でなければなりません。

uuid

validation の下のフィールドは、有効な RFC 4122(バージョン 1、3、4、または 5)の unique な識別子( UUID )でなければなりません。

Conditionally Adding Rules

フィールドが特定の Values を持つ場合の Validation スキップ

たまに、あるフィールドがある value を持っている場合に、特定のフィールドの validate を行いたくないかもしれません。これは、exclude_if validation ルールを使用して実現できます。この例では、has_appointment フィールドが false の value を持っている場合、appointment_date および doctor_name フィールドは検証されません：

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',
]);

別の選択肢として、特定のフィールドが特定の value を持つ場合に限り、特定のフィールドを validate しないように、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',
]);

Validating が存在する場合

一部の状況では、検証される data にそのフィールドが存在する場合にのみ、フィールドに対して validation チェックを実行したい場合があります。これを素早く実現するには、sometimesルールをルールリストに追加します。

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

上記の例では、emailフィールドは、$dataの array に存在する場合にのみ検証されます。

NOTE

もし常に存在するべきだが、空であるかもしれないフィールドを validate しようとしている場合は、このオプションのフィールドに関するメモをチェックしてください。

複雑な条件付き Validation

時には、より複雑な条件ロジックに基づいた validation ルールを追加したい場合があるかもしれません。例えば、あるフィールドが 100 よりも大きい value を持つ場合にのみ、特定のフィールドを必須にすることが望ましいかもしれません。または、他のフィールドが存在する場合にのみ、2 つのフィールドが特定の value を持つ必要があるかもしれません。これらの validation ルールを追加するために苦労する必要はありません。まず、static rules(静的なルール)を持つValidatorインスタンスを作成します。これらのルールは変わることがありません。

use Illuminate\Support\Facades\Validator;

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

私たちの web application がゲーム収集家のためのものだと仮定しましょう。ゲーム収集家が私たちの application に登録し、そして彼らが 100 以上のゲームを所有している場合、なぜそんなに多くのゲームを所有しているのか説明してもらいたいと思います。例えば、ゲームのリセールショップを運営しているかもしれませんし、単にゲーム収集を楽しんでいるだけかもしれません。この要件を条件付きで追加するために、Validatorインスタンスのsometimes method を使用することができます。

use Illuminate\Support\Fluent;

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

sometimesの最初の引数は、条件付きでバリデートしているフィールドの名前です。2 番目の引数は追加したいルールのリストです。3 番目の引数として渡されるクロージャがtrueを返すと、ルールが追加されます。この method により、複雑な条件付き検証を作成するのが容易になります。複数のフィールドに一度に条件付き検証を追加することも可能です。

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

NOTE

あなたのクロージャに渡される $input パラメータは Illuminate\Support\Fluent のインスタンスとなり、 input や validation の下にあるファイルにアクセスするために使用することができます。

複雑な条件付き Array Validation

時々、同じネストされた array 内の別のフィールドに基づいてフィールドを validate したい場合があるかもしれませんが、そのインデックスはわかりません。このような状況では、クロージャに 2 つ目の引数を受け取らせることができます。これは現在検証中の array の個々の項目になります。

$input = [
    'channels' => [
        [
            'type' => 'email',
            'address' => 'abigail@example.com',
        ],
        [
            'type' => 'url',
            'address' => 'https://example.com',
        ],
    ],
];

$validator->sometimes('channels.*.address', 'email', function (Fluent $input, Fluent $item) {
    return $item->type === 'email';
});

$validator->sometimes('channels.*.address', 'url', function (Fluent $input, Fluent $item) {
    return $item->type !== 'email';
});

クロージャに渡される$inputパラメータと同様に、$itemパラメータは属性 data が array の場合、Illuminate\Support\Fluentのインスタンスです。それ以外の場合、それは string です。

Validating Arrays

array validation ルールのドキュメンターションで議論されたように、array ルールは許可された array keys のリストを受け入れます。追加の keys が array 内に存在する場合、 validation は失敗します:

use Illuminate\Support\Facades\Validator;

$input = [
    'user' => [
        'name' => 'Taylor Otwell',
        'username' => 'taylorotwell',
        'admin' => true,
    ],
];

Validator::make($input, [
    'user' => 'array:name,username',
]);

一般的に、あなたの array 内に存在してもよい array keys を常に指定するべきです。そうしないと、バリ keys の validate および validated methods は、すべての検証済みの data を返します。これには、 array およびそのすべての keys 、それが他のネストされた array validation ルールによって検証されていなくても含まれます。

Validating ネストされた Array Input

ネストされた「 array 」ベースのフォーム「 input 」フィールドの「 Validating 」は苦痛である必要はありません。"dot notation"を使用して、 「 array 」内の「 validate attributes 」を利用することができます。例えば、送信されてくる「 HTTP request 」が photos[profile] フィールドを含んでいる場合、以下のように「 validate 」することができます：

use Illuminate\Support\Facades\Validator;

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

あなたはまた、 array の各要素を validate することもできます。例えば、与えられた array input フィールドの中の各 email が unique であることを validate するために、次のようにすることができます：

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

同様に、あなたは*文字を使用して、言語ファイルでcustomvalidation メッセージを指定する際に使用することができます。これにより、array ベースのフィールドに対する単一の validation メッセージを使用することが非常に簡単になります。

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

ネストされた Array Data へのアクセス

時々、Rule::forEach method を使用して、特定のネストされた array 要素の value にアクセスする必要があるかもしれません。これは、attribute に validation ルールを割り当てる際に必要になる場合があります。forEach method はクロージャを受け取り、それを validation 下の array attribute の各反復で呼び出し、attribute の value と明示的な、完全に展開された attribute 名を受け取ります。クロージャは、array 要素に割り当てるルールの array を返す必要があります：

use App\Rules\HasPermission;
use Illuminate\Support\Facades\Validator;
use Illuminate\Validation\Rule;

$validator = Validator::make($request->all(), [
    'companies.*.id' => Rule::forEach(function (string|null $value, string $attribute) {
        return [
            Rule::exists(Company::class, 'id'),
            new HasPermission('manage-company', $value),
        ];
    }),
]);

Error メッセージのインデックスと位置

array を検証する際に、特定のアイテムのインデックスまたは位置を参照して、そのアイテムが検証に失敗したことを application が表示する error メッセージ内に表示することがあります。これを達成するためには、あなたのcustom 検証メッセージ内に:index(0から始まる)および:position(1から始まる)プレースホルダーを含めることができます：

use Illuminate\Support\Facades\Validator;

$input = [
    'photos' => [
        [
            'name' => 'BeachVacation.jpg',
            'description' => 'A photo of my beach vacation!',
        ],
        [
            'name' => 'GrandCanyon.jpg',
            'description' => '',
        ],
    ],
];

Validator::validate($input, [
    'photos.*.description' => 'required',
], [
    'photos.*.description.required' => 'Please describe photo #:position.',
]);

上記の例から、 validation は失敗し、 user には次のような error が表示されます。"Please describe photo #2."

必要であれば、second-index、second-position、third-index、third-position、 etc など、より深くネストされたインデックスや位置を参照することができます。

'photos.*.attributes.*.string' => 'Invalid attribute for photo #:second-position.',

Validating Files

Laravel は、mimes、image、min、maxなど、アップロードされたファイルを validate するために使用できるさまざまな validation ルールを提供しています。ファイルを validating する際にこれらのルールを個別に指定することも自由ですが、 Laravel はまた、便利なファイル validation ルールビルダーも提供しています:

use Illuminate\Support\Facades\Validator;
use Illuminate\Validation\Rules\File;

Validator::validate($input, [
    'attachment' => [
        'required',
        File::types(['mp3', 'wav'])
            ->min(1024)
            ->max(12 * 1024),
    ],
]);

もしご自身の application が users からアップロードされた画像を受け入れる場合、アップロードされたファイルが image であることを示すために、File ルールの image コンストラクタ method を使用することができます。また、dimensions ルールを使用して、 image の次元を制限することも可能です：

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

Validator::validate($input, [
    'photo' => [
        'required',
        File::image()
            ->min(1024)
            ->max(12 * 1024)
            ->dimensions(Rule::dimensions()->maxWidth(1000)->maxHeight(500)),
    ],
]);

NOTE

validating image の寸法に関する詳しい情報は、dimension rule documentationで見つけることができます。

ファイルサイズ

便宜上、最小および最大のファイルサイズはファイルサイズの単位を示す接尾辞を含む string として指定することができます。 kb、mb、gb、およびtbの接尾辞がサポートされています：

File::image()
    ->min('1kb')
    ->max('10mb')

ファイルタイプ

types method を呼び出すときには extensions だけを指定する必要がありますが、この method は実際にはファイルの内容を読み取り、その MIME type を推定することでファイルの MIME type を検証します。MIME type とそれに対応する extensions の全リストは次の場所で見つけることができます:

Validating Passwords

適切なレベルの複雑さを持つ passwords を確保するために、Laravel の Password ルールの object を使用することができます:

use Illuminate\Support\Facades\Validator;
use Illuminate\Validation\Rules\Password;

$validator = Validator::make($request->all(), [
    'password' => ['required', 'confirmed', Password::min(8)],
]);

Passwordルールの object を使用すると、たとえば password には少なくとも 1 つの文字、数字、記号、または大文字と小文字が混在する文字が必要であることを指定するなど、 application の passwords の複雑さの要件を簡単にカスタマイズできます。

// Require at least 8 characters...
Password::min(8)

// Require at least one letter...
Password::min(8)->letters()

// Require at least one uppercase and one lowercase letter...
Password::min(8)->mixedCase()

// Require at least one number...
Password::min(8)->numbers()

// Require at least one symbol...
Password::min(8)->symbols()

また、uncompromised method を使って、 password が public password data ブリーチ漏洩で侵害されていないことを確認することもできます。

Password::min(8)->uncompromised()

内部的には、Passwordルール object は k-Anonymity model の使用で、ユーザーのプライバシーやセキュリティを犠牲にすることなく、ある password がhaveibeenpwned.com service 経由で漏洩したかどうかを判断します。

default で、 password が一度でも data リークに出現すると、それは侵害されたと見なされます。この閾 values は、uncompromised method の最初の引数を使用してカスタマイズできます。

// Ensure the password appears less than 3 times in the same data leak...
Password::min(8)->uncompromised(3);

もちろん、上記の例のすべてのメソッドを連鎖させることが可能です：

Password::min(8)
    ->letters()
    ->mixedCase()
    ->numbers()
    ->symbols()
    ->uncompromised()

Default Password ルールの定義

passwords の default validation ルールをアプリケーションの single ロケーションに指定することが便利です。Password::defaults method を使用すると、これを簡単に実現できます。defaults method に渡されるクロージャは、Password ルールの default 構成を返す必要があります。通常、defaults ルールはアプリケーションの service providers の 1 つの boot method 内で呼び出されるべきです。

use Illuminate\Validation\Rules\Password;

/**
 * Bootstrap any application services.
 */
public function boot(): void
{
    Password::defaults(function () {
        $rule = Password::min(8);

        return $this->app->isProduction()
                    ? $rule->mixedCase()->uncompromised()
                    : $rule;
    });
}

次に、特定の password が validation を受けるときに default のルールを適用したい場合、引数なしでdefaults method を呼び出すことができます:

'password' => ['required', Password::defaults()],

たまに、追加の validation ルールを default の password 検証ルールに attach したい場合があるかもしれません。これを達成するために、rules method を使用できます。

use App\Rules\ZxcvbnRule;

Password::defaults(function () {
    $rule = Password::min(8)->rules([new ZxcvbnRule]);

    // ...
});

Custom Validation Rules

ルールオブジェクトの使用

Laravel はさまざまな便利な validation ルールを提供しています。しかし、自分自身でいくつか指定したい場合もあるでしょう。custom バリデーションルールを登録する一つの方法は、ルールオブジェクトを使用することです。新しいルール object を生成するためには、make:rule Artisan command を使用することができます。この command を使用して、string が大文字であることを確認するルールを生成してみましょう。Laravel は新しいルールをapp/Rulesディレクトリに配置します。このディレクトリが存在しない場合、Laravel はルールを作成するための Artisan command を実行するときにそれを作成します。

php artisan make:rule Uppercase

ルールが作成されたら、その振る舞いを定義する準備が整います。ルールの object は、 single method ：validateを含みます。この method は、 attribute の名前、その value 、そして、 validation error メッセージで失敗時に呼び出すべきコールバックを受け取ります：

<?php

namespace App\Rules;

use Closure;
use Illuminate\Contracts\Validation\ValidationRule;

class Uppercase implements ValidationRule
{
    /**
     * Run the validation rule.
     */
    public function validate(string $attribute, mixed $value, Closure $fail): void
    {
        if (strtoupper($value) !== $value) {
            $fail('The :attribute must be uppercase.');
        }
    }
}

ルールが定義されたら、そのルールの object のインスタンスを他の validation ルールと一緒に渡すことで、それを validator に attach することができます：

use App\Rules\Uppercase;

$request->validate([
    'name' => ['required', 'string', new Uppercase],
]);

Validation メッセージの翻訳

$failクロージャに直訳的な error メッセージを提供する代わりに、翻訳 string キーを提供し、 Laravel に error メッセージの翻訳を指示することもできます。

if (strtoupper($value) !== $value) {
    $fail('validation.uppercase')->translate();
}

必要に応じて、プレースホルダーの代替内容と優先言語を、translate method の第一引数および第二引数として提供できます。

$fail('validation.location')->translate([
    'value' => $this->value,
], 'fr')

追加の Data にアクセスする

もし、あなたの custom validation ルールの class が、すべての他の data に対する validation にアクセスする必要がある場合、あなたのルールの class は、Illuminate\Contracts\Validation\DataAwareRuleインターフェースを実装することができます。 このインターフェースでは、あなたの class がsetData method を定義することが必要です。 この method は、すべての data に対する validation が開始する前に(Laravel により)自動的に呼び出されます。

<?php

namespace App\Rules;

use Illuminate\Contracts\Validation\DataAwareRule;
use Illuminate\Contracts\Validation\ValidationRule;

class Uppercase implements DataAwareRule, ValidationRule
{
    /**
     * All of the data under validation.
     *
     * @var array<string, mixed>
     */
    protected $data = [];

    // ...

    /**
     * Set the data under validation.
     *
     * @param  array<string, mixed>  $data
     */
    public function setData(array $data): static
    {
        $this->data = $data;

        return $this;
    }
}

または、もし validation ルールが実行中の validator インスタンスへのアクセスを必要とする場合、ValidatorAwareRuleインターフェースを実装することができます。

<?php

namespace App\Rules;

use Illuminate\Contracts\Validation\ValidationRule;
use Illuminate\Contracts\Validation\ValidatorAwareRule;
use Illuminate\Validation\Validator;

class Uppercase implements ValidationRule, ValidatorAwareRule
{
    /**
     * The validator instance.
     *
     * @var \Illuminate\Validation\Validator
     */
    protected $validator;

    // ...

    /**
     * Set the current validator.
     */
    public function setValidator(Validator $validator): static
    {
        $this->validator = $validator;

        return $this;
    }
}

Using Closures

あなたが application 全体で一度だけ custom ルールの機能が必要な場合、ルールの object の代わりにクロージャを使用することができます。クロージャは属性の名前、属性の value 、そして validation が失敗した場合に呼び出されるべき$failコールバックを受け取ります：

use Illuminate\Support\Facades\Validator;
use Closure;

$validator = Validator::make($request->all(), [
    'title' => [
        'required',
        'max:255',
        function (string $attribute, mixed $value, Closure $fail) {
            if ($value === 'foo') {
                $fail("The {$attribute} is invalid.");
            }
        },
    ],
]);

暗黙のルール

default によると、検証される属性が存在しない、または空の string を含む場合、通常の検証ルール(custom ルールを含む)は実行されません。例えば、空の string に対してuniqueルールは実行されません。

use Illuminate\Support\Facades\Validator;

$rules = ['name' => 'unique:users,name'];

$input = ['name' => ''];

Validator::make($input, $rules)->passes(); // true

属性が空であっても custom ルールが実行されるようにするには、そのルールが属性が必須であることを示さなければなりません。新しい暗黙的な object ルールを素早く生成するには、make:rule Artisan command を--implicitoption とともに使用することができます：

php artisan make:rule Uppercase --implicit

WARNING

"暗黙的な" ルールは、単に attribute が required であることを示唆しているだけです。実際に欠落しているまたは空の attribute を無効にするかどうかはあなた次第です。