內容:對使用者輸入進行驗證是基於 web 的應用程式中常見的情況。為了開發應用程式,開發人員經常在這項工作中花費大量的時間和編輯大量的**,比我們希望的多得多。在 asp+ 頁面架構的構建過程中,努力使輸入驗證這一任務比以前更容易是很重要的。
在 html 3.2中,驗證資料是乙個困難的過程。每次得到請求後,您需要編寫**來檢查輸入並向頁面返回使用者的錯誤,幫助使用者正確填寫驗證窗體。對於終端使用者、開發人員和伺服器來說,這實在是乙個繁雜的過程。
dthml 和指令碼語言使這一局面有所改善。它們在出現輸入錯誤時可以立即反饋到使用者,並在未改正前阻止使用者發布頁面。但是,這幾乎不可能保證站點的每乙個使用者都擁有所需的指令碼設計環境。這通常意味著,如果您要使用指令碼改善網頁的介面,就必須分別在客戶機和伺服器編寫兩次同樣的驗證邏輯,以防止無法執行客戶機**。
對於驗證,我們的目標是:
我們訪問了大量實際的網頁來確定這些元件應該能夠處理的場景。我們的目標是在今後的應用程式中極大地減少驗證**。
驗證器控制項是此解決方案的主要部分。驗證器是乙個可視的 asp+ 控制項,它用來檢查另乙個控制項的特定驗證條件。它通常以一段文字的形式出現在使用者面前,根據它正在檢查的控制項是否發生錯誤來顯示或隱藏。它也可以是一幅影象,甚至也可以不可見,但仍然做有用的工作。有五種可以執行不同型別檢查任務的驗證器控制項。
解決方案的另乙個元素是 validationsummary 控制項。大的資料輸入頁面通常有一塊列出所有錯誤的區域。validationsummary 通過從頁面上的驗證器控制項自動收集並生成其中的內容。
解決方案的最後乙個元素是頁面物件自身。它顯示最重要的「isvalid」屬性,可以在伺服器**中檢查並確定使用者輸入是否正確。
大多數**在伺服器上執行驗證檢查,您無論如何都要為無指令碼的客戶機編寫基於伺服器的檢查,因此很難判斷是否要為所有胖客戶機重寫所有檢查。
驗證控制項改變了這一切,因為幾乎所有重複的邏輯都封裝在控制項中。如果乙個使用 ie 4.0 或更新版本的客戶機使用了您的頁面,那麼它可以執行與在伺服器上相同的驗證,而無需編寫任何特殊的客戶機指令碼。
客戶機端驗證過程包括以下幾個特性:
為了有效地使用驗證器,給出其嚴格的定義是很有幫助的,讓我們提煉一下以前給出的定義:
「驗證是乙個控制項,它在乙個輸入控制項中檢查某種特定型別的錯誤條件,並顯示該問題的說明。」
這是乙個重要的定義,因為它意味著您經常需要為每個輸入控制項使用多個驗證器控制項。
例如,如果您要檢查文字框中的使用者輸入是否為 (a) 非空,(b) 在特定範圍中的合法日期,或 (c) 小於在另一文字輸入控制項中的日期,那麼您可能要使用三個驗證器。這也許顯得有些繁瑣,但請記住這對使用者是有幫助的,對所有這些情況您可能要使用三種不同的文字說明。
下面列出幾種不同的驗證器:
requiredfieldvalidator
檢查使用者是否輸入或選擇了任何內容
regularexpressionvalidator
comparevalidator
將輸入控制項與乙個固定值或另乙個輸入控制項進行比較。例如,它可以用在口令驗證欄位中。也可以用來比較輸入的日期和數字。
rangevalidator
與 comparevalidator 非常相似, 只是它用來檢查輸入是否在兩個值或其它輸入控制項的值之間。
customvalidator
允許使用者編寫自己的**以加入到驗證框架中。
為了示範驗證任務,我們將概要介紹向現有頁面新增驗證的過程。以下是一些必需條件的示例:
編寫乙個 web 頁面來收集新的使用者 id 和口令。使用者 id 必須包含 6-10 個字母字元,且必須是未使用的。口令必須包括 4-12 個字母,其中至少有乙個數字和乙個「@#$%^&*/」中的字元。使用者必須再次輸入口令以確保輸入無誤。
我將從乙個 html 頁面開始,該頁面已做了最小程度的轉換以適用於 asp+ 頁面框架。
轉換頁面的過程包括下述步驟:
將擴充套件字尾從「.html」 或「.asp」 轉換為「.aspx」。
將窗體模板和所有輸入標籤改為「runat=server」。
使用「id」 而不是「name」。
起始**:
請輸入新的使用者 id 和口令
起始頁:
我們首先要強制使所有欄位都已填充。
在每乙個欄位前新增 requiredfieldvalidator。若輸入欄位為空,我們要在字段前顯示乙個星號(*),並在摘要區域報告文字錯誤。以下是向 user id 字段新增 requiredfieldvalidator 控制項的方法:
*
user id:
若輸入為空,則在標籤旁邊顯示 *。出錯訊息在摘要中報告。「controltovalidate」屬性指定了需要驗證的控制項 id。最後一步是向頁面頂部新增驗證總結,如下所示:
該頁面如下所示:
下面顯示了如何指定對使用者 id 的限制:
注意在本示例中,我們並沒有指定標記內的任何內部內容。內部文字等同於控制項的「文字屬性」。如果它為空,出錯資訊將顯示在控制項所在的位置,同樣它也出現在摘要中。
可以用下面兩個驗證器來檢查口令。如果您使用了多個驗證器,則只有它們全都匹配時,才可以認為輸入是有效的。
這是操作中帶有表示式的窗體。
我們需要確認口令的重新輸入欄位與口令匹配。需要使用 comparevalidator 控制項完成此操作。因為它能夠同時處理兩個輸入控制項。
預設情況下,comparevalidator 只做簡單的字串匹配比較。如果需要,它可進行涉及日期和數字的更複雜的比較。
我們需要檢查的最後一件事是名稱尚未在假想的站點中使用。這要繼續在伺服器上查詢一些資料。為了模擬此操作,我在伺服器端的**段中建立乙個啞函式來檢查第乙個字元是否不是「a」。下面的 visual basic 函式在頁面上定義:
public function checkid(source as object, value as string) as boolean
return value.substring(0, 1).tolower() <> "a"
end function
要呼叫這一函式,我將新增乙個 customvalidator,它用於呼叫開發者的**來執行檢查。以下是它的宣告:
它也可以呼叫客戶機指令碼中的定製函式,儘管如果它必須在資料庫中查詢值時這會不太實用。在有指令碼的客戶機上,在其它所有驗證器先在客戶機上執行檢查後才允許提交。如果只在伺服器上進行的檢查檢測到這樣的錯誤,則會向使用者返回頁面指出這些錯誤。
現在,唯一剩下的事就是使用經過精細驗證後的資料了。您需要做的只是檢查頁面的 isvalid 屬性,判定是否可以進行資料庫的更新。您提交的處理程式可能類似下面的形式:
public sub onsubmit(source as object, e as eventargs)
if page.isvalid then
'現在我們可以執行事務。
end if
end sub
正如您所看到的那樣, 該處理程式允許資料輸入頁包含特定於您應用程式的**,而不是通篇**都來處理一般的輸入檢查。
以下是關於最終活動頁面的其它一些資訊:
使用者輸入資料的驗證
1 1 手工程式設計驗證,針對該動作類中的所有的動作方法 2步驟 3a 動作類繼承actionsupport 4 b 覆蓋呼叫public void validate 方法 5c 在validate方法中,編寫不符合要求的 判斷,並呼叫父類的addfielderror string fieldnam...
關於使用者介面輸入的驗證
1 資料的驗證。使用者在介面輸入資料後,接著呼叫 dataprovider 裡的介面對資料進行處理,但是在向服務端提交之前,得先對資料進行驗證。那個這個驗證如何進行呢?dataprovider先從服務端獲實體的描述資訊,這些描述包括但不限於 主外來鍵 屬性的驗證資訊 比如是否可空 當然,這個實體資訊...
php filter函式驗證 過濾使用者輸入資料
php filter 簡介 php 過濾器用於對來自非安全 的資料 比如使用者輸入 進行驗證和過濾。例子 除去html標籤,或除去編碼特殊字元 var dump filter var 中文abc bbb filter sanitize string url encoded編碼,除去或編碼特殊字元 v...