ASP.NET 验证器清晰解读






4.92/5 (45投票s)
2003年3月31日
23分钟阅读

402160

3097
揭开神秘的 ASP.NET 验证控件的神秘面纱,实现 Web Forms 的快速无痛验证。
引言
无论您从事何种开发,用户输入验证始终是一个重要且经常令人头疼的问题。
什么数据需要验证?有效条件是什么?我们需要一次报告所有错误,还是允许用户一次纠正一个错误?我们是在客户端还是服务器端进行验证?问题不断。
更糟糕的是,代码很快就会变得难以管理,特别是当我们试图一次性验证所有内容时。嵌套的 if 语句,解构字符串,构建错误消息列表,无休止的注释试图理清头绪。
我个人认为,除了我之外,任何人都可能更新的所有内容都应该在每次有机会时进行验证,并且我们应该始终一次性验证所有内容。但这并不意味着我从未在紧迫的截止日期下试图回避问题。
在某些方面,对于网页开发者来说可能会更糟。尽可能在客户端进行验证以节省带宽很重要,但 HTTP 请求很容易伪造;如果您想要任何形式的安全性,相同的数据需要在服务器上再次验证。
如果客户希望您标记无效字段然后将错误列在一个地方(网页设计中常见的用户友好约定),则可能会出现另一个问题。
很难想象有人喜欢编写验证代码,对于经典的 ASP 开发者来说更是如此。值得庆幸的是,.NET 框架通过引入六个包罗万象且对开发者友好的验证控件,大大缓解了 ASP.NET 开发者的问题。
RequiredFieldValidator(必填字段验证器) |
确保必填字段已填写。 |
CompareValidator |
将一个控件与另一个控件或与文字进行比较。 |
RangeValidator(范围验证器) |
检查数据是否在给定范围内。 |
RegularExpressionValidator |
用于数据必须匹配给定正则表达式格式的情况。 |
CustomValidator(自定义验证器) |
使用自定义验证函数验证控件。 |
ValidationSummary |
整理整个表单的验证结果。 |
本文假设您具备向 Web 表单添加控件以及设置属性和事件处理程序的基本知识。它旨在概述这些控件以及如何使用它们来执行简单的实际任务。
所有示例都使用 C# 和 GridLayout
页面。但本文中的任何内容都应该很容易转换为 VB.NET 和/或 FlowLayout
页面。
BaseValidator 控件
除 ValidationSummary
外,所有上述控件都派生自 BaseValidator
类,并共享一些功能。
前四个验证控件专为特定目的而设计,旨在在客户端和服务器上验证相同条件。每个控件都会生成一些特定用途的 JavaScript(使用 aspnet_client Web 中的 WebUIValidation.js),以根据给定验证控件旨在处理的条件来验证您指向的输入控件。
CustomValidator
允许您使用客户端、服务器或两者上的事件处理程序定义自己的验证例程。
实际的客户端验证在您正在验证的控件值发生变化以及您尝试提交表单时触发的事件中进行。服务器端验证在您回发表单时进行,并且可以使用 Form
类的 .IsValid
属性访问验证结果。
每个控件的属性看起来都相当相似。除了标准字体和格式属性之外,每个标准控件都具有以下从 BaseValidator
派生的通用属性
.ControlToValidate |
我们正在验证的控件名称。 |
.ErrorMessage |
与无效条件相关的错误消息。 |
.Text |
如果无效,此控件中显示的文本。 |
.EnableClientScript |
客户端和服务器端验证。 |
.IsValid |
此控件的验证结果 |
ControlToValidate
一个 string
,包含验证控件将检查的 Control
对象的名称。此控件必须使用 ValidationPropertyAttribute
进行开发。
在标准控件中,唯一标记有 ValidationProperty
的是
文本框
ListBox
DropDownList
RadioButtonList
HtmlInputText
HtmlInputFile
HtmlSelect
HtmlTextArea
如果您正在开发可能需要验证的控件,这一点值得牢记。您应该始终在类定义前加上 [ValidationProperty("MyProperty")]
(其中 MyProperty
是用户输入可更改的属性的名称,通常是文本)。
ErrorMessage
这定义了与无效条件相关的消息。此消息可以显示在控件本身中,或传递给 ValidationSummary
控件。
文本
当条件无效时,要在控件中显示的文本。如果留空,控件将显示 ErrorMessage
文本。
如果 .ErrorMessage
和 .Text
之间的区别令人困惑,请继续阅读。当我们检查 ValidationSummary
控件时,它应该会变得清晰。在此之前,我们只使用 .ErrorMessage
属性(.Text
应留空)
EnableClientScript
默认情况下,此属性设置为 true
,.ControlToValidate
将在客户端和服务器端进行两次验证。
如果 .EnableClientScript
属性设置为 false
,则验证将仅限于服务器端。
IsValid
唯一不可用于 WebForm 设计器的属性 .IsValid
在表单验证完成后包含此控件的验证结果。
如果您希望在页面只有一部分无效时做出不同的反应,这会很有用。
示例
以下部分将引用一个非常简单的示例。如屏幕截图所示,此示例将包含一个单一的 TextBox
进行验证。您知道那种情况:在这里留下您的电子邮件地址,我们将免费向您发送一些非常好的东西。(然后将您的电子邮件地址出售给五百个垃圾邮件发送者)
创建一个 Web 表单,只包含一个 Label
(“电子邮件地址:”),一个空的 TextBox
,一个提交 Button
和我们正在查看的任何 -Validator 控件。(参见示例图片)
ControlToValidate
属性应始终指向 TextBox
,ErrorMessage
应包含与我们正在进行的验证相关的内容。
在 Button_Click
处理程序中包含一些代码,以便在单击按钮时重定向到另一个页面,但前提是页面有效。例如
private void myButton_Click(object sender, System.EventArgs e)
{
if (this.IsValid)
Response.Redirect("anvokay.aspx", true);
}
或者……如果您感到懒惰,您可以下载页面顶部的示例代码,并将其解压缩到新的或现有的 Web 应用程序中。
注意:Web 浏览器和 .NET 框架之间的交互存在一个奇怪的行为怪癖,这意味着如果您在单 TextBox
表单中按 Enter,它将回发到服务器,但 Button_Click
处理程序不会执行。
这显然是一个遗留的浏览器问题,对于单个文本框表单,按钮名称不会作为响应的一部分发送,导致 .NET 不知道是什么触发了回发。
可能的解决方法是
- 始终物理单击提交按钮,而不是按 Enter 键。
- 包含第二个什么也不做的
TextBox
,只是为了避免此“功能”。 - 下载并使用 MetaBuilders 的默认按钮控件,安全地将提交按钮与
TextBox
的 Enter 键关联起来。
(感谢 Andy Smith 帮助我理解这一点)
RequiredFieldValidator(必填字段验证器)
顾名思义,RequiredFieldValidator
通常用于验证必填字段是否已填写。它也可以自定义,以便空白是有效响应,而其他一些文本表示未输入任何内容。
RequiredFieldValidator
只有一个唯一的属性
.InitialValue |
将此文本视为“未更改”,将空白视为“已更新”。 |
示例
使用 RequiredFieldValidator
验证我们的简单表单,如上面的示例图所示。如果您在不输入任何文本的情况下单击提交按钮,您会看到表单不会回发到服务器,客户端的 JavaScript 会捕获错误并显示您提供的错误消息。
如果您将 .EnableClientScript
设置为 false
并再次运行应用程序,那么您将看到提交按钮现在会强制回发,但该字段仍然会经过验证,因此如果恶意用户尝试伪造 HTTP 请求以绕过您的验证,它将不会成功。
就是这样。您现在已经成功地使用一个控件和一行代码(if (this.IsValid)
)实现了 ASP.NET 验证。这有多容易?
InitialValue
.InitialValue
属性让您有机会在 TextBox
中输入一些文本,并仍然确保在提交之前对其进行编辑。
尝试将 RequiredFieldValidator.InitialValue
和 TextBox.Text
都更改为“EMAIL ADDRESS”并再次运行应用程序。
您应该会发现,如果您不更改此文本而只是点击“提交”,您将收到指定的错误消息,但现在如果您清空该字段,则将其视为有效。
在许多方面,这与 CompareValidator
的功能重叠,稍后将变得清晰。但在某些情况下,使用 RequiredFieldValidator
更合理(即更具可读性)——例如,验证 DropDownList
是否已从“请选择一个...”的默认值更改。
BaseCompareValidator 控件
CompareValidator
和 RangeValidator
都将值与文字或用户输入的其他数据进行比较。这两个控件不可避免地包含一些共同的功能,因此都派生自 BaseCompareValidator
类。
BaseCompareValidator
除了 BaseValidator
类提供的属性外,只为我们提供了一个属性
.Type |
允许精确比较特定格式的字符串。 |
然而,这个属性非常重要,并且包含一些您可能需要注意的“陷阱”。
类型
.Type
属性可用于定义字符串的处理方式。如果文本框用于数字、日期或货币值,您可以使用 BaseCompareValidator
控件之一来验证输入的数据类型或更准确地将其与相同类型的值进行比较。
例如:如果直接作为字符串比较,“90”大于“100”;但如果作为数字比较,“90”显然小于“100”。
但请注意,客户端和服务器验证都将使用服务器机器的区域设置处理输入数据,除非您设置页面或应用程序的 Culture
/UICulture
属性(请参阅 MSDN 中的全球化)。
如果您不设置 Culture
,并且像我一样,您主要在英语区域设置机器(日期格式:DD/MM/YYYY)上进行开发,然后将您的网站部署到美国区域设置服务器(日期格式:MM/DD/YYYY)上,那么,如上面的屏幕截图所示,数据在开发环境中与生产环境中的验证方式将不同。
毕竟,无论您来自哪个国家,1月10日都在10月1日之前。
在您的页面上注明用户预期使用的格式总是值得的(记住 YYYY/MM/DD 被认为是文化独立的),但您将事情做得越傻瓜化,互联网上出现的傻瓜就越多。您无法保证用户会注意说明,即使您要求使用 YYYY/MM/DD,仍然会有人尝试使用 MM/DD/YYYY,甚至没有怀疑您的机器具有英语区域设置。
强烈建议您始终(即使您在生产机器或非常相似的机器上进行开发)在 Web.Config 文件中指定 Culture
,例如
<configuration>
<system.web>
<!-- Other settings here -->
<globalization
requestEncoding="utf-8"
responseEncoding="utf-8"
culture="en-US"
uiCulture="en-US" />
</system.web>
</configuration>
一旦您完成了这一点,您就确切地知道您处于什么位置。您可以以 MM/DD/YYYY 格式请求日期,如果用户选择忽略它并使用文化无关的样式,那么就没有坏处。
如果您甚至在 @Page
子句中也没有指定文化,那么在与文字进行比较时需要特别小心,这可能在开发与生产环境中处理方式不同(事实上,如果区域设置不同且值变为无效,可能会导致异常)。然后,您必须对文字日期使用文化无关的样式。
所有这些同样适用于将逗号(,)作为小数点的国家/地区的数字以及使用不同货币符号的系统。
另一件需要注意的事情是,如果任何被比较的值不是验证所期望的类型(在日期的情况下,这包括 DD-MMM-YYYY,例如 10-Jan-2003),表单数据将被视为有效。这样做的原因是,一个额外的 CompareValidator
(使用下面描述的 DataTypeCheck
运算符)为您提供了一种摆脱困境的方法,并且您通常会期望错误消息是不同的。
CompareValidator(比较验证器)
CompareValidator
乍一看是标准验证控件中最不实用的。然而,它确实有其用武之地,并且拥有大量设计器属性(包括 BaseCompareValidator.Type
属性,见上文),可以以有趣的方式调整其功能。
.ControlToCompare |
将此控件中的值与另一个控件的值进行比较。 |
.Operator |
我们应该以何种方式比较这些值? |
.ValueToCompare |
将值与文字值进行比较。 |
示例
在简单示例中,我们可以使用此控件确保没有人使用表单中的特定电子邮件地址(我的意思是,我们不希望有人为我们自己的垃圾邮件骗局注册我们,对吧?)。
用 CompareValidator
替换 RequiredFieldValidator
;将 .Operator
设置为 NotEqual
(为什么 Equal
会是默认值超出我的理解!)并将 .ValueToCompare
设置为您自己的电子邮件地址。当然,不要忘记像以前一样设置 .ControlToValidate
和 .ErrorMessage
属性。
当您运行应用程序并尝试在表单中输入您自己的电子邮件地址时,验证器应该在您离开 TextBox
后立即给您一条消息。它还应该拒绝让您将表单提交到服务器。
正如之前指出的,这本身并不是完全有用的;对于您会使用它的极少数情况,您不会介意修改 RequiredFieldValidator
以满足您的要求。
只有当您开始考虑上面列出的独特属性的组合时,您才会意识到它的强大之处。
ControlToCompare
除了将控件与文字值进行比较之外,您还可以将其与另一个用户输入的字符串进行比较。您可以通过将 .ControlToCompare
属性指向您希望验证的控件来完成此操作。
如果同时设置了此属性和 .ValueToCompare
,则 .ValueToCompare
将被忽略。
运算符
不仅可以比较值的相等性(或不相等性),还可以查找 GreaterThan
(大于)、GreatThanEqual
(大于等于)、LessThan
(小于)或 LessThanEqual
(小于等于)。
在所有情况下,如果条件为真,则 .ControlToValidate
被视为有效。
或者,您甚至可以使用此属性中的 DataTypeCheck
值检查输入数据是否可以转换为特定类型。正如上面所指出的,这是必不可少的,因为包含无效值的比较将始终被视为有效。
例如,当比较两个日期时,如果将“F”与“01/01/2003”进行比较,则它同时被认为是大于、小于和等于。但当使用 CompareValidator
检查“F”,其中 .Operator = DataTypeCheck
且 .Type = Date
时,验证将失败。
当使用 .Operator = DataTypeCheck
时,.ValueToCompare
和 .ControlToCompare
属性都被忽略,并且 .Type
属性用于定义有效类型。
RangeValidator(范围验证器)
RangeValidator
非常类似于 CompareValidator
控件(因此它们有共同的基类),不同之处在于它验证用户数据是否落在两个常量值之间,而不是将其与单个值(常量或变量)进行比较。
考虑到这一点,该控件的唯一属性(不属于 BaseCompareValidator
)与您预期的大致相同。
.MaximumValue |
值不能大于此值。 |
.MinimumValue |
值不能小于此值。 |
示例
参照我们的简单表单,我们可以轻松使用 RangeValidator
来验证输入的电子邮件地址是否以小写字母字符开头。当然,这对电子邮件地址来说不是很多验证,但它是 RangeValidator
的一个很好的演示。
用 RangeValidator
替换您正在使用的任何验证器,并像任何验证器一样设置 .ControlToValidate
和 .ErrorMessage
。然后将 .MinimumValue
设置为 a
,将 .MaximumValue
设置为 z
。
现在,任何以小写字母字符开头的字符串都将被视为有效。请再次注意,如果 TextBox
留空,它仍然被视为有效。如果该字段是强制性的,则必须使用单独的 RequiredFieldValidator
。
MaximumValue
用户输入的值不能大于此值,但这两个值可以相等。
MinimumValue
用户输入的值不能小于此值(除非为空),但这两个值可以相等。
RegularExpressionValidator(正则表达式验证器)
可以说,ASP.NET 验证武器库中最大、最通用的武器非 RegularExpressionValidator
莫属。
仅比 BaseValidator
类多一个自定义属性,就能开启一个充满各种可能的世界。
.ValidationExpression |
值必须符合描述的格式。 |
示例
在我们的简单示例中,将当前的验证器替换为 RegularExpressionValidator
,并像往常一样设置 .ControlToValidate
和 .ErrorMessage
。
将 .ValidationExpression
设置为 \w+([-+.]\w+)*@\w+([-.]\w+)*\.\w+([-.]\w+)*
。如果您正在使用 Visual Studio .NET,您可以点击属性旁边的省略号 (...) 按钮,然后从默认列表中选择 Internet Email Address
。
尽管电子邮件地址验证并不完美(见下文),但这已经是一个相当好的近似值了。它确保地址只包含“单词”字符(A-Z、a-z、0-9、_),并且正好有一个 @ 符号,其后至少有一个句点(.),同时允许包括单词中带有连字符以及 @ 符号前后有额外句点的变体。
再次注意,除非您还使用 RequiredFieldValidator
,否则空白字段始终有效。而且,与所有验证控件一样,无需编写代码即可在客户端和服务器上执行相同的验证。
ValidationExpression
输入的数据(如果非空白)必须与正则表达式格式中指定的格式匹配。
本文不会详细介绍正则表达式,关于此主题,本网站和其他地方已有很多文章。
坦率地说,我不敢声称自己对它理解得有多好,我通常使用 Visual Studio .NET 提供的默认值或通过 Google 找到的其他表达式(如果您仔细寻找,会发现一些非常有趣的表达式)。
Visual Studio .NET 的默认值可以通过属性(在属性表内)右侧的省略号 (...) 按钮找到,并提供以下验证:
美国/法国/德国/日本/中国电话号码
美国/法国/德国/日本/中国法国邮政编码
美国/中国电话号码
互联网电子邮件地址
互联网 URL
这里有一些令人惊讶的遗漏(某些国籍、美国州缩写、ISBN、信用卡、长日期格式),并且一些默认表达式(包括电子邮件地址)并非 100% 准确。
正则表达式库是我找到的关于那些缺失的和改进现有正则表达式的最佳资源。
如果任何人有其他资源,我很乐意在下次更新时列出它们。
CustomValidator(自定义验证器)
迟早(老实说,很可能更迟),您需要验证某些内容,而标准验证器无法提供。也许您需要访问数据库,或者执行涉及多个控件的复杂验证。
如果您需要重复执行此操作,您可能需要考虑创建自己的验证控件,但对于一次性的特殊情况,您可以使用 CustomValidator
。
CustomValidator
允许您添加要在客户端和/或服务器上运行的代码,并设置一个显示结果的值。
您可以填充 .ControlToValidate
属性,将控件的值传递给事件处理程序或脚本。但是,与其他验证控件不同,如果 .ControlToValidate
为空,CustomValidator
不会抛出异常。
除此之外,它的行为与任何其他验证控件完全相同,要么在控件本身中显示 .ErrorMessage
,要么将其传递给 ValidationSummary
控件。
CustomValidator
只有一个独特的属性和一个独特的事件处理程序。
.ClientValidationFunction |
验证时要执行的 HTML 脚本函数的名称 |
.ServerValidate |
服务器端验证的事件处理程序。 |
示例
再次使用我们的简单示例,用 CustomValidator
替换验证控件。像以前一样设置 .ControlToValidate
和 .ErrorMessage
属性。暂时忽略 .ClientValidationFunction
属性,并为 .ServerValidate
事件添加一个事件处理程序。
如果您愿意,您可以根据数据库验证输入的值。为简单起见,我选择使用简单的 if
语句来模拟这一点。
private void alreadyInUse_ServerValidate(object source,
System.Web.UI.WebControls.ServerValidateEventArgs args)
{
// Default Value
args.IsValid = true;
// Simulating a check against a database
if (args.Value == "pdriley@santt.com")
args.IsValid = false;
}
验证器将始终回发到服务器的 ClickEvent
处理程序,该处理程序请求验证结果。但是,如果您输入一个“现有”的电子邮件地址(在我的例子中是我的地址),那么错误消息将被报告回来,并且 Response
不会被重定向。
注意:ServerValidate
事件本身,实际上所有服务器端验证,都在 Page_Load
事件之后和任何其他事件之前执行。但是,除非您稍后检查表单是否有效,否则验证结果无关紧要。在这种情况下,Button_Click
事件仍然会执行。
ServerValidate(事件)
如上例所示,ServerValidate
事件处理程序应接受一个对象(CustomValidator
)和 ServerValidateEventArgs
类型的参数。
ServerValidateEventArgs
类公开了两个属性:.IsValid
和 .Value
。在大多数情况下,您所要做的就是检查 .Value
是否有效并相应地设置 .IsValid
。
如果未为 CustomControl
设置 .ControlToValidate
属性,则 args.Value
将默认为 String.Empty
,但您仍然可以验证控件中包含的值。
ClientValidationScript
编写 JavaScript 处理程序与编写服务器端处理程序非常相似。它仍然公开相同的两个参数,source
和 args
。
上面的 C# 示例代码将直接翻译为
function alreadyInUse_Validate (source, args)
{
// Default Value
args.IsValid = true;
// Simulating a check against a database
if (args.Value == "pdriley@santt.com")
args.IsValid = false;
}
剩下的就是将 .ClientValidationScript
属性设置为 alreadyInUse_Validate
,客户端验证就完成了。
ValidationSummary(验证摘要)
现在应该很清楚,许多网页将包含大量的验证控件。没有用户会乐意看到所有这些错误消息随机出现在页面的各个位置,但很高兴能有一些东西标记无效字段。
这就是 ValidationSummary
控件发挥作用的地方。
ValidationSummary
直接派生自 WebControl
,除了共生功能外,与其他控件无关。
当页面被验证时,同一容器中(例如 Form
或 DataGrid
行)验证失败的验证控件的所有 .ErrorMessage
属性都将传递给 ValidationSummary
控件,以无序列表的形式显示。
这最终解释了验证控件通用的 .Text
属性。如果 .Text
已填充,它将显示在验证控件的位置,但 .ErrorMessage
仍将用于填充 ValidationSummary
。
ValidationSummary
控件具有许多独特的属性,这些属性会影响消息向用户显示的方式。
.DisplayMode |
无序列表的渲染方式。 |
.EnableClientScript |
在客户端验证期间是否应更新错误列表? |
.HeaderText |
定义错误列表的标题文本。 |
.ShowMessageBox |
在 JavaScript“alert”中显示错误消息列表。 |
.ShowSummary |
在页面本身上渲染错误消息。 |
示例
为了演示 ValidationSummary
的全部功能,需要提出一些比文章其余部分使用的简单示例更复杂的内容。
考虑一个简单的注册表单,例如,用于聊天室。
要求此表单的客户提出了以下要求
- 用户 ID - 必填,必须为 6-8 个字符
- 密码 - 必填,必须为 8 个字符,至少包含两个数字,并且已确认
- 姓名 - 必填
- 电子邮件 - 必填,必须是有效格式
- 性别 - 必填,下拉列表,不得为默认值
- 出生日期 - 非必填,但如果输入则必须有效
根据本文其余部分作为指南,自行设置表单,并附带验证器。除了为每个控件提供错误消息外,还将 .Text
属性更改为 *
,并将新的(小得多)控件放在其验证的控件旁边。
尽管 Visual Studio .NET IDE 不允许您将验证控件直接拖放到彼此之上,但您可以编辑 HTML 视图以强制控件处于相同位置。
除了图表之外,这里有一个提示:总共有 12 个验证控件
- 6 x
RequiredFieldValidator
- 4 x
RegularExpressionValidator
- 2 x
CompareValidator
在页面底部,提交按钮旁边放置一个 ValidationSummary
。您可能只想设置的属性是 .HeaderText
。(在示例中,它设置为 请修复以下错误:
)
运行表单,您现在可以看到如何结合使用验证控件和 ValidationSummary
控件来创建一个非常安全、灵活且最重要的是可用的 Web 表单。
如果您遇到困难,示例再次包含在文章顶部的可下载 zip 文件中。
DisplayMode
列表可以以以下任何 DisplayMode
样式呈现
BulletList
(无序列表中的列表项)List
(仅由换行符分隔)SingleParagraph
(由空格分隔)
默认选项是 BulletList
。
EnableClientScript
默认情况下,.EnableClientScript
设置为 true
,并且在提交表单时将显示错误列表。
如果 .EnableClientScript
设置为 false
,则 ValidationSummary
将不会显示,直到服务器将错误报告回客户端机器。
这在(并且仅在)所有验证控件的 .EnableClientScript
属性也为 false
时才有用。如果不是,则表单将不会回发到服务器,并且 ValidationSummary
将永远不会报告错误。
HeaderText
允许定义文本来描述错误列表。此文本将直接发布在错误消息列表之前,无论 .DisplayStyle
值如何。
ShowMessageBox
如果设置为 true
,ShowMessageBox
属性会创建一个 JavaScript alert()
调用,以在消息框中显示所有错误消息。
消息框将尽可能模拟 .DisplayMode
中定义的样式。
ShowSummary
如果设置为 true
,ShowSummary
属性会在 Label
的位置将错误消息列表渲染到 HTML 中。
ShowMessageBox
或 ShowSummary
应该始终为 true
,但只有在绝对必要时才应同时为 true。
绕过验证
如果您有两个回发事件(例如,“下一步”和“返回”按钮),并且一个需要验证而另一个不需要,您可以将其中一个控件的 .CausesValidation
属性设置为 true
,另一个设置为 false
。
这将绕过客户端和服务器端验证。如果您想为这两个事件使用一些通用代码,您仍然可以检查 this.IsValid
,即使没有输入有效数据,验证也会成功。
结论
这是一组功能非常强大且几乎没有明显危险的控件。作为额外的好处,它们实现起来非常简单。在 Visual Studio .NET 中,只需拖放并选择几个属性即可。
虽然一次性需要吸收大量信息,但希望本文能作为一份相当简单的参考指南和“操作指南”。
一旦您多次使用这些验证控件,您就会乐此不疲地将它们拖放到页面中。
下载次数
只需将文件放入任何 Web 应用程序中,将 .aspx 文件包含在项目中,并将 anvindex.aspx 设置为起始页。