深入讲解 ASP+ 验证

Anthony Moore
Microsoft Corporation
2000年10月
摘要：有关使用 ASP+ 验证 Web 控件的详细讲解。
目录

简介
入门
何时发生何事？
服务器端的验证序列
客户端的验证
有效性规则和有用的错误信息
Enabled、Visible 和 Display 属性的作用
CustomValidator 控件
哪些控件可以被验证？
到此为止

简介
这篇文章详细讲解了 ASP+ 验证控件的工作方式。如果要生成其中包含验证控件的复杂页面，或是要扩展验证框架，建议您阅读本文。如果要学习使用验证控件，或是要决定是否使用验证控件，请参见“ASP+ 中的用户输入验证（英文）”。

入门
我们知道，在整个 ASP+ 开发过程中，了解验证非常重要。看看如今的大多数商业 Web 站点，您会发现，这些站点中有许多表单，这些表单明显是通过执行大量手写的代码来执行验证。编写验证代码并不是一件有趣的工作。如果要通过编写代码来显示数据表或动态生成图表，可能会很吸引人，但是没有人可以向他的同事证实这种很“酷”的方法能够禁止在姓名字段中输入空值。
因为其它一些原因，Web 应用程序的验证也是非常麻烦的。HTML 3.2 对您可以控制的内容或可以从用户处得到的反馈的限制很多，因此无法应用在功能更全的客户机上可以使用的技巧，例如禁止用户输入某些字符，或发出嘀声。使用浏览器脚本可能会产生更强大的验证。但是这种方法很难得以证实，因为客户浏览器中并非一定有脚本，并且恶意的用户可以绕过。因此，为了保证站点安全，有必要对服务器进行同样的检查。
在开发 ASP+ 时，我们的初衷是只使用一个控件来处理验证，可能本该是一个能够显示错误的 TextBox 控件。可是到了设计该控件时，却发现无法实现这种愿望。我们研究了大量的数据输入表单，试图找到可以适用于尽可能多的表单的一种解决方案。我们发现，数据输入表单具有许多有趣的特性：
尽管错误信息或图标经常与输入元素相邻，但是它们几乎总是位于表的不同单元格中。
页面中经常会有一个区域来汇总所有错误。
许多站点包含客户端脚本，以便提供更快捷的反馈，同时防止白白地在与服务器之间往返。
许多包含客户端脚本的站点在出现错误时会显示信息框。
不仅会验证文本输入，还会验证下拉列表和单选按钮。
如果某个字段为空，站点通常会显示与该条目无效时不同的信息或图标。
许多有效性检查可以很好地代替常用的表达式。
验证通常是基于两个输入之间的比较结果。
90% 或 90% 以上的验证任务是一些常见的操作，例如检查姓名或邮政编码。大多数站点似乎仍在重复进行这些工作。
因为站点之间的差别通常太大，无法获得一种完美的解决方案来处理每个站点的所有验证任务。
考虑了上述所有情况，最终获得的解决方案包括五个验证器控件、ValidationSummary 控件以及与 Page 对象的集成。同时很明显，该解决方案需要扩展，在客户机和服务器上均需要有一个 API 来配合。
我们在研究进行的各种验证时发现，我们似乎需要一个更大的工具箱。在大多数组件环境中，例如 Microsoft® ActiveX®，我们可能本来试图将所有验证控件的功能集成到一个控件中，处理不同模式下的不同属性。不过，幸好 Microsoft® .NET 框架中有神奇的继承性，可以提供一套控件来对特定的属性进行特定的验证，因为派生每个新控件所需的额外工作量非常小。
这些控件所完成的大多数工作均在其公用的父级 BaseValidator 中实现。您也可以从 BaseValidator 或其它控件派生来完成各项工作。实际上，即使 BaseValidator 都懒得实现其自己的 Text 属性，而是从 Label 属性继承。

何时发生何事？
在处理包含验证 Web 控件的页面时，了解事件序列非常有效。如果某个验证条件是可选的，您需要准确了解客户机和服务器上何时进行验证。如果要自己编写验证例程，可能会非常耗时，或者有副作用。同时，了解调用验证例程的时机也很重要。
首先，让我们看一下服务器。

