Laravel
検証

パラメーター

基本的な例

validateメソッド（ ValidatesRequests特性によって提供されるベースコントローラーで使用可能）を使用して、要求データを検証することができます。

ルールが合格すると、コードは正常に実行され続けます。ただし、検証に失敗すると、検証エラーを含むエラー応答が自動的に返されます。

• 一般的なHTMLフォーム要求の場合、ユーザーはフォームを送信した値を保持した状態で、前のページにリダイレクトされます
• JSON応答を要求する要求の場合、コード422のHTTP応答が生成されます

たとえば、 UserControllerでは、新しいユーザーをstoreメソッドに保存している可能性があります。保存する前に検証が必要です。

/**
 * @param  Request  $request
 * @return Response
 */
public function store(Request $request) {
    $this->validate($request, [
        'name' => 'required',
        'email' => 'email|unique:users|max:255'
    ],
    // second array of validation messages can be passed here
    [
        'name.required' => 'Please provide a valid name!',
        'email.required' => 'Please provide a valid email!',
    ]);

    // The validation passed
}

上記の例では、 nameフィールドが空でない値で存在することを検証します。次に、 emailフィールドに有効な電子メール形式があり、データベーステーブルの "users"で一意で、最大長が255文字であることを確認します。

| （パイプ）文字は、1つのフィールドに対して異なる検証規則を組み合わせています。

場合によっては、最初の検証に失敗した後で属性に対する検証ルールの実行を停止することもできます。これを行うには、 bailルールを属性に割り当てます。

$this->validate($request, [
    'name' => 'bail|required',
    'email' => 'email|unique:users|max:255'
]);

利用可能な検証ルールの完全なリストは、 下記のパラメータセクションにあります 。

アレイバリデーション

配列フォームの入力フィールドの検証は非常に簡単です。

指定された配列内の各名前、電子メール、および父の名前を検証する必要があるとします。あなたは以下を行うことができます：

$validator = \Validator::make($request->all(), [
    'name.*'       => 'required', 
    'email.*'      => 'email|unique:users',
    'fatherName.*' => 'required'
]);

if ($validator->fails()) {
    return back()->withInput()->withErrors($validator->errors());
}

Laravelは検証のためのデフォルトのメッセージを表示します。ただし、配列ベースのフィールドのカスタムメッセージが必要な場合は、次のコードを追加できます。

[
    'name.*' => [
        'required' => 'Name field is required',
    ],
    'email.*' => [
        'unique'   => 'Unique Email is required',
    ],
    'fatherName.*' => [
        'required' => 'Father Name required',
    ]
]

最終的なコードは次のようになります：

$validator = \Validator::make($request->all(), [
    'name.*'       => 'required', 
    'email.*'      => 'email|unique:users',
    'fatherName.*' => 'required',
], [
    'name.*'       => 'Name Required',
    'email.*'      => 'Unique Email is required',
    'fatherName.*' => 'Father Name required',
]);

if ($validator->fails()) {
    return back()->withInput()->withErrors($validator->errors());
}

その他の検証アプローチ

1）フォームリクエストの検証

アプリケーション内の特定の要求に対して、認可ロジック、検証ルール、およびエラーメッセージを保持できる「フォーム要求」を作成することができます。

make:request Artisan CLIコマンドは、クラスを生成し、 app/Http/Requestsディレクトリに配置します。

php artisan make:request StoreBlogPostRequest

authorizeメソッドは、このリクエストの認可ロジックでオーバーライドできます。

public function authorize()
{        
    return $this->user()->can('post');
}

rulesメソッドは、このリクエストの特定のルールでオーバーライドできます。

public function rules()
{
    return [
        'title' => 'required|unique:posts|max:255',
        'body' => 'required',
    ];
}

messagesメソッドは、この要求の特定のメッセージを無効にすることができます。

public function messages()
{
    return [
        'title.required' => 'A title is required',
        'title.unique' => 'There is another post with the same title',
        'title.max' => 'The title may not exceed :max characters',
        'body.required' => 'A message is required',
    ];
}

リクエストを検証するには、対応するコントローラメソッドに特定のリクエストクラスをタイプヒントしてください。検証に失敗すると、エラー応答が返されます。

public function store(StoreBlogPostRequest $request)
{
    // validation passed
}

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

柔軟性を高めるために、検証ツールを手動で作成し、失敗した検証を直接処理することができます。

<?php    
namespace App\Http\Controllers;

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

class PostController extends Controller
{
    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();
        }

        // Store the blog post...
    }
}

2）流暢にルールを作成する

場合によっては、サービスプロバイダ内のboot()メソッドを使用して一意のルールを作成する必要がある場合があります.Laravel 5.4ではRuleクラスを使用して新しいルールを作成できます。

例として、ユーザーを挿入または更新する場合のために、 UserRequestを使用して作業します。今のところ、名前が必要で、電子メールアドレスは一意でなければなりません。 uniqueルールを使用する際の問題は、ユーザーを編集しているときに同じ電子メールを保持する可能性があるため、現在のユーザーをルールから除外する必要があるということです。次の例は、新しいRuleクラスを利用して簡単にこれを行う方法を示しています。

