ASP.NET 検証の詳細

  • [アーティクル]

 

アンソニー・ムーア
Microsoft Corporation

2000 年 10 月
更新日: 2002 年 3 月

概要： ASP.NET 検証 Web コントロールの動作の詳細な調査。 (15ページ印刷)

内容

はじめに
初めは
どのような場合に発生しますか?
Server-Side検証シーケンス
Client-Side検証
有効性ルールと意味のあるエラー メッセージ
Enabled プロパティ、Visible プロパティ、Display プロパティの効果
CustomValidator コントロール
検証できるコントロールはどれですか?
それです

はじめに

この記事では、ASP.NET 検証コントロールのしくみについて詳しく説明します。 この記事は、検証コントロールを使用して複雑なページを構築するユーザー、または検証フレームワークの拡張を検討しているユーザーに推奨される読み取りです。 検証コントロールの使用を開始する、または使用するかどうかを決定しようとしているユーザーについては、「 ASP.NET でのユーザー入力の検証」を参照してください。

初めは

ASP.NET の開発を通じて、検証の支援が重要であることを知っていました。 今日のほとんどの商用 Web サイトを見ると、検証を実行するために多くの手書きのコードを明確に実行するフォームが埋め込まれていることがわかります。 検証コードは特にセクシーではありません。 データのテーブルを表示したり、グラフを動的に生成したりするためのコードを記述することは魅力的ですが、同僚が名前フィールドに空白の値を入力するのを止めたクールな方法をチェックする人はいません。

Web アプリケーションの検証は、他の理由でも特にフラストレーションが発生します。 HTML 3.2 は、制御できる内容とユーザーから得られるフィードバックに限られているため、ユーザーが特定の文字を入力できないようにしたり、ビープ音を鳴らしたりするなど、より豊富なクライアントで使用できるのと同じテクニックを適用することはできません。 ブラウザー スクリプトを使用して、より強力な検証を作成できます。 ただし、スクリプトがクライアント ブラウザーに常に存在するとは限らず、悪意のあるユーザーによってバイパスされる可能性があるため、これは正当化するのが難しい場合があります。 そのため、セキュリティで保護されたサイトを確保するために、サーバーに対して同じチェックを実装する必要があります。

ASP.NET の開発では、検証を処理するコントロールが 1 つだけ必要でした。これは、エラーを表示できる TextBox コントロールのバージョンでした。 しかし、コントロールを設計する時が来たとき、マスタードをカットしないことが明らかになりました。 多数のデータ入力フォームを見て、できるだけ多くのデータ入力フォームに適合するソリューションを見つけようとしました。 データ入力フォームに関する興味深い点が多数見つかりました。

  • 入力要素に隣接してエラー メッセージまたはアイコンが表示されるのが一般的ですが、ほとんどの場合、異なるテーブル セルに配置されます。
  • 一般的に、すべてのエラーが集計されるページの領域があります。
  • 多くのサイトには、より迅速なフィードバックを提供し、サーバーへの無駄なラウンド トリップを防ぐためのクライアント側スクリプトが含まれています。
  • クライアント側スクリプトがある多くのサイトでは、エラーが発生した場合にメッセージ ボックスが表示されます。
  • 検証されるテキスト入力だけではありません。 ドロップダウン リストとラジオ ボタンも頻繁に検証されます。
  • フィールドが空の場合、通常、サイトには、エントリが無効な場合に表示されるメッセージまたはアイコンとは異なるメッセージまたはアイコンが表示されます。
  • 多くの検証チェックは、正規表現の優れた候補です。
  • 有効性は、入力間の比較に依存することが一般的です。
  • 検証タスクの 90% 以上は、名前や郵便番号のチェックなどの一般的な操作です。 ほとんどのサイトは車輪を再発明しているように見えました。
  • 一般に、サイト間のバリエーションが多すぎて、すべてのサイトに対して検証タスクの 100% を実行できる完璧なソリューションが得られます。

