フォームの検証


#フォーム検証

##概要 Laravel は、アプリケーションに渡されたデータを検証するためのいくつかの異なる方法を提供します。デフォルトでは、Laravel のコントローラー基本クラスは

ValidatesRequests トレイトを使用します。これは、さまざまな強力な検証ルールを使用して受信 HTTP リクエストを検証する便利な方法を提供します。

クイック検証

Laravel の強力な検証機能を理解するために、フォームを検証してユーザーにエラー メッセージを表示する完全な例を見てみましょう。

ルートの定義

まず、routes/web.php## で次のように仮定します。 # file 次のルートは次の場所で定義されています:

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

明らかに、

GET ルートはユーザーが新しいブログ投稿を作成するためのフォームを表示し、POST ルートは新しいブログを保存します。データベースの真ん中に投稿します。

ルーターの作成

これらのルートを処理するコントローラー、

ストア ## を見てみましょう。 # ここではメソッドを空白のままにしておきます。

<?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 応答が送信されます。

store

メソッドに戻り、validate メソッドを詳しく理解しましょう:

/**
 * 保存一篇新的博客文章。
 *
 * @param  Request  $request
 * @return Response
 */
 public function store(Request $request){ 
    $validatedData = $request->validate([      
      'title' => 'required|unique:posts|max:255',        
      'body' => 'required',    
    ]);    
    // 博客文章验证通过
  }
ご覧のとおり、検証が必要です。 rules

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 はユーザーを前の場所に自動的にリダイレクトします。さらに、すべての検証エラー メッセージは session に自動的に保存されます。

もう一度言いますが、GET ルート内のビューにエラー メッセージを明示的にバインドする必要はありません。 Lavarel はセッション データ内のエラー情報をチェックし、それを自動的にビューにバインドします (ビュー ファイルが存在する場合)。変数 $errors は、Illuminate\Support\MessageBag のインスタンスです。このオブジェクトの詳細については、このドキュメントを参照してください。

{ヒント} $errors 変数は、Web によって提供される Illuminate\View\Middleware\ShareErrorsFromSession ミドルウェアによってバインドされます。ミドルウェア グループが表示されます。 このミドルウェアが適用されると、$error 変数 がビューで取得され、常に $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 アプリケーションのグローバル ミドルウェア スタック内の App\Http\ Kernel クラスには、TrimStrings および ConvertEmptyStringsToNull ミドルウェアが含まれています。したがって、バリデーターで 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 応答は、HTTP ステータス コード 422 とともに送信されます。

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

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

より複雑な検証シナリオに直面して、より複雑なロジックを処理するための「フォーム リクエスト」を作成できます。フォームリクエストは、検証ロジックを含むカスタムリクエストクラスです。アーティザン コマンド make:request を使用して、フォーム リクエスト クラスを作成できます。

php artisan make:request StoreBlogPost

新しく生成されたクラスは、app/Http/Requests ディレクトリに保存されます。このディレクトリが存在しない場合は、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();
 }

検証が失敗した場合は、ユーザーを前の状態に戻すメッセージが生成されます。ロケーションリダイレクト応答。これらのエラーは session にもフラッシュされ、ページ上に表示できるようになります。受信リクエストが AJAX の場合、422 ステータス コードと検証エラー情報を含む JSON データの HTTP 応答がユーザーに返されます。

フォーム リクエストの後にフックを追加する

フォーム リクエストの「後」にフックを追加する場合は、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 メソッドの呼び出しにも注意してください。このメソッドを使用すると、呼び出されるルートで定義されている URI パラメータ (次の例の {comment} パラメータなど) を取得できます。メソッドが

false

を返すと、403 ステータス コードを含む HTTP 応答が自動的に返され、コントローラー メソッドは実行されません。 アプリケーションの他の部分で認可ロジックを処理する予定がある場合は、authorize メソッドから

true

を返すだけです:

Route::post('comment/{comment}');
{ ヒント} 必要な依存関係を authorize

メソッドに渡すことができます。これらはLaravelが提供するサービスコンテナによって自動的に解決されます。

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

フォーム リクエストの messages メソッドをオーバーライドすることで、エラー メッセージをカスタマイズできます。このメソッドは、プロパティ/ルールのペアの配列と、それに対応するエラー メッセージを返す必要があります:

/**
 * 判断用户是否有权限进行此请求。
 *
 * @return bool
 */
 public function authorize(){  
   return true;
  }