服务器端的验证序列
了解页面的有效期非常重要。如果习惯于在 Visual Basic 或类似功能齐全的客户机工具中处理表单，则需要花一定的时间来了解。页面和页面上的所有对象并非在与用户交互时一直有效，尽管有时表面上是这样。
以下是在第一次访问某个页面时一个简化的事件序列：
基于 ASPX 文件创建页面及其控件。
触发 Page_Load 事件。
页面和控件属性保存在一个隐藏字段中。
页面和控件转换到 HTML。
丢弃所有内容。
现在，当用户单击某个按钮或类似控件时，将返回服务器，然后执行一个类似的事件序列。该序列称为返回序列：
基于 ASPX 文件创建页面及其控件。
从隐藏字段恢复页面和控件属性。
根据用户输入更新页面控件。
触发 Page_Load 事件。
触发更改通知事件。
页面和控件属性保存在一个隐藏字段中。
页面和控件转换到 HTML。
再次丢弃所有内容。
我们为什么不将所有对象保留在内存中呢？因为使用 ASP+ 建立的 Web 站点无法处理数量非常大的用户。因此，服务器的内存中只保留马上要处理的内容。
何时进行服务器端验证？在第一次获取页面信息时，根本不会进行服务器端验证。大多数最终用户都非常认真，我们允许用户自己确认在表单中填写的信息是否正确，然后我们再使用红色的文字通知用户填错的信息。
在返回事件序列中，第 3 步和第 4 步之间会进行验证。也就是说，进行验证是在来自用户的数据装回控件属性后，但在大多数代码执行之前。这意味着在编写用户事件代码时，通常可以利用已经进行的验证。一般情况下，您都会希望这样做。
在该时刻进行验证的缺点是：如果您要通过编程来修改某些影响该验证的属性，该时刻就太迟了。例如，您会发现，如果通过编写代码来启用或禁用验证控件或更改验证控件的属性，在下一次处理该页之前，不会看到任何影响。通过以下两种方法可以避免这个问题：
在进行验证之前修改属性。
在属性更改之后重新验证控件。
这两种方法均需要使用在 Page 对象上有效的验证属性和方法。
页面 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();
}

如果有 Beta 1 版或更高版本，也可以只对 Page 对象调用 Validate 方法，这样可以完成相同的任务。要在验证前进行某些更改，可以覆盖 Validate 方法。本例显示一个包含验证器的页面，其中的验证器根据复选框的值开或关：

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

protected override void Validate() {
//只检查到货地址（如果与付款地址不同）
bool enableShip = !chkSameAs.Checked;
rfvalShipAddress.Enabled = enableShip;
//现在执行验证
base.Validate();
}
}

客户端的验证
如果您的页面启用了客户端验证，则在往返过程中会发生完全不同的事件序列。客户端的验证使用客户端 JScript® 实现。实现该验证不需要任何二进制组件。
尽管 JScript 语言的标准化做得很好，但是用于与浏览器中的 HTML 文档交互的文档对象模型 (Document Object Model, DOM) 没有广泛采用的标准。因此，客户端的验证只在 Internet Explorer 4.0 和更高版本中进行，因为该验证的对象是 Internet Explorer DOM。
从服务器的角度来说，客户端的验证只意味着验证控件将不同的内容发送到 HTML 中。除此之外，其事件序列完全相同。服务器端的检查仍然执行。尽管看起来似乎多余，但是却十分重要，因为：
某些验证控件可能不支持客户端脚本。有一个很好的例子：如果要同时使用 CustomValidator 和服务器验证函数，但是没有客户机验证函数。
安全性注意事项。某些人可以很容易得到一个包含脚本的页面，然后禁用或更改该页面。您不应利用脚本来阻止坏数据进入您的系统，而只应是为了用户得到更快的反馈。因此，如果要使用 CustomValidator，则不应提供没有相应服务器验证函数的客户机验证函数。
每个验证控件都可以确保将一个标准的客户端脚本块发送到页面中。实际上，这只是一小部分代码，其中包含对脚本库 WebUIValidation.js 中的代码的引用。这个脚本库文件包含客户端验证的所有逻辑，该文件需单独下载，并且可以存储在浏览器的缓存中。
关于脚本库
因为验证 Web 控件脚本在脚本库中，所以不必将所有客户端验证的代码直接发送到页面中，尽管表面上似乎是这样做的。主要的脚本文件引用类似如下所示：

