バージョン: master

検証 (Validation)

Introduction
検証のクイックスタート
フォームリクエストの検証
バリデーターを手動で作成する
検証された入力の使用
エラーメッセージの処理
利用可能な検証ルール
条件付きルールの追加
配列の検証
- ネストされた配列入力の検証
- エラーメッセージのインデックスと位置
ファイルの検証
パスワードの検証
カスタム検証ルール

導入 (Introduction)

Laravel は、アプリケーションの受信データを検証するためのいくつかの異なるアプローチを提供します。すべての受信 HTTP リクエストで使用できる validate メソッドを使用するのが最も一般的です。ただし、他の検証アプローチについても説明します。

Laravel には、データに適用できる便利な検証ルールが幅広く含まれており、特定のデータベーステーブル内で値が一意であるかどうかを検証する機能も提供します。 Laravel のすべての検証機能を理解できるように、これらの検証ルールのそれぞれについて詳しく説明します。

検証のクイックスタート (Validation Quickstart)

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 メソッドに渡されます。心配しないでください。使用可能な検証ルールはすべて documented です。繰り返しますが、検証が失敗した場合は、適切な応答が自動的に生成されます。検証に合格すると、コントローラは通常どおりに実行を続けます。

あるいは、単一の | で区切られた文字列の代わりに、検証ルールをルールの配列として指定することもできます。

$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 はユーザーを以前の場所に自動的にリダイレクトします。さらに、すべての検証エラーと入力を要求するは自動的にセッションにフラッシュされましたになります。

$errors 変数は、web ミドルウェアグループによって提供される Illuminate\View\Middleware\ShareErrorsFromSession ミドルウェアによって、アプリケーションのすべてのビューと共有されます。このミドルウェアを適用すると、$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:publish Artisan コマンドを使用してディレクトリを作成するように Laravel に指示できます。

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

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

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

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

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

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

フォームの再入力

Laravel が検証エラーによりリダイレクト応答を生成すると、フレームワークは自動的にすべてのリクエストの入力をセッションにフラッシュしますを実行します。これは、次のリクエスト中に入力に簡単にアクセスし、ユーザーが送信しようとしたフォームに再入力できるようにするために行われます。

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

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

フォームリクエストの検証 (Form Request Validation)

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

より複雑な検証シナリオの場合は、「フォームリクエスト」を作成することもできます。フォームリクエストは、独自の検証および認可ロジックをカプセル化するカスタムリクエストクラスです。フォームリクエストクラスを作成するには、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\ValidationRule|array<mixed>|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 リクエストの場合、検証エラーの JSON 表現を含む 422 ステータスコードを含む HTTP 応答がユーザーに返されます。

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

追加の検証の実行

場合によっては、最初の検証が完了した後、追加の検証を実行する必要があります。これは、フォームリクエストの 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 回発生したらすべての属性の検証を停止するようバリデーターに通知できます。

<?php

namespace App\Http\Requests;

use Illuminate\Foundation\Http\Attributes\StopOnFirstFailure;
use Illuminate\Foundation\Http\FormRequest;

#[StopOnFirstFailure]
class StorePostRequest extends FormRequest
{
    // ...
}

リダイレクト場所のカスタマイズ

フォームリクエストの検証が失敗すると、ユーザーを以前の場所に戻すリダイレクト応答が生成されます。ただし、この動作は自由にカスタマイズできます。これを行うには、フォームリクエストで RedirectTo 属性を使用します。

<?php

namespace App\Http\Requests;

use Illuminate\Foundation\Http\Attributes\RedirectTo;
use Illuminate\Foundation\Http\FormRequest;

#[RedirectTo('/dashboard')]
class StorePostRequest extends FormRequest
{
    // ...
}

または、ユーザーを名前付きルートにリダイレクトしたい場合は、代わりに RedirectToRoute 属性を使用できます。

<?php

namespace App\Http\Requests;

use Illuminate\Foundation\Http\Attributes\RedirectToRoute;
use Illuminate\Foundation\Http\FormRequest;