<?php
namespace App\Http\Requests;
use Illuminate\Foundation\Http\FormRequest;
use Illuminate\Http\Request;
use Illuminate\Validation\Rule;

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

    /**
     * Get the validation rules that apply to the request.
     *
     * @return array
     */
    public function rules(Request $request)
    {
        $id = $request->route()->getParameter('user');

        return [
            'name'           =>  'required',
            
            // Notice the value is an array and not a string like usual
            'email'         =>  [
                'required',
                Rule::unique('users')->ignore($id)
            ]
        ];
    }
}

POST、PUT、PATCHの単一フォーム要求クラス

'Form Request Validation'の例に従えば、同じリクエストクラスをPOST 、 PUT 、 PATCH使用できるので、同じ/類似のバリデーションを使用して別のクラスを作成する必要はありません。これは、テーブル内に一意の属性がある場合に便利です。

/**
 * Get the validation rules that apply to the request.
 *
 * @return array
 */
public function rules() {
    switch($this->method()) {
        case 'GET':
        case 'DELETE':
            return [];
        case 'POST':
            return [
                'name'     => 'required|max:75|unique',
                'category' => 'required',
                'price'    => 'required|between:0,1000',
            ];
        case 'PUT':
        case 'PATCH':
            return [
                'name'     => 'required|max:75|unique:product,name,' . $this->product,
                'category' => 'required',
                'price'    => 'required|between:0,1000',
            ];
        default:break;
    }
}

上から順に、switch文はリクエストのメソッドタイプ（ GET 、 DELETE 、 POST 、 PUT 、 PATCH ）を調べます。

メソッドに応じて、定義されたルールの配列を返します。例のnameフィールドのように一意のフィールドがある場合、無視する検証の特定のIDを指定する必要があります。

'field_name' => 'unique:table_name,column_name,' . $idToIgnore`

id以外のラベルが付けられた主キーがある場合は、主キー列を4番目のパラメータとして指定します。

'field_name' => 'unique:table_name,column_name,' . $idToIgnore . ',primary_key_column'

この例では、 PUTを使用して、プロダクトIDの値をルート（ admin/products/{product} ）に渡しています。したがって、 $this->productは無視するidと等しくなります。

PUT|PATCHとPOST検証規則は同じである必要はありません。要件に合ったロジックを定義します。この手法では、カスタムフォーム要求クラス内で定義したカスタムメッセージを再利用することができます。

エラーメッセージ

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

/resources/lang/[lang]/validation.phpファイルには、バリデーターが使用するエラーメッセージが含まれています。必要に応じて編集することができます。

それらのほとんどには、エラーメッセージを生成するときに自動的に置き換えられるプレースホルダがあります。

たとえば、 'required' => 'The :attribute field is required.' :attributeプレースホルダはフィールド名に置き換えられます（または、同じファイル内のattributes配列の各フィールドの表示値をカスタマイズすることもできます）。

例

メッセージ設定：

'required' => 'Please inform your :attribute.',
//...
'attributes => [
    'email' => 'E-Mail address'
]

ルール：

`email' => `required`

結果として生じるエラーメッセージ：

"あなたのEメールアドレスをお知らせください。"

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

Requestクラスは配列を返すべきmessages()メソッドにアクセスできます。これはlangファイルに入ることなくメッセージをオーバーライドするために使用できます。たとえば、カスタムのfile_exists検証がある場合、以下のようなメッセージを表示できます。

class SampleRequest extends Request {

    /**
     * Get the validation rules that apply to the request.
     *
     * @return array
     */
    public function rules()
    {
        return [
            'image' =>  'required|file_exists'
        ];
    }

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

    public function messages()
    {
        return [
            'image.file_exists' =>  'That file no longer exists or is invalid'
        ];
    }

}

エラーメッセージの表示

検証エラーはセッションにフラッシュされ、 $errors変数でも利用できます。これは自動的にすべてのビューに共有されます。

ブレードビューでエラーを表示する例：

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

カスタム検証ルール

カスタム検証ルールを作成する場合は、Validatorファサードを使用して、サービスプロバイダのbootメソッドなどでカスタム検証ルールを作成できます。

<?php
namespace App\Providers;

use Illuminate\Support\ServiceProvider;
use Validator;

class AppServiceProvider extends ServiceProvider
{
    public function boot()
    {
        Validator::extend('starts_with', function($attribute, $value, $parameters, $validator) {
            return \Illuminate\Support\Str::startsWith($value, $parameters[0]);
        });

        Validator::replacer('starts_with', function($message, $attribute, $rule, $parameters) {
            return str_replace(':needle', $parameters[0], $message);
        });
    }
}

extendメソッドは、ルールの名前となる文字列と、属性の名前、検証される値、ルールパラメータの配列、およびバリデータインスタンスを渡す関数を取ります。検証は合格になります。この例では、値の文字列が指定された部分文字列で始まるかどうかを確認しています。

このカスタムルールのエラーメッセージは、通常/resources/lang/[lang]/validation.phpファイルで設定でき、パラメータ値などのプレースホルダを含めることができます。

'starts_with' => 'The :attribute must start with :needle.'

replacerメソッドは、ルールの名前である文字列と、置換前の元のメッセージ、属性の名前、ルールの名前、およびルールパラメータの配列を順番に渡す関数を取ります。必要に応じてプレースホルダを置き換えた後にメッセージを返す必要があります。

このルールを他のルールと同じように使用します。

$this->validate($request, [
    'phone_number' => 'required|starts_with:+'
]);