##カスタム検証プロパティ

#検証メッセージの

:attribute 部分をカスタム属性名に置き換える場合は、attributes メソッドをオーバーライドしてカスタム名を指定できます。このメソッドは、プロパティと名前のペアの配列を返す必要があります:

/**
 * 获取已定义验证规则的错误消息。
 *
 * @return array
 */
 public function messages(){  
   return [       
    'title.required' => 'A title is required',        
    'body.required'  => 'A message is required',    
    ];
  }

バリデーターを手動で作成します

そうしない場合は、リクエストで

validate メソッドを使用すると、Validator ファサードを介してバリデーターのサンプルを手動で作成できます。
Validator ファサードで make メソッドを使用してバリデーターの例を作成します:

/**
 * 获取验证错误的自定义属性。
 *
 * @return array
 */
 public function attributes(){  
   return [      
     'email' => 'email address',    
     ];
   }

make メソッドに渡される最初のパラメーターは次のとおりです。検証が必要なデータ。 2 番目のパラメーターは、データの検証ルールです。

検証が失敗した場合は、

withErrors メソッドを使用してエラー メッセージをセッションにフラッシュできます。このメソッドをリダイレクトに使用すると、$errors 変数がビューと自動的に共有され、これらのメッセージをユーザーに表示できるようになります。 withErrors メソッドは、バリデータ、MessageBag または PHP Array を受け取ります。

自動リダイレクト

バリデーター インスタンスを手動で作成し、

validates# を使用する場合## メソッドは自動リダイレクトを提供します。その後、既存のバリデーターの例で validate メソッドを呼び出すことができます。検証が失敗した場合、ユーザーは自動的にリダイレクトされます。 AJAX リクエストでは、JSON 形式のレスポンスが返されます。

<?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();       
           }       
       // Store the blog post...  
        }
      }

名前付きエラー パッケージ

ページ上に複数のフォームがある場合は、次のようにしてエラー パッケージに名前を付けることができます。特定のフォームのエラー メッセージを取得します。

withErrors

メソッド

Validator::make($request->all(), [   
 'title' => 'required|unique:posts|max:255',    
 'body' => 'required',
])->validate();
の 2 番目の引数として名前を渡すだけで、指定したフォームのエラー メッセージを

$errors

変数から取得できます。 # #

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

検証後フック
バリデーターでは、検証が成功した後に許可されるコールバック関数を追加することもできます。検証の次のステップでは、さらに多くのエラー メッセージをメッセージ コレクションに追加することもできます。これを使用するには、検証インスタンスで

after

メソッドを使用するだけです:

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

エラー メッセージの処理

Validator インスタンスで errors メソッドを呼び出した後、Illuminate\Support\MessageBag インスタンスを取得します。 , エラーメッセージを処理するためのさまざまな便利な方法が用意されています。 $errors 変数はすべてのビューに自動的に提供され、MessageBag クラスのインスタンスでもあります。

特定のフィールドの最初のエラー メッセージを表示する

特定のフィールドの最初のエラー メッセージを表示するには、first メソッドを使用します。 :

$validator = Validator::make(...);$validator->after(function ($validator) {   
 if ($this->somethingElseIsInvalid()) {     
    $validator->errors()->add('field', 'Something is wrong with this field!');   
     }
   });
 if ($validator->fails()) {  
   //
 }

特定のフィールドのすべてのエラー メッセージを表示

指定したフィールドのすべてのエラー メッセージの配列を取得する必要がある場合は、get メソッド:

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

フォームの配列フィールドを検証する場合は、# を使用して各配列要素のすべてのエラー メッセージを取得できます:

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

すべてのフィールドのすべてのエラー メッセージを表示

すべてのフィールドのすべてのエラー メッセージを取得したい場合は、all メソッドを使用できます。

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

フィールドにエラー メッセージが含まれているかどうかを特定する

has メソッドを使用して、指定されたフィールドにエラー メッセージが含まれているかどうかを判断できます:

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

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

必要に応じて、検証にデフォルト値の代わりにカスタム エラー メッセージを使用することもできます。カスタム メッセージを指定するには、いくつかの方法があります。まず、カスタム メッセージを 3 番目のパラメーターとして

Validator::make メソッドに渡すことができます。

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

この例では、

:attribute プレースホルダーが置き換えられます。検証フィールドの実際の名前によって。さらに、検証メッセージで他のプレースホルダーを使用することもできます。例:

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

