CakePHP 2.x CookBook 中国語版モデルデータ検証_PHPチュートリアル

データ検証

データ検証は、モデル内のデータがアプリケーションのビジネス ルールに準拠していることを確認するため、あらゆるアプリケーションの重要な部分です。 たとえば、パスワードの長さが 8 文字以上であることや、ユーザー名が一意であることを確認することができます。 検証ルールを定義すると、フォームの処理が非常に簡単になります。

検証プロセスにはさまざまな側面があります。このセクションではモデル側について説明します。 つまり、モデル内の save() メソッドが呼び出されたときに何が起こるかということです。 検証エラーの表示を処理する方法の詳細については、「フォーム アシスタント」を参照してください。

データ検証の最初のステップは、モデル内に検証ルールを確立することです。これは、モデル定義で Model::validate 配列を使用して実現されます:

1 クラス ユーザーが AppModel を拡張する {

2 public $validate = array();

3}

上記の例では、$validate 配列が User モデルに追加されていますが、配列には検証ルールが含まれていません。 users テーブルに、login、password、email、および Born 列があると仮定します。次の例は、これらの列に適用されるいくつかの簡単な検証ルールを示しています。

1 クラス ユーザーが AppModel を拡張する {

2 public $validate = array(

3 'ログイン' => '英数字',

4 「メール」 => 「メール」、

5「生まれ」=>「日付」

6);

7 }

上記の例は、モデル列に検証ルールを追加する方法を示しています。ログイン列では、文字と数字のみを使用できます。電子メールは有効な電子メール アドレス、生年月日は有効な日付である必要があります。 これらの検証ルール定義により、送信されたデータが定義されたルールに違反する場合に CakePHP がフォームにエラー メッセージを自動的に表示できるようになります。

CakePHP には多くの検証ルールがあり、使いやすいです。 一部の組み込みルールでは、電子メール、URL、クレジット カード番号の形式をチェックできます。これらの詳細については後ほど説明します。

いくつかの組み込みの検証ルールを使用した非常に複雑な検証の例を次に示します:

1 クラス ユーザーが AppModel を拡張する {

2 public $validate = array(

3 'ログイン' => array(

4 'alphaNumeric' => array(

5

6 '必須' => true、

7 'メッセージ' => 'アルファベットと数字のみ'

8 )、

9 '間' => array(

10

11 'メッセージ' => '5～15文字以内'

12)

13)、

14 'パスワード' => array(

15 'ルール' => 配列('minLength', '8'),

16 'メッセージ' => '長さは最低 8 文字'

17)、

18 「メール」 => 「メール」、

19 '誕生' => array(

20

21 'メッセージ' => '有効な日付を入力してください',

22 'allowEmpty' => true

23)

24);

25 }

そのうち 2 つはログイン用に定義されています。文字と数字のみを含めることができ、長さは 5 ～ 15 である必要があります。パスワード列の長さは 8 文字以上である必要があります。 email は有効な電子メール アドレスである必要があり、born は有効な日付である必要があります。 検証が失敗したときに表示される特定のエラー メッセージを定義する方法にも注意してください。

上記の例では、単一の列で複数の検証ルールを使用できます。組み込みルールが要件を満たせない場合は、必要な検証ルールを追加できます。

データ検証の全体像が見えてきたので、モデル内でこれらのルールを定義する方法を見てみましょう。単純な配列、列ごとに単一のルール、列ごとに複数のルールの 3 つの異なるアプローチがあります。

簡単なルール

名前が示すように、これは検証ルールを定義する最も簡単な方法です。 このメソッドのルールを定義するための標準構文は次のとおりです:

1 public $validate = array('fieldName' => 'ruleName');

「fieldName」はルールが適用される列の名前で、「ruleName」は「alphaNumeric」、「email」、「isUnique」などの事前定義されたルール名です。

たとえば、ユーザーが適切な形式の電子メール アドレスを提供していることを確認するには、次のルールを使用できます:

1 public $validate = array('user_email' => 'email');

列ごとに 1 つのルール

この定義方法では、検証ルールの動作をより適切に制御できます。これについて説明する前に、単一の列にルールを追加する標準的な使用法を見てみましょう:

1 public $validate = array(

2 'フィールド名1' => array(

3

4 '必須' => true、

5 'allowEmpty' => false,

6 'on' => 'create'、// または: 'update'

7 'メッセージ' => 'エラーメッセージ'

8)

9);

「ルール」キーは必須です。 'required' => true のみが設定されている場合、フォーム検証は正しく機能しません。 「必須」というのは実際のルールではないからです。

ご覧のとおり、各列 (上では 1 つの列のみを示しています) は、「ru​​le」、「required」、「allowEmpty」、「on」、「message」の 5 つのキーを含む配列に関連付けられています。これらのキーを詳しく見てみましょう。

ルール

「rule」メソッドは検証の側面を定義し、値または配列を指定します。この特定の「ルール」は、モデル内のメソッドの名前、コア Validation クラスのメソッドの名前、または正規表現の場合があります。デフォルトのルールの詳細については、「カーネル検証ルール」を参照してください。

ルールにパラメーターが含まれていない場合、「ルール」は単一の値になります。例:

