Laravel 5.6 バリデーション

イントロダクション

Laravelは入力されたデータに対するバリデーションの様々なアプローチを提供しています。Laravelの基本コントローラクラスはパワフルでバラエティー豊かなバリデーションルールを使いHTTPリクエストをバリデーションするために便利な手法を提供している、ValidatesRequestsトレイトをデフォルトで使用しています。

クイックスタート

パワフルなバリデーション機能を学ぶために、フォームバリデーションとユーザーにエラーメッセージを表示する完全な例を見てください。

ルート定義

まず、routes/web.phpファイルに以下のルートを定義してあるとしましょう。

Route::get('post/create', 'PostController@create');

Route::post('post', 'PostController@store');

もちろん、GETのルートは新しいブログポストを作成するフォームをユーザーへ表示し、POSTルートで新しいブログポストをデータベースへ保存します。

コントローラ作成

次に、これらのルートを処理する簡単なコントローラを見てみましょう。今のところstoreメソッドは空のままです。

<?php

namespace App\Http\Controllers;

use Illuminate\Http\Request;
use App\Http\Controllers\Controller;

class PostController extends Controller
{
    /**
     * 新ブログポスト作成フォームの表示
     *
     * @return Response
     */
    public function create()
    {
        return view('post.create');
    }

    /**
     * 新しいブログポストの保存
     *
     * @param  Request  $request
     * @return Response
     */
    public function store(Request $request)
    {
        // ブログポストのバリデーションと保存コード…
    }
}

バリデーションロジック

これで新しいブログポストに対するバリデーションロジックをstoreメソッドに埋め込む準備ができました。そのためには、Illuminate\Http\Requestオブジェクトが提供する、validateメソッドを使います。バリデーションルールに成功すると、コードは通常通り続けて実行されます。逆にバリデーションに失敗すると、例外が投げられ、ユーザーに対し自動的に適切なエラーレスポンスが返されます。伝統的なHTTPリクエストの場合は、リダイレクトレスポンスが生成され、一方でAJAXリクエストにはJSONレスポンスが返されます。

validateメソッドをもっとよく理解するため、storeメソッドに取り掛かりましょう。

/**
 * 新ブログポストの保存
 *
 * @param  Request  $request
 * @return Response
 */
public function store(Request $request)
{
    $validatedData = $request->validate([
        'title' => 'required|unique:posts|max:255',
        'body' => 'required',
    ]);

    // ブログポストは有効
}

ご覧のとおりに、実行したいバリデーションルールをvalidateメソッドへ渡します。繰り返しますが、バリデーションに失敗すれば、適切なレスポンスが自動的に生成されます。バリデーションに成功すれば、コントローラは続けて通常通り実行されます。

最初のバリデーション失敗時に停止

最初のバリデーションに失敗したら、残りのバリデーションルールの判定を停止したいことも、時々あります。このためには、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',
]);

バリデーションエラー表示

ではやって来たリクエストの入力が指定したバリデーションルールに当てはまらなかった場合はどうなるんでしょう? 既に説明した通り、Laravelは自動的にユーザーを以前のページヘリダイレクトします。付け加えて、バリデーションエラーは全部自動的にフラッシュデータとしてセッションへ保存されます。

GETルートのビューへエラーメッセージを明示的に結合する必要がないことに注目してください。これはつまり、Laravelはいつもセッションデータの中にエラーの存在をチェックしており、見つけた場合は自動的に結合しているからです。$errors変数はIlluminate\Support\MessageBagのインスタンスです。このオブジェクトの詳細は、ドキュメントを参照してください。

Tip!! $errors変数はwebミドルウェアグループに所属する、Illuminate\View\Middleware\ShareErrorsFromSessionミドルウェアによりビューに結合されます。このミドルウェアが適用される場合は、いつでもビューの中で$errors変数が使えます。$errors変数はいつでも定義済みであると想定でき、安心して使えます。

この例では、バリデーションに失敗すると、エラーメッセージをビューで表示できるように、コントローラのcreateメソッドにリダイレクトされることになります。

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