特定のプロパティのカスタム メッセージを指定します

特定のフィールドのみのエラー メッセージをカスタマイズしたい場合があります。属性名の後に「ドット」構文を使用して検証ルールを指定するだけです:

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

言語ファイルで独自のルールを指定します。メッセージ

ほとんどの場合、カスタム メッセージを

Validator に直接渡すのではなく、言語ファイルで指定することになるでしょう。これを行うには、resources/lang/xx/validation.php 言語ファイルの custom 配列にメッセージを配置します。

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

言語ファイルでカスタム属性を指定する

検証メッセージの

:attribute プレースホルダーをカスタム属性名に置き換える場合resources/lang/xx/validation.php 言語ファイルの attributes 配列でカスタム名を指定できます:

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

言語ファイルでのカスタム値の指定

場合によっては、検証メッセージの :value プレースホルダーを値のカスタム リテラルに置き換える必要がある場合があります。たとえば、payment_type の値が cc の場合、クレジット カード番号が必須であることを指定する次の検証ルールを使用します。

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

この検証ルールの場合失敗すると、次の結果が表示されます。 エラー メッセージ:

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

を表示する代わりに、values 配列を定義することで、validation 言語ファイルでカスタム値表現を指定できます。 cc 支払いタイプの値として:

    当payment type为cc时,credit card number 不能为空。

検証ルールが失敗すると、次のメッセージが生成されます:

'values' => [ 
   'payment_type' => [    
       'cc' => '信用卡' 
        ],
    ],

##

使用可能な認証とその機能の一覧は次のとおりです:

承認済み

#アクティブな URL
(日付)以降
(日付)以降
アルファ
アルファダッシュ
英数字
配列
保釈金
前 (日付)
前または等しい (日付)

ブール値
確認済み
日付
日付が等しい
日付形式
異なる

間の桁
ディメンション (画像ファイル)
別個の
電子メール
存在 (データベース)
ファイル
塗りつぶし
より大きい
以上
# #画像 (ファイル)
In
In Array
Integer
IP アドレス
JSON
以下
以下
最大
MIME タイプ
ファイル拡張子別の MIME タイプ
Min
Not In
Not Regex
Nullable
数値
現在
正規表現
必須
必須の場合は
必須以外は#必須の場合
すべての場合は必須
必須なし
すべてなしで必須
同じ
サイズ
で始まる
文字列
タイムゾーン
一意 (データベース)
URL
UUID

accepted

検証フィールドは、yeson1、または true である必要があります。利用規約に同意するかどうかを確認する場合に便利です。

active_url

PHP 関数 dns_get_record によると、検証フィールドには有効な A または AAAA レコード。

#after:

date

検証フィールドは、指定された日付以降の値である必要があります。日付値は、PHP 関数

strtotime:

    当payment type 为信用卡时,credit card number不能为空。

に渡されます。

strtotime によって処理される日付を渡す代わりに、別のフィールドを指定して、日付文字列:

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

after_or_equal:

date

検証フィールドは指定されたこの日付以降の値、またはこの日付と同じ値。詳細については、

after ルールを参照してください。

#alpha

検証フィールドは完全に文字で構成されている必要があります。

alpha_dash

検証フィールドには、文字、数字、ダッシュ (-) およびアンダースコア (_) を含めることができます。 )。

alpha_num

検証フィールドは完全に文字と数字である必要があります。

#array
検証されるフィールドは PHP 配列である必要があります。

#bail

最初の検証が失敗した後、検証ルールの実行を停止します。

before:

date

検証フィールドは、指定された日付より前である必要があります。この日付値は、計算のために PHP の strtotime 関数に渡されます。

before_or_equal:date

検証フィールドは、指定された日付よりも前である必要があります。同じ日付。この日付値は、計算のために PHP の

strtotime 関数に渡されます。

間:min

,
max

検証フィールドサイズは、指定された minmax

の間である必要があります。文字列、数値、配列、ファイルは、

size メソッドを使用して計算されます。

boolean

検証されるフィールドはブール型に変換可能である必要があります。受け入れ可能な入力は、truefalse10"1"、および " です。 0"

confirmed

検証フィールドには、一致するフィールド

foo_confirmation が必要です。たとえば、検証フィールドが password の場合、一致する password_confirmation フィールドが入力に存在する必要があります。

date