<script language="javascript"
src="/_aspx/1.0.9999/script/WebUIValidation.js"></script>

默认情况下，脚本文件将安装在 "_aspx" 目录中默认的根目录下，并使用相对于根的脚本 include 指令调用，该指令以正斜线开头。该引用表明每个单独的对象不必包含脚本库，同一台计算机上的所有页面可以引用同一个文件。您会注意到，该路径中还有一个公用的语言运行时版本号，以便不同的运行时版本可以在同一台计算机上运行。
如果查看一下您默认的虚拟根目录，您会找到该文件并查看其中的内容。这些文件的位置在 config.web 文件中指定。config.web 文件是一个用于大多数 ASP+ 设置的 XML 文件。以下是该文件中位置的定义：

<webcontrols
clientscriptslocation="/_aspx/{0}/script/"
/>

鼓励您阅读该脚本，以便深入了解发生的事件。不过，建议您不要修改这些脚本，因为它们的功能与特定的运行时版本紧密相连。在运行时版本更新时，这些脚本可能也需要相应的更新，您将或者放弃更改，或者面临脚本不工作的问题。如果特定项目必须更改这些脚本，先备份这些脚本，然后将您的项目指向备份文件，方法是使用私有的 config.web 文件替代这些文件的位置。如果字符串中包含格式指令 "{0}"，运行时版本号将替换该指令。最好将该位置更改为一个相对引用或绝对引用。
禁用客户端的验证
有时您可能不希望进行客户端验证。如果输入字段的数目很少，客户端验证可能用处不大。您毕竟每次都要有一个需要往返服务器一次的逻辑。您会发现客户机上动态出现的信息对您的布局会有负面影响。
要禁用客户端验证，应使用 Page 指令 "clienttarget=downlevel"。该指令类似以下 ASPX 文件的开头：

<%@ Page Language="c#" clienttarget=downlevel %>

该指令的默认值为 "auto"，表示您只对 Microsoft Internet Explorer 4.0 或更高版本进行客户端验证。 注意：   不幸的是，在 Beta 1 中，该指令并非仅仅是禁用验证，同时还会使所有 Web 控件使用 HTML 3.2 标记来处理，这可能会产生意想不到的结果。最终版本提供了更好的方法来控制这个问题。
客户端事件序列
该序列是在运行包含客户端验证的页面时发生的事件序列：
在页面载入浏览器时，需要对每个验证控件进行一些初始化。这些控件作为 <span> 标记发送，其 HTML 特性与服务器上的特性最接近。最重要的是，此时会将验证器引用的所有输入元素“挂接”。被引用的输入元素将修改其客户端事件，以便在每次输入更改时调用验证例程。
脚本库中的代码将在用户使用 tab 键在各字段之间切换时执行。某个独立的字段更改时，将重新评估验证条件，根据需要使验证器可见或不可见。
当用户尝试提交表单时，将重新评估所有验证器。如果这些验证器全部有效，表单将提交给服务器。如果存在一处或多处错误，则会出现下述情况： 提交被取消。表单并不提交给服务器。
所有无效的验证器均可见。
如果某个验证摘要包含 ShowSummary=true，则将收集来自验证控件的所有错误，并使用这些错误更新其内容。
如果某个验证摘要包含 ShowMessageBox=true，则将收集错误，并在客户机的信息框中显示这些错误。

