本篇要講述的知識點如下：
數據驗證介紹
純客戶端腳本驗證
asp.net驗證控件概述
RequiredFieldValidator控件
CompareValidator控件
RangeValidator控件
正則表達式
RegularExpressionValidator控件
CustomValidator控件
ValidationSummary控件
分組校驗技術
數據驗證介紹
在我們的開發中要提高網站的健壯性，為了做到這些筆者曾經在企業培訓時候提到了兩個原則：
第一條原則：就是盡量減少讓用戶輸入的機會，比如數據的錄入時間我們可以設置該條記錄的為數據庫的當前時間，這個可以在創建或者設計表的時候實現。下面就是一個例子：
create table ActionLog (
LogID bigint identity(1,1),
UserID int not null,
UserIP varchar(15) not null,
ActionDate datetime null default getdate(),
ActionDescription nvarchar(800) not null,
ActionStatus tinyint not null,
WebSiteID int not null,
constraint PK_ACTIONLOG primary key (LogID)
)
Go
上面中的ActionDate字段就是設置成自動獲取數據庫服務器當前時間，這樣在插入記錄的時候無需在這個字段插入值。如果這個值讓用戶填寫一來可能用戶不能按照我們要求的格式填寫，二來即使按照我們的要求填寫也可能用戶不會填寫當前時間，如果采用上面的辦法就能有效避免這個問題。
第二條原則：就是不要過分相信用戶一定會按照我們的要求規規矩矩去做。最終使用我們的軟件產品的用戶大都計算機水平不高（如果水平高可能就會自己開發了），所以他們可能不太懂得什麼格式和要求之類的，這就經常需要對用戶填寫的數據進行檢查。如果我們對用戶提交的數據經過充分檢查，那麼就能有效提高程序的健壯性，這樣也能從某些途徑堵住了黑客入侵我們系統的路子。
對數據的檢查按時機來分可以分為客戶端檢查和服務器端檢查。
在客戶端檢查是指通過客戶端腳本（如javascript腳本或者vbscript腳本）來進行檢查，利用客戶端腳本檢查的好處是減小網絡流量、減輕服務器壓力和反映迅速。因為客戶端腳本是在客戶端運行，我們可以定義好檢驗規則，在客戶端就可以完成檢驗，一旦不能通過驗證客戶端馬上就能得到提示，而不用將整個表單提交到服務器（筆者早些年曾經就有這樣的經歷：網速28.8K的情況下提交一個注冊表單，數分鐘後得到服務器的反饋說是用戶名不符合要求，當時差點吐血），用戶體驗非常好。客戶端驗證也有一些缺點：因為我們的驗證規則完全定義在客戶端腳本中，不懷好意的窺探者可以從這些客戶端代碼找出我們腳本的漏洞或者某些跳過腳本驗證的方法，從而造成網站的健壯性出現問題，這就對客戶端代碼的客戶端腳本編程能力提出了挑戰。另外客戶端驗證可能會使我們寫得非常優秀的代碼在短短幾天流傳整個網絡，不能進行版權控制。
在服務器端檢查是指將表單提交到服務器後在服務器上用服務器端代碼進行驗證（如用C#或者VB.NET等），服務器端驗證的優點是我們的驗證規則對用戶來說是一個黑匣子，比較難找出我們驗證代碼的漏洞，並且服務器端驗證的代碼編寫起來相對客戶端腳本要容易得多，但是服務器端驗證也有缺點：那就是大量的復雜驗證會降低服務器的性能。
因此一般驗證辦法都是上面兩種樣式結合，利用客戶端驗證建立驗證的第一道關卡，這個關卡將大量無意中填寫的不符合要求的數據阻止在客戶端，然後在服務器端建立第二道關卡，將那些利用了我們的客戶端腳本漏洞的數據阻止在保存之前。