PHP 関数

strtotime によると、検証フィールドは有効な日付。

#date_equals:
date

検証フィールドは指定された日付と一致する必要があります。日付は PHP 関数

strtotime

に渡されます。

#date_format:
format

検証フィールドは、指定された日付形式と一致する必要があります。フィールドを検証するときは、

date

または date_format のみを使用し、両方を使用することはできません。

違う:フィールド

検証フィールドは

と同じ値である必要がありますfield 異なる値。

digits:value

検証フィールドは
numeric

である必要があります、_value_ と正確な長さでなければなりません。

digits_between:min,

max

検証済みフィールド長さは、指定された minmax の間である必要があります。

dimensions検証対象のファイルは画像であり、指定されたルール制約に準拠している必要があります:

'finish_date' => 'required|date|after:start_date'
利用可能な制約は次のとおりです:
min_width

max_width

min_height

max_heightwidth高さ比率ratio 制限は、幅を高さで割ったものとして表す必要があります。これは、3/2 のような式、または

1.5

のような浮動小数点数を使用して指定できます。

'avatar' => 'dimensions:min_width=100,min_height=200'
このルールには複数の引数が必要なので、 Rule::dimensions ルールをスムーズに構築するメソッド:
'avatar' => 'dimensions:ratio=3/2'

distinctWhen When配列を検証する場合、検証フィールドに重複した値が含まれていてはなりません。

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

email 検証フィールドは、適切な形式の電子メール アドレスである必要があります。

exists:table,column

検証フィールドは指定されたデータベース テーブルに存在する必要があります。

Exists 基本ルールの使用法

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

column オプションが指定されていない場合は、フィールド名が使用されます。

カスタム テーブル フィールドを指定する

'state' => 'exists:states'

「exists」クエリに使用する特定のデータベース接続を指定する必要がある場合があります。これを行うには、「ドット」構文を使用してテーブル名に接続名を追加します。

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

検証ルールによって実行されるクエリをカスタマイズする場合は、Rule を使用できます。クラス ルールをスムーズに定義します。次の例では、検証ルールを | 文字で区切るのではなく、配列として指定します。

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

file

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

#filled

検証フィールドが存在する場合、空であってはなりません。

gt:
field

検証フィールドは指定された

より大きくなければなりません分野 ###。両方のフィールドは同じタイプである必要があります。文字列、数値、配列、ファイルはすべて、

size を使用して同様に評価されます。

gte:

field

検証フィールドは指定された # 以上でなければなりません# #分野###。両方のフィールドは同じタイプである必要があります。文字列、数値、配列、ファイルはすべて、size を使用して同様に評価されます。

#image

検証するファイルは画像 (jpeg、png、bmp、gif、またはsvg)

in:

foo,bar

,...
検証フィールドは、指定された値のリストに含まれている必要があります。このルールでは通常、配列を

implode する必要があるため、Rule :: in メソッドを使用してルールをスムーズに構築できます。

#in_array:anotherfield

検証対象のフィールドは、別のフィールド

anotherfield の値内に存在する必要があります。

#integer

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

#ip

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

ipv4

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

ipv6

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

json

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

lt:field

検証対象のフィールドは、指定されたフィールドより小さくなければなりません。両方のフィールドは同じタイプである必要があります。文字列、数値、配列、およびファイルのサイズは、size メソッドで計算および評価されます。

lte:

field

検証対象のフィールドは、以下である必要があります。指定された

フィールド 。両方のフィールドは同じタイプである必要があります。文字列、数値、配列、およびファイルのサイズは、size メソッドで計算および評価されます。

#max:
value

検証対象のフィールドは # 以下でなければなりません## 価値###。文字列、数値、配列、またはファイル サイズの計算は、

size

メソッドを使用して評価されます。

mimetypes:text/plain,...

検証するファイルは次のとおりです。指定された MIME タイプのいずれかと一致します:
use Illuminate\Validation\Rule;
Validator::make($data, [  
  'email' => [      
    'required',        
    Rule::exists('staff')->where(function ($query) {  
           $query->where('account_id', 1);    
        }),
     ],
  ]);

アップロードされたファイルの MIME タイプを決定するには、ファイルの内容が読み取られて MIME タイプが決定されますが、指定された MIME タイプとは異なる場合があります。クライアントによって。

##マイム:

foo

,bar,...

検証されるファイルは、リストされた拡張子のいずれかに対応する MIME タイプを持っている必要があります。