<h1>ポスト作成</h1>

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

<!-- ポスト作成フォーム -->

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

LaravelはTrimStringsConvertEmptyStringsToNullミドルウェアをアプリケーションのデフォルトグローバルミドルウェアスタックに含んでいます。これらのミドルウェアはApp\Http\Kernelクラスでリストされています。このため、バリデータがnull値が無効であると判定されないように、オプションフィールドへnullableを付ける必要がたびたび起きるでしょう。

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

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

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

この例ではアプリケーションにデータを送るために伝統的なフォームを使いました。しかし、多くのアプリケーションでAJAXリクエストが使用されています。AJAXリクエストにvalidateメソッドを使う場合、Laravelはリダイレクトレスポンスを生成しません。代わりにバリデーションエラーを全部含んだJSONレスポンスを生成します。このJSONレスポンスは422 HTTPステータスコードで送られます。

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

フォームリクエスト作成

より複雑なバリデーションのシナリオでは、「フォームリクエスト」を生成したほうが良いでしょう。フォームリクエストは、バリデーションロジックを含んだカスタムリクエストクラスです。フォームリクエストクラスを作成するには、make:request Artisan CLIコマンドを使用します。

php artisan make:request StoreBlogPost

生成されたクラスは、app/Http/Requestディレクトリへ設置されます。このディレクトリが存在しなくても、make:requestコマンドを実行すれば作成されます。では、バリデーションルールを少しrulesメソッドへ追加してみましょう。

/**
 * リクエストに適用するバリデーションルールを取得
 *
 * @return array
 */
public function rules()
{
    return [
        'title' => 'required|unique:posts|max:255',
        'body' => 'required',
    ];
}

Tip!! rulesメソッドの引数として、必要な依存をタイプヒントで指定できます。それらはLaravelのサービスコンテナにより、自動的に依存解決されます。

では、どのようにバリデーションルールを実行するのでしょうか?必要なのは、コントローラのメソッドで、このリクエストをタイプヒントで指定することです。やって来たフォームリクエストはコントローラメソッドが呼び出される前にバリデーションを行います。つまり、コントローラにバリデーションロジックを取っ散らかす必要はありません。

/**
 * ブログポストの保存
 *
 * @param  StoreBlogPost  $request
 * @return Response
 */
public function store(StoreBlogPost $request)
{
    // 送信されたリクエストは正しい

    // バリデーション済みデータの取得
    $validated = $request->validated();
}

バリデーションに失敗すると、前のアドレスにユーザーを戻すために、リダイレクトレスポンスが生成されます。エラーも表示できるように、フラッシュデーターとしてセッションに保存されます。もしリクエストがAJAXリクエストであれば、バリデーションエラーを表現するJSONを含んだ、422ステータスコードのHTTPレスポンスがユーザーに返されます。

フォームリクエストへのAfterフックを追加

フォームリクエストへ"after"フックを追加したい場合は、withValidatorメソッドを使用します。このメソッドは完全に構築されたバリデータを受け取るため、バリデーションルールが実際に評価される前に、バリデータのどんなメソッドも呼び出すことができます。

/**
 * バリデータインスタンスの設定
 *
 * @param  \Illuminate\Validation\Validator  $validator
 * @return void
 */
public function withValidator($validator)
{
    $validator->after(function ($validator) {
        if ($this->somethingElseIsInvalid()) {
            $validator->errors()->add('field', 'Something is wrong with this field!');
        }
    });
}

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

フォームリクエストクラスはauthorizeメソッドも用意しています。このメソッドでは認証されているユーザーが、指定されたリソースを更新する権限を実際に持っているのかを確認します。たとえば、ユーザーが更新しようとしているブログコメントを実際に所有しているかを判断するとしましょう。

/**
 * ユーザーがこのリクエストの権限を持っているかを判断する
 *
 * @return bool
 */
