FuelPHPの標準バリデーションルール総まとめ

こんにちは。
開発チームのワイルド担当、まんだいです。
今回は、FuelPHP標準のバリデーションルールについて、知ってることや意外な使い方など、ドキュメントに載っていない情報をなるべく盛り込んでお届けしたいと思います。
なお、FuelPHPのバージョンは1.7.2で確認しております。

 

required

requiredは必須項目のチェックで、「false」、「null」、「空文字」、「要素を持たない空の配列」以外の時、パスできます。
required以外のバリデーションルールは、空文字でパスできてしまうのに注意が必要です。

 

required_with

$fieldnameの名前を持つフィールドのデータがrequiredルールをパスした時のみ、requiredルールが適用されます。
チェックボックスにチェックが付いていた場合、テキストボックスの中身をバリデートする、みたいな使い方でしょうか。

 

match_value

$compareのデータと同じかどうかを比較します。
$compareは、文字列、数字の場合、「===」による型も含めた比較をします。
また、$strictがfalseの場合、「==」による型を無視した比較をします。

$compareが配列の場合、配列を走査し、順に「===」による型も含めた比較をします。
同じものがあった場合、バリデーションをパスします。
$strictがfalseの場合、「==」による型を無視した比較をします。

 

match_pattern

preg_match関数による正規表現を用いたパターンマッチを行います。
Fuelphpのfieldsetで入力フォームを高速かつエレガントかつワイルドに量産してみる | 株式会社ビヨンドにもサンプルがありますので合わせてご確認いただければと思います。

 

match_field

$fieldで指定したフィールドと型チェックを含めた比較をします。
このルールには、strictの指定はできないので「===」の場合と空文字の場合のみ、パスします。

 

match_collection

$collectionが配列の場合、in_array関数で配列内の値と比較します。
$strictがtrueの場合、in_array関数の第三引数にtrueがセットされ、型チェックも含めた厳密な比較を実施します。

$collectionが配列ではない場合、与えられた引数全てを配列にセットし、in_array関数による比較を実施します。
例えば、「1, true, 2, 'test3'」というデータを引数にした場合、フォームから1を入力しても、$strictにtrueがセットされているためパスできません（POST送信された数字は文字列扱いのため）。
実質、このバリデーションをパスできる文字列はtest3のみという事になります。

また、「1, 'true', 2, 'test3'」というデータを引数にした場合、$strictにtrueがセットされているように見えますが、ブール値ではないため、型チェックなしの比較となります。
よって、POST送信されたデータをバリデーションする場合は、「true」、「test3」の2つがパスできる事になります。

仕様が不明瞭でわかりにくい、かつmatch_valueルールで第一引数を配列にした時と同じ挙動をするため、$collectionに配列以外のデータを入力して使用するのは思わぬ落とし穴になりそうです。

 

min_length

文字列のサイズが$length以上の場合、パスできます。
サイズが0の場合（=空文字）もパスできますので、$length = 1としたところで必須項目の検証にはなりません。

 

max_length

文字列のサイズが$length以下の場合、パスできます。

 

exact_length

文字列のサイズが$lengthの場合、パスできます。
サイズが0の場合（=空文字）もパスできますので、requiredとセットで使う事が多いかもしれません。

 

valid_date

与えられた文字列が、日時のフォーマットに沿ったデータかどうか検証します。
空文字の場合、パスできるのは言わずもがなですが、$formatを敢えて指定する必要はないというのはドキュメントしか見ていないと中々気付けないでしょう。
$formatにフォーマットをセットした場合、date_parse_from_format関数によって$formatに基いたパースが行われます。
$formatがnullの場合、date_parse関数によって、パースするので、フォーマットを決め打ちする必要がありません（日付としてパースできてしまうデータが誤ってパスする可能性もある訳ですが）。

$formatにnullをセットした場合のメリットとしては、「Y-m-d」と「Y/m/d」の両方がパスできるルールにできるという事でしょうか。

 

valid_email

filter_var関数を使って、メールアドレスとして妥当な文字列かを検証します。
filter_var関数でのメールアドレス検証はpreg_match関数を使って自前の正規表現を通すより遥かに安全です。

 

valid_emails

$separatorに設定された文字列で入力データをexplodeで分解した後、ループでvalid_emailルールの検証します。

なお、$separatorのデフォルト値は「,」になっています。

 

valid_url

filter_var関数を使って、URLとして妥当な文字列かを検証します。
filter_var関数の落とし穴として、マルチバイト文字を含むURLは実在するURLだとしてもパスできません。

 

valid_ip

filter_var関数を使って、IPアドレスとして妥当な文字列かを検証します。
IPv4、IPv6問わず検証できます。

 

numeric_min

入力値が数字として$min_val以上かどうかを検証します。
内部的には入力値と$min_valをfloatにキャストして比較するので、小数も比較もできます。

 

numeric_max

入力値が数字として$max_val以下かどうかを検証します。
内部的には入力値と$max_valをfloatにキャストして比較するので、小数も比較もできます。

 

numeric_between

入力値が数字として$min_val以上、 $max_val以下であるかを検証します。
numeric_minルールとnumeric_maxルールを同時に検証している内容です。

 

valid_string

ルールを選ぶだけで汎用的な正規表現を組み立てて検証を行います。
match_patternでも同等のものはできますが、込み入った正規表現でないなら、正規表現を読む必要がない分見通しは良いかも知れません。
$flagsに格納される配列が取り得る文字列は、以下の通りです。

内部処理では、これらのルールを組み合わせて、正規表現を組み立てています。
配列で幾つか指定する必要がある訳ですが、入力データの形式が決まっている場合、データフォーマットに沿ったルールを自動的にセットしてくれる隠し機能があります。

URLであれば、「$flags = 'url_safe'」とするだけで、'alpha', 'numeric', 'dashes'の3つのフラグが設定されます。
このようなルール（複数のルールがセットになった、ルールセット？）が実は隠し機能として存在しています。

allのやけくそっぷりがハンパないですね（いつ使うんだよ）。

 
以上です。