因为在每次输入更改时或提交时会执行客户端验证控件，所以在客户机上通常会评估这些验证控件两次或两次以上。请注意，提交后，仍将会在服务器上对这些验证控件进行重新评估。
客户端 API
有一个可以在客户机上使用的小型 API，以便在您自己的客户端代码中实现各种效果。因为某些例程不可能隐藏，所以理论上讲，您可以利用客户端验证脚本所定义的所有变量、特性和函数。不过，其中许多都是可以更改的实施细节。以下总结了我们鼓励您使用的客户端对象。
表 3. 客户端对象

名称	类型	说明
Page_IsValid	Boolean 变量	指出页面当前是否有效。验证脚本总是保持该变量为最新。
Page_Validators	元素数组	这是包含页面上所有验证器的数组。
Page_ValidationActive	Boolean 变量	指出是否应进行验证。将此变量设置为 False 可以通过编程关闭验证。
isvalid	Boolean 属性	每个客户端验证器均具有该属性，指出验证器当前是否有效。请注意，在 PDC 版本中，该属性混用大小写 ("IsValid")。

绕过客户端验证
您经常需要执行的一项任务是在页面上添加“取消”按钮或导航按钮。在这种情况下，即使页面上有错误，您可能也希望使用该按钮提交页面。因为客户端按钮 "onclick" 事件在表单的 "onsubmit" 事件之前发生，因此可能会避免提交检查，并绕过验证。以下说明如何使用 HTML Image 控件作为“取消”按钮完成该任务：

<input type=image runat=server
value="取消"
onclick="Page_ValidationActive=false;"
OnServerClick=cmdCancel_Click >

使用 Button 或 ImageButton 控件执行该任务会出现一些混淆，因为 "onclick" 事件假定为同名的服务器端事件。您应在客户端脚本中设置该事件：

<asp:ImageButton runat=server id=cmdImgCancel
AlternateText="取消"
OnClick=cmdCancel_Click/>

<script language="javascript">
document.all["cmdImgCancel "].onclick =
new Function("Page_ValidationActive=false;");
</script>

解决该问题的另一种方法是：对“取消”按钮进行一定的设置，使其在返回时不会触发客户端脚本中的提交事件。HtmlInputButton 和 LinkButton 控件就是这样的例子。
特殊效果
另一种常见的要求是：在出错时，除了由验证器自身显示的错误信息外，还需要其它一些效果。在这种情况下，您所作的任何修改均需在服务器或客户机上同时进行。假设您需要加入一个 Label，根据输入是否有效来更改颜色。以下是如何在服务器上实现该任务：

public class ChangeColorPage : Page {
public Label lblZip;
public RegularExpressionValidator valZip;

protected override void OnLoad(EventArgs e) {
lblZip.ForeColor = valZip.IsValid? Color.Black : Color.Red;
}
}

上述方法一切都很完美，但是，只要您如上所述修改验证，就会发现除非您在客户机上进行了相同的操作，否则看起来会非常不一致。验证框架会使您避免许多这种双重效果，但是无法避免您必须在客户机和服务器上同时实现的其它效果。以下是在客户机上执行同一任务的片段：

<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="无效的邮政编码"
ValidationExpression="[0-9]{5}" /><br>

<script language=javascript>
function txtZipOnChange() {
//如果客户端验证未处于活动状态，则不执行任何操作
if (typeof(Page_Validators) == "undefined")  return;
//更改标签的颜色
lblZip.style.color = valZip.isvalid ? "Black" : "Red";
}
</script>

Beta 1 客户端 API
对于 Beta 1 版，一些可以从客户端脚本调用的函数会造成其它一些情况。
表 4. 从客户端脚本调用的函数

名称	说明
ValidatorValidate(val)	将某个客户端验证器作为输入。使验证器检查其输入并更新其显示。
ValidatorEnable(val, enable)	获取一个客户端验证器和一个 Boolean 值。启用或禁用客户端验证器。如果禁用，将不会评估客户端验证器，客户端验证器将总是显示为有效。
ValidatorHookupControl(control, val)	获取一个输入 HTML 元素和一个客户端验证器。修改或创建该元素的 change 事件，以便在更改时更新验证器。该函数适合于基于多个输入值的自定义验证器。