public function authorize()
{
    $comment = Comment::find($this->route('comment'));

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

全リフォームリクエストはLaravelのベースリクエストクラスを拡張していますので、現在認証されているユーザーへアクセスする、userメソッドが使えます。また、上記例中のrouteメソッドの呼び出しにも、注目してください。例えば{comment}パラメーターのような、呼び出しているルートで定義されているURIパラメータにもアクセスできます。

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

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

アプリケーションの他の場所で認証のロジックを行おうと設計しているのでしたら、authorizeメソッドからtrueを返してください。

/**
 * ユーザーがこのリクエストの権限を持っているかを判断する
 *
 * @return bool
 */
public function authorize()
{
    return true;
}

Tip!! authorizeメソッドの引数として、必要な依存をタイプヒントで指定できます。それらはLaravelのサービスコンテナにより、自動的に依存解決されます。

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

フォームリクエストにより使用されているメッセージはmessageメソッドをオーバーライドすることによりカスタマイズできます。このメソッドから属性/ルールと対応するエラーメッセージのペアを配列で返してください。

/**
 * 定義済みバリデーションルールのエラーメッセージ取得
 *
 * @return array
 */
public function messages()
{
    return [
        'title.required' => 'A title is required',
        'body.required'  => 'A message is required',
    ];
}

バリデータの生成

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

<?php

namespace App\Http\Controllers;

use Validator;
use Illuminate\Http\Request;
use App\Http\Controllers\Controller;

class PostController extends Controller
{
    /**
     * 新しいブログポストの保存
     *
     * @param  Request  $request
     * @return Response
     */
    public function store(Request $request)
    {
        $validator = Validator::make($request->all(), [
            'title' => 'required|unique:posts|max:255',
            'body' => 'required',
        ]);

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

        // ブログポストの保存処理…
    }
}

makeメソッドの第1引数は、バリデーションを行うデータです。第2引数はそのデータに適用するバリデーションルールです。

リクエストのバリデーションが失敗するかを確認した後、セッションにエラーメッセージをフラッシュデータとして保存するためにwithErrorsメソッドが利用できます。このメソッドを使うと、簡単にユーザーに情報を表示できるようにするため、リダイレクトの後でビューに対し$errors変数を自動的に共有します。withErrorsメソッドはバリデータかMessageBag、PHPの配列を受け取ります。

自動リダイレクト

バリデータインスタンスを自分で生成したいが、リクエストのvalidateメソッドが提供する自動リダイレクト機能を使用したい場合は、生成したバリデータインスタンスのvalidateメソッドを呼び出すこともできます。バリデーションに失敗すると、ユーザーは自動的にリダイレクトされるか、AJAXリクエストの場合は、JSONリクエストが返されます。

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

名前付きエラーバッグ

1ページの中に複数のフォームを入れている場合は、特定のフォームのエラーメッセージを受け取れるように、MessageBagへ名前を付けてください。withErrorsの第2引数に名前を渡します。

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

$errors変数を使い、名前を付けたMessageBagインスタンスへアクセスできます。

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

バリデーション後のフック

バリデータにはさらに、バリデーションが終了した時点で実行するコールバックを付け加えられます。これにより、追加のバリデーションを行い、さらにエラーメッセージコレクションにエラーメッセージを追加することが簡単にできます。バリデータインスタンスのafterメソッドを使ってみましょう。

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

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

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

エラーメッセージの操作

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

カスタムエラーメッセージ

必要であればバリデーションでデフォルトのメッセージの代わりに、カスタムエラーメッセージを使うことができます。カスタムメッセージを指定するにはいくつか方法があります。最初の方法はValidator::makeメソッドの第3引数として、カスタムメッセージを渡す方法です。

$messages = [
    'required' => 'The :attribute field is required.',
];

$validator = Validator::make($input, $rules, $messages);

この例中の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 e-mail address!',
];

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

多くの場合、Validatorに直接カスタムメッセージを渡すよりは言語ファイルに指定したいですよね。ならばresources/lang/xx/validation.php言語ファイルのcustom配列にメッセージを追加してください。

'custom' => [
    'email' => [
        'required' => 'We need to know your e-mail address!',
    ],
],

言語ファイル中のカスタム属性名の指定