1 public $validate = array(

2 'ログイン' => array(

3 'ルール' => '英数字'

4)

5);

ルールにパラメーター (最大、最小、範囲など) が含まれる場合、「ルール」は配列になります:

1 public $validate = array(

2 'パスワード' => array(

3 'ルール' => 配列('minLength', 8)

4)

5);

配列モードでルールを定義する場合は、「ru​​le」キーが必要であることに注意してください。

必須

このキーは論理値、作成または更新を受け入れます。これを true に設定すると、この列が常に必須になります。作成または更新に設定すると、この列は更新または作成操作にのみ必要になります。 「required」が true の場合、この列を配列に指定する必要があります。たとえば、次の検証ルールが定義されているとします。

1 public $validate = array(

2 'ログイン' => array(

3 'ルール' => '英数字',

4 '必須' => true

5)

6);

モデルの save() メソッドに渡されるデータには、ログイン列に提供されたデータが含まれている必要があります。存在しない場合、検証は失敗します。このキーのデフォルト値は論理 false です。

required => true は、検証ルールの notEmpty() と同じではありません。 required => true は、この配列キーを指定する必要があることを意味しますが、値が必要であることを意味するわけではありません。データセットが提供されていない場合、検証は失敗しますが、null 値 ('') が送信された場合は成功する可能性があります (これはルールの詳細な定義によって異なります)。

バージョン 2.1 での変更点: 作成と更新のサポートが追加されました。

空を許可する

false に設定した場合、フィールド値は空でない必要があります。「空でない」は !empty($value) || is_numeric($value) として定義されます。 数値検出の場合、CakePHP は $value が 0 の場合に正しいとみなします。

required とallowEmpty の違いにより混乱が生じる可能性があります。 'required' => true は、$this->data でこの列にキーを指定しないとモデルを保存できないことを意味し、'allowEmpty' => false は、上記の検索と同様に、この列の値が確実であることを意味します。 null ではない。

に

「オン」キーは「更新」または「作成」に設定できます。これは、新しいレコードの作成またはレコードの更新プロセス中にいくつかのルールを適用できるメカニズムを提供します。

ルールが「on」 => 「create」として定義されている場合、このルールは新しいレコードの作成プロセス中にのみ有効です。同様に、「on」 => 「update」として定義されている場合、レコードの更新プロセス中にのみ有効になります。

「on」のデフォルト値はnullです。 「on」が null の場合、このルールは作成プロセスと更新プロセスの両方で有効になります。

メッセージ

メッセージ キーは、ルールが検証エラーをカスタマイズするときに表示されるメッセージです:

1 public $validate = array(

2 'パスワード' => array(

3 'ルール' => 配列('minLength', 8),

4 'メッセージ' => 'パスワードは8文字以上である必要があります'

5)

6);

列ごとに複数のルール

上記のテクノロジーにより、単純なルール割り当てよりも優れた柔軟性が得られ、さらに一歩進んで、より詳細なデータ検証制御を実現できます。以下では、各列に複数のルールを割り当てることができる手法を紹介します。

1つの列に複数の入力規則を割り当てたい場合の基本的な書き方は以下の通りです。

1 パブリック $validate = array(

2 'フィールド名' => array(

3 'ルール名' => array(

4 'ルール' => 'ルール名',

5

6 )、

7 'ruleName2' => array(

8 'ルール' => 'ルール名2',

On 9 // ON と同様に、必須キーとその他の拡張キーがここに配置されます ...

10)

11)

12);

ご覧のとおり、これは前のセクションで行ったことと非常に似ています。ここでは、列ごとに検証パラメーター配列が 1 つだけ存在します。ここで、各「fieldName」は通常の配列のインデックスです。各「ruleName」には検証パラメータの配列が含まれます。

実際の例を使ってより分かりやすく説明します:

1 パブリック $validate = array(

2 'ログイン' => array(

3 'loginRule-1' => 4 'ルール' = & GT;

5 'メッセージ' => 'アルファベットと数字のみ使用可能',

6 )、

7 'loginRule-2' => array(

8 'ルール' = & gt; 配列 ('minlength', 8),

;

9 'メッセージ' => '最小長は 8 文字'

10)

11)

12);

上記の例では、ログイン列に 2 つのルール、loginRule-1 と loginRule-2 を定義しています。ご覧のとおり、各ルールの識別子には任意の名前が付けられています。

単一の列に複数のルールを定義する場合、「required」キーと「allowEmpty」キーは最初のルールで 1 回だけ使用する必要があります。

最後

各列に複数のルールがある場合、デフォルトでは、ルールの検証に失敗してエラー メッセージが返された場合、この列の後続のルールは計算されなくなります。ルールが失敗した場合でも検証を継続する場合は、ルールの最後のキーを false に設定します。

以下の例では、「ru​​le1」が失敗した場合でも、「rule2」は引き続き評価され、「rule2」も失敗した場合はすべてのエラー メッセージが返されます。

1 パブリック $validate = array(

2 'ログイン' => array(

3 'rule1' => array(

4 'ルール' = & GT;

5 'メッセージ' => 'アルファベットと数字のみ使用可能',

6

7 )、

8 'rule2' => array(

9 'ルール' = & gt; 配列 ('minlength', 8),

;

10 'メッセージ' => '最小長は 8 文字'

11)

12)

13 );