これらすべての点を考慮すると、5 つの Validator コントロール、ValidationSummary コントロール、 Page オブジェクトとの統合が最終的に解決されました。 また、ソリューションを拡張可能にする必要があること、およびクライアントとサーバーの両方で操作するための API が必要になることも明らかでした。

さまざまな種類の検証を見ると、より大きなツールボックスが必要のように思えました。 Microsoft® ActiveX® のようなほとんどのコンポーネント環境では、すべての検証コントロールの機能を、異なるモードの異なるプロパティで動作する 1 つのコントロールにオーバーロードしようとしました。 ただし、Microsoft® .NET Frameworkでの継承の魔法のおかげで、各新しいコントロールを派生させるオーバーヘッドが非常に小さいため、特定のプロパティを使用して特定の検証を行うコントロールのスイートを提供できます。

これらのコントロールによって実行される作業のほとんどは、共通の親である BaseValidator に実装されます。 これを利用するために、BaseValidator またはその他のコントロールから派生することもできます。 実際、BaseValidator でさえ、独自の Text プロパティを実装するには面倒で、Label から継承します。

どのような場合に発生しますか?

検証 Web コントロールを持つページが処理されるときに、イベントのシーケンスを理解すると便利です。 いずれかの検証条件が省略可能な場合は、クライアントとサーバーの両方で検証が行われるタイミングを正確に把握する必要があります。 時間がかかる可能性がある、または副作用を持つ独自の検証ルーチンを作成する場合は、いつ呼び出されるかを把握することも重要です。

まず、サーバーを見てみましょう。

Server-Side検証シーケンス

ページのライフ サイクルを理解することが重要です。 Visual Basic や同様のリッチ クライアント ツールでフォームを操作する場合は、少し慣れる必要があります。 ページとその上のすべてのオブジェクトは、ユーザーが操作している限り、実際には存続しませんが、ユーザーが操作しているように見えることがあります。

ページが最初にアクセスされたときのイベントの簡略化されたシーケンスを次に示します。

  1. ページとそのコントロールは、ASPX ファイルに基づいて作成されます。
  2. Page_Loadイベントが発生します。
  3. ページプロパティとコントロールプロパティは非表示フィールドに保存されます。
  4. ページとコントロールは HTML に変換されます。
  5. すべてが捨てられる。

これで、ユーザーがボタンまたは同様のコントロールをクリックすると、サーバーに戻り、同様のシーケンスが実行されます。 これはポストバック シーケンスと呼ばれます。

  1. ページとそのコントロールは、ASPX ファイルに基づいて作成されます。
  2. ページとコントロールのプロパティは非表示フィールドから回復されます。
  3. ページ コントロールは、ユーザー入力に基づいて更新されます。
  4. Page_Loadイベントが発生します。
  5. 変更通知イベントが発生します。
  6. ページプロパティとコントロールプロパティは非表示フィールドに保存されます。
  7. ページとコントロールは HTML に変換されます。
  8. すべてが再び捨てられる。

すべてのオブジェクトをメモリ内に保持しないのはなぜですか? Web サイトは ASP.NET を使用して構築されるため、非常に多くのユーザーで動作しません。 このように、サーバー上のメモリ内のオブジェクトは、現在処理されているだけです。

サーバー側の検証はいつ行われますか? まあ、最初のページフェッチではまったく行われません。 私たちのエンドユーザーのほとんどは非常に熱心であり、我々は彼らに赤いテキストで彼らを襲う前に、彼らが正しくフォームを埋めるという疑いの利点を与えたいと考えています。

ポストバックでは、検証をトリガーしたボタンまたはコントロールに対してイベントが発生する直前の手順 5 で検証が行われます。 ASP.NET のボタン コントロールには 、 CausesValidation というプロパティがあり、既定値は True です。 これは、検証を行うボタンをクリックするアクションです。 検証の結果をチェックするのに最適な場所は、検証をトリガーしたイベント ハンドラーにあります。 また、CausesValidation=False のボタンを含めることもできます。これにより、検証コントロールは評価されません。