バリデーションメッセージの:attribute部分をカスタムアトリビュート名で置き換えたい場合は、resources/lang/xx/validation.php言語ファイルのattributes配列でカスタム名を指定してください。

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

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

使用可能な全バリデーションルールとその機能の一覧です。

accepted

そのフィールドがyeson1trueであることをバリデートします。これは「サービス利用規約」同意のバリデーションに便利です。

active_url

フィールドが、dns_get_record PHP関数により、有効なAかAAAAレコードであることをバリデートします。

after:日付

フィールドの値が与えられた日付より後であるかバリデーションします。日付はPHPのstrtotime関数で処理されます。

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

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

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

after_or_equal:日付

フィールドが指定した日付以降であることをバリデートします。詳細はafterルールを参照してください。

alpha

フィールドが全部アルファベット文字であることをバリデートします。

alpha_dash

フィールドが全部アルファベット文字と数字、ダッシュ(-)、下線(_)であることをバリデートします。

alpha_num

フィールドが全部アルファベット文字と数字であることをバリデートします。

array

フィールドが配列タイプであることをバリデートします。

bail

バリデーションに初めて失敗した時点で、残りのルールのバリデーションを中止します。

before:日付

フィールドが指定された日付より前であることをバリデートします。日付はPHPのstrtotime関数で処理されます。

before_or_equal:日付

フィールドが指定した日付以前であることをバリデートします。日付はPHPのstrtotime関数で処理されます。

between:min,max

フィールドが指定された最小値最大値の間のサイズであることをバリデートします。sizeルールと同様の判定方法で、文字列、数値、配列、ファイルが評価されます。

boolean

フィールドが論理値として有効であることをバリデートします。受け入れられる入力は、truefalse10"1""0"です。

confirmed

フィールドがそのフィールド名+_confirmationフィールドと同じ値であることをバリデートします。例えば、バリデーションするフィールドがpasswordであれば、同じ値のpassword_confirmationフィールドが入力に存在していなければなりません。

date

パリデーションされる値はPHP関数のstrtotimeを使用し確認されます。

date_equals:日付

バリデーションされる値が、指定した日付と同じことをバリデートします。日付は、PHPのstrtotime関数へ渡されます。

date_format:フォーマット

バリデーションされる値がフォーマット定義と一致するか確認します。バリデーション時にはdatedate_formatどちらかを使用しなくてはならず、両方はできません。

different:フィールド

フィールドが指定されたフィールドと異なった値を指定されていることをバリデートします。

digits:

フィールドが数値で、の桁数であることをバリデートします。

digits_between:最小値,最大値

フィールドが整数で、桁数が最小値から最大値の間であることをバリデートします。

dimensions

バリデーション対象のファイルが、パラメータにより指定されたサイズに合致することをバリデートします。

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

使用可能なパラメータは、min_widthmax_widthmin_heightmax_heightwidthheight、_ratio_です。

_ratio_制約は、横/縦比を表します。3/2という指定も、1.5のようにfloatでの指定も可能です。

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

このルールは多くの引数を要求するので、Rule::dimensionsメソッドを使い、記述的にこのルールを構築してください。

use Illuminate\Validation\Rule;

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

distinct

対象が配列の時、フィールドに重複した値がないことをバリデートします。

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

email

フィールドがメールアドレスとして正しいことをバリデートします。

exists:テーブル,カラム

フィールドの値が、指定されたデータベーステーブルに存在することをバリデートします。

基本的なExistsルールの使用法

'state' => 'exists:states'

カスタムカラム名の指定

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

existsクエリにデータベース接続を指定する必要があることも多いでしょう。「ドット」記法を用い、テーブル名の前に接続名を付けることで、指定可能です。

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

バリデーションルールで実行されるクエリをカスタマイズしたい場合は、ルールをスラスラと定義できるRuleクラスを使ってください。下の例では、|文字を区切りとして使用する代わりに、バリデーションルールを配列として指定しています。

use Illuminate\Validation\Rule;

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

file

フィールドがアップロードに成功したファイルであることをバリデートします。

filled