配列で検証ルールを指定する場合、メッセージキーを使用する必要はありません。次の例を考えてみましょう:

1 public $validate = array(

2 'ログイン' => array(

3 'アルファベットと数字のみを使用できます' => array(

4

5)、

6)

7);

alphaNumeric ルールが失敗した場合、メッセージ キーが設定されていないため、ルールのキー「アルファベットと数字のみを許可する」がエラー メッセージとして返されます。

カスタマイズされた検証ルール

必要な検証ルールが見つからない場合は、カスタマイズできます。カスタマイズするには、正規表現をカスタマイズする方法と、カスタム検証メソッドを作成する方法の 2 つがあります。

カスタマイズされた検証正規表現

必要な検証方法が正規表現の一致によって完了できる場合は、その式を列の検証ルールとしてカスタマイズできます:

1 public $validate = array(

2 'ログイン' => array(

3 'ルール' => '/^[a-z0-9]{3,}$/i',

4 'メッセージ' => '文字と整数のみ、最小 3 文字'

5)

6);

上記の例は、ログインに文字と整数のみが含まれているかどうか、また 3 文字以上である必要があるかどうかを確認します。

「rule」内の正規表現はスラッシュ(/)で囲む必要があります。末尾のオプションの「i」は、正規表現が大文字と小文字を区別しないことを示します。

独自の認証方法を追加します

通常のパターンを使用してデータを検証するだけでは不十分な場合があります。 たとえば、プロモーション コードを 25 回のみ使用できるようにしたい場合は、独自の検証方法を追加する必要があります。例は次のとおりです。

1 クラス ユーザーが AppModel を拡張する {

2

3 public $validate = array(

4 'プロモーションコード' => array(

5

6 'message' => 'このコードは何度も使用されています。'

7)

8 );

9

10 パブリック関数 limitDuplicates($check, $limit) {

11 // $check の値: array('promotion_code' => 'some-value')

12 // $limit 値: 25

13 $existing_promo_count = $this->find('count', array(

)

14 '条件' => $check,

15 '再帰的' => -1

16 ));

17 戻り $existing_promo_count <

18 }

19 }

検証中の現在の列は、関数の最初のパラメーターとして、キーとしての列名と値としての post からのデータで構成される連想配列として関数に渡されます。

追加のパラメータを check 関数に渡したい場合は、要素を「rule」配列に追加し、関数内で拡張パラメータとして処理します (メインパラメータ $check の後)。

検証関数は、(上記の例のように) モデルに配置することも、モデルによって実装される動作に配置することもできます。マッピング方法が含まれます。

モデル/動作メソッドが最初に検証され、Validation クラスのメソッドよりも優先されます。これは、既存の検証メソッド (alphaNumeric() など) をアプリケーション レベル (AppModel にメソッドを追加すること) またはモデル レベルでオーバーライドできることを意味します。

$check 配列から列の値を抽出する、複数の列に適用できる検証ルールを作成する場合は注意してください。 $check 配列は、キーとしてのフォーム ドメイン名と値としてのフォーム フィールド値で構成されます。 $this->data メンバー変数に格納されているレコード全体が検証されます。

1 クラス Post は AppModel を拡張します {

2

3 public $validate = array(

4 'ナメクジ' => array(

5 'ルール' = & GT;

6 'メッセージ' => 'スラッグには文字、数字、ダッシュ、アンダースコアのみを使用できます'

7)

8 );

9

10 パブリック関数 alphaNumericDashUnderscore($check) {

11 // $data 配列は、フォームのドメイン名をキーとして渡されます

12 // 関数をユニバーサルにするために、この値を抽出する必要があります

13 $value = array_values($check);

14 $value = $value[0];

15

16 return preg_match('|^[0-9a-zA-Z_-]*$|', $value);

17 }

18 }

メモ

カスタム検証メソッドの公開設定は公開する必要があります。保護されたプライベート レベルの検証方法はサポートされていません。

ルールが有効な場合、このメソッドは true を返します。検証に失敗した場合は false が返されます。もう 1 つの有効な戻り値は、表示されるエラー メッセージである文字列です。文字列が返された場合は、検証が失敗したことを意味します。 この文字列は、$validate 配列に設定された情報を上書きし、列が無効である理由としてビューのフォームに表示されます。

検証ルールを動的に変更する

$validate 属性を使用して検証ルールを定義することは、各モデルの静的ルールを定義する良い方法です。ただし、場合によっては、事前定義されたルール セットから検証ルールを動的に追加、変更、または削除する必要があります。

すべての検証ルールは ModelValidator オブジェクトに保存され、モデル内の各列に設定された各ルールが保持されます。 必要な列の新しい検証メソッドを保存するようにこのオブジェクトに通知することで、新しい検証ルールを簡単に定義できます。

新しい検証ルールを追加します

2.2の新しいバージョンの機能

ModelValidator オブジェクトは、セットに新しい列を追加するいくつかの方法を提供します。 1 つ目は、add メソッドを使用することです:

1 // モデルクラス内

2 $this->validator()->add('パスワード', '必須', array(

)

3 'ルール' => 'notEmpty',

4 '必須' => '作成'

5 ));