このタイミングについて混乱を招く可能性のある点の 1 つは、Page_Loadがトリガーされた時点で検証コントロールが評価されていないことです。 この利点は、特定の検証コントロールの有効化や無効化など、ページの有効性に影響するプロパティ値をプログラムで変更できるということです。

このタイミングが好みではなく、Page_Load内のすべてを評価する場合は、Page.Validate を呼び出して、このイベント中に検証を明示的にトリガーすることでこれを行うことができます。 これを呼び出した後、Page.IsValid の結果をチェックできます。 Page.Validate が明示的に呼び出されるか、CausesValidation=True のボタンによってトリガーされる前に Page.IsValid の結果に対してクエリを実行しようとすると、その値は意味がないため、例外がスローされます。

ページ API

Page オブジェクトには、サーバー側の検証に関して重要なプロパティとメソッドがいくつかあります。 これらは表 1 にまとめられています。

表 1 Page オブジェクトのプロパティとメソッド

プロパティまたはメソッド 説明
IsValid プロパティ これは最も便利なプロパティです。 フォーム全体が有効かどうかをチェックできます。 これは通常、データベース更新を実行する前に行われます。 これは、 Validators コレクション内のすべてのオブジェクトが有効であり、この値をキャッシュしない場合にのみ当てはまります。
Validators プロパティ ページのすべての検証オブジェクトのコレクション。 これは、IValidator インターフェイスを実装するオブジェクトのコレクションです。
Validate メソッド 検証時に呼び出されるメソッド。 Page の既定の実装は、各検証コントロールに移動し、それ自体を評価するように要求します。

Validators コレクションは、多くの場合に役立ちます。 これは、IValidator インターフェイスを実装する のオブジェクトのコレクションです。 PageはIValidatorインターフェイスのみを扱うので、コントロールではなくオブジェクトという用語を使用します。 通常、すべての検証コントロールは IValidator を実装するビジュアル コントロールになりますが、誰かが任意の検証オブジェクトと一緒に来てページに追加できない理由はありません。

IValidator インターフェイスには、次のプロパティとメソッドがあります。

表 2 IValidator インターフェイスのプロパティとメソッド

プロパティまたはメソッド 説明
IsValid プロパティ 個々の検証オブジェクトによって行われた検証チェックが成功したかどうかを示します。 検証が行われた後、この値を手動で変更できます。
ErrorMessage プロパティ 検証オブジェクトが検証中で、ユーザーに表示される可能性があるエラーについて説明します。
Validate メソッド 検証オブジェクトの検証チェックを実行して、その IsValid 値を更新します。

