メインコンテンツまでスキップ

バリデーション

はじめに​

Laravel は、アプリケーションの受信データを検証するためのさまざまなアプローチを提供しています。ほとんどの場合、すべての受信 HTTP リクエストで利用可能な validate メソッドを使用することが一般的です。ただし、他の検証アプローチについても説明します。

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 メソッドは空のままにしておきます:

    <?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]);
        }
    }

検証ロジックの記述​

新しいブログ投稿を検証するためのロジックを store メソッドに記入する準備が整いました。これには、Illuminate\Http\Request オブジェクトが提供する validate メソッドを使用します。検証ルールが成功すると、コードは通常通り実行されます。ただし、検証に失敗すると、Illuminate\Validation\ValidationException 例外がスローされ、適切なエラーレスポンスが自動的にユーザーに送信されます。

HTTPリクエスト中に検証が失敗した場合、前のURLにリダイレクトする応答が生成されます。着信リクエストがXHRリクエストである場合、検証エラーメッセージを含むJSON応答が返されます。

validateメソッドをよりよく理解するために、storeメソッドに戻りましょう：

    /**
     * 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');
    }

検証ルールが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',
    ]);

この例では、title属性のuniqueルールが失敗した場合、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はユーザーを自動的に前の場所にリダイレクトします。さらに、すべての検証エラーとリクエスト入力はセッションに自動的にフラッシュされます。

Illuminate\View\Middleware\ShareErrorsFromSessionミドルウェアによって、$errors変数がすべてのアプリケーションのビューで共有されます。このミドルウェアが適用されると、ビューで常に$errors変数が利用可能になり、$errors変数が常に定義されて安全に使用できると便利です。$errors変数はIlluminate\Support\MessageBagのインスタンスになります。このオブジェクトの操作方法について詳しくは、そのドキュメントを参照してください。

したがって、この例では、検証に失敗した場合にユーザーをコントローラーのcreateメソッドにリダイレクトし、ビューでエラーメッセージを表示できます：

<!-- /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 -->

エラーメッセージのカスタマイズ​

Laravelの組み込みの検証ルールには、アプリケーションのlang/en/validation.phpファイルにあるエラーメッセージがあります。langディレクトリがない場合は、lang:publishArtisanコマンドを使用して作成するようにLaravelに指示できます。

lang/en/validation.phpファイル内には、各検証ルールの翻訳エントリがあります。アプリケーションのニーズに基づいてこれらのメッセージを変更または修正することができます。

さらに、このファイルを別の言語ディレクトリにコピーして、アプリケーションの言語のメッセージを翻訳することができます。Laravelのローカライゼーションについて詳しく知りたい場合は、完全なローカライゼーションドキュメントを参照してください。

警告

デフォルトでは、Laravelアプリケーションのスケルトンにはlangディレクトリが含まれていません。Laravelの言語ファイルをカスタマイズしたい場合は、lang:publishArtisanコマンドを使用して公開することができます。

XHRリクエストとバリデーション​

この例では、伝統的なフォームを使用してアプリケーションにデータを送信しました。ただし、多くのアプリケーションはJavaScriptで動作するフロントエンドからXHRリクエストを受信します。XHRリクエスト中にvalidateメソッドを使用すると、Laravelはリダイレクトレスポンスを生成しません。代わりに、Laravelはバリデーションエラーを含むJSONレスポンスを生成します。このJSONレスポンスは422 HTTPステータスコードで送信されます。

@errorディレクティブ​

指定された属性に対するバリデーションエラーメッセージが存在するかどうかを迅速に判断するために@error Bladeディレクティブを使用できます。@errorディレクティブ内では、エラーメッセージを表示するために$message変数をエコーすることができます：

<!-- /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ディレクティブの第2引数としてエラーバッグの名前を渡すことができます：

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

フォームの再入力​

Laravelがバリデーションエラーによるリダイレクトレスポンスを生成すると、フレームワークは自動的にリクエストのすべての入力をセッションにフラッシュします。これにより、次のリクエスト中に入力に便利にアクセスし、ユーザーが送信しようとしたフォームを再入力できます。

前のリクエストからフラッシュされた入力を取得するには、Illuminate\Http\Requestのインスタンスでoldメソッドを呼び出します。oldメソッドは、以前にフラッシュされた入力データをセッションから取得します：

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

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

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

オプションフィールドに関する注意​

デフォルトでは、Laravel はアプリケーションのグローバルミドルウェアスタックに TrimStrings と ConvertEmptyStringsToNull ミドルウェアを含めます。そのため、バリデータが null 値を無効として扱わない場合は、"オプション"のリクエストフィールドを nullable としてマークする必要があります。例：

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

この例では、publish_at フィールドが null または有効な日付表現のいずれかであることを指定しています。ルール定義に nullable 修飾子が追加されていない場合、バリデータは null を無効な日付と見なします。

バリデーションエラーレスポンスのフォーマット​

アプリケーションが Illuminate\Validation\ValidationException 例外をスローし、着信 HTTP リクエストが JSON レスポンスを期待している場合、Laravel は自動的にエラーメッセージをフォーマットして 422 Unprocessable Entity HTTP レスポンスを返します。

以下では、バリデーションエラーのための JSON レスポンスフォーマットの例を確認できます。ネストされたエラーキーは "ドット" 表記形式に平坦化されています：

{
    "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."
        ]
    }
}

フォームリクエストのバリデーション​

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

より複雑なバリデーションシナリオの場合、"フォームリクエスト" を作成することができます。フォームリクエストは、独自のバリデーションと認可ロジックをカプセル化したカスタムリクエストクラスです。フォームリクエストクラスを作成するには、make:request Artisan CLI コマンドを使用できます：

php artisan make:request StorePostRequest

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

おそらくお察しの通り、authorize メソッドは、リクエストによって表されるアクションを現在認証されているユーザーが実行できるかどうかを決定し、rules メソッドはリクエストデータに適用すべきバリデーションルールを返します。

    /**
     * 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',
        ];
    }

注記

rules メソッドのシグネチャ内で必要な依存関係を型ヒントすることができます。これらは Laravel の サービスコンテナ を介して自動的に解決されます。

バリデーションルールはどのように評価されますか？コントローラーメソッドでリクエストを型ヒントするだけで済みます。コントローラーメソッドが呼び出される前に、受信したフォームリクエストが検証されるため、コントローラーに検証ロジックを詰め込む必要はありません。

    /**
     * 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');
    }

検証に失敗した場合、ユーザーを前の場所に戻すためにリダイレクトレスポンスが生成されます。エラーはセッションにフラッシュされ、表示可能になります。リクエストが XHR リクエストである場合、422 ステータスコードを含む HTTP レスポンスがユーザーに返され、検証エラーの JSON 表現が含まれます。

注記

Inertia を使用した Laravel フロントエンドにリアルタイムフォームリクエスト検証を追加する必要がありますか？Laravel Precognition をチェックしてください。

追加の検証の実行​

初期の検証が完了した後に追加の検証を実行する必要がある場合があります。これはフォームリクエストの after メソッドを使用して行うことができます。

after メソッドは、検証が完了した後に呼び出される配列のコールバックまたはクロージャを返す必要があります。指定されたコールバックは Illuminate\Validation\Validator インスタンスを受け取り、必要に応じて追加のエラーメッセージを出力できます。

    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 メソッドによって返される配列には、呼び出し可能なクラスも含めることができます。これらのクラスの __invoke メソッドは 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) {
            //
        }
    ];
}

最初の検証ルールの失敗で停止​

リクエストクラスに stopOnFirstFailure プロパティを追加することで、バリデータに、1 つの検証失敗が発生した時点ですべての属性の検証を停止するように指示できます。

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

リダイレクトの場所をカスタマイズする​

前述の通り、フォームリクエストのバリデーションが失敗した場合、ユーザーを前の場所に戻すリダイレクトレスポンスが生成されます。ただし、この動作をカスタマイズすることも可能です。これを行うには、フォームリクエストに$redirectプロパティを定義します：

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

または、ユーザーを名前付きルートにリダイレクトしたい場合は、代わりに$redirectRouteプロパティを定義することができます：

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

フォームリクエストの認可​

フォームリクエストクラスにはauthorizeメソッドも含まれています。このメソッド内で、認証されたユーザーが実際に指定されたリソースを更新する権限を持っているかどうかを判断することができます。たとえば、ユーザーが更新しようとしているブログコメントを実際に所有しているかどうかを判断することができます。おそらく、このメソッド内で認可ゲートおよびポリシーとやり取りすることになるでしょう：

    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);
    }

すべてのフォームリクエストは基本となるLaravelリクエストクラスを拡張しているため、userメソッドを使用して現在認証されているユーザーにアクセスできます。また、上記の例でrouteメソッドを呼び出していることにも注意してください。このメソッドを使用すると、例えば以下の例の{comment}パラメータなど、呼び出されているルートで定義されたURIパラメータにアクセスできます：

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

したがって、アプリケーションがルートモデルバインディングを利用している場合、リクエストのプロパティとして解決されたモデルにアクセスすることで、コードをより簡潔にすることができます：

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

authorizeメソッドがfalseを返すと、403ステータスコードを持つHTTPレスポンスが自動的に返され、コントローラーメソッドは実行されません。

リクエストの認可ロジックをアプリケーションの別の部分で処理する予定がある場合は、authorizeメソッドを完全に削除するか、単にtrueを返すだけでも構いません。

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

注記

authorize メソッドのシグネチャ内で必要な依存関係をタイプヒントすることができます。これらは Laravel の サービスコンテナ を介して自動的に解決されます。

エラーメッセージのカスタマイズ​

フォームリクエストで使用されるエラーメッセージをカスタマイズすることができます。messages メソッドをオーバーライドすることで行います。このメソッドは、属性とルールのペアとそれに対応するエラーメッセージの配列を返す必要があります。

    /**
     * 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',
        ];
    }

バリデーション属性のカスタマイズ​

Laravel の組み込みバリデーションルールのエラーメッセージには :attribute プレースホルダが含まれています。バリデーションメッセージの :attribute プレースホルダをカスタム属性名で置き換えたい場合は、attributes メソッドをオーバーライドしてカスタム名を指定することができます。このメソッドは、属性と名前のペアの配列を返す必要があります。

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

バリデーションのための入力の準備​

バリデーションルールを適用する前にリクエストからデータを準備したりサニタイズしたりする必要がある場合は、prepareForValidation メソッドを使用できます。

    use Illuminate\Support\Str;

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

同様に、バリデーションが完了した後にリクエストデータを正規化する必要がある場合は、passedValidation メソッドを使用できます。

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

手動でバリデータを作成する​

リクエストで validate メソッドを使用したくない場合は、Validator ファサード を使用して手動でバリデータインスタンスを作成することができます。ファサード上の make メソッドは新しいバリデータインスタンスを生成します。

    <?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 メソッドに渡される最初の引数はバリデーション対象のデータです。2番目の引数はデータに適用するべきバリデーションルールの配列です。

リクエストのバリデーションが失敗したかどうかを判断した後、withErrors メソッドを使用してエラーメッセージをセッションにフラッシュすることができます。このメソッドを使用すると、リダイレクト後に $errors 変数が自動的にビューと共有され、ユーザーに簡単に表示できます。withErrors メソッドは、バリデータ、MessageBag、または PHP の array を受け入れます。

最初の検証エラーで停止​

stopOnFirstFailure メソッドは、1つの検証エラーが発生した時点で、すべての属性の検証を停止するようにバリデータに通知します：

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

自動リダイレクト​

バリデータインスタンスを手動で作成したいが、HTTPリクエストの validate メソッドが提供する自動リダイレクト機能を利用したい場合は、既存のバリデータインスタンスで 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');

名前付きエラーバッグ​

1つのページに複数のフォームがある場合、検証エラーを含む MessageBag に名前を付けて、特定のフォームのエラーメッセージを取得できるようにすることができます。これを実現するには、withErrors の第2引数に名前を渡します：

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

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

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

エラーメッセージのカスタマイズ​

必要に応じて、Laravelが提供するデフォルトのエラーメッセージの代わりに、バリデータインスタンスが使用するカスタムエラーメッセージを指定することができます。カスタムメッセージを指定する方法はいくつかあります。まず、Validator::make メソッドの第3引数としてカスタムメッセージを渡すことができます：

    $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 メソッドは、検証が完了した後に呼び出されるクロージャまたは呼び出し可能な配列を受け入れます。指定された呼び出し可能な関数は、必要に応じて追加のエラーメッセージを発生させるために Illuminate\Validation\Validator インスタンスを受け取ります：

    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 メソッドは、呼び出し可能な配列も受け入れます。これは、"検証後" のロジックが呼び出し可能クラスにカプセル化されている場合に特に便利です。これらのクラスは、__invoke メソッドを介して Illuminate\Validation\Validator インスタンスを受け取ります：

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

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

検証済みの入力を扱う​

フォームリクエストや手動で作成したバリデータインスタンスを使用して受信したリクエストデータを検証した後、実際に検証された受信リクエストデータを取得したい場合があります。これはいくつかの方法で実現できます。まず、フォームリクエストやバリデータインスタンスで validated メソッドを呼び出すことができます。このメソッドは、検証されたデータの配列を返します：

    $validated = $request->validated();

    $validated = $validator->validated();

また、フォームリクエストやバリデータインスタンスで safe メソッドを呼び出すこともできます。このメソッドは Illuminate\Support\ValidatedInput のインスタンスを返します。このオブジェクトは、検証されたデータのサブセットまたは検証されたデータの配列全体を取得するための only、except、all メソッドを公開しています：

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

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

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

また、Illuminate\Support\ValidatedInput インスタンスは、配列のように反復処理およびアクセスできます：

    // 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'];

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

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

検証済みデータを collection インスタンスとして取得したい場合は、collect メソッドを呼び出すことができます：

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

エラーメッセージの取り扱い​

Validator インスタンスの errors メソッドを呼び出した後、エラーメッセージを取り扱うための便利なメソッドを持つ 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の組み込みバリデーションルールには、アプリケーションの lang/en/validation.php ファイルに配置されているエラーメッセージがそれぞれ含まれています。lang ディレクトリが存在しない場合は、lang:publish Artisanコマンドを使用してLaravelにそのディレクトリを作成するよう指示できます。

lang/en/validation.php ファイル内には、各バリデーションルールに対する翻訳エントリが含まれています。これらのメッセージは、アプリケーションのニーズに基づいて自由に変更または修正できます。

さらに、このファイルを別の言語ディレクトリにコピーして、アプリケーションの言語に対するメッセージを翻訳することができます。Laravelのローカライゼーションについて詳しく知りたい場合は、完全なローカライゼーションドキュメントを参照してください。

警告

デフォルトでは、Laravelアプリケーションのスケルトンには lang ディレクトリが含まれていません。Laravelの言語ファイルをカスタマイズしたい場合は、lang:publish Artisanコマンドを使用してそれらを公開することができます。

特定の属性用のカスタムメッセージ​

アプリケーションのバリデーション言語ファイル内で、指定された属性とルールの組み合わせに使用されるエラーメッセージをカスタマイズすることができます。これを行うには、アプリケーションの lang/xx/validation.php 言語ファイルの custom 配列にメッセージのカスタマイズを追加してください：

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

言語ファイルで属性を指定する​

Laravelの多くの組み込みエラーメッセージには、:attribute プレースホルダが含まれており、これはバリデーション中のフィールドまたは属性の名前で置換されます。バリデーションメッセージの :attribute 部分をカスタム値で置換したい場合は、lang/xx/validation.php 言語ファイルの attributes 配列にカスタム属性名を指定できます：

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

警告

デフォルトでは、Laravelアプリケーションのスケルトンには lang ディレクトリが含まれていません。Laravelの言語ファイルをカスタマイズしたい場合は、lang:publish Artisanコマンドを使用してそれらを公開することができます。

言語ファイルでの値の指定​

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 を表示する代わりに、lang/xx/validation.php 言語ファイルで values 配列を定義することで、よりユーザーフレンドリーな値表現を指定できます：

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

警告

Laravelアプリケーションのスケルトンにはデフォルトで lang ディレクトリが含まれていません。Laravelの言語ファイルをカスタマイズしたい場合は、lang:publish Artisanコマンドを使用して公開することができます。

この値を定義した後、バリデーションルールは次のエラーメッセージを生成します：

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

利用可能なバリデーションルール​

以下は、すべての利用可能なバリデーションルールとその機能の一覧です：

Accepted Accepted If Active URL After (Date) After Or Equal (Date) Alpha Alpha Dash Alpha Numeric Array](#rule-array) Ascii Bail Before (Date) Before Or Equal (Date) Between Boolean Confirmed Contains Current Password Date Date Equals Date Format Decimal Declined Declined If Different Digits Digits Between Dimensions (Image Files) Distinct Doesnt Start With Doesnt End With Email Ends With Enum Exclude Exclude If Exclude Unless Exclude With Exclude Without Exists (Database) Extensions File Filled Greater Than Greater Than Or Equal Hex Color Image (File) In In Array Integer IP Address JSON Less Than Less Than Or Equal List Lowercase MAC Address Max Max Digits MIME Types MIME Type By File Extension Min Min Digits Missing Missing If Missing Unless Missing With Missing With All Multiple Of Not In Not Regex Nullable Numeric Present Present If Present Unless Present With Present With All Prohibited Prohibited If Prohibited Unless Prohibits Regular Expression Required Required If Required If Accepted Required If Declined Required Unless Required With Required With All Required Without Required Without All Required Array Keys Same Size Sometimes Starts With String Timezone Unique (Database) Uppercase URL ULID UUID

accepted​

検証対象のフィールドは、"yes"、"on"、1、"1"、true、または"true"でなければなりません。これは、「利用規約」の同意などを検証するのに役立ちます。

accepted_if:anotherfield,value,...​

検証対象のフィールドは、別の検証対象のフィールドが指定された値と等しい場合にのみ、"yes"、"on"、1、"1"、true、または"true"でなければなりません。これは、「利用規約」の同意などを検証するのに役立ちます。

active_url​

検証対象のフィールドは、dns_get_record PHP関数による有効なAレコードまたはAAAAレコードを持っていなければなりません。提供されたURLのホスト名は、parse_url PHP関数を使用して抽出され、dns_get_record に渡される前に変換されます。

after:date​

検証対象のフィールドは、指定された日付よりも後の値でなければなりません。日付は、有効なDateTimeインスタンスに変換されるためにstrtotime PHP関数に渡されます：

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

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

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

after_or_equal:date​

検証対象のフィールドは、指定された日付よりも後または等しい値でなければなりません。詳細については、after ルールを参照してください。

alpha​

検証対象のフィールドは、\p{L} および \p{M} に含まれるUnicodeアルファベット文字でなければなりません。

この検証ルールをASCII範囲の文字（a-z および A-Z）に制限するには、検証ルールに ascii オプションを指定できます：

'username' => 'alpha:ascii',

alpha_dash​

検証対象のフィールドは、\p{L}、\p{M}、\p{N} およびASCIIダッシュ（-）およびASCIIアンダースコア（_）で構成されるUnicode英数字文字でなければなりません。

制約をASCII範囲の文字（a-zおよびA-Z）に制限するには、検証ルールにasciiオプションを指定できます：

'username' => 'alpha_dash:ascii',

alpha_num​

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

制約をASCII範囲の文字（a-zおよびA-Z）に制限するには、検証ルールにasciiオプションを指定できます：

'username' => 'alpha_num:ascii',

array​

検証対象のフィールドはPHPのarrayでなければなりません。

arrayルールに追加の値が提供されると、入力配列の各キーはルールに提供された値のリスト内に存在していなければなりません。次の例では、入力配列のadminキーはarrayルールに提供された値のリストに含まれていないため無効です：

    use Illuminate\Support\Facades\Validator;

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

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

一般的には、配列内に存在してもよい配列キーを常に指定するべきです。

ascii​

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

bail​

最初の検証失敗後にフィールドの検証ルールの実行を停止します。

bailルールは特定のフィールドの検証を検証失敗時に停止しますが、stopOnFirstFailureメソッドは、単一の検証失敗が発生した時点ですべての属性の検証を停止するようにバリデータに通知します：

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

before:date​

検証対象のフィールドは、指定された日付より前の値でなければなりません。日付はPHPのstrtotime関数に渡され、有効なDateTimeインスタンスに変換されます。また、afterルールと同様に、dateの値として他の検証対象フィールドの名前を指定することができます。

before_or_equal:date​

検証対象のフィールドは、指定された日付より前または同じ値である必要があります。日付は、有効な DateTime インスタンスに変換するために PHP の strtotime 関数に渡されます。さらに、date の値として別の検証対象フィールドの名前を指定することもできます。

between:min,max​

検証対象のフィールドは、指定された min と max の間（両端を含む）のサイズである必要があります。文字列、数値、配列、ファイルは、size ルールと同様に評価されます。

boolean​

検証対象のフィールドは、ブール値としてキャストできる必要があります。受け入れられる入力は true、false、1、0、"1"、"0" です。

confirmed​

検証対象のフィールドは、{field}_confirmation と一致するフィールドを持っている必要があります。たとえば、検証対象のフィールドが password の場合、入力には一致する password_confirmation フィールドが存在する必要があります。

contains:foo,bar,...​

検証対象のフィールドは、指定されたパラメータ値すべてを含む配列である必要があります。

current_password​

検証対象のフィールドは、認証されたユーザーのパスワードと一致する必要があります。ルールの最初のパラメータとして 認証ガード を指定することができます。

    'password' => 'current_password:api'

date​

検証対象のフィールドは、strtotime PHP 関数に従った有効な非相対日付である必要があります。

date_equals:date​

検証対象のフィールドは、指定された日付と等しい必要があります。日付は、有効な DateTime インスタンスに変換するために PHP の strtotime 関数に渡されます。

date_format:format,...​

検証対象のフィールドは、指定された formats のいずれかと一致する必要があります。フィールドを検証する際には、date または date_format のいずれかを使用する必要があります。この検証ルールは、PHP の DateTime クラスでサポートされているすべてのフォーマットをサポートしています。

decimal:min,max​

検証対象のフィールドは数値でなければならず、指定された小数点以下の桁数を含んでいなければなりません：

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

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

declined​

検証対象のフィールドは、"no"、"off"、0、"0"、false、または"false"でなければなりません。

declined_if:anotherfield,value,...​

検証対象のフィールドは、別の検証対象のフィールドが指定された値と等しい場合に、"no"、"off"、0、"0"、false、または"false"でなければなりません。

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'

doesnt_start_with:foo,bar,...​

検証フィールドは、指定された値のいずれかで始まってはいけません。

doesnt_end_with:foo,bar,...​

検証フィールドは、指定された値のいずれかで終わってはいけません。

email​

検証フィールドは、メールアドレスとしてフォーマットする必要があります。この検証ルールは、メールアドレスを検証するためにegulias/email-validatorパッケージを使用します。デフォルトではRFCValidationバリデータが適用されますが、他のバリデーションスタイルも適用できます：

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

上記の例では、RFCValidationおよびDNSCheckValidationの検証が適用されます。適用できる検証スタイルの完全なリストは次のとおりです：

  • rfc: RFCValidation
  • strict: NoRFCWarningsValidation
  • dns: DNSCheckValidation
  • spoof: SpoofCheckValidation
  • filter: FilterEmailValidation
  • filter_unicode: FilterEmailValidation::unicode()

filterバリデータは、PHPのfilter_var関数を使用しており、Laravelに同梱されており、Laravelバージョン5.8以前のLaravelのデフォルトのメール検証動作でした。

警告

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

ends_with:foo,bar,...​

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

enum​

Enumルールは、有効な列挙値を含むかどうかを検証するクラスベースのルールです。Enumルールは、その唯一のコンストラクタ引数として列挙型の名前を受け入れます。プリミティブ値を検証する場合は、EnumルールにバックエンドEnumを提供する必要があります：

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

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

Enumルールのonlyおよびexceptメソッドを使用して、どの列挙ケースを有効とするかを制限できます：

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

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

whenメソッドを使用して、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メソッドによって返されるリクエストデータから除外されます。

exclude_if:anotherfield,value​

検証対象のフィールドは、_anotherfield_フィールドが_value_と等しい場合、validateおよびvalidatedメソッドによって返されるリクエストデータから除外されます。

複雑な条件付きの除外ロジックが必要な場合は、Rule::excludeIfメソッドを使用できます。このメソッドはブール値またはクロージャを受け入れます。クロージャが与えられた場合、クロージャは検証対象のフィールドを除外すべきかどうかを示すために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),
    ]);

exclude_unless:anotherfield,value​

検証対象のフィールドは、_anotherfield_フィールドが_value_と等しくない場合、validateおよびvalidatedメソッドによって返されるリクエストデータから除外されます。_value_がnullの場合（exclude_unless:name,null）、比較フィールドがnullであるか、比較フィールドがリクエストデータに存在しない場合を除いて、検証対象のフィールドは除外されます。

exclude_with:anotherfield​

検証対象のフィールドは、_anotherfield_フィールドが存在する場合、validateおよびvalidatedメソッドによって返されるリクエストデータから除外されます。

exclude_without:anotherfield​

検証対象のフィールドは、_anotherfield_フィールドが存在しない場合、validateおよびvalidatedメソッドによって返されるリクエストデータから除外されます。

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

Rule::exists メソッドによって生成される exists ルールで使用されるデータベースカラム名を明示的に指定する場合は、exists メソッドの第二引数としてカラム名を指定します：

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

拡張ルール: foo, bar,...​

検証されるファイルは、リストされた拡張子のいずれかに対応するユーザーが割り当てた拡張子を持っている必要があります：

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

警告

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

file​

検証されるフィールドは、正常にアップロードされたファイルである必要があります。

filled​

検証されるフィールドは、存在する場合には空であってはいけません。

gt: field​

検証されるフィールドは、指定された field または value よりも大きくなければなりません。2 つのフィールドは同じ型でなければなりません。文字列、数値、配列、ファイルは、size ルールと同じ規則を使用して評価されます。

gte:field​

検証対象のフィールドは、指定された field または value よりも大きいか等しい必要があります。2つのフィールドは同じ型である必要があります。文字列、数値、配列、ファイルは、size ルールと同じ規則で評価されます。

hex_color​

検証対象のフィールドは、16進数 形式の有効なカラー値を含んでいる必要があります。

image​

検証対象のファイルは画像である必要があります（jpg、jpeg、png、bmp、gif、svg、または webp）。

in:foo,bar,...​

検証対象のフィールドは、指定された値のリストに含まれている必要があります。このルールはしばしば配列をimplodeする必要があるため、Rule::in メソッドを使用してルールをスムーズに構築できます：

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

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

in ルールを array ルールと組み合わせると、入力配列内の各値が in ルールに提供された値のリスト内に存在する必要があります。次の例では、入力配列内の LAS 空港コードは、in ルールに提供された空港のリストに含まれていないため無効です：

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

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

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

in_array:anotherfield.*​

検証対象のフィールドは、anotherfield の値の中に存在する必要があります。

integer​

検証対象のフィールドは整数である必要があります。

警告

この検証ルールは、入力が "integer" 変数型であることを検証しないことに注意してください。単に、PHP の FILTER_VALIDATE_INT ルールで受け入れられる型であることを検証します。入力が数値であることを検証する必要がある場合は、 numeric 検証ルール と組み合わせてこのルールを使用してください。

ip​

検証対象のフィールドは IP アドレスである必要があります。

ipv4​

検証対象のフィールドは IPv4 アドレスである必要があります。

ipv6​

検証対象のフィールドは IPv6 アドレスである必要があります。

json​

The field under validation must be a valid JSON string.

lt:field​

検証対象のフィールドは、指定された field より小さい必要があります。2 つのフィールドは同じ型である必要があります。文字列、数値、配列、ファイルは、size ルールと同じ規則で評価されます。

lte:field​

検証対象のフィールドは、指定された field 以下である必要があります。2 つのフィールドは同じ型である必要があります。文字列、数値、配列、ファイルは、size ルールと同じ規則で評価されます。

lowercase​

検証対象のフィールドは小文字である必要があります。

list​

検証対象のフィールドは、リストである配列である必要があります。配列のキーが 0 から count($array) - 1 までの連続した数値で構成されている場合、配列はリストと見なされます。

mac_address​

検証対象のフィールドは MAC アドレスである必要があります。

max:value​

検証対象のフィールドは、最大値 value 以下である必要があります。文字列、数値、配列、ファイルは、size ルールと同様の方法で評価されます。

max_digits:value​

検証対象の整数は、value の最大長を持つ必要があります。

mimetypes:text/plain,...​

検証対象のファイルは、指定された MIME タイプのいずれかと一致する必要があります：

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

アップロードされたファイルの MIME タイプを決定するために、ファイルの内容が読み取られ、フレームワークは MIME タイプを推測しようとします。これは、クライアントが提供した MIME タイプと異なる場合があります。

mimes:foo,bar,...​

検証対象のファイルは、リストされた拡張子に対応する MIME タイプを持つ必要があります：

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

拡張子のみを指定する必要がありますが、このルールは実際にはファイルの MIME タイプを検証し、ファイルの内容を読み取り、その MIME タイプを推測します。 MIME タイプとそれに対応する拡張子の完全なリストは、次の場所で見つけることができます：

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

MIME タイプと拡張子​

この検証ルールは、ユーザーがファイルに割り当てた MIME タイプと拡張子の一致を検証しません。たとえば、mimes:png 検証ルールは、有効な PNG コンテンツを含むファイルを有効な PNG 画像と見なしますが、そのファイルの名前が photo.txt である場合でもです。ファイルに割り当てられた拡張子を検証したい場合は、extensions ルールを使用できます。

min:value​

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

min_digits:value​

検証される整数は、value の最小長を持つ必要があります。

multiple_of:value​

検証されるフィールドは、value の倍数である必要があります。

missing​

検証されるフィールドは、入力データに存在してはいけません。

missing_if:anotherfield,value,...​

検証されるフィールドは、anotherfield フィールドが任意の value に等しい場合に存在してはいけません。

missing_unless:anotherfield,value​

検証されるフィールドは、anotherfield フィールドが任意の value に等しくない限り、存在してはいけません。

missing_with:foo,bar,...​

検証されるフィールドは、他の指定されたフィールドのいずれかが存在する場合にのみ存在してはいけません。

missing_with_all:foo,bar,...​

検証されるフィールドは、他の指定されたすべてのフィールドが存在する場合にのみ存在してはいけません。

not_in:foo,bar,...​

検証されるフィールドは、指定された値のリストに含まれてはいけません。Rule::notIn メソッドを使用して、ルールを流暢に構築することができます。

    use Illuminate\Validation\Rule;

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

not_regex:pattern​

検証対象のフィールドは指定された正規表現と一致してはいけません。

このルールは、内部的に PHP の preg_match 関数を使用します。指定されたパターンは、preg_match で必要とされるフォーマットに従う必要があり、有効な区切り文字も含める必要があります。例: 'email' => 'not_regex:/^.+$/i'。

警告

regex / not_regex パターンを使用する際は、正規表現に | 文字が含まれている場合、| 区切り文字を使用せずに、バリデーションルールを配列で指定する必要がある場合があります。

nullable​

検証対象のフィールドは null であってもよいです。

numeric​

検証対象のフィールドは数値である必要があります。

present​

検証対象のフィールドは入力データに存在する必要があります。

present_if:anotherfield,value,...​

検証対象のフィールドは、anotherfield フィールドが任意の value に等しい場合に存在する必要があります。

present_unless:anotherfield,value​

検証対象のフィールドは、anotherfield フィールドが任意の value に等しくない場合に存在する必要があります。

present_with:foo,bar,...​

検証対象のフィールドは、他の指定されたフィールドのいずれかが存在する場合にのみ存在する必要があります。

present_with_all:foo,bar,...​

検証対象のフィールドは、他の指定されたすべてのフィールドが存在する場合にのみ存在する必要があります。

prohibited​

検証対象のフィールドは欠落しているか空でなければなりません。フィールドが「空」である条件は次のいずれかを満たす場合です:

  • 値が null である。
  • 値が空の文字列である。
  • 値が空の配列または空の Countable オブジェクトである。
  • 値が空のパスを持つアップロードされたファイルである。

バリデーション対象のフィールドは、anotherfield フィールドが任意の value に等しい場合、欠落または空でなければなりません。フィールドが「空」であるとは、次のいずれかの基準を満たす場合です：

  • 値が null である。
  • 値が空の文字列である。
  • 値が空の配列または空の Countable オブジェクトである。
  • 値が空のパスを持つアップロードされたファイルである。

複雑な条件付き禁止ロジックが必要な場合は、Rule::prohibitedIf メソッドを利用することができます。このメソッドはブール値またはクロージャを受け入れます。クロージャが与えられた場合、クロージャはバリデーション対象のフィールドを禁止すべきかどうかを示すために 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),
    ]);

prohibited_unless:anotherfield,value,...​

バリデーション対象のフィールドは、anotherfield フィールドが任意の value に等しい場合を除いて、欠落または空でなければなりません。フィールドが「空」であるとは、次のいずれかの基準を満たす場合です：

  • 値が null である。
  • 値が空の文字列である。
  • 値が空の配列または空の Countable オブジェクトである。
  • 値が空のパスを持つアップロードされたファイルである。

prohibits:anotherfield,...​

バリデーション対象のフィールドが欠落または空でない場合、anotherfield 内のすべてのフィールドが欠落または空でなければなりません。フィールドが「空」であるとは、次のいずれかの基準を満たす場合です：

  • 値が null である。
  • 値が空の文字列である。
  • 値が空の配列または空の Countable オブジェクトである。
  • 値が空のパスを持つアップロードされたファイルである。

regex:pattern​

バリデーション対象のフィールドは、指定された正規表現と一致しなければなりません。

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

警告

regex / not_regex パターンを使用する場合、正規表現に | 文字が含まれる場合、| 区切り記号を使用せずに、ルールを配列で指定する必要がある場合があります。

必須​

検証対象のフィールドは、入力データに存在し、空でなければなりません。フィールドが「空」であるとは、次のいずれかの条件を満たす場合です：

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

required_if_accepted:anotherfield,...​

検証対象のフィールドは、anotherfield フィールドが "yes"、"on"、1、"1"、true、または "true" に等しい場合にのみ存在し、空でなければなります。

required_if_declined:anotherfield,...​

検証対象のフィールドは、anotherfield フィールドが "no"、"off"、0、"0"、false、または "false" に等しい場合にのみ存在し、空でなければなります。

required_unless:anotherfield,value,...​

検証対象のフィールドは、anotherfield フィールドが任意の value に等しくない場合にのみ存在し、空でなければなります。これは、value が null の場合（required_unless:name,null）、比較フィールドが null であるか、比較フィールドがリクエストデータに存在しない場合を除き、検証対象のフィールドが必要であることを意味します。

required_with:foo,bar,...​

検証対象のフィールドは、他の指定されたフィールドのいずれかが存在し、空でない場合にのみ存在し、空でなければなります。

required_with_all:foo,bar,...​

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

required_without:foo,bar,...​

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

required_without_all:foo,bar,...​

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

required_array_keys:foo,bar,...​

検証対象のフィールドは配列であり、少なくとも指定されたキーを含んでいる必要があります。

same:field​

指定された field は、検証対象のフィールドと一致する必要があります。

size:value​

検証対象のフィールドは、指定された value と一致するサイズである必要があります。文字列データの場合、value は文字数に対応します。数値データの場合、value は与えられた整数値に対応します（属性には numeric または integer ルールも必要です）。配列の場合、size は配列の 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';

starts_with:foo,bar,...​

検証対象のフィールドは、指定された値のいずれかで始まる必要があります。

string​

検証対象のフィールドは文字列である必要があります。フィールドが null であることも許可したい場合は、フィールドに nullable ルールを割り当てる必要があります。

timezone​

検証対象のフィールドは、DateTimeZone::listIdentifiers メソッドに従った有効なタイムゾーン識別子である必要があります。

この検証ルールには、DateTimeZone::listIdentifiers メソッドで受け入れられる引数も指定できます。

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

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

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

unique:table,column​

検証対象のフィールドは、指定されたデータベーステーブル内に存在してはいけません。

カスタムテーブル/カラム名の指定:

直接テーブル名を指定する代わりに、テーブル名を決定するために使用される Eloquent モデルを指定することができます:

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

column オプションを使用して、フィールドに対応するデータベースカラムを指定できます。column オプションが指定されていない場合、検証対象のフィールド名が使用されます。

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

カスタムデータベース接続の指定

時折、バリデータによって行われるデータベースクエリに対してカスタム接続を設定する必要があるかもしれません。これを達成するために、テーブル名の前に接続名を付けることができます:

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

指定された ID を無視するための一意のルールの強制

時には、一意の検証中に特定の ID を無視したい場合があります。たとえば、ユーザーの名前、メールアドレス、および場所を含む「プロフィールを更新」画面を考えてみてください。おそらく、メールアドレスが一意であることを確認したいでしょう。ただし、ユーザーが名前フィールドのみを変更し、メールフィールドを変更しない場合、ユーザーが既に問題のメールアドレスの所有者であるため、検証エラーがスローされることは望ましくありません。

バリデータにユーザーの ID を無視するように指示するには、Rule クラスを使用してルールを流暢に定義します。この例では、ルールを | 文字で区切るのではなく、配列として検証ルールを指定します:

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

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

警告

ignore メソッドにユーザーが制御可能なリクエスト入力を渡してはいけません。代わりに、Eloquent モデルのインスタンスからの自動増分 ID または UUID などのシステム生成の一意の ID のみを渡すべきです。そうしないと、アプリケーションは SQL インジェクション攻撃の脆弱性にさらされる可能性があります。

ignore メソッドにモデルキーの値を渡す代わりに、モデルインスタンス全体を渡すこともできます。Laravel は自動的にモデルからキーを抽出します:

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

テーブルが id 以外の主キー列名を使用している場合は、ignore メソッドを呼び出す際に列の名前を指定できます：

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

デフォルトでは、unique ルールは検証されている属性の名前に一致する列の一意性をチェックします。ただし、unique メソッドの第2引数として異なる列名を渡すこともできます：

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

追加の条件を追加する:

where メソッドを使用してクエリをカスタマイズすることで、追加のクエリ条件を指定できます。たとえば、account_id 列の値が 1 のみを検索するクエリ条件を追加してみましょう：

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

uppercase​

検証されるフィールドは大文字である必要があります。

url​

検証されるフィールドは有効な URL である必要があります。

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

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

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

ulid​

検証されるフィールドは有効な Universally Unique Lexicographically Sortable Identifier (ULID) である必要があります。

uuid​

検証されるフィールドは有効な RFC 4122 (バージョン 1、3、4、または 5) の普遍的に一意な識別子 (UUID) である必要があります。

条件付きルールの追加​

特定の値を持つフィールドがある場合の検証のスキップ​

別のフィールドが特定の値を持っている場合、特定のフィールドを検証しない場合があります。これは exclude_if 検証ルールを使用して達成できます。この例では、has_appointment フィールドの値が false の場合、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',
    ]);

また、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($data, [
        'email' => 'sometimes|required|email',
    ]);

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

注記

常に存在する必要があるが空である可能性があるフィールドを検証しようとしている場合は、オプションフィールドに関するこのノートをご覧ください。

複雑な条件付き検証​

時には、より複雑な条件付きロジックに基づいて検証ルールを追加したい場合があります。たとえば、別のフィールドが100より大きい値を持っている場合にのみ、特定のフィールドを必要とすることができます。また、別のフィールドが存在する場合にのみ、2つのフィールドが特定の値を持つ必要がある場合もあります。これらの検証ルールを追加することは苦労する必要はありません。まず、変更されない 静的ルール を持つ Validator インスタンスを作成します：

    use Illuminate\Support\Facades\Validator;

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

Webアプリケーションがゲームコレクター向けであると仮定しましょう。ゲームコレクターが当社のアプリケーションに登録し、100以上のゲームを所有している場合、なぜそんなに多くのゲームを所有しているのかを説明してもらいたいとします。たとえば、ゲームの再販ショップを運営しているかもしれませんし、単にゲームを収集するのが好きかもしれません。この要件を条件付きで追加するために、Validator インスタンスで sometimes メソッドを使用できます。

    use Illuminate\Support\Fluent;

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

sometimes メソッドに渡される最初の引数は、条件付きで検証するフィールドの名前です。2番目の引数は追加したいルールのリストです。第3引数として渡されるクロージャが true を返す場合、ルールが追加されます。このメソッドを使用すると、複雑な条件付き検証を簡単に構築できます。複数のフィールドに対して条件付き検証を追加することもできます：

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

注記

クロージャに渡される $input パラメータは Illuminate\Support\Fluent のインスタンスであり、入力と検証中のファイルにアクセスするために使用できます。

複雑な条件付き配列の検証​

時には、同じネストされた配列内の他のフィールドに基づいてフィールドを検証したいことがありますが、そのインデックスがわからない場合があります。このような状況では、クロージャに第2引数を受け取らせることができます。この引数は、検証されている配列内の個々のアイテムを表します。

    $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 パラメータは、属性データが配列の場合は Illuminate\Support\Fluent のインスタンスであり、それ以外の場合は文字列です。

配列の検証​

array 検証ルールのドキュメントで説明されているように、array ルールは許可された配列キーのリストを受け入れます。配列内に追加のキーが存在する場合、検証は失敗します。

    use Illuminate\Support\Facades\Validator;

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

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

一般的には、配列内に存在してもよいキーを常に指定するべきです。そうしないと、ネストされた配列の検証ルールで検証されていないキーであっても、バリデータの validate メソッドと validated メソッドは、検証されたデータ全体、つまり配列とそのすべてのキーを返します。

ネストされた配列入力の検証​

ネストされた配列ベースのフォーム入力フィールドの検証は面倒な作業ではありません。配列内の属性を検証するために "ドット表記" を使用できます。たとえば、着信 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',
        ]
    ],

ネストされた配列データへのアクセス​

時には、属性に検証ルールを割り当てる際に、ネストされた配列要素の値にアクセスする必要がある場合があります。これは、Rule::forEach メソッドを使用して行うことができます。forEach メソッドは、検証中の配列属性の各反復ごとに呼び出されるクロージャを受け入れ、属性の値と明示的で完全に展開された属性名を受け取ります。クロージャは、配列要素に割り当てるルールの配列を返す必要があります：

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

エラーメッセージのインデックスと位置​

配列を検証する際に、アプリケーションが表示するエラーメッセージ内で、特定の検証に失敗したアイテムのインデックスや位置を参照したい場合があります。これを実現するために、カスタム検証メッセージ 内に :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.',
    ]);

上記の例では、検証が失敗し、ユーザーに "Please describe photo #2." というエラーが表示されます。

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

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

ファイルの検証​

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

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

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

ユーザーがアップロードした画像を受け入れるアプリケーションの場合、File ルールの image コンストラクタメソッドを使用して、アップロードされたファイルが画像であることを示すことができます。さらに、dimensions ルールを使用して画像の寸法を制限することもできます：

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

注記

画像の寸法を検証する詳細情報は、dimension rule documentation で確認できます。

ファイルサイズ​

便宜上、最小および最大のファイルサイズは、ファイルサイズの単位を示すサフィックスを付けた文字列として指定することができます。 kb、mb、gb、tb のサフィックスがサポートされています：

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

ファイルタイプ​

types メソッドを呼び出す際に拡張子のみを指定する必要があるとしても、このメソッドは実際にはファイルの内容を読み取り、その MIME タイプを推測してファイルの MIME タイプを検証します。 MIME タイプとそれに対応する拡張子の完全なリストは、次の場所で見つけることができます：

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

パスワードの検証​

パスワードが適切な複雑さレベルを持っていることを確認するために、Laravel の Password ルールオブジェクトを使用することができます：

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

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

Password ルールオブジェクトを使用すると、アプリケーションのパスワードの複雑さ要件を簡単にカスタマイズすることができます。たとえば、パスワードには少なくとも1つの文字、数字、記号、または大文字と小文字が混在した文字が必要であると指定することができます：

    // 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 メソッドを使用して、パスワードが公開されたパスワードデータの漏洩によって危険にさらされていないことを確認することができます：

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

内部的に、Password ルールオブジェクトは、ユーザーのプライバシーやセキュリティを犠牲にすることなく、パスワードが haveibeenpwned.com サービスを介して漏洩されたかどうかを判断するために k-匿名性 モデルを使用します。

デフォルトでは、データ漏洩でパスワードが少なくとも1回表示された場合、そのパスワードは危険と見なされます。 uncompromised メソッドの最初の引数を使用してこの閾値をカスタマイズすることができます：

    // 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()

デフォルトのパスワードルールの定義​

便利な場合があります。アプリケーションの単一の場所にパスワードのデフォルト検証ルールを指定することができます。Password::defaults メソッドを使用してこれを簡単に実現できます。このメソッドはクロージャを受け入れます。defaults メソッドに与えられるクロージャは、パスワードルールのデフォルト構成を返す必要があります。通常、defaults ルールは、アプリケーションのサービスプロバイダーの boot メソッド内で呼び出されるべきです：

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;
    });
}

その後、特定のパスワードにデフォルトルールを適用したい場合は、引数なしで defaults メソッドを呼び出すことができます：

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

時折、デフォルトパスワード検証ルールに追加の検証ルールを添付したい場合があります。これを実現するために rules メソッドを使用できます：

    use App\Rules\ZxcvbnRule;

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

        // ...
    });

カスタム検証ルール​

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

Laravel はさまざまな便利な検証ルールを提供していますが、独自のルールを指定したい場合があります。カスタム検証ルールを登録する方法の1つは、ルールオブジェクトを使用することです。新しいルールオブジェクトを生成するには、make:rule Artisan コマンドを使用できます。文字列が大文字であることを検証するルールを生成するためにこのコマンドを使用しましょう。Laravel は新しいルールを app/Rules ディレクトリに配置します。このディレクトリが存在しない場合は、ルールを作成するために Artisan コマンドを実行すると作成されます：

php artisan make:rule Uppercase

ルールが作成されたら、その動作を定義する準備が整いました。ルールオブジェクトには validate メソッドが1つ含まれています。このメソッドは、属性名、その値、および検証エラーメッセージで失敗した場合に呼び出すべきコールバックを受け取ります：

    <?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.');
            }
        }
    }

ルールが定義されたら、他の検証ルールと一緒にルールオブジェクトのインスタンスを渡すことで、バリデータにアタッチできます：

    use App\Rules\Uppercase;

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

検証メッセージの翻訳​

代わりに$fail クロージャにリテラルなエラーメッセージを提供する代わりに、翻訳文字列キー を提供し、Laravel にエラーメッセージを翻訳するよう指示することもできます:

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

必要に応じて、プレースホルダーの置換とtranslate メソッドへの最初と2番目の引数として好ましい言語を提供することができます:

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

追加データへのアクセス​

カスタムバリデーションルールクラスがバリデーションを受ける他のすべてのデータにアクセスする必要がある場合、ルールクラスはIlluminate\Contracts\Validation\DataAwareRule インターフェースを実装することができます。このインターフェースでは、クラスがsetData メソッドを定義する必要があります。このメソッドは、バリデーションが進行する前に 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;
        }
    }

または、バリデーションルールがバリデーションを実行するバリデータインスタンスにアクセスする必要がある場合は、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;
        }
    }

クロージャの使用​

アプリケーション全体でカスタムルールの機能性が1回だけ必要な場合は、ルールオブジェクトの代わりにクロージャを使用することができます。クロージャは属性の名前、属性の値、およびバリデーションが失敗した場合に呼び出す必要がある$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.");
                }
            },
        ],
    ]);

暗黙のルール​

デフォルトでは、バリデーションされている属性が存在しないか空の文字列を含む場合、通常のバリデーションルール、カスタムルールを含むルールは実行されません。たとえば、unique ルールは空の文字列に対して実行されません:

    use Illuminate\Support\Facades\Validator;

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

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

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

属性が空である場合でもカスタムルールを実行するには、ルールが属性が必須であることを暗示する必要があります。新しい暗黙のルールオブジェクトを素早く生成するには、make:rule Artisan コマンドを--implicit オプションとともに使用できます:

php artisan make:rule Uppercase --implicit
警告

"暗黙" ルールは属性が必須であることを_暗示_するだけです。実際に欠落しているか空の属性を無効にするかはあなた次第です。