#[RedirectToRoute('dashboard')]
class StorePostRequest extends FormRequest
{
    // ...
}

エラーバッグのカスタマイズ

フォームリクエストの検証が失敗すると、エラーは default エラーバッグにフラッシュされます。エラーを別の名前付きエラーバッグに保存する必要がある場合は、フォームリクエストで ErrorBag 属性を使用できます。

<?php

namespace App\Http\Requests;

use Illuminate\Foundation\Http\Attributes\ErrorBag;
use Illuminate\Foundation\Http\FormRequest;

#[ErrorBag('login')]
class LoginRequest extends FormRequest
{
    // ...
}

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

フォーム要求クラスには、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']);
}

バリデーターを手動で作成する (Manually Creating Validators)

リクエストで validate メソッドを使用したくない場合は、Validator facade を使用してバリデーターインスタンスを手動で作成できます。ファサードの 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 に名前を付けると、特定のフォームのエラーメッセージを取得できるようになります。これを実現するには、2 番目の引数として名前を withErrors に渡します。

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 メソッドの 4 番目の引数として渡すことができます。

$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) {
        // ...
    },
]);

検証された入力の使用 (Working With Validated Input)

フォームリクエストまたは手動で作成したバリデータインスタンスを使用して受信リクエストデータを検証した後、実際に検証を受けた受信リクエストデータを取得したい場合があります。これはいくつかの方法で実現できます。まず、フォームリクエストまたはバリデーターインスタンスで 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();

エラーメッセージの処理 (Working With Error Messages)

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

'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.

利用可能な検証ルール (Available Validation Rules)

以下は、利用可能なすべての検証ルールとその機能のリストです。

Booleans

Accepted 受け入れられる場合 Boolean Declined 拒否された場合

Strings

Utilities

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 のホスト名は、dns_get_record に渡される前に、parse_url PHP 関数を使用して抽出されます。

after:date

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

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

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

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

便宜上、日付ベースのルールは、滑らかな date ルールビルダを使用して構築できます。

use Illuminate\Validation\Rule;

'start_date' => [
    'required',
    Rule::date()->after(today()->addDays(7)),
],

afterToday メソッドと todayOrAfter メソッドは日付をスムーズに表現するために使用でき、それぞれ今日以降、または今日以降である必要があります。

'start_date' => [
    'required',
    Rule::date()->afterToday(),
],

after_or_equal:date

検証対象のフィールドは、指定された日付以降の値である必要があります。詳細については、after ルールを参照してください。

便宜上、日付ベースのルールは、滑らかな date ルールビルダを使用して構築できます。

use Illuminate\Validation\Rule;

'start_date' => [
    'required',
    Rule::date()->afterOrEqual(today()->addDays(7)),
],

anyOf

Rule::anyOf 検証ルールを使用すると、検証対象のフィールドが指定された検証ルールセットのいずれかを満たす必要があることを指定できます。たとえば、次のルールは、username フィールドが電子メールアドレスであるか、または少なくとも 6 文字の長さの英数字文字列 (ダッシュを含む) であることを検証します。

use Illuminate\Validation\Rule;

'username' => [
    'required',
    Rule::anyOf([
        ['string', 'email'],
        ['string', 'alpha_dash', 'min:6'],
    ]),
],

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、および 0-9) に制限するには、検証ルールに ascii オプションを指定できます。

'username' => 'alpha_dash:ascii',

alpha_num

検証対象のフィールドは、\p{L}、\p{M}、および \p{N} に含まれる完全に Unicode の英数字である必要があります。

この検証ルールを ASCII 範囲の文字 (a-z、A-Z、および 0-9) に制限するには、検証ルールに 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

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

便宜上、日付ベースのルールは、滑らかな date ルールビルダを使用して構築することもできます。

use Illuminate\Validation\Rule;

'start_date' => [
    'required',
    Rule::date()->before(today()->subDays(7)),
],

beforeToday メソッドと todayOrBefore メソッドは日付をスムーズに表現するために使用でき、それぞれ今日より前、または今日以前である必要があります。