フィールドが存在する場合、空でないことをバリデートします。

gt:field

The field under validation must be greater than the given field. The two fields must be of the same type. Strings, numerics, arrays, and files are evaluated using the same conventions as the size rule.

gte:field

The field under validation must be greater than or equal to the given field. The two fields must be of the same type. Strings, numerics, arrays, and files are evaluated using the same conventions as the size rule.

image

フィールドで指定されたファイルが画像(jpg、png、bmp、gif、svg)であることをバリデートします。

in:foo,bar...

フィールドが指定したリストの中の値に含まれていることをバリデートします。このルールを使用するために配列をimplodeする必要が多くなりますので、ルールを記述的に構築するには、Rule::inメソッドを使ってください。

use Illuminate\Validation\Rule;

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

in_array:別のフィールド

フィールドが、他のフィールドの値のどれかであることをバリデートします。

integer

フィールドが整数値であることをバリデートします。

ip

フィールドがIPアドレスの形式として正しいことをバリデートします。

ipv4

フィールドがIPv4アドレスの形式として正しいことをバリデートします。

ipv6

フィールドがIPv6アドレスの形式として正しいことをバリデートします。

json

フィールドが有効なJSON文字列であることをバリデートします。

lt:field

The field under validation must be less than the given field. The two fields must be of the same type. Strings, numerics, arrays, and files are evaluated using the same conventions as the size rule.

lte:field

The field under validation must be less than or equal to the given field. The two fields must be of the same type. Strings, numerics, arrays, and files are evaluated using the same conventions as the size rule.

max:

フィールドが最大値として指定された以下であることをバリデートします。sizeルールと同様の判定方法で、文字列、数値、配列、ファイルが評価されます。

mimetypes:text/plain,...

フィールドが指定されたMIMEタイプのどれかであることをバリデートします。

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

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

mimes:foo,bar,...

フィールドで指定されたファイルが拡張子のリストの中のMIMEタイプのどれかと一致することをバリデートします。

MIMEルールの基本的な使用法

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

拡張子だけを限定する必要があるとしても、このルールはファイルのMIMEタイプに基づき、ファイルの内容を読み、MIMEタイプを推測することでバリデーションを行います。

MIMEタイプと対応する拡張子の完全なリストは、https://svn.apache.org/repos/asf/httpd/httpd/trunk/docs/conf/mime.typesで確認できます。

min:

フィールドが最小値として指定された以上であることをバリデートします。sizeルールと同様の判定方法で、文字列、数値、配列、ファイルが評価されます。

not_in:foo,bar,...

フィールドが指定された値のリスト中に含まれていないことをバリデートします。Rule::notInメソッドのほうが、ルールの構成が読み書きしやすいでしょう。

use Illuminate\Validation\Rule;

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

not_regex:pattern

フィールドが指定した正規表現と一致しないことをバリデートします。

注目: regexnot_regexパターンを使用する場合はルールをパイプ(縦棒)で区切らず、ルールの配列で指定する必要があります。特に正規表現に縦棒を含んでいる場合に該当します。

nullable

フィールドがnullでも良いことをバリデートします。これは特にnull値を含む文字列や整数のようなプリミティブをバリデートする場合に便利です。

numeric

フィールドは数値であることをバリデートします。

present

フィールドが存在していることをバリデートしますが、存在していれば空を許します。

regex:正規表現

フィールドが指定された正規表現にマッチすることをバリデートします。

注目: regexnot_regexパターンを使用する場合はルールをパイプ(縦棒)で区切らず、ルールの配列で指定する必要があります。特に正規表現に縦棒を含んでいる場合に該当します。

required

フィールドが入力データに存在しており、かつ空でないことをバリデートします。フィールドは以下の条件の場合、「空」であると判断されます。

  • 値がnullである。
  • 値が空文字列である。
  • 値が空の配列か、空のCountableオブジェクトである。
  • 値がパスのないアップロード済みファイルである。

required_if:他のフィールド,,...

他のフィールドのどれかと一致している場合、このフィールドが存在し、かつ空でないことをバリデートします。