其特殊用途是启用或禁用验证器。如果您希望验证只是在特定的情况下生效，可能需要在服务器和客户机上同时更改激活状态，否则，您会发现用户无法提交该页面。
以下是上面的示例加上一个字段，该字段只在取消选中某个复选框时才会进行验证。

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

以下是客户端等效的代码：

<input type=checkbox runat=server id=chkSameAs
onclick="OnChangeSameAs();" >与付款地址相同<br>
<script language=javascript>
function OnChangeSameAs() {
var enableShip = !event.srcElement.status;
ValidatorEnable(rfvalShipAddress, enableShip);
}
</script>

有效性规则和有用的错误信息
每个验证器会显示有关特定控件特定情况的特定错误信息。其中有一些确认是否有效的规则，开始，您作为一个开发人员可能会有些混淆，但是如果要生成对用户有实际帮助的错误信息，这些规则是必要的。
所有空的验证器（除了 RequiredFieldValidator）均会被认为有效。如果某个空值无效，您通常需要一个 RequiredFieldValidator 和一个其它验证器。您需要这样做，因为一般情况下，您总是希望对空验证器和有效性显示不同的错误信息。您也可以使用不明确的信息，例如“您必须输入一个值，并且该值必须在 1 和 10 之间”。
在输入字段无法转换为指定数据类型时使用的另一个特殊规则与 CompareValidator 和 RangeValidator 有关。对指定了 ControlToCompare 的 CompareValidator 进行的有效性评估过程类似如下所述：
如果 ControlToValidate 引用的输入字段为空，则有效。
如果 ControlToValidate 引用的输入字段无法转换成所需数据类型，则无效。
如果 ControlToCompare 引用的输入字段无法转换成所需数据类型，则有效。
输入字段转换成所需数据类型并进行比较。
第三步看起来有些不符合直觉。之所以这样评估，是因为如果验证器同时检查多个字段的有效性，很难为该验证器写出有意义的错误信息。应使用一个独立的验证器来报告 ControlToCompare 输入字段中的错误情况。RangeValidator 的工作方式类似，具有 maximum 和 minimum 属性。

Enabled、Visible 和 Display 属性的作用
验证器的 Enabled、[b]Visible 和 Display[/b]、Visible 和 Display 属性之间的区别可能不是非常明显。
Display=None 可以用来指定验证器不直接显示任何内容，但是仍然进行评估，仍然影响总体的有效性，并且仍可以将错误放在客户机和服务器上的摘要中。对于客户端验证，这些值确定使用可见性样式特性还是使用显示样式特性来打开或关闭验证器。对于服务器端验证，Display=Dynamic 表示输入有效时不显示任何内容，而 Display=Static 表示显示一个不换行的空格 (" ")。使用最后一个设置是为了表中只包含验证器的单元格在有效时，不会折叠成不显示任何内容。
为什么不只使用 Visible=false 使验证器不可见呢？在 ASP+ 中，控件的 Visible 属性有许多含义：Visible=false 的控件根本不会被处理来预显示或显示。正是因为这种含义，验证器的 Visible=false 意味着不仅不会显示任何内容，而且无法使用。不会对这样的验证器进行评估，不会影响页面的有效性，也不会将错误放在摘要中。
Enabled 则为中性。对于大多数情况，Enabled=false 与 Visible=false 的效果完全相同。在 Beta 1 版或更高版本中，存在一个重要的区别：在客户端验证中，禁用的验证器仍会发送到浏览器中，但是处于禁用状态。您可以使用客户端脚本中的 ValidatorEnable 函数激活该验证器。
使用 Visible 或 [b]Enabled[/b] 或 Enabled 控制是否进行验证时，应注意上述服务器上的事件顺序。或者在验证之前进行更改，或者在更改之后重新验证。否则，它们的 IsValid 值不会将更改反映到属性上。