これにより、モデルのパスワード列に 1 つのルールが追加されます。チェーン内で add を複数回呼び出して、複数の必要なルールを作成できます:

1 // モデルクラス内

2 $this->validator()

3 ->add('パスワード', '必須', array(

4 'ルール' => 'notEmpty',

5 「必須」 => 「作成」

6 ))

7 ->add('パスワード', 'サイズ', array(

8 'ルール' => 配列('間', 8, 20),

9 'メッセージ' => 'パスワードは8文字以上である必要があります'

10));

1 つの列に複数のルールを一度に追加することもできます:

1 $this->validator()->add('パスワード', array(

)

2 '必須' => array(

3 'ルール' => 'notEmpty',

4 '必須' => '作成'

5 )、

6 'サイズ' => 配列(

7 'ルール' => 配列('間', 8, 20),

8 'メッセージ' => 'パスワードは8文字以上である必要があります'

9)

10));

または、配列インターフェイスを使用してこのオブジェクトを使用して、列のルールを直接設定することもできます:

1 $validator = $this->validator();

2 $validator['ユーザー名'] = array(

3 'ユニーク' => array(

4 'ルール' => 'isUnique',

5 「必須」 => 「作成」

6 )、

7 '英数字' => 配列(

8 'ルール' => '英数字'

9)

10);

既存の検証ルールを編集する

2.2の新しいバージョンの機能

既存の検証ルールは、バリデーター オブジェクトを使用して編集できます。 既存のルールを変更したり、列にメソッドを追加したり、列ルール セットからルールを完全に削除したりするには、いくつかの方法があります。

1 // モデルクラス内

2 $this->validator()->getField('パスワード')->setRule('必須', array(

)

3 'ルール' => '必須'、

4 '必須' => true

5 ));

同様の方法を使用して、列のすべてのルールを完全に置き換えることもできます:

1 // モデルクラス内

2 $this->validator()->getField('password')->setRules(array(

)

3 '必須' => 配列(...),

4 'otherRule' => array(...)

5 ));

ルール内の 1 つの属性を取得したいだけの場合は、CakeValidationRule オブジェクトの属性を直接設定できます:

1 // モデルクラス内

2 $this->validator()->getField('password')

3 ->getRule('required')->message = 'このフィールドを空白のままにすることはできません';

CakeValidationRule のプロパティは、$validate 属性を使用してモデル内の対応するルールを定義する有効な配列キーによって名前が付けられます。

ルールセットにルールを追加するとき、配列インターフェースを使用して既存のルールを編集することもできます:

1 $validator = $this->validator();

2 $validator['ユーザー名']['一意'] = array(

3 'ルール' => 'isUnique',

4 '必須' => '作成'

5);

6

7 $validator['username']['unique']->last = true;

8 $validator['username']['unique']->message = '名前はすでに使用されています';

ルールセットからルールを削除する

2.2の新しいバージョンの機能

列のすべてのルールを完全に削除することも、列ルール セット内の 1 つのルールのみを削除することも可能です:

1 // 列のすべてのルールを完全に削除します

2 $this->validator()->remove('username');

3

4 // パスワードから「必須」ルールを削除します

5 $this->validator()->remove('パスワード', '必須');

配列インターフェースを使用してルールセットからルールを削除することもできます:

1 $validator = $this->validator();

2 // 列のすべてのルールを完全に削除します

3 unset($validator['username']);

4

5 // passworkd から 'required' ルールを削除します

6 unset($validator['password']['required']);

カーネル検証ルール

クラスの検証

CakePHP の Validation クラスには、モデルデータの検証を容易にする多くの検証ルールが含まれています。このクラスには、一般的に使用される検証テクニックが多数含まれており、自分で記述する必要はありません。 以下は、すべてのルールの完全なリストとその使用例です。

静的検証::alphaNumeric(mixed $check)

列データには文字と数字のみを含める必要があります。

1 public $validate = array(

2 'ログイン' => array(

3 'ルール' => '英数字',

4 'メッセージ' => 'ユーザー名には文字と数字のみを含めてください。'

5)

6);

静的検証::between(文字列 $check, 整数 $min, 整数 $max)

列のデータ長は指定された値の範囲内である必要があります。最小値と最大値の両方を指定する必要があります。用途 = ではありません。:

1 public $validate = array(

2 'パスワード' => array(

3 'ルール' => 配列('間', 5, 15),

4 'メッセージ' => 'パスワードの長さは 5 ～ 15 文字である必要があります。'

5)

6);

データ長とは「文字列データのバイト数」を指します。非 ASCII 文字を扱う場合、値が文字数を超える可能性があることに注意してください。

静的検証::blank(混合 $check)

このルールは、列の値が空であるか、その値に空白文字のみが含まれていることを確認するために使用されます。空白文字には、スペース、タブ、キャリッジ リターン、ライン フィードが含まれます。

1 public $validate = array(

2 'id' => array(

3 'ルール' => '空白'、

4 「オン」=>「作成」

5)

6);

静的検証::boolean(string $check)

列データは論理値である必要があります。有効な値には、true または false、整数値 0 または 1、文字列値 '0' または '1' が含まれます。