'start_date' => [
    'required',
    Rule::date()->beforeToday(),
],

before_or_equal:date

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

便宜上、日付ベースのルールは、滑らかな date ルールビルダを使用して構築することもできます。

use Illuminate\Validation\Rule;

'start_date' => [
    'required',
    Rule::date()->beforeOrEqual(today()->subDays(7)),
],

between:min,max

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

boolean

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

strict パラメータを使用すると、値が true または false の場合にのみフィールドが有効であると見なすことができます。

'foo' => 'boolean:strict'

confirmed

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

カスタム確認フィールド名を渡すこともできます。たとえば、confirmed:repeat_username は、フィールド repeat_username が検証中のフィールドと一致することを期待します。

contains:foo,bar,...

検証対象のフィールドは、指定されたパラメータ値をすべて含む配列である必要があります。このルールでは配列を implode する必要があることが多いため、ルールをスムーズに構築するために Rule::contains メソッドを使用できます。

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

Validator::make($data, [
    'roles' => [
        'required',
        'array',
        Rule::contains(['admin', 'editor']),
    ],
]);

doesnt_contain:foo,bar,...

検証対象のフィールドは、指定されたパラメータ値を含まない配列である必要があります。このルールでは配列を implode する必要があることが多いため、ルールをスムーズに構築するために Rule::doesntContain メソッドを使用できます。

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

Validator::make($data, [
    'roles' => [
        'required',
        'array',
        Rule::doesntContain(['admin', 'editor']),
    ],
]);

current_password

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

'password' => 'current_password:api'

date

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

date_equals:date

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

date_format:format,...

検証中のフィールドは、指定された_formats_のいずれかに一致する必要があります。フィールドを検証するときは、date または date_format の両方ではなく、どちらか を使用する必要があります。この検証ルールは、PHP の DateTime クラスでサポートされるすべての形式をサポートします。

便宜上、日付ベースのルールは、滑らかな date ルールビルダを使用して構築できます。

use Illuminate\Validation\Rule;

'start_date' => [
    'required',
    Rule::date()->format('Y-m-d'),
],

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 - サポートされている RFC に従って電子メールアドレスを検証します。
strict: NoRFCWarningsValidation - サポートされている RFC に従って電子メールを検証し、警告 (例: 末尾のピリオドや複数の連続するピリオド) が見つかった場合は失敗します。
dns: DNSCheckValidation - 電子メールアドレスのドメインに有効な MX レコードがあることを確認します。
spoof: SpoofCheckValidation - 電子メールアドレスに同形異義語や欺瞞的な Unicode 文字が含まれていないことを確認してください。
filter: FilterEmailValidation - 電子メールアドレスが PHP の filter_var 関数に従って有効であることを確認します。
filter_unicode: FilterEmailValidation::unicode() - 電子メールアドレスが PHP の filter_var 関数に従って有効であることを確認し、一部の Unicode 文字を許可します。

便宜上、電子メール検証ルールは Fluent ルールビルダを使用して構築できます。

use Illuminate\Validation\Rule;

$request->validate([
    'email' => [
        'required',
        Rule::email()
            ->rfcCompliant(strict: false)
            ->validateMxRecord()
            ->preventSpoofing()
    ],
]);

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

encoding:encoding_type

検証対象のフィールドは、指定された文字エンコーディングと一致する必要があります。このルールは、PHP の mb_check_encoding 関数を使用して、指定されたファイルまたは文字列値のエンコードを検証します。便宜上、encoding ルールは、Laravel の Fluent ファイルルールビルダを使用して構築できます。

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

Validator::validate($input, [
    'attachment' => [
        'required',
        File::types(['csv'])
            ->encoding('utf-8'),
    ],
]);

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) {
            $query->where('account_id', 1);
        }),
    ],
]);

exists メソッドの 2 番目の引数として列名を指定することで、Rule::exists メソッドによって生成される exists ルールで使用されるデータベース列名を明示的に指定できます。

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