required_unless:他のフィールド,,...

他のフィールドのどれとも一致していない場合、このフィールドが存在し、かつ空でないことをバリデートします。

required_with:foo,bar,...

指定した他のフィールドが一つでも存在している場合、このフィールドが存在し、かつ空でないことをバリデートします。

required_with_all:foo,bar,...

指定した他のフィールドがすべて存在している場合、このフィールドが存在し、かつ空でないことをバリデートします。

required_without:foo,bar,...

指定した他のフィールドのどれか一つでも存在していない場合、このフィールドが存在し、かつ空でないことをバリデートします。

required_without_all:foo,bar,...

指定した他のフィールドがすべて存在していない場合、このフィールドが存在し、かつ空でないことをバリデートします。

same:フィールド

フィールドが、指定されたフィールドと同じ値であることをバリデートします。

size:

フィールドは指定されたと同じサイズであることをバリデートします。文字列の場合、は文字長です。数値項目の場合、は整数値です。配列の場合、は配列の個数(count)です。ファイルの場合、はキロバイトのサイズです。

string

フィルードは文字列タイプであることをバリデートします。フィールドがnullであることも許す場合は、そのフィールドにnullableルールも指定してください。

timezone

timezone_identifiers_list PHP関数の値に基づき、フィールドがタイムゾーンとして識別されることをバリデートします。

unique:テーブル,カラム,除外ID,IDカラム

フィールドは指定されたデータベーステーブルで一意であることをバリデートします。columnオプションが指定されない場合、フィールド名が使用されます。

カスタムカラム名の指定

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

カスタムデータベース接続

場合により、バリデータにより生成されるデータベースクエリに、カスタム接続を設定する必要があるかもしれません。上記のバリデーションルール、unique:usersではクエリに対し、デフォルトデータベース接続が使用されます。これをオーバーライドするにはドット記法で、接続に続けテーブル名を指定してください。

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

指定されたIDのuniqueルールを無視する

uniqueチェックで指定したIDを除外したい場合があります。たとえばユーザー名、メールアドレス、それと住所の「プロフィール更新」の状況を考えてください。もちろん、メールアドレスは一意であることを確認したいと思います。しかし、もしユーザーが名前フィールドだけ変更し、メールフィールドを変更しなければ、そのユーザーが既にそのメールアドレスの所有者として登録されているために起きるバリデーションエラーを避けたいと思うでしょう。

バリデータにユーザーIDを無視するように指示するには、ルールをスラスラと定義できるRuleクラスを使います。以下の例の場合、さらにルールを|文字を区切りとして使用する代わりに、バリデーションルールを配列として指定しています。

use Illuminate\Validation\Rule;

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

もしテーブルの主キーとして、id以外のカラム名を使用している場合、ignoreメソッドを呼び出す時に、カラムの名前を指定してください。

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

追加のWHERE節を付け加える

whereメソッドを使用し、クエリをカスタマイズすることにより、追加のクエリ制約を指定することも可能です。例として、account_id1であることを確認する制約を追加してみましょう。

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

url

フィールドが有効なURLであることをバリデートします。

条件付きでルールを追加する

項目存在時のバリデーション

ある状況では、そのフィールドが入力配列の中に存在する場合のみ、バリデーションを実行したいことがあると思います。これを簡単に行うには、sometimesルールを追加してください。

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

上の例ではemailフィールドが、$data配列の中に存在している場合のみバリデーションが実行されます。

Tip!! フィールドが常に存在しているが、空であることをバリデートする場合は、この追加フィールドに対する注意事項を確認してください。

複雑な条件のバリデーション

時々もっと複雑な条件のロジックによりバリデーションルールを追加したい場合もあります。たとえば他のフィールドが100より大きい場合のみ、指定したフィールドが入力されているかをバリデートしたいときなどです。もしくは2つのフィールドのどちらか一方が存在する場合は、両方共に値を指定する必要がある場合です。こうしたルールを付け加えるのも面倒ではありません。最初にValidatorインスタンスを生成するのは、固定ルールの場合と同じです。

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