MIME ルールの基本的な使用法
use Illuminate\Validation\Rule;
Validator::make($data, [  
  'zones' => [      
    'required',        
    Rule::in(['first-zone', 'second-zone']),  
   ],
]);
指定された拡張子を確認するだけでよい場合でも、このルールは実際にはファイルを読み取ることでファイルの MIME タイプを確認します。コンテンツの MIME タイプを推測します。

MIME タイプとそれに対応する拡張子の完全なリストは、次のリンクで見つけることができます:

https://svn.apache.org/repos/asf/httpd/htt...


min:

value

検証対象のフィールドには最小値が必要です。文字列、数値、配列、またはファイル サイズの計算は、

size

メソッドを使用して評価されます。

not_in:foo

,

bar,... #検証中のフィールドを、指定された値のリストに含めることはできません。

Rule::notIn
メソッドを使用してルールを構築できます:
'video' => 'mimetypes:video/avi,video/mpeg,video/quicktime'

not_regex:pattern

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

内部的には、このルールは PHP preg_match 関数を使用します。入力する値は、preg_match 関数で必要とされるのと同じ形式に従う必要があるため、有効な区切り文字も含めてください。例: 'email' => 'not_regex:/^. $/i'.

注: regex/not_regex パターンを使用する場合、パイプ区切り文字を使用するのではなく、配列でルールを指定する必要がある場合があります。特に、正規表現にパイプ文字が含まれている場合です。

nullable

検証済みフィールドは null である可能性があります。これは、NULL 値を含む可能性のある文字列や整数などの基本データ型を検証する場合に特に役立ちます。

数値

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

#present

検証されるフィールドは入力データに存在する必要がありますが、空であってもかまいません。

regex:
pattern

検証されるフィールドは、指定された正規表現と一致する必要がありますマッチ。

内部的には、このルールは PHP

preg_match

関数を使用します。入力する値は、preg_match 関数で必要とされるのと同じ形式に従う必要があるため、有効な区切り文字も含めてください。例: 'email' => 'regex:/^. @. $/i'.

注:

regex ルールを使用する場合、特に正規表現に | が含まれる場合は、| 区切り文字を使用する代わりに配列を使用する必要があります。 文字。

必須

検証されるフィールドは入力データ内に存在する必要があり、空であってはなりません。次の条件のいずれかが満たされる場合、フィールドは「null」とみなされます:

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

required_if:
anotherfield
,

value,.. anotherfield

フィールドが任意の

value と等しい場合、検証されるフィールドは空ではなく存在する必要があります。 required_if

ルールに対してより複雑な条件を作成する場合は、

Rule::requiredIf メソッドを使用できます。このメソッドはブール値またはクロージャを受け入れます。クロージャを渡すときは、フィールドを検証する必要があるかどうかを確認するために true または false を返す必要があります:

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

##

required_unless:anotherfield,value,...

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

required_with:
foo

,bar,...検証済みフィールドは、他の指定されたフィールドが表示される場合にのみ表示される必要があり、空であってはなりません。

required_with_all:

foo
,
bar

,...他の指定されたフィールドがすべて表示される場合にのみ、検証済みフィールドが表示され、空であってはなりません。

required_without:foo

,
bar
,...

他の指定されたフィールドが表示されない場合にのみ、検証済みフィールドが表示され、空であってはなりません。

required_without_all:

foo,bar

,...
他のすべての指定フィールドが表示されない場合にのみ、検証済みフィールドが表示され、空であってはなりません。

#same:

field

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

#size:

value

検証されるフィールドには、指定された値のサイズ。文字列の場合、値は文字数に対応します。数値の場合、value は指定された整数値に対応します。配列の場合、サイズは配列の count

値に対応します。ファイルの場合、size はファイル サイズ (kb) に対応します。

starts_with:foo,

bar

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

#string

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

null

を許可する場合は、このフィールドに

nullable ルールを割り当てる必要があります。

timezone検証するフィールドは、PHP 関数に基づいた有効なタイムゾーンである必要があります timezone_identifiers_list

のロゴ。

unique:table,column,excel,idColumn

検証対象のフィールドは指定されたデータベースはテーブル内で一意である必要があります。 column が指定されていない場合は、フィールド自体の名前が使用されます。

カスタム フィールドの指定

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

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