値の配列がデータベースに存在するかどうかを検証したい場合があります。これを行うには、検証対象のフィールドに exists ルールと array ルールの両方を追加します。

'states' => ['array', Rule::exists('states', 'abbreviation')],

これらのルールの両方がフィールドに割り当てられている場合、Laravel は、指定されたすべての値が指定されたテーブルに存在するかどうかを判断する単一のクエリを自動的に構築します。

extensions: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

検証中のフィールドには、hexadecimal 形式の有効な色の値が含まれている必要があります。

image

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

デフォルトでは、XSS 脆弱性の可能性があるため、画像ルールは SVG ファイルを許可しません。 SVG ファイルを許可する必要がある場合は、allow_svg ディレクティブを image ルール (image:allow_svg) に指定できます。

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 の値に存在する必要があります。

in_array_keys:value.*

検証対象のフィールドは、配列内のキーとして指定された values の少なくとも 1 つを持つ配列である必要があります。

'config' => 'array|in_array_keys:timezone'

integer

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

strict パラメーターを使用すると、フィールドのタイプが integer の場合にのみフィールドが有効であると見なすことができます。整数値を含む文字列は無効とみなされます。

'age' => 'integer:strict'

この検証ルールは、入力が「整数」変数タイプであることを検証するのではなく、入力が PHP の FILTER_VALIDATE_INT ルールで受け入れられるタイプであることのみを検証します。入力が数値であることを検証する必要がある場合は、このルールを numeric 検証ルールと組み合わせて使用してください。

ip

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

ipv4

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

ipv6

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

json

検証対象のフィールドは有効な JSON 文字列である必要があります。

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',

'media' => 'mimetypes:image/*,video/*',

アップロードされたファイルの 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 検証ルールでは、ファイルの名前が photo.txt であっても、有効な PNG コンテンツを含むファイルは有効な PNG イメージであると見なされます。ユーザーが割り当てたファイルの拡張子を検証したい場合は、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

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

strict パラメータを使用すると、値が整数型または浮動小数点型の場合にのみフィールドが有効であると見なすことができます。数値文字列は無効とみなされます。

'amount' => 'numeric:strict'

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 オブジェクトです。
値は、空のパスを持つアップロードされたファイルです。

prohibited_if:anotherfield,value,...

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_if_accepted:anotherfield,...

anotherfield フィールドが "yes"、"on"、1、"1"、true、または "true" と等しい場合、検証中のフィールドは欠落しているか空である必要があります。

prohibited_if_declined:anotherfield,...

anotherfield フィールドが "no"、"off"、0、"0"、false、または "false" と等しい場合、検証中のフィールドは欠落しているか空である必要があります。

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 パターンを使用する場合、特に正規表現に | 文字が含まれている場合は、| 区切り文字を使用する代わりに配列でルールを指定する必要がある場合があります。

required

検証対象のフィールドは入力データに存在する必要があり、空であってはなりません。次の基準のいずれかを満たしている場合、フィールドは「空」です。

値はnullです。
値は空の文字列です。
値は空の配列または空の Countable オブジェクトです。
値は、パスのないアップロードされたファイルです。

required_if:anotherfield,value,...

anotherfield フィールドがいずれかの value と等しい場合、検証中のフィールドは存在する必要があり、空であってはなりません。

required_if ルールのより複雑な条件を作成したい場合は、Rule::requiredIf メソッドを使用できます。このメソッドはブール値またはクロージャを受け入れます。クロージャが渡されると、クロージャは true または false を返し、検証中のフィールドが必要かどうかを示す必要があります。

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

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