1 public $validate = array(

2 'myCheckbox' => array(

3 'ルール' => 配列('ブール'),

4 'メッセージ' => 'myCheckboxの値が正しくありません'

5)

6);

静的検証::cc(混合 $check、混合 $type = 'fast'、ブール値 $deep = false、文字列 $regex = null)

このルールは、データが有効なクレジット カード番号であるかどうかを確認します。これには、「type」、「deep」、「regex」の 3 つのパラメータがあります。

「type」キーには、「fast」または「all」のいずれかの値を割り当てることができます。

アメックス

銀行カード

ディナー

ディスク

電子

途中

jcb

マエストロ

MC

ソロ

スイッチ

ビザ

ボイジャー

「タイプ」が「高速」に設定されている場合、メインのクレジットカードのエンコード形式がチェックされます。 「type」を「all」に設定すると、すべてのクレジット カード タイプが検証されます。 「type」をチェックしたい型の配列に設定することもできます。

「ディープ」キーは論理値に設定する必要があります。 true の場合、検証ルールはクレジット カードの Luhn アルゴリズム (http://en.wikipedia.org/wiki/Luhn_algorithm) をチェックします。デフォルト値は false です。

「regex」キーを使用すると、クレジット カード番号を検証するためのカスタム正規表現を指定できます:

1 public $validate = array(

2 'ccnumber' => array(

3 'ルール' => 配列('cc', 配列('ビザ', 'マエストロ'), false, null),

4 「メッセージ」 => 「指定されたクレジット カード番号は無効です。」

5)

6);

静的検証::比較(混合 $check1, 文字列 $operator = null, 整数 $check2 = null)

比較は数値を比較するために使用されます。 「より大きい」、「等しい」、「以上」、「以下」、「等しい」、および「等しくない」をサポートします。以下は例です:

1 パブリック $validate = array(

2 '年齢' => array(

3 'ルール' => 配列('比較', '>=', 18),

4 'message' => '資格を得るには 18 歳以上である必要があります。'

5)

6 );

7

8 public $validate = array(

9 '年齢' => array(

10 'ルール' => 配列('比較', '以上', 18),

11 'メッセージ' => '資格を得るには18歳以上である必要があります。'

12)

13 );

静的検証::custom(mixed $check, string $regex = null)

カスタム正規表現の場合:

1 public $validate = array(

2 '無限' => 配列(

3 'ルール' => 配列('カスタム', 'u221E'),

4 'メッセージ' => '無限の数字を入力してください。'

5)

6);

静的検証::date(string $check、mixed $format = 'ymd'、string $regex = null)

このルールにより、送信されたデータが正しい日付形式であることが保証されます。検証する日付の形式を指定するパラメーター (配列も可能) を渡すことができます。このパラメータは次のいずれかになります:

「dmy」 例: 27-12-2006 または 27-12-06 (区切り文字はスペース、ピリオド、ダッシュ、スラッシュです)

‘mdy’ たとえば、12-27-2006 または 12-27-06 (区切り文字はスペース、ピリオド、ダッシュ、スラッシュにすることができます)

‘ymd’ 例: 2006-12-27 または 06-12-27 (区切り文字はスペース、ピリオド、ダッシュ、スラッシュです)

それぞれ「dMy」2006 年 12 月 27 日または 2006 年 12 月 27 日

「Mdy」 例: 2006 年 12 月 27 日または 2006 年 12 月 27 日 (カンマはオプション)

「私の」例 (2006 年 12 月または 2006 年 12 月)

「my」 たとえば、12/2006 または 12/06 (区切り文字はスペース、ピリオド、ダッシュ、スラッシュにすることができます)

このキーが指定されていない場合は、デフォルトで「ymd」が使用されます:

1 public $validate = array(

2 '誕生' => array(

3 'ルール' => 配列('日付', 'ymd'),

4 'メッセージ' => 'YY-MM-DD形式で有効な日付を入力してください。',

5 'allowEmpty' => true

6)

7);

大量のデータを特定の形式で保存する必要がある場合は、ユーザーに特定の形式の提供を強制するのではなく、より幅広い形式を受け入れて変換することを検討できます。あなたは顧客のために、より多くのことをより良くすることができます。

静的検証::datetime(配列 $check、混合 $dateFormat = 'ymd'、文字列 $regex = null)

このルールにより、データが有効な日時形式であることが保証されます。検証する日付の形式を指定するパラメーター (配列も可能) を渡すことができます。このパラメータは次のいずれかになります:

「dmy」 例: 27-12-2006 または 27-12-06 (区切り文字はスペース、ピリオド、ダッシュ、スラッシュです)

‘mdy’ たとえば、12-27-2006 または 12-27-06 (区切り文字はスペース、ピリオド、ダッシュ、スラッシュにすることができます)

‘ymd’ 例: 2006-12-27 または 06-12-27 (区切り文字はスペース、ピリオド、ダッシュ、スラッシュです)

それぞれ「dMy」2006 年 12 月 27 日または 2006 年 12 月 27 日

「Mdy」 例: 2006 年 12 月 27 日または 2006 年 12 月 27 日 (カンマはオプション)

「私の」例 (2006 年 12 月または 2006 年 12 月)

「my」 たとえば、12/2006 または 12/06 (区切り文字はスペース、ピリオド、ダッシュ、スラッシュにすることができます)

このキーが指定されていない場合は、デフォルトで「ymd」が使用されます:

1 public $validate = array(

2 '誕生日' => array(

3 'rule' => array('datetime', 'dmy'),

4 'メッセージ' => '有効な日付と時刻を入力してください。'

5)

6);

2 番目のパラメータを渡すことでカスタム正規表現を指定できます。このパラメータを使用する場合は、これを検証の基準として使用します。

date() とは異なり、datetime() は日付と時刻を検証します。

静的検証::10 進数 (整数 $check, 整数 $places = null, 文字列 $regex = null)

このルールにより、データが有効な数値であることが保証されます。小数点以下の桁数を指定するパラメータを渡すことができます。パラメーターが渡されない場合、データは厳密に浮動小数点でなければなりません。小数点の後に数値が見つからない場合、チェックは失敗します。

1 public $validate = array(

2 '価格' => 配列(

3 'ルール' => 配列('10進数', 2)

4)

5);

静的検証::email(文字列 $check、ブール値 $deep = false、文字列 $regex = null)

このルールは、データが有効な電子メール アドレスであるかどうかを検証します。 2 番目の引数として論理値を渡すと、このルールはアドレス内のホストが有効かどうかをチェックしようとします:

1 public $validate = array('email' => array('rule' => 'email'));

2

3 public $validate = array(

4 'メール' => array(

5 'ルール' => 配列('メール', true),

6 'メッセージ' => '有効なメールアドレスを入力してください。'

7)

8);

静的検証::equalTo(混合 $check、混合 $compareTo)

このルールは、データが指定された値と同じ型および数値的等しいことを保証します。

1 public $validate = array(

2 '食べ物' => array(

3 'rule' => array('equalTo', 'cake'),

4 'メッセージ' => 'この値は文字列ケーキである必要があります'

5)

6);

静的検証::extension(mixed $check, array $extensions = array('gif', 'jpeg', 'png', 'jpg'))

このルールは、ファイル拡張子が .jpg か .png かをチェックします。複数の拡張子を配列として渡すことができます。

1 public $validate = array(

2 '画像' => 配列(

3 'ルール' => 配列('拡張子', 配列('gif', 'jpeg', 'png', 'jpg')),

4 'メッセージ' => '有効な画像を提供してください。'

5)

6);

静的検証::fileSize($check, $operator = null, $size = null)

このルールにより、ファイルの長さの検出が可能になります。 $operator を使用して、必要な比較の種類を決定できます。比較() によってサポートされるすべての操作は、ここでもサポートされます。 このメソッドは、tmp_name キーを読み取ることで、$_FILES からの配列値を自動的に処理します ($check がそのキーを含む配列の場合):

1 public $validate = array(

2 '画像' => 配列(

3 'ルール' => 配列('ファイルサイズ', '<=', '1MB'),

4 'メッセージ' => '画像は1MB未満である必要があります'

5)

6);

バージョン 2.3 の新機能: このメソッドはバージョン 2.3 で追加されました。

静的検証::inList(string $check, array $list)

このルールは、値が指定されたセット内にあることを保証します。値の配列が必要です。列の値が指定された配列の値と一致する場合、その列は有効であるとみなされます。

例:

1 public $validate = array(

2 '関数' => 配列(

3 'allowedChoice' => array(

4 'ルール' = & GT; 配列 ('インリスト', 配列 ('Foo', 'Bar')),

5 'メッセージ' => 'Foo または Bar を入力してください。'

6)

7)

8);

静的検証::ip(string $check, string $type = 'both')

このルールにより、有効な IPv4 または IPv6 アドレスが送信されることが保証されます。引数「both」(デフォルト)、「IPv4」または「IPv6」を受け入れます。

1 public $validate = array(

2 'clientip' => array(

3 'rule' => array('ip', 'IPv4'), // または 'IPv6' または '両方' (デフォルト)

4 'メッセージ' => '有効な IP アドレスを入力してください。'

5)

6);

静的検証::isUnique

列データは一意である必要があり、他の行で使用することはできません。

1 public $validate = array(

2 'ログイン' => array(

3 'ルール' => 'isUnique'、

4 'メッセージ' => 'このユーザー名はすでに使用されています。'

5)

6);

静的検証::luhn(string|array $check, boolean $deep = false)

Luhn アルゴリズム: さまざまな識別コードの検証アルゴリズム。詳細については、http://en.wikipedia.org/wiki/Luhn_algorithm を参照してください。

静的検証::maxLength(string $check, integer $max)

このルールにより、データが最大長内に収まることが保証されます。

1 public $validate = array(

2 'ログイン' => array(

3 'ルール' => 配列('maxLength', 15),

4 'メッセージ' => 'ユーザー名の長さは 15 文字以下である必要があります。'

5)

6);

ここでの長さは「文字列データのバイト数」です。非 ASCII 文字を扱う場合、値が文字数を超える可能性があることに注意してください。

静的検証::mimeType(混合 $check, 配列 $mimeTypes)

2.2の新しいバージョンの機能

このルールは有効な mimeType をチェックします

1 public $validate = array(

2 '画像' => 配列(

3 'rule' => array('mimeType', array('image/gif')),

4 'メッセージ' => '無効な MIME タイプです。'

5)、

6);

静的検証::minLength(文字列 $check, 整数 $min)

このルールにより、データが最小長以上であることが保証されます。

1 public $validate = array(

2 'ログイン' => array(

3 'ルール' => 配列('minLength', 8),

4 'メッセージ' => 'ユーザー名は少なくとも 8 文字の長さである必要があります。'

5)

6);

ここでの長さは「文字列データのバイト数」です。非 ASCII 文字を扱う場合、値が文字数を超える可能性があることに注意してください。

静的検証::money(string $check, string $symbolPosition = 'left')

このルールにより、値が有効な金額であることが保証されます。

2 番目のパラメータは、通貨記号の位置 (左/右) を定義します。

1 public $validate = array(

2 '給与' => array(

3 'ルール' => 配列('お金', '左'),

4 'メッセージ' => '有効な金額を入力してください。'

5)

6);

静的検証::multiple(混合 $check, 混合 $options = array())

このルールは、複数の選択入力フォームを検証するために使用されます。サポートされているパラメータは、「in」、「max」、および「min」です。

1 パブリック $validate = array(

2 '複数' => array(

3 'ルール' => array('複数', array(

4 'in' => array('do', 'ray', 'me', 'fa', 'so', 'la', 'ti'),

5 '分' => 1,

6 '最大' => 3

7 ))、

8 「メッセージ」 => 「1 つ、2 つ、または 3 つのオプションを選択してください」

9)

10);

静的検証::notEmpty(混合 $check)

このルールにより、列が空ではないことが保証されます。

1 public $validate = array(

2 'タイトル' => 配列(

3 'ルール' => 'notEmpty',

4 'メッセージ' => 'このフィールドを空白のままにすることはできません'

5)

6);

複数の選択入力を検証する場合は、エラーが発生するため、このルールを使用しないでください。代わりに「複数」を使用してください。

静的検証::数値(文字列 $check)

渡されたデータが有効な数値であるかどうかを確認します。

1 public $validate = array(

2 '車' => array(

3 'ルール' => '数値',

4 'メッセージ' => '車の台数を入力してください。'

5)

6);

static Validation::naturalNumber(mixed $check, boolean $allowZero = false)

2.2の新しいバージョンの機能

このルールは、渡されたデータが有効な自然数であるかどうかをチェックします。 $allowZero が true に設定されている場合、0 も許容値になります。

1 パブリック $validate = array(

2 'ホイール' => array(

3 'ルール' => 'naturalNumber',

4 'メッセージ' => 'ホイールの数を入力してください。'

5 )、

6 'エアバッグ' => array(

7 'rule' => array('naturalNumber', true),

8 'メッセージ' => 'エアバッグの数を入力してください。'

9 )、

10);

静的検証::phone(mixed $check, string $regex = null, string $country = 'all')

電話認証は米国の電話番号を対象としています。米国以外の電話番号を検証する場合は、2 番目のパラメータとして正規表現を指定して、追加の番号形式をオーバーライドできます。

1 public $validate = array(

2 '電話' => 配列(

3 'rule' => array('phone', null, 'us')

4)

5);

静的検証::postal(mixed $check, string $regex = null, string $country = 'us')

郵便番号は、米国、カナダ、英国、イタリア、ドイツ、ベルギーのものです。他の郵便番号の場合は、2 番目の引数として正規表現を指定できます。

1 public $validate = array(

2 '郵便番号' => array(

3 'rule' => array('postal', null, 'us')

4)

5);

静的検証::range(string $check, integer $ lower = null, integer $upper = null)

このルールは、渡された値が指定された範囲内にあることを保証します。範囲が指定されていない場合、このルールは渡された値が現在のプラットフォームで有効な値であることをチェックして確認します。

1 public $validate = array(

2 '数値' => 配列(

3 'ルール' => 配列('範囲', -1, 11),

4「メッセージ」=>「0から10までの数字を入力してください」

5)

6);

上記の例では、0 より大きい値 (例: 0.01) と 10 未満の値 (例: 9.99) を受け入れます。

メモ

範囲の上限/下限は含みません。

静的検証::ssn(混合 $check、文字列 $regex = null、文字列 $country = null)

Ssn 米国、デンマーク、オランダの社会保障番号を確認します。他の社会保障番号の場合は、正規表現を指定する必要があります。

1 public $validate = array(

2 'ssn' => array(

3 'ルール' => 配列('ssn', null, 'us')

4)

5);

静的検証::time(string $check)

時刻検証により、渡された文字列が有効な時刻であるかどうかが判断されます。 24 時間形式 (HH:MM) または午前/午後形式 ([H]H:MM[a|p]m) の 2 つの形式があります。秒は許可されず、秒はチェックされません。

静的検証::uploadError(混合 $check)

2.2の新しいバージョンの機能

このルールは、ファイルのアップロード中にエラーが発生したかどうかを検出します。

1 public $validate = array(

2 '画像' => 配列(

3 'ルール' => 'アップロードエラー',

4 'メッセージ' => 'アップロードで問題が発生しました。'

5)、

6);

静的検証::url(string $check, boolean $strict = false)

このルールは、URL 形式が有効かどうかをチェックします。 http、ftp、ファイル、ニュース、ゴーファープロトコルをサポート:

1 public $validate = array(

2 'ウェブサイト' => array(

3 'ルール' => 'URL'

4)

5);

プロトコルが URL であることを確認するには、厳密モードを有効にします。例は次のとおりです。

1 public $validate = array(

2 'ウェブサイト' => array(

3 'ルール' => 配列('url', true)

4)

5);

静的検証::userDefined(混合 $check、オブジェクト $object、文字列 $method、配列 $args = null)

ユーザー定義の検証を実行します。

静的検証::uuid(string $check)

値が有効な uuid かどうかを確認します: http://tools.ietf.org/html/rfc4122

ローカリゼーションの検証

phone() および postal() 検証ルールは、どうすればよいかわからないすべての国プレフィックスを正しい名前で他のクラスに渡します。 たとえば、オランダに住んでいる場合は、次のようなクラスを作成できます:

1 クラス NlValidation {

2 パブリック静的機能電話($check) {

3 // ...

4 }

5 パブリック静的関数 postal($check) {

6 // ...

7 }

8 }

このファイルは APP/Validation/ または App/PluginName/Validation/ に配置できますが、使用する前に App::uses() でインポートする必要があります。 次の方法で検証クラス内で NLValidation クラスを使用できます:

1 public $validate = array(

2 'phone_no' => array('rule' => array('phone', null, 'nl')),

3 'postal_code' => array('rule' => array('postal', null, 'nl')),

4);

モデルデータが検証されると、Validation は処理できない nl 国コードを確認し、その戻り値を検証の合否結果として使用して NlValidation::postal() に委譲しようとします。 このアプローチにより、ローカリゼーション サブセットまたはローカリゼーション グループを処理するクラスを作成できます。 独立した検証メソッドの使用法は変更されておらず、その機能は追加のバリデーターの追加によって引き継がれます。

ヒント

ローカリゼーション プラグインには、すでにいくつかの便利なルールが含まれています: https://github.com/cakephp/localized ローカリゼーション検証ルールを自由に投稿することもできます。

コントローラー内のデータを確認する

通常はモデルの保存メソッドのみを使用しますが、場合によっては保存せずにデータを確認するだけで済みます。 たとえば、実際にデータをデータベースに保存する前に、ユーザーに追加情報を表示したい場合があります。 このときのデータ検証は、データ保存時の検証とは少し異なります。

まず、データをモデルに割り当てます:

1 $this->ModelName->set($this->request->data);

次に、モデルの検証メソッドを使用してデータが有効かどうかを確認し、有効な場合は true を返し、そうでない場合は false を返します。

1 if ($this->ModelName->validates()) {

2 // データ有効ロジック

3 } 他 {

4 // 無効なデータのロジック

5 $errors = $this->ModelName->validationErrors;

6 }

モデルで指定された検証セットのサブセットのみを使用してモデルを検証することをお勧めします。 たとえば、first_name、last_name、電子メール、パスワードを含む User モデルがあります。 ユーザーを作成または編集するときに、4 つの列ルールをすべて確認したいと考えています。 ユーザーがログインすると、電子メールとパスワードのルールのみが検証されます。 これは、検証する列を指定するオプション データを渡すことで実現できます:

1 if ($this->User->validates(array('fieldList' => array('email', 'password')))) {

2 // 有効です

3 } 他 {

4 // 無効です

5 }

検証メソッドは、invalidFields メソッドを呼び出して、モデルの validationErrors 属性を設定します。また、invalidFields メソッドは次のデータを返します:

1 $errors = $this->ModelName->invalidFields(); // validationErrors 配列が含まれます

検証エラー リストは、invalidFields() の連続呼び出し中にクリアされません。 したがって、検証がループ内で行われ、エラー セットを分離したい場合は、invalidFields() を使用しないでください。代わりに、 validates() メソッドを使用して、モデルの validationErrors プロパティにアクセスします。

データを検証する前に、データをモデルに割り当てる必要があることに注意することが重要です。 これは、データをパラメータとして渡すことができる save メソッドとは異なります。 また、save は実際にデータを保存する前に自動的にデータを検証するため、save を呼び出す前に verify を呼び出す必要はないことに注意してください。

複数のモデルを確認するには、次の方法を使用します:

1 if ($this->ModelName->saveAll($this->request->data, array('validate' => 'only'))) {

2 // 無効な www.2cto.com

3 } 他 {

4 // 有効です

5 }

保存前にデータが検証されている場合は、検証をオフにして繰り返し検出を防ぐことができます:

1 if ($this->ModelName->saveAll($this->request->data, array('validate' => false))) {

2 // 保存時に検証が不要になりました

3}

http://www.bkjia.com/PHPjc/477761.htmlwww.bkjia.comtru​​ehttp://www.bkjia.com/PHPjc/477761.html技術記事データ検証 データ検証は、モデル内のデータがアプリケーションのビジネス ルールに準拠していることを確認するのに役立つため、あらゆるアプリケーションの重要な部分です。 たとえば、次のことを確認してください...