バリデータ クエリ用のデータベースの作成が必要になる場合があります。カスタム接続の設定。上記の例では、検証ルールとして unique:users を設定することは、デフォルトのデータベース接続を使用してデータベースにクエリを実行することと同じです。変更する場合は、「ドット」メソッドを使用して接続とテーブル名を指定してください:

use Illuminate\Validation\Rule;
Validator::make($request->all(), [  
  'role_id' => Rule::requiredIf($request->user()->is_admin),]);
  Validator::make($request->all(), [   
   'role_id' => Rule::requiredIf(function () use ($request) {     
      return $request->user()->is_admin;   
      }),
    ]);

指定された ID を無視するように一意のルールを強制します:

# フィールドの一意性を検証するときに、指定された ID を無視したい場合があります。たとえば、[プロフィールの更新] ページには、ユーザー名、電子メール アドレス、場所が含まれます。この時点で、更新された電子メールの値が一意であることを確認する必要があります。ユーザーがユーザー名フィールドのみを変更し、電子メールフィールドを変更しない場合、ユーザーはすでに電子メールの所有者であるため、検証エラーをスローする必要はありません。

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

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

{tip} ユーザー制御のリクエスト入力を

ignore## メソッドに渡さないでください。 。代わりに、Eloquent モデル インスタンスからは、自動インクリメント ID や UUID などのシステム生成の一意の ID のみを渡す必要があります。そうしないと、アプリケーションが SQL インジェクション攻撃に対して脆弱になります。

モデル キーの値を
ignore

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

'email' => 'unique:connection.users,email_address'
データテーブルで使用される主キー名が

id

ではない場合は、ignore# を呼び出すときにフィールドを指定します。 ## メソッド名:

use Illuminate\Validation\Rule;
Validator::make($data, [ 
   'email' => [      
     'required',        
     Rule::unique('users')->ignore($user->id),  
     ],
 ]);
デフォルトでは、unique

ルールは、検証されるプロパティの名前に一致する列が一意であるかどうかをチェックします。ただし、別の列名を

unique メソッドの 2 番目の引数として渡すことができます:

Rule::unique('users')->ignore($user)
追加の Where ステートメントを追加します:

you 追加クエリ条件は、where

メソッドを使用して指定することもできます。たとえば、

account_id1 の制約に追加します:

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

##url

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

uuid

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

#条件に基づいてルールを追加する

存在する場合は検証

場合によっては、フィールドが配列内に存在する場合にのみ、フィールドに対して検証チェックを実行できます。これは、ルール リストに something を追加することで実現できます:

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

上記の例では、

email フィールドは $data## にのみ存在します。 # 配列が検証されます。

{ヒント} 常に存在する必要があるフィールドが空である可能性があることを検証しようとしている場合は、
オプション フィールドに関する注意事項

## を確認してください。

#複雑な条件付き検証
より複雑な条件付きロジックに基づいた検証ルールを追加する必要がある場合があります。たとえば、別のフィールドの値が 100 を超える場合にのみ、指定したフィールドを必須にすることができます。または、指定されたフィールドが存在する場合、他の 2 つのフィールドは指定された値を持つことができます。このような検証条件を追加することは難しくありません。まず、静的ルールを使用して

Validator

インスタンスを作成します。

'email' => Rule::unique('users')->where(function ($query) {  
  return $query->where('account_id', 1);
})
ゲーム コレクター向けに設計された Web アプリケーションがあるとします。ゲーム コレクターが 100 を超えるゲームを所有している場合は、なぜこれほど多くのゲームを所有しているのか説明してもらいます。たとえば、ゲーム配信ストアを運営しているかもしれませんし、単に収集を楽しんでいるかもしれません。特定の条件下でこの検証要件を含めるには、Validator

インスタンスで

something メソッドを使用できます。

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

メソッドの最初のパラメータに渡すのは、検証に使用するフィールドの名前です。 2 番目のパラメータは、使用する検証ルールです。

Closure が 3 番目のパラメータとして渡されます。true が返された場合、追加のルールが追加されます。この方法を使用すると、複雑な条件付き検証を簡単に作成できます。条件付き検証を複数のフィールドに一度に追加することもできます。

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

クロージャ
に渡される

$input パラメータは Illuminate です。入力オブジェクトまたはファイル オブジェクトにアクセスするために使用できる \Support\Fluent のインスタンス。

#配列の検証