Validator::make($request->all(), [
    'role_id' => Rule::requiredIf(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 でない限り、anotherfield がリクエストデータに存在する必要があることも意味します。 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 メソッドに従った有効なタイムゾーン識別子である必要があります。

引数 accepted by the DateTimeZone::listIdentifiers method もこの検証ルールに指定できます。

'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 句を追加する:

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

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

一意のチェックで論理的に削除されたレコードを無視する:

デフォルトでは、一意性を判断するときに、一意のルールには論理的に削除されたレコードが含まれます。論理的に削除されたレコードを一意性チェックから除外するには、withoutTrashed メソッドを呼び出すことができます。

Rule::unique('users')->withoutTrashed();

モデルで論理的に削除されたレコードに deleted_at 以外の列名を使用する場合は、withoutTrashed メソッドを呼び出すときに列名を指定できます。

Rule::unique('users')->withoutTrashed('was_deleted_at');

uppercase

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

url

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

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

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

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

ulid

検証対象のフィールドは有効な辞書順に並べ替え可能な普遍的に一意な識別子 (ULID) である必要があります。

uuid

検証対象のフィールドは、有効な RFC 9562 (バージョン 1、3、4、5、6、7、または 8) の汎用一意識別子 (UUID) である必要があります。

指定された UUID がバージョンごとの UUID 仕様と一致することを検証することもできます。

'uuid' => 'uuid:4'

条件付きルールの追加 (Conditionally Adding Rules)

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

別のフィールドに特定の値がある場合、特定のフィールドを検証したくない場合があります。これは、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 ルールをルールリストに追加します。

$validator = 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|integer|min:0',
]);

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' => '[email protected]',
        ],
        [
            '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 のインスタンスになります。それ以外の場合は文字列です。

配列の検証 (Validating Arrays)

配列検証ルールのドキュメントで説明したように、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(), [
    'users.*.email' => 'email|unique:users',
    'users.*.first_name' => 'required_with:users.*.last_name',
]);

同様に、言語ファイル内のカスタム検証メッセージを指定するときに * 文字を使用すると、配列ベースのフィールドに単一の検証メッセージを簡単に使用できるようになります。

'custom' => [
    'users.*.email' => [
        'unique' => 'Each user 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 から始まる)、または :ordinal-position (1st から始まる) プレースホルダーをカスタム検証メッセージ内に含めることができます。

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

上記の例では、検証は失敗し、ユーザーには 「写真 #2 について説明してください。」 というエラーが表示されます。

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

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

ファイルの検証 (Validating Files)

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

ファイルタイプの検証

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

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

ファイルサイズの検証

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

File::types(['mp3', 'wav'])
    ->min('1kb')
    ->max('10mb');

画像ファイルの検証

アプリケーションがユーザーによってアップロードされた画像を受け入れる場合、File ルールの image コンストラクターメソッドを使用して、検証中のファイルが画像 (jpg、jpeg、png、bmp、gif、または webp) であることを確認できます。

さらに、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)),
    ],
]);

画像の寸法の検証に関する詳細については、ディメンションルールのドキュメントを参照してください。

XSS 脆弱性の可能性があるため、デフォルトでは、image ルールは SVG ファイルを許可しません。 SVG ファイルを許可する必要がある場合は、allowSvg: true を image ルールに渡すことができます: File::image(allowSvg: true)。

画像の寸法の検証

画像の寸法を検証することもできます。たとえば、アップロードされた画像が少なくとも幅 1000 ピクセル、高さ 500 ピクセルであることを検証するには、dimensions ルールを使用できます。

use Illuminate\Validation\Rule;
use Illuminate\Validation\Rules\File;

File::image()->dimensions(
    Rule::dimensions()
        ->maxWidth(1000)
        ->maxHeight(500)
)

画像の寸法の検証に関する詳細については、ディメンションルールのドキュメントを参照してください。

パスワードの検証 (Validating Passwords)

パスワードに適切なレベルの複雑さを持たせるには、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 ルールオブジェクトは k-Anonymity モデルを使用して、ユーザーのプライバシーやセキュリティを犠牲にすることなく、パスワードが haveibeenpwned.com サービス経由で漏洩したかどうかを判断します。

デフォルトでは、パスワードがデータ漏洩の際に少なくとも 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 ルールは、アプリケーションのサービスプロバイダの 1 つの 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]);

    // ...
});

カスタム検証ルール (Custom Validation Rules)

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

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

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