ゲームコレクターのためのWebアプリケーションだと仮定しましょう。ゲームコレクターがアプリケーションに登録する時に、100ゲーム以上所有しているのであれば、なぜそんなに多く持っているのか理由を説明してもらいます。たとえば販売店を運営しているのかも知れませんし、ただ収集家なのかも知れません。この条件付きの要求を追加するためにValidatorインスタンスへ、sometimesメソッドを使用してください。

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

sometimesメソッドの最初の引数は条件付きでバリデーションを行うフィールドの名前です。2つ目の引数は追加したいルールです。3つ目の引数にクロージャが渡され、trueを返したらそのルールは追加されます。このメソッドにより複雑な条件付きのバリデーションが簡単に作成できます。一度に多くのフィールドに、条件付きバリデーションを追加することもできます。

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

Tip!! クロージャに渡される$inputパラメーターはIlluminate\Support\Fluentのインスタンスで、フィールドと入力値にアクセスするためのオブジェクトです。

配列のバリデーション

フォーム入力フィールドの配列をバリデーションするのに苦労する必要はありません。配列中の属性をバリデーションするために「ドット記法」が使えます。たとえば、送信されたHTTPリクエストに、photos[profile]フィールドが含まれているかをバリデーションするには、次のように行います。

$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 e-mail address',
    ]
],

カスタムバリデーションルール

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

Laravelは様々な便利なバリデーションルールを提供しています。しかし、独自のバリデーションも利用したいでしょう。カスタムバリデーションルールを登録する一つ目の方法は、ルールオブジェクトを使うやり方です。新しいルールオブジェクトを生成するには、make:rule Artisanコマンドを使用します。このコマンドを使用し、文字列が大文字であることをバリデートするルールを生成してみましょう。Laravelの新しいルールは、app/Rulesディレクトリに設置されます。

php artisan make:rule Uppercase

ルールを生成したら、動作を定義する準備ができました。ルールオブジェクトは2つのメソッドを含みます。passesmessageです。passesメソッドは属性の値と名前を受け取り、その属性値が有効であればtrue、無効であればfalseを返します。messageメソッドは、バリデーション失敗時に使用する、バリデーションエラーメッセージを返します。

<?php

namespace App\Rules;

use Illuminate\Contracts\Validation\Rule;

class Uppercase implements Rule
{
    /**
     * バリデーションの成功を判定
     *
     * @param  string  $attribute
     * @param  mixed  $value
     * @return bool
     */
    public function passes($attribute, $value)
    {
        return strtoupper($value) === $value;
    }

    /**
     * バリデーションエラーメッセージの取得
     *
     * @return string
     */
    public function message()
    {
        return 'The :attribute must be uppercase.';
    }
}

もちろん、翻訳ファイルのエラーメッセージを返したい場合は、messageメソッドからtransヘルパを呼び出せます。

/**
 * バリデーションエラーメッセージの取得
 *
 * @return string
 */
public function message()
{
    return trans('validation.uppercase');
}

ルールが定義できたら、他のバリデーションルールと一緒に、ルールオブジェクトのインスタンスをバリデータへ渡し、指定します。

use App\Rules\Uppercase;

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

クロージャの使用

アプリケーション全体で一回のみカスタムルールの機能が必要な場合は、ルールオブジェクトの代わりにクロージャが使えます。属性名、属性の値、バリデーション失敗時に返す必要のある$failコールバックがクロージャに渡されます。

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

拡張の使用

カスタムバリデーションルールを登録するもう一つの方法では、Validatorファサードextendメソッドを使用します。カスタムバリデーションルールを登録するために、 サービスプロバイダの中で、このメソッドを使ってみましょう。

<?php

namespace App\Providers;

use Illuminate\Support\ServiceProvider;
use Illuminate\Support\Facades\Validator;

class AppServiceProvider extends ServiceProvider
{
    /**
     * アプリケーションサービスの初期処理
     *
     * @return void
     */
    public function boot()
    {
        Validator::extend('foo', function ($attribute, $value, $parameters, $validator) {
            return $value == 'foo';
        });
    }