フォームの入力が配列であることを検証するのは難しくありません。分野。 「ドット」メソッドを使用して、配列内のプロパティを検証できます。たとえば、受信 HTTP リクエストに
photos[profile]

フィールドが含まれている場合、次のように検証できます。

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

配列内の各要素を検証することもできます。たとえば、指定された配列入力フィールド内の各電子メールが一意であることを確認するには、次のように実行できます:

$v->sometimes(['reason', 'cost'], 'required', function ($input) {   
   return $input->games >= 100;
 });
同様に、言語で検証情報を定義するときに

# 文字を使用できます。ファイル、配列ベースのフィールドに単一の検証メッセージを使用します:

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

カスタム検証ルール

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

Laravel は多くの便利な検証ルールを提供しており、カスタム ルールもサポートしています。カスタム検証ルールを登録する 1 つの方法は、ルール オブジェクトを使用することです。アーティザン コマンド make:rule を使用して、新しいルール オブジェクトを生成できます。次に、このコマンドを使用して、文字列が大文字であることを検証するルールを生成しましょう。 Laravel は新しいルールを app/Rules ディレクトリに保存します:

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

ルールが作成されたら、その動作を定義できます。ルール オブジェクトには、passesmessage という 2 つのメソッドが含まれています。 passes メソッドは属性値と名前を受け取り、属性値がルールに準拠しているかどうかに応じて true または false を返します。 message メソッドは、検証が失敗した場合に使用する検証エラー メッセージを返す必要があります:

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

もちろん、翻訳ファイルからエラー メッセージを返したい場合は、そうすることができます。 from message メソッド trans でヘルパー関数を呼び出します:

php artisan make:rule Uppercase

ルール オブジェクトが定義されたら、ルール オブジェクトのインスタンスをバリデータに渡すことができます。他の検証ルールを使用する場合:

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

クロージャの使用

カスタム ルールの機能が 1 回だけ必要な場合アプリケーションでは、ルール オブジェクトの代わりにクロージャを使用できます。クロージャはプロパティの名前を受け取ります。コールバックで検証が失敗した場合にその値が使用されます ($fail:

/**
 * 获取验证错误消息。
 *
 * @return string
 */
 public function message(){  
   return trans('validation.uppercase');
  }

)

拡張機能の使用

カスタム検証ルールを登録する別の方法は、Validator ファサードの extend メソッドを使用することです。サービス コンテナでこのメソッドを使用してカスタム検証ルールを登録しましょう:

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

カスタム検証クロージャは 4 つのパラメータを受け取ります: 検証される属性名 $attribute、属性 値 $value、検証ルールに渡されるパラメーター配列 $parameters、および Validator 実際の列。

クロージャの使用に加えて、クラスとメソッドを extend メソッドに渡すこともできます。

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

エラー メッセージを定義する

カスタム ルールのエラー メッセージも定義する必要があります。この機能は、インライン カスタム メッセージ配列を使用するか、検証言語ファイルにエントリを追加することで実現できます。メッセージは、属性固有のエラー メッセージを格納するためにのみ使用される custom 配列ではなく、配列の最初に配置する必要があります。

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

カスタム検証ルールを作成する場合、エラー メッセージのカスタム プレースホルダーを定義する必要がある場合があります。これを行うには、カスタム バリデーターを作成し、Validator ファサードで Replacer メソッドを呼び出します。サービス コンテナの boot メソッドで次の操作を実行できます:

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

暗黙的な拡張

デフォルトでは、検証対象の属性が存在しないか、required ルールで定義された null 値が含まれている場合、通常の検証ルールが適用されます。 、カスタム拡張機能を含むは実行されません。たとえば、unique ルールは null 値を検証しません:

"foo" => "Your input was invalid!",
"accepted" => "The :attribute must be accepted.",
// 其余的验证错误消息...

これは、プロパティを検証する必要がある場合に必要です。 null の場合、hint 属性は必須です。このような「暗黙的」拡張を作成するには、Validator::extendImplicit() メソッドを使用できます。

/**
 * 启动应用程序。
 *
 * @return void
 */
 public function boot(){  
   Validator::extend(...);    
   Validator::replacer('foo', function ($message, $attribute, $rule, $parameters) {    
       return str_replace(...);  
      });
 }

{note} 「暗黙的」拡張は、プロパティがに必要な。欠落しているか null であるかはあなた次第です。

この記事は、LearnKu.com Web サイトで初めて公開されました。