CustomValidator 控件
扩展验证框架最简单的方法是使用 CustomValidator 控件。该控件既可以用来执行其它验证控件无法进行的验证，也可以执行需要访问服务器上信息（例如数据库或 Web 服务）的验证。
如果添加了只定义一个服务器验证函数的 CustomValidator，您会注意到，该验证器并不参与客户端验证。当用户使用 tab 键在各字段之间切换时，CustomValidator 不会更新，并且需要往返服务器一次以执行其验证。如果要使用 CustomValidator 执行不需要任何服务器上信息的检查，您也可以使用 ClientValidationFunction 属性让验证器完全参与客户端验证。假设您提供了一个 ClientValidationFunction，理想情况下，应与服务器验证处理程序执行完全相同的检查。但实际上，只是执行该验证的一部分。客户端验证函数进行的验证不要超过在服务器上执行的验证，因为黑客很容易绕过该验证函数。
以下是在客户机和服务器上使用 CustomValidator 的一个简单示例，只检查输入是否是偶数。以下先介绍服务器函数（在 C# 中）：

public bool ServerValidation(object source, string value) {
try {
int i = int.FromString(value);
return ((i % 2) == 0);
} catch {
return false;
}
}

以下是该函数在客户机上的声明方法，以及一个执行相同检查的客户端验证函数。这通常是 JScript 形式，不过如果您的目标是 Microsoft® Internet Explorer，也可以使用 VBScript® 形式。

<asp:CustomValidator id="customVal2" runat=server
ErrorMessage="数字不可以被 2 除！"
ControlToValidate="txtCustomData"
OnServerValidationFunction=ServerValidation
ClientValidationFunction="CheckEven" /><br>
Data Field : <asp:TextBox id="txtCustomData" runat="server" />
<script language=javascript>
<!--
function CheckEven(source, value) {
var val = parseInt(value, 10);
if (isNaN(val))
return false;
return ((val % 2) == 0);
}
// -->
</script>

以下是使用 CustomValidator 的一些注意事项：
与所有其它验证控件类似（RequiredFieldValidator 除外），如果输入字段为空，则认为 CustomValidator 有效。
如果使用较旧的浏览器，或者关闭了客户端验证，将无法调用客户端验证函数。在定义该函数之前，您不必检查所用浏览器的功能，但是需要确保浏览器不会因为定义而造成脚本错误。一定要使您的客户端代码作为 HTML 注释，如下例所示。
两个参数传递到您的客户端函数中，与传递给服务器函数的参数对应。第一个是客户端验证器元素，第二个是 ControlToValidate 指定的控件值。不过，在客户机上，您可以选择不为函数定义参数，这样也会正常工作。
如果使用 Beta1 版或更高版本，您可以保留 ControlToValidate 为空。在该模式中，服务器函数每次往返总会触发一次，客户端函数每次尝试提交时总会触发一次。您可以使用该特性来验证其它方法无法验证的控件，例如 CheckBoxList 或单独的单选按钮。如果条件是基于多个控件，并且您不希望用户使用 tab 键在页面上各字段之间切换时评估该条件，可以使用该方法。
Beta 1 版或更高版本中的另一个选项是挂接多个控件的 change 事件。方法是加入一些调用客户端函数 ValidatorHookupControl 的内嵌脚本，如上所述。

哪些控件可以被验证？
要使控件可以被验证控件引用，该控件必须具有验证属性。所有可以验证的控件均具有 ValidationPropertyAttribute 属性，该属性指明验证时应读取的属性。如果编写自己的控件，可以通过提供其中一个特性来指定要使用的属性，从而使该控件参与验证。
要使验证可以在客户端正常进行，该属性必须与客户端显示的 HTML 元素的 value 特性对应。许多复杂的控件（例如 DataGrid 和 Calendar）在客户端没有值，只能在服务器上进行验证。因此，只有最接近 HTML 元素的控件才可以参与验证。此外，控件必须在客户端具有单个逻辑值。因此，RadioButtonList 可以被验证，但是 CheckBoxList 不可以。

到此为止
上述对 ASP+ 验证的讲解可能已经超过了您要了解的内容。尽情享用吧！