    /**
     * サービスプロバイダ登録
     *
     * @return void
     */
    public function register()
    {
        //
    }
}

カスタムバリデータのクロージャは4つの引数を取ります。$attributeはバリデーションをしているフィールド、$valueはその値、$parametersはルールに渡された引数、最後はValidatorインスタンスです。

クロージャの代わりにextendメソッドへクラスとメソッドを渡すこともできます。

Validator::extend('foo', 'FooValidator@validate');

エラーメッセージの定義

カスタムルールに対するエラーメッセージを定義する必要もあります。インラインでカスタムエラーの配列を使うか、バリデーション言語ファイルにエントリーを追加するどちらかで行えます。このメッセージは属性とエラーメッセージを指定するだけの一次配列で、「カスタマイズ」した配列を入れてはいけません。

"foo" => "Your input was invalid!",

"accepted" => "The :attribute must be accepted.",

// 残りのバリデーションエラーメッセージ…

カスタムバリデーションルールを作成する場合、エラーメッセージのカスタムプレースフォルダも定義したいことがあります。前記の方法でカスタムバリデータを作成し、それからValidatorファサードのreplacerメソッドを呼びだしてください。これはサービスプロバイダbootメソッドの中で行います。

/**
 * 全アプリケーションサービスの初期処理
 *
 * @return void
 */
public function boot()
{
    Validator::extend(...);

    Validator::replacer('foo', function ($message, $attribute, $rule, $parameters) {
        return str_replace(...);
    });
}

暗黙の拡張

バリデートする属性が存在していない場合か、requiredルールで定義している「空」の場合、カスタム拡張したものも含め、通常のバリデーションルールは実行されません。たとえばuniqueルールはnull値に対して実行されません。

$rules = ['name' => 'unique'];

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

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

属性が空であってもルールを実行するということは、その属性が必須であることを暗黙のうちに示しています。このような「暗黙の」拡張を作成するには、Validator::extendImplicit()メソッドを使います。

Validator::extendImplicit('foo', function ($attribute, $value, $parameters, $validator) {
    return $value == 'foo';
});

Note: 「暗黙の」拡張は、単にその属性が必須であるとほのめかしているだけです。属性が存在しない場合や空のときに、実際にバリデーションを失敗と判断するかどうかは、みなさん次第です。

ドキュメント章別ページ

公式パッケージ

ヘッダー項目移動

注目:アイコン:ページ内リンク設置(リンクがないヘッダーへの移動では、リンクがある以前のヘッダーのハッシュをURLへ付加します。

移動

クリックで即時移動します。

バージョン

設定

適用ボタンクリック後に、全項目まとめて適用されます。

カラーテーマ
和文指定 Pagination
和文指定 Scaffold
Largeスクリーン表示幅
インデント
本文フォント
コードフォント
フォント適用確認

フォントの指定フィールドから、フォーカスが外れると、当ブロックの内容に反映されます。EnglishのDisplayもPreviewしてください。

フォント設定時、表示に不具合が出た場合、当サイトのクッキーを削除してください。

バックスラッシュを含むインライン\Code\Blockの例です。

以下はコードブロックの例です。

<?php

namespace App;

use Illuminate\Database\Eloquent\Model;

class User extends Model
{
    /**
     * ユーザに関連する電話レコードを取得
     */
    public function phone()
    {
        return $this->hasOne('App\Phone');
    }
}

設定を保存する前に、表示が乱れないか必ず確認してください。CSSによるフォントファミリー指定の知識がない場合は、フォントを変更しないほうが良いでしょう。

キーボード・ショートカット

オープン操作

PDC

ページ(章)移動の左オフキャンバスオープン

HA

ヘッダー移動モーダルオープン

MS

移動/設定の右オフキャンバスオープン

ヘッダー移動

T

最初のヘッダーへ移動

E

最後のヘッダーへ移動

NJ

次ヘッダー(H2〜H4)へ移動

BK

前ヘッダー(H2〜H4)へ移動

その他

?

このヘルプページ表示
閉じる