このインターフェイスを使用すると、いくつかの興味深いことができます。 たとえば、ページを有効な状態にリセットするには、次のコードを使用します (C#に示されている例)。

    IValidator val;
    foreach(val in Validators) {
        Val.IsValid = true;
    }

検証シーケンス全体を再実行するには、次のコードを使用します。

    IValidator val;
    foreach(val in Validators) {
        Val.Validate();
    }

これは、Page で Validate() メソッドを呼び出すことと同じです。

検証を行う前に変更を加えるもう 1 つの方法は、 Validate メソッドをオーバーライドすることです。 次の使用例は、チェック ボックスの値に基づいてオンまたはオフになっている検証コントロールを含むページを示しています。

    public class Conditional : Page {
        public HtmlInputCheckBox chkSameAs;
        public RequiredFieldValidator rfvalShipAddress;

        public override void Validate() {
            // Only check ship address if not same as billing
            bool enableShip = !chkSameAs.Checked;
            rfvalShipAddress.Enabled = enableShip;
            // Now perform validation
            base.Validate();
        }
    }

Client-Side検証

ページに対してクライアント側の検証が有効になっている場合、ラウンド トリップの間にまったく異なるシーケンスが発生します。 クライアント側の検証は、クライアント JScript を使用して機能します®。 動作させるためにバイナリ コンポーネントは必要ありません。

JScript 言語は合理的に標準化されていますが、ブラウザーで HTML ドキュメントを操作するためのドキュメント オブジェクト モデル (DOM) には、これらのコンポーネントの開発とテスト時に広く採用された標準がありませんでした。 その結果、クライアント側の検証はインターネット エクスプローラー 4.0 以降でのみ行われます。これは、インターネット エクスプローラー DOM を対象とするためです。

サーバーの観点からは、クライアント側の検証は、検証コントロールが HTML に異なるものを出力することを意味します。 それ以外のイベントのシーケンスはまったく同じです。 サーバー側のチェックは引き続き実行されます。これは冗長に見えるかもしれませんが、次の理由で重要です。

  • 一部の検証コントロールでは、クライアント スクリプトがサポートされない場合があります。 良い例は、サーバー検証関数で CustomValidator を使用しているが、クライアント検証関数がない場合です。
  • セキュリティに関する注意点 誰かがスクリプトを含むページを非常に簡単に取得し、それを無効または変更することができます。 システムに不正なデータが入るのを止めるためにスクリプトに頼ってはいけません。ユーザーに対してより迅速なフィードバックを提供することだけです。 このため、CustomValidator を使用している場合は、対応するサーバー検証関数を使用せずにクライアント検証関数を指定しないでください。

すべての検証コントロールにより、クライアント スクリプトの標準ブロックがページに出力されます。 これは実際には、WebUIValidation.js というスクリプト ライブラリ内のコードへの参照を含む少量のスクリプトです。 このファイルは個別にダウンロードされ、ブラウザーでキャッシュできます。このファイルには、クライアント側の検証用のすべてのロジックが含まれています。

スクリプト ライブラリについて

検証 Web はスクリプト ライブラリ内のスクリプトを制御するため、クライアント側の検証用のすべてのコードをページに直接出力する必要はありませんが、これは発生したかのように機能します。 メイン スクリプト ファイル参照は次のようになります。

<script language="javascript" 
        src="/aspnet_client/system_web/1_0_3617_0/WebUIValidation.js">
</script>

既定では、スクリプト ファイルは aspnet_client ディレクトリの既定のルートにインストールされ、スラッシュで始まるルート相対スクリプトインクルード ディレクティブを使用して参照されます。 この参照は、各プロジェクトがその中にスクリプト ライブラリを含める必要がないことを意味し、同じコンピューター上のすべてのページで同じファイルを参照できます。 パスには共通言語ランタイムのバージョン番号も含まれているため、同じコンピューターで異なるバージョンのランタイムを実行できます。

既定の仮想ルートを調べる場合は、このファイルを見つけて、その中を見ることができます。 これらのファイルの場所は、ほとんどの ASP.NET 設定に使用される XML ファイルである machine.config ファイルで指定されます。 そのファイル内の場所の定義を次に示します。

        <webControls
            clientScriptsLocation="/aspnet_client/{0}/{1}/"
        />

スクリプトを読んで、何が起こっているのかを確認することをお勧めします。 ただし、これらのスクリプトの関数は特定のバージョンの実行時に非常に密接に関連付けられているため、これらのスクリプトを変更することはお勧めしません。 実行時が更新されると、スクリプトに対応する更新が必要になる場合があり、変更を失うか、スクリプトが機能しない問題に直面する必要があります。 特定のプロジェクトのスクリプトを変更する必要がある場合は、ファイルのコピーを取得し、プライベート web.config ファイルでファイルの場所をオーバーライドしてプロジェクトをポイントします。この場所を相対参照または絶対参照に変更しても問題ありません。

Client-Side検証の無効化

クライアント側の検証が必要ない場合があります。 入力フィールドの数が非常に少ない場合は、クライアント側の検証はあまり役に立たない可能性があります。 毎回サーバーへのラウンド トリップを必要とするロジックがある場合があります。 クライアントに動的に表示されるメッセージが、レイアウトに悪影響を及ぼす場合があります。

メモ クライアント側の検証を無効にする方法は、検証コントロールまたは ValidationSummary コントロールの EnableClientScript プロパティを False に設定することです。 サーバーのみの検証コンポーネントとクライアントサーバー検証コンポーネントを同じページに混在させる可能性があります。

Client-Side シーケンス

これは、クライアント側の検証を含むページが実行されるイベントのシーケンスです。

  1. ページがブラウザーに読み込まれると、各検証コントロールで初期化が行われます。 コントロールは、サーバー上のプロパティに密接に対応する HTML 属性を持つスパン> タグとして<出力されます。 ここで最も重要なことは、検証コントロールによって参照されるすべての入力要素が "フックアップ" されていることです。参照される入力要素では、入力が変更されるたびに検証ルーチンが呼び出されるように、クライアント イベントが変更されます。
  2. スクリプト ライブラリ内のコードは、フィールドからフィールドへのユーザー タブとして実行されます。 依存フィールドが変更され、必要に応じて検証コントロールが表示または非表示になると、検証条件が再評価されます。
  3. CausesValidation プロパティが True に設定されているボタンをユーザーがプッシュすると、検証コントロールはすべて再評価されます。 すべて有効な場合は、フォームがサーバーにポストされます。 1 つ以上のエラーがある場合は、次のようなことが発生します。
    • 送信は取り消されます。 フォームはサーバーにポストバックされません。
    • 無効な検証コントロールが表示されます。
    • ShowSummary=true の検証の概要がある場合は、検証コントロールからすべてのエラーを収集し、その内容を更新します。
    • ShowMessageBox=true の検証の概要がある場合、エラーが収集され、クライアント メッセージ ボックスに表示されます。

入力が変更されるたびに送信時に実行されるため、クライアント側の検証コントロールは通常、クライアントで 2 回以上評価されます。 送信が行われた後も、サーバーで再評価されることに注意してください。

The Client-Side API

独自のクライアント側コードでさまざまな効果を実現するために、クライアントで使用できるミニ API があります。 特定のルーチンを非表示にすることはできないため、理論的には、クライアント側の検証スクリプトで定義されている変数、属性、および関数を使用できます。 ただし、その多くは、変更可能な実装の詳細です。 使用することをお勧めするクライアント側オブジェクトの概要を次に示します。

表 3 クライアント側オブジェクト

名前 Type 説明
Page_IsValid ブール型変数 ページが現在有効かどうかを示します。 検証スクリプトでは、これを常に最新の状態に保ちます。
Page_Validators 要素の配列 これは、ページ上のすべての検証コントロールを含む配列です。
Page_ValidationActive ブール型変数 検証を行う必要があるかどうかを示します。 プログラムによって検証を無効にするには、この変数を False に設定します。
Isvalid Boolean プロパティ これは、現在有効かどうかを示す各クライアント検証コントロールのプロパティです。

クライアント検証のバイパス

実行する必要がある一般的なタスクは、ページに "キャンセル" ボタンまたはナビゲーション ボタンを設定することです。 この場合、ボタンの CausesValidation プロパティを False に設定すると、サーバーまたはクライアントで検証は行われません。 このようなページをレイアウトする場合は、ボタン偶数ハンドラーに Page.IsValid をチェックします。 Page_Load中に Page.Validate を呼び出す代わりに、送信ボタンとキャンセル ボタンがプッシュされたかどうかを知る方法はありません。

特殊効果

もう 1 つの一般的な要件は、エラー状況で検証コントロール自体によって表示されるエラー メッセージ以外の効果を持つことです。 この場合は、サーバーとクライアントの両方で動作を変更する必要があります。 入力が有効かどうかに応じて色を変更するラベルがあるとします。 サーバーでこれを行う方法を次に示します。

public class ChangeColorPage : Page {
    public Label lblZip;
    public RegularExpressionValidator valZip;
    
protected override void OnLoad(EventArgs e) {     
    Page.Validate();       
        lblZip.ForeColor = valZip.IsValid? Color.Black : Color.Red;
    }               
}

これはすべて非常に便利ですが、このような検証を変更するたびに、クライアントで同等の操作を行わない限り、一貫性が見えない場合があります。 検証フレームワークを使用すると、この 2 つの作業の多くを節約できますが、追加の効果を得るために、2 か所で行う必要があります。 同じことを行うクライアント フラグメントを次に示します。

<asp:Label id=lblZip runat=server 
   Text="Zip Code:"/> 
<asp:TextBox id=txtZip runat=server 
   OnChange="txtZipOnChange();" /></asp:TextBox><br>
<asp:RegularExpressionValidator id=valZip runat=server
   ControlToValidate=txtZip
   ErrorMessage="Invalid Zip Code" 
   ValidationExpression="[0-9]{5}" /><br>

<script language=javascript>
function txtZipOnChange() {
   // Do nothing if client validation is not active
   if (typeof(Page_Validators) == "undefined")  return;
   // Change the color of the label
   lblZip.style.color = valZip.isvalid ? "Black" : "Red";
}
</script>

Client-Side API

一部の追加シナリオは、クライアント側スクリプトから呼び出すことができる関数によって有効になります。

表 4 クライアント側スクリプトから呼び出される関数

名前 説明
ValidatorValidate(val) クライアント検証コントロールを入力として受け取ります。 検証コントロールを入力チェックし、その表示を更新します。
ValidatorEnable(val, enable) クライアント検証コントロールとブール値を受け取ります。 クライアント検証コントロールを有効または無効にします。 無効にすると、評価が停止され、常に有効に表示されます。
ValidatorHookupControl(control, val) 入力 HTML 要素とクライアント検証コントロールを受け取ります。 変更時に検証コントロールを更新するように、要素の変更イベントを変更または作成します。 これは、複数の入力値に依存するカスタム検証コントロールに役立ちます。

特に使用するのは、検証コントロールを有効または無効にできることです。 特定のシナリオでのみアクティブにする検証がある場合は、サーバーとクライアントの両方でアクティブ化を変更する必要がある場合や、ユーザーがページを送信できない場合があります。

次に示すのは、チェック ボックスがオフになっている場合にのみ検証する必要があるフィールドの例です。

    public class Conditional : Page {
        public HtmlInputCheckBox chkSameAs;
        public RequiredFieldValidator rfvalShipAddress;
        public override void Validate() {
            bool enableShip = !chkSameAs.Checked;
            rfvalShipAddress.Enabled = enableShip;
            base.Validate();
        }
    }

クライアント側の同等のコードを次に示します。

<input type=checkbox runat=server id=chkSameAs 
   onclick="OnChangeSameAs();" >Same as Billing<br>
<script language=javascript>
function OnChangeSameAs() {
    var enableShip = !event.srcElement.status;
    ValidatorEnable(rfvalShipAddress, enableShip);
}
</script>

有効性ルールと意味のあるエラー メッセージ

各検証コントロールは、特定のコントロールの特定の条件に関する特定のエラー メッセージを表示します。 有効と見なされるものに関するルールがあり、最初は開発者にとって混乱しているように見えますが、ユーザーにとって実際に役立つエラー メッセージを作成できるようにするために必要です。

すべての検証コントロール (RequiredFieldValidator を除く) は、空白の場合は有効と見なされます。 空白の値が無効な場合は、通常、別の検証コントロールに加えて RequiredFieldValidator を指定する必要があります。 ほとんどの場合、空白と有効性に対して異なるエラー メッセージが必要であるため、これを行う必要があります。 それ以外の場合は、"値を入力する必要があり、1 から 10 の間である必要があります" のような混乱を招くメッセージが表示されます。

入力フィールドを指定したデータ型に変換できない場合、もう 1 つの特殊な規則は CompareValidator と RangeValidator に関連しています。 ControlToCompare が指定された CompareValidator の有効性の評価は、次のようになります。

  1. ControlToValidate によって参照される入力フィールドが空白の場合は有効です。
  2. ControlToValidate によって参照される入力フィールドをデータ型に変換できない場合は、無効です。
  3. ControlToCompare によって参照される入力フィールドをデータ型に変換できない場合は、有効です。
  4. 入力フィールドはデータ型に変換され、比較されます。

3 番目のステップは、少し直感に反しているように見えるかもしれません。 この手順は、一度に複数のフィールドの有効性をチェックする場合に検証コントロールに意味のあるエラー メッセージを書き込むのが難しいため、この方法で動作します。 ControlToCompare 入力フィールドのエラー状態をレポートするには、別の検証コントロールを使用する必要があります。 RangeValidator は、その最大プロパティと最小プロパティと同様の方法で動作します。

Enabled プロパティ、Visible プロパティ、Display プロパティの効果

検証コントロールの Enabled プロパティ、 Visible プロパティ、 Display プロパティの違いはすぐには明らかでない場合があります。

Display=None を使用すると、何も直接表示されずに評価され、全体的な有効性に影響を与え、クライアントとサーバーの両方の概要にエラーが発生する可能性がある検証コントロールを指定できます。 クライアント側の検証では、これらの値によって、検証コントロールのオンとオフを切り替えるために可視性属性と表示スタイル属性のどちらを使用するかが決まります。 サーバー側の検証では、Display=Dynamic は入力が有効な場合は何も表示されませんが、Display=Static は 1 つの改行されていないスペース ("&nbsp") が出力されることを意味します。 この最後の動作は、検証コントロールのみを含むテーブル セルが有効な場合に何も折りたたまれていないように存在します。

Visible=false を使用して非表示の検証コントロールを作成しないのはなぜですか? ASP.NET では、コントロールの Visible プロパティは非常に強力な意味を持ちます。Visible=false のコントロールは、プリレンダリングやレンダリングのためにまったく処理されません。 このより強い意味の結果として、検証コントロールの Visible=false は、何も表示されないだけでなく、機能もないことを意味します。 評価されず、ページの有効性に影響せず、概要にエラーが含まれません。

ここでトレッド中央の地面を有効にしました。 ほとんどの場合、Enabled=false は Visible=false とまったく同じ効果を持ちます。 ただし、クライアント側の検証では、無効な検証コントロールは引き続きブラウザーに送信されますが、無効な状態になります。 クライアント スクリプトの ValidatorEnable 関数を使用してアクティブ化できます。

[表示] または [有効] を使用して検証を行うかどうかを制御する場合は、上記のサーバー上の一連のイベントに注意してください。 検証が行われる前に変更するか、後で再検証します。 それ以外の場合、 IsValid 値はプロパティの変更を反映しない可能性があります。

CustomValidator コントロール

検証フレームワークを拡張する最も簡単な方法は、CustomValidator コントロールを使用することです。 これは、別の検証コントロールで実行できる何かの対象ではない検証を実行したり、データベースや Web サービスなどのサーバー上の情報へのアクセスを必要とする検証を実行したりするために使用できます。

サーバー検証関数のみを定義して CustomValidator を追加すると、クライアント側の検証には含まれないことがわかります。 CustomValidator はフィールド間の [ユーザー] タブとして更新されず、検証を実行するにはサーバーへのラウンド トリップが必要です。 CustomValidator を使用して、サーバー上に存在する情報を必要としないチェックを実行する場合は、ClientValidationFunction プロパティを使用して検証コントロールをクライアント側の検証に完全に参加させることができます。 ClientValidationFunction を指定する場合は、サーバー検証ハンドラーとまったく同じチェックを実行するのが理想的であると想定されます。 失敗した場合は、その検証のサブセットを実行する必要があります。 ハッカーが簡単にバイパスできるため、サーバーで実行されるよりも多くの検証を行うクライアント検証関数を使用しないでください。

クライアントとサーバーで動作する CustomValidator の簡単な例を次に示します。この例では、入力が偶数であることを確認するだけです。 まず、(C#の) サーバー関数を次に示します。

protected void ServerValidate(object source, ServerValidateEventArgs args) {
    try { 
        int i = Int32.Parse(args.Value);
        args.IsValid = ((i % 2) == 0);
    } catch {
        args.IsValid = false;
    }        
}

同じチェックを実行するクライアント検証関数と共に、クライアントで宣言する方法を次に示します。 これは通常 JScript にありますが、Microsoft® インターネット エクスプローラーを対象としている場合は VBScript® でもかまいません。

<asp:CustomValidator id="CustomValidator1" runat="server" 
    ErrorMessage="Number not divisible by 2!" 
    ControlToValidate="txtCustomData" 
    OnServerValidate="ServerValidate" 
    ClientValidationFunction="CheckEven" /><br>
Input:
<asp:TextBox id="txtCustomData" runat="server" />
<script language="javascript">
<!--
function CheckEven(source, args) {
    var val = parseInt(args.Value, 10);
    if (isNaN(val)) {
        args.IsValid = false;
    }
    else {
        args.IsValid = ((val % 2) == 0);
    }
}
// -->
</script>

CustomValidator の使用に関して注意すべき点を次に示します。

  • 他のすべての検証コントロール (RequiredFieldValidator 以外) と同様に、入力フィールドが空白の場合は有効と見なされます。
  • 古いブラウザーの場合、またはクライアント検証がオフになっている場合、クライアント検証関数は呼び出されません。 関数を定義する前にブラウザー機能を自分でチェックする必要はありませんが、定義されているだけでスクリプト エラーが発生しないようにする必要があります。 例のように、常にクライアント コードを HTML コメントで囲みます。
  • サーバー関数に渡されるパラメーターに対応する 2 つのパラメーターがクライアント関数に渡されます。 1 つ目はクライアント検証コントロール要素で、2 つ目はサーバー上の引数と同等です。 検証する入力を含む Value プロパティと IsValid プロパティの 2 つがあり、これを更新して有効性を示すことができます。
  • ControlToValidate は空白のままにしておくことができます。 このモードでは、サーバー関数はラウンド トリップごとに常に 1 回起動し、クライアント関数は送信の試行ごとに常に 1 回起動します。 これを使用すると、CheckBoxList やスタンドアロン ラジオ ボタンなど、検証できないコントロールを検証できます。 また、条件が複数のコントロールに基づいており、ページ上のフィールド間のユーザー タブとして評価したくない場合にも役立ちます。
  • 複数のコントロールの変更イベントをフックすることもできます。 これを行うには、前述のクライアント関数 ValidatorHookupControl を呼び出すインライン スクリプトを用意します。

検証できるコントロールはどれですか?

検証コントロールで参照するには、コントロールに検証プロパティが必要です。 検証できるすべてのコントロールには ValidationPropertyAttribute があり、検証のために読み取る必要があるプロパティを示します。 独自のコントロールを記述する場合は、これらの属性のいずれかを指定して使用するプロパティを指定することで、検証に参加させることができます。

検証がクライアント側でも機能するためには、このプロパティは、クライアントでレンダリングされる HTML 要素の value 属性に対応している必要があります。 DataGrid や Calendar などの複雑なコントロールの多くは、クライアントに値を持たず、サーバーでのみ検証できます。 このため、HTML 要素に密接に対応するコントロールのみが検証に関与できます。 また、コントロールには、クライアントで 1 つの論理値が必要です。 これが RadioButtonList を検証できる理由ですが、CheckBoxList では検証できません。

それです

これはおそらく、ASP.NET 検証について知りたかった以上の機能です。 それを楽しんでください!

© Microsoft Corporation. All rights reserved.