「暗黙の」ルールは、属性が必須であることを_暗黙的に示すだけです。欠落している属性または空の属性を実際に無効にするかどうかは、ユーザー次第です。

導入 (Introduction)​

検証のクイックスタート (Validation Quickstart)​

ルートの定義​

コントローラの作成​

検証ロジックの作成​

最初の検証失敗時に停止する​

ネストされた属性に関する注意​

検証エラーの表示​

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

XHR リクエストと検証​

@error ディレクティブ​

フォームの再入力​

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

検証エラーの応答形式​

フォームリクエストの検証 (Form Request Validation)​

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

追加の検証の実行​

最初の検証失敗時に停止する​

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

エラーバッグのカスタマイズ​

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

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

検証属性のカスタマイズ​

検証のための入力の準備​

バリデーターを手動で作成する (Manually Creating Validators)​

最初の検証失敗時に停止する​

自動リダイレクト​

名前付きエラーバッグ​

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

特定の属性に対するカスタム メッセージの指定​

カスタム属性値の指定​

追加の検証の実行​

検証された入力の使用 (Working With Validated Input)​

エラーメッセージの処理 (Working With Error Messages)​

フィールドの最初のエラー メッセージの取得​

フィールドのすべてのエラー メッセージの取得​

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

フィールドにメッセージが存在するかどうかを確認する​

言語ファイルでのカスタム メッセージの指定​

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

言語ファイルでの属性の指定​

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

利用可能な検証ルール (Available Validation Rules)​

Booleans​

Strings​

Numbers​

Arrays​

Dates​

Files​

Database​

Utilities​

accepted​

accepted_if:anotherfield,value,...​

active_url​

after:date​

after_or_equal:date​

anyOf​

alpha​

alpha_dash​

alpha_num​

array​

ascii​

bail​

before:date​

before_or_equal:date​

between:min,max​

boolean​

confirmed​

contains:foo,bar,...​

doesnt_contain:foo,bar,...​

current_password​

date​

date_equals:date​

date_format:format,...​

decimal:min,max​

declined​

declined_if:anotherfield,value,...​

different:field​

digits:value​

digits_between:min,max​

導入 (Introduction)

検証のクイックスタート (Validation Quickstart)

ルートの定義

コントローラの作成

検証ロジックの作成

最初の検証失敗時に停止する

ネストされた属性に関する注意

検証エラーの表示

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

XHR リクエストと検証

`@error` ディレクティブ

フォームの再入力

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

検証エラーの応答形式

フォームリクエストの検証 (Form Request Validation)

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

追加の検証の実行

最初の検証失敗時に停止する

リダイレクト場所のカスタマイズ

エラーバッグのカスタマイズ

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

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

検証属性のカスタマイズ

検証のための入力の準備

バリデーターを手動で作成する (Manually Creating Validators)

最初の検証失敗時に停止する

自動リダイレクト

名前付きエラーバッグ

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

特定の属性に対するカスタムメッセージの指定

カスタム属性値の指定

追加の検証の実行

検証された入力の使用 (Working With Validated Input)

エラーメッセージの処理 (Working With Error Messages)

フィールドの最初のエラーメッセージの取得

フィールドのすべてのエラーメッセージの取得

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

フィールドにメッセージが存在するかどうかを確認する

言語ファイルでのカスタムメッセージの指定

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

言語ファイルでの属性の指定

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

利用可能な検証ルール (Available Validation Rules)

Booleans

Strings

Numbers

Arrays

Dates

Files

Database

Utilities

accepted

accepted_if:anotherfield,value,...

active_url

after:date

after_or_equal:date

anyOf

alpha

alpha_dash

alpha_num

array

ascii

bail

before:date

before_or_equal:date

between:min,max

boolean

confirmed

contains:foo,bar,...

doesnt_contain:foo,bar,...

current_password

date

date_equals:date

date_format:format,...

decimal:min,max

declined

declined_if:anotherfield,value,...

different:field

digits:value

digits_between:min,max