目錄分析 ASPX 代碼分析 HTML 客戶(hù)端代碼視圖狀態(tài)字段回發(fā)機制分析類(lèi)代碼軟件行業(yè)的一個(gè)趨勢是將許多編寫(xiě)代碼的工作量轉移到基本平臺的基礎結構。眾多開(kāi)發(fā)平臺只是要求開(kāi)發(fā)人員使用相對寬松的語(yǔ)法，在較高級別上對所需的信息進(jìn)行描述，而不是按照一組嚴格的語(yǔ)法規則進(jìn)行逐字節的硬編碼?，F在，開(kāi)發(fā)人員經(jīng)常使用 XML 語(yǔ)言來(lái)描述所需的結果，通過(guò)編譯器或運行時(shí)引擎對內容進(jìn)行分析，并將其處理成傳統的可執行代碼。
例如，Windows® Presentation Foundation（.NET Framework 3.0 的支柱之一）使用 XAML 作為基于 XML 的呈現語(yǔ)言，以描述表單用戶(hù)界面。Microsoft AJAX 庫（以前代碼名為 ASP.NET“Atlas”的系統的一部分）使用其 XML-Script 元語(yǔ)言將相同原則應用于富文本網(wǎng)頁(yè)（盡管從技術(shù)上看，XML-Script 不屬于其核心發(fā)布內容，而是作為非官方示例技術(shù)進(jìn)行共享）。XML-Script 是聲明性布局語(yǔ)言，它將 HTML 元素和腳本組合在一起，形成虛擬的客戶(hù)端控件。最終，XML-Script 為客戶(hù)端頁(yè)面引入了邏輯處理和功能。
使用聲明性語(yǔ)言創(chuàng )作網(wǎng)頁(yè)和表單有幾個(gè)優(yōu)點(diǎn)。通過(guò)采用此方式，服務(wù)器端組件可以更方便地生成頁(yè)面和表單，而不必生成實(shí)際的 Visual Basic®、C# 或 JavaScript 代碼。此外，對于諸如 Visual Studio® 這樣的創(chuàng )作工具，聲明性標記就其本質(zhì)而言更容易進(jìn)行設計。從體系結構角度來(lái)看，采用聲明標記的方式，所指定的是頁(yè)面元素的行為，而不是這些元素如何實(shí)現這類(lèi)行為。這樣，就可以創(chuàng )建更多的抽象層。
第一個(gè)利用這種模型的具體編程環(huán)境是 ASP.NET（從版本 1.0 開(kāi)始）。正如大多數 Web 開(kāi)發(fā)人員現在所知的，ASP.NET 頁(yè)通常是在一、兩個(gè)文件中進(jìn)行編寫(xiě)的：一個(gè) .aspx 標記文件和一個(gè)可選的代碼隱藏文件。代碼隱藏文件中包含了以任何受支持的編程語(yǔ)言（通常是 Visual Basic 或 C#）所編寫(xiě)的類(lèi)文件。.aspx 標記文件包含形成頁(yè)面結構的 HTML 標記、ASP.NET 控制標記和文字（它還可以包含代碼）。此文本將在運行時(shí)進(jìn)行分析，并轉換成頁(yè)類(lèi)。這樣的頁(yè)類(lèi)，在與代碼隱藏類(lèi)和一些系統生成的代碼組合之后，共同形成可執行代碼，以處理任何提交的數據，并生成響應，然后將其發(fā)送回客戶(hù)端。
雖然這個(gè)總體模型為絕大多數 ASP.NET 開(kāi)發(fā)人員所知，但還是存在很多只有少部分開(kāi)發(fā)人員有深入了解的“黑洞”。MSDN®、相關(guān)書(shū)籍和在線(xiàn)文章對頁(yè)面機制的各個(gè)方面進(jìn)行了解釋?zhuān)匀蝗鄙賹?yè)面內部機制進(jìn)行的全面而統一的介紹。如果看一看 ASP.NET 頁(yè)的 HTML 源代碼，就會(huì )發(fā)現很多您可能幾乎不了解的隱藏字段和自動(dòng)插入的 JavaScript 代碼塊。但是，正是在這些字段和代碼塊的支持下，網(wǎng)頁(yè)才能正常工作。在本專(zhuān)欄中，我將分析 ASP.NET 頁(yè)所生成的客戶(hù)端源代碼。我不單要討論如視圖狀態(tài)這類(lèi)大家熟悉的隱藏字段，而且還會(huì )涉及到一些少有人知的隱藏字段，例如，控件狀態(tài)、事件驗證、事件目標和參數，以及系統提供的腳本代碼。
我在此處討論的很多實(shí)現細節均是針對當前的 ASP.NET 版本而言的。這些細節在將來(lái)的版本中會(huì )有所更改（相對于過(guò)去的版本已有了更改），因此您不應當構建任何依賴(lài)于不成文細節的運行代碼。
分析 ASPX 代碼
圖 1 顯示了一個(gè)雖然很小但可以運行的 ASP.NET 頁(yè)。盡管它非常簡(jiǎn)單，但這是一個(gè)很好示例，因為它包括真實(shí)環(huán)境中的 ASP.NET 頁(yè)面的典型元素：輸入域、可點(diǎn)擊的回發(fā)元素以及只讀元素。
.aspx 頁(yè)包含三個(gè)服務(wù)器控件：用于捕獲數據的文本框、用于啟動(dòng)回發(fā)操作的提交按鈕、用于顯示只讀數據的標簽。在 .aspx 文件頂部，Page 指令定義了單個(gè)頁(yè)面的一些全局屬性。讓我們看一看 Page 指令的最常用屬性，比如在
圖 1 中顯示的那些屬性。<%@ Page Language="C#"AutoEventWireup="true"CodeFile="Test.aspx.cs"Inherits="Test"%>
大多數 Page 指令屬性對頁(yè)標記（即，瀏覽器通過(guò) HTTP 響應接收的 HTML 代碼）的影響都有限。但是，大部分 Page 屬性都會(huì )影響由系統在 .aspx 標記和代碼隱藏類(lèi)的頂部構建的動(dòng)態(tài)生成頁(yè)的代碼。Language 屬性指定在 Visual Studio 中創(chuàng )作代碼隱藏類(lèi)所使用的語(yǔ)言。系統將使用相同語(yǔ)言生成動(dòng)態(tài)頁(yè)類(lèi)，以處理瀏覽器對 .aspx 資源的請求。CodeFile 屬性指示存儲代碼隱藏類(lèi)的源文件。Inherits 屬性指示在代碼文件中應當作為動(dòng)態(tài)生成的頁(yè)類(lèi)的父類(lèi)的代碼隱藏類(lèi)的名稱(chēng)。最后，AutoEventWireup 屬性指示是否應當使用默認命名約定將處理代碼映射到 Page 事件。如果將 AutoEventWireup 設置為 True，則可以在代碼文件中添加 Page_Load 方法，以處理頁(yè)面的 Load 事件，并且它將自動(dòng)注冊到 Page 的 Load 事件。隱式命名約定指示事件處理程序將采用 Page_XXX 格式，其中，XXX 可以是在 Page 類(lèi)中定義的任何公共事件的名稱(chēng)。如果將 AutoEventWireup 設置為 false，則必須將 Page 類(lèi)事件與它的處理程序進(jìn)行顯式綁定。您可以在專(zhuān)門(mén)設計的類(lèi)構造函數中執行此操作：public partial class Test : System.Web.UI.Page{public Test(){this.Load += new EventHandler(Page_Load);}...}
Web 服務(wù)器收到對給定 .aspx 資源的 HTTP 請求時(shí)，它會(huì )將請求轉發(fā)給 ASP.NET 工作進(jìn)程。該進(jìn)程中駐留有 CLR，在其內部創(chuàng )建了一個(gè)運行時(shí)環(huán)境來(lái)處理 ASP.NET 請求。ASP.NET HTTP 運行時(shí)環(huán)境的最終目標是處理請求，即獲得將嵌入 HTTP 響應中的標記（HTML、WML、XHTML 以及應用程序應當返回的任何其他標記）。負責返回請求標記的是稱(chēng)為 HTTP 處理程序的特殊系統組件。
HTTP 處理程序是實(shí)現了 IHttpHandler 接口的類(lèi)的實(shí)例。ASP.NET Framework 提供了少量預定義的 HTTP 處理程序，以處理特定情況，或者用作處理其他或更多特定請求的基類(lèi)。System.Web.UI.Page 類(lèi)是 ASP.NET 中的一個(gè)最復雜的內置 HTTP 處理程序。
每個(gè) ASP.NET 請求都會(huì )映射到一個(gè) HTTP 處理程序。假設客戶(hù)端瀏覽器對一個(gè)名為 test.aspx 的頁(yè)面發(fā)出請求。請求將傳遞給 ASP.NET，并由 HTTP 運行時(shí)進(jìn)行處理。運行時(shí)通過(guò)頁(yè)處理程序工廠(chǎng)確定由 HTTP 處理程序類(lèi)來(lái)處理該請求。如果在 AppDomain 中尚未提供正確的處理程序，則會(huì )動(dòng)態(tài)地創(chuàng )建該處理程序，并將其存儲在 Web 服務(wù)器計算機的 ASP.NET 臨時(shí)文件夾中。對于名為 test.aspx 的頁(yè)，將以類(lèi)的形式創(chuàng )建一個(gè)名為 ASP.text_aspx 的 HTTP 處理程序。
針對給定請求的 HTTP 處理程序類(lèi)的動(dòng)態(tài)創(chuàng )建過(guò)程對于每個(gè)頁(yè)面只發(fā)生一次，即在應用程序運行期間內該頁(yè)面第一次被請求時(shí)進(jìn)行創(chuàng )建（盡管來(lái)說(shuō)，使用批編譯時(shí)，只要應用程序內有一個(gè)頁(yè)面收到了第一次請求即可生成處理程序）。如果應用程序重新啟動(dòng)或 Web 服務(wù)器上的頁(yè)面源文件發(fā)生了修改，則動(dòng)態(tài)創(chuàng )建的程序集將無(wú)效并被替換。圖 2 顯示了從基礎 Page 類(lèi)直到處理用戶(hù)請求的動(dòng)態(tài)生成類(lèi)等頁(yè)類(lèi)的層次結構。
圖 2 Page 類(lèi)的層次結構 (單擊該圖像獲得較小視圖)
圖 2 Page 類(lèi)的層次結構 (單擊該圖像獲得較大視圖)
ASP.NET 運行時(shí)通過(guò)分析相應 .aspx 文件的源代碼來(lái)創(chuàng )建動(dòng)態(tài)頁(yè)類(lèi)的 Visual Basic 或 C# 源代碼。每個(gè)包含 runat="server" 的標記都將映射到一個(gè)服務(wù)器控件實(shí)例。任何其他文本則映射到文字控件，并按原樣一字不差地發(fā)出。Register 指令（如果有）幫助解析指向非標準控件的標記。返回到客戶(hù)端瀏覽器的標記是通過(guò)將頁(yè)面中每個(gè)服務(wù)器控件所發(fā)出的標記組合到一起而形成的。請注意，每個(gè)頁(yè)通常都會(huì )發(fā)出標記，而且通常是 HTML 標記。但是，這不是必需的，并且 ASP.NET 頁(yè)可以輸出它需要的任何數據。
分析 HTML 客戶(hù)端代碼
圖 3 顯示了
圖 1 中的示例頁(yè)的 HTML 輸出。在該 HTML 中，服務(wù)器端 .aspx 頁(yè)中看不到任何有 Page 指令的跡象。而是逐字復制 !DOCTYPE 指令。
圖 1 中的第一個(gè) runat="server" 塊是 <form> 標記。這意味著(zhù) Page 和 <form> 之間的任何文本都將按原樣發(fā)出。在服務(wù)器上動(dòng)態(tài)創(chuàng )建的頁(yè)類(lèi)的源代碼中，此文本將轉換成 LiteralControl 類(lèi)的一個(gè)實(shí)例。<form> 標記類(lèi)似以下方式發(fā)出：<form name="form1" method="post" action="Test.aspx" id="form1">
<form runat="server" …> 標記將轉換為 HtmlForm 類(lèi)的實(shí)例。該控件類(lèi)沒(méi)有相應的屬性可用于設置輸出標記中的 action 屬性。action 屬性被硬編碼到當前頁(yè)的 URL 中。此行為是基于 ASP.NET 平臺基礎的。請注意，ID 屬性同一個(gè)與 name 屬性值相同的值形成一對。
<asp:textbox> 標記轉換為 HTML 中的 <input type="text"> 元素。在這里，將添加 name 屬性，以便與原來(lái)的 ID 屬性匹配。請注意，如果省略 ID 屬性，則可能會(huì )收到 Visual Studio 2005 發(fā)出的警告，但 ASP.NET 仍將成功編譯該頁(yè)。如果缺少 ID 屬性，則會(huì )生成隨機字符串，并將其綁定到 name 屬性。<asp:Button> 標記轉換為 <input type="submit"> 按鈕。<asp:Label> 標記將在客戶(hù)端瀏覽器上轉換為 HTML 的 <span> 標記。
在大多數情況下（雖然不是全部），帶有 runat="server" 屬性的每個(gè)標記都將生成一個(gè)對應的 HTML 標記塊。ID 字符串將保證兩個(gè)塊之間穩定的匹配關(guān)系：一個(gè)在客戶(hù)端，另一個(gè)在服務(wù)器端。在
圖 3 中可以看到，兩個(gè)隱藏字段用于填充了 HTML 標記：__VIEWSTATE 和 __EVENTVALIDATION。
視圖狀態(tài)字段
__VIEWSTATE 字段的內容代表了頁(yè)面最后在服務(wù)器上處理時(shí)的狀態(tài)。盡管被發(fā)送到了客戶(hù)端，但視圖狀態(tài)并不包含客戶(hù)端應當使用的任何信息。存儲在視圖狀態(tài)中的信息只涉及服務(wù)器頁(yè)和它的一些子控件，并且由服務(wù)器獨占讀取、使用和修改。
通過(guò)采用此實(shí)現方式，視圖狀態(tài)可以不使用任何關(guān)鍵服務(wù)器資源，因此可以快速檢索和使用。另一方面，正是因為視圖狀態(tài)與頁(yè)面組合在一起，因此必然會(huì )使 HTTP 請求和響應的大小增加幾千字節。注意，包含若干數據的實(shí)際頁(yè)面的視圖狀態(tài)大小很容易達到 20KB。而每次進(jìn)行上傳和下載時(shí)都要包括這個(gè)額外的負載量。視圖狀態(tài)是 ASP.NET 的最重要功能之一，因為它可以基于諸如 HTTP 這樣的無(wú)狀態(tài)協(xié)議實(shí)現狀態(tài)編程。雖然使用時(shí)不需要嚴格的條件，但視圖狀態(tài)很容易成為頁(yè)面的負擔。
通過(guò)重寫(xiě)代碼文件類(lèi)的兩個(gè)方法，可以將視圖狀態(tài)字段的內容留在服務(wù)器上、存儲在數據庫、緩存或會(huì )話(huà)對象中。但請注意，將視圖狀態(tài)信息留在服務(wù)器上并非像一開(kāi)始感覺(jué)的那樣是一個(gè)順理成章的解決辦法。實(shí)際上，ASP.NET 團隊選擇基于頁(yè)的視圖狀態(tài)并不是偶然的。只要用戶(hù)沿著(zhù)應用程序中的鏈接從一頁(yè)導航到下一頁(yè)，基于服務(wù)器的視圖狀態(tài)確實(shí)是個(gè)好的選擇。請記住，ASP.NET 應用程序的工作方式是在同一頁(yè)上進(jìn)行重復發(fā)布。但是，如果用戶(hù)單擊“后退”按鈕，情況會(huì )如何呢？為了安全起見(jiàn)，應當基于每個(gè)請求而不是基于每個(gè)頁(yè)來(lái)維護視圖狀態(tài)。而且，被跟蹤的請求鏈應當與用戶(hù)通過(guò)“后退”和“前進(jìn)”按鈕可以到達的請求相匹配。將視圖狀態(tài)存儲在客戶(hù)端可能不是一個(gè)完美的方案，但存儲在服務(wù)器上同樣也有其不足。對于您的應用程序來(lái)說(shuō)，更為可取的選擇取決于您對應用程序的要求。
在 ASP.NET 2.0 中，__VIEWSTATE 隱藏字段包含兩種類(lèi)型的信息：視圖狀態(tài)和控件狀態(tài)。開(kāi)發(fā)人員可以完全禁用視圖狀態(tài)，并以純粹的無(wú)狀態(tài)方式運行其應用程序。只要您使用內置的控件和您自己編寫(xiě)的控件，或者至少是您可以訪(fǎng)問(wèn)其源代碼的控件，這就不是問(wèn)題。如果使用了已啟用視圖狀態(tài)的自定義控件，情況會(huì )怎么樣呢？某些控件（通常是大量第三方和自定義的控件）需要跨回發(fā)持久保存私有信息。此信息不是公共的，并且不準備對應用程序級別公開(kāi)，例如，下拉面板的折疊/展開(kāi)狀態(tài)。此信息只能保存在視圖狀態(tài)。如果禁用視圖狀態(tài)，則控件可能會(huì )意外地失去作用。
為了緩解這一問(wèn)題，ASP.NET 2.0 引入了控件狀態(tài)的概念。每個(gè)服務(wù)器控件都可以將任何關(guān)鍵屬性打包到集合，并將它存儲到頁(yè)面的控件狀態(tài)中?？丶顟B(tài)保存到 __VIEWSTATE 字段，但與傳統的視圖狀態(tài)不同，它不能被禁用，并且始終可用。開(kāi)發(fā)人員通過(guò) Page 類(lèi)的一對新的可重寫(xiě)方法 LoadControlState 和 SaveControlState 來(lái)管理控件狀態(tài)。但是，談到 ASP.NET 2.0 中的視圖狀態(tài)，還應當注意到該版本采用了更為有效的新序列化算法，來(lái)使各個(gè)控件的狀態(tài)有效地存儲在隱藏字段中。因此，在大多數情況下，__VIEWSTATE 隱藏字段的總體大小是 ASP.NET 1.x 中的相應字段大小的一半。
前面提到過(guò)，視圖狀態(tài)存儲在隱藏字段中，以便使它與特定的頁(yè)請求明確關(guān)聯(lián)。當給定頁(yè)實(shí)例中的任何 HTML 元素回發(fā)時(shí)，動(dòng)態(tài)生成的頁(yè)類(lèi)開(kāi)始在服務(wù)器上運行，并使用存儲在視圖狀態(tài)中的數據，來(lái)為頁(yè)面中的控件重新創(chuàng )建最后所能夠知道的正常狀態(tài)。如果視圖狀態(tài)在客戶(hù)端被篡改了，情況會(huì )怎么樣呢？這種情況可能發(fā)生嗎？默認情況下，會(huì )使用 Base64 公式對視圖狀態(tài)編碼并進(jìn)行散列處理，所得到的散列值也與視圖狀態(tài)一起存儲。散列值是通過(guò)計算視圖狀態(tài)的內容外加服務(wù)器密鑰得到的。一旦回發(fā)頁(yè)面，頁(yè)類(lèi)中的代碼會(huì )將視圖狀態(tài)的內容和散列值分離。下一步，它將基于檢索到的視圖狀態(tài)內容和服務(wù)器密鑰重新計算散列值。如果兩個(gè)散列值不匹配，則引發(fā)安全異常（請參見(jiàn)圖 4）。
圖 4 不能在客戶(hù)端上更改頁(yè)面視圖 (單擊該圖像獲得較小視圖)
圖 4 不能在客戶(hù)端上更改頁(yè)面視圖 (單擊該圖像獲得較大視圖)
如果惡意用戶(hù)試圖發(fā)布已修改了視圖狀態(tài)的假請求，情況會(huì )怎么樣呢？惡意用戶(hù)需要知道服務(wù)器密鑰，才能為經(jīng)過(guò)修改的視圖狀態(tài)內容生成可以在服務(wù)器上匹配的散列值。但是，服務(wù)器密鑰是僅由服務(wù)器信息組成的，并且不出現在視圖狀態(tài)字段中。附帶代碼中的 tweakviewstate.aspx 頁(yè)包含的腳本代碼可以修改視圖狀態(tài)，并演示所發(fā)生的異常情況，如圖 4 所示。
盡管視圖狀態(tài)幾乎不能用于發(fā)動(dòng)攻擊，但它無(wú)法保證數據的機密性，除非使用加密。實(shí)際上，可以在客戶(hù)端對視圖狀態(tài)的內容進(jìn)行解碼和檢查，但不可能成功修改該內容以使經(jīng)過(guò)更改的頁(yè)狀態(tài)用于服務(wù)器環(huán)境。
__EVENTVALIDATION 隱藏字段是 ASP.NET 2.0 的新增安全措施。該功能可以阻止由潛在的惡意用戶(hù)從客戶(hù)端發(fā)送的未經(jīng)授權的請求。為了確保每個(gè)回發(fā)和回調事件來(lái)自于所期望的用戶(hù)界面元素，頁(yè)將在事件中添加額外的驗證層。頁(yè)通常通過(guò)將請求的內容與 __EVENTVALIDATION 字段中的信息進(jìn)行匹配，來(lái)驗證未在客戶(hù)端添加額外的輸入域，并且該值是在服務(wù)器已知的列表中選擇的。頁(yè)將在生成期間創(chuàng )建事件驗證字段，而這是最不可能獲取該信息的時(shí)刻。 像視圖狀態(tài)一樣，事件驗證字段包含散列值以防止發(fā)生客戶(hù)端篡改。
控件使用 ClientScriptManager 對象的 RegisterEventForValidation 方法存儲自己的安全回發(fā)相關(guān)信息。每個(gè)控件還可能會(huì )注冊它自己的唯一 ID，但這種情況十分少見(jiàn)。列表控件還會(huì )存儲列表中的所有值。支持事件驗證的服務(wù)器控件通常在其 IPostBackDataHandler 接口的實(shí)現中調用 ValidateEvent 方法。如果驗證失敗，將引發(fā)安全異常。
可以基于每個(gè)頁(yè)啟用和禁用事件驗證；每個(gè)控件類(lèi)都通過(guò) SupportsEventValidation 屬性來(lái)啟用事件驗證。目前，還不能在特定控件實(shí)例上啟用或禁用事件驗證。
事件驗證是為了僅限輸入一組已知值而設置的防衛屏障。它只是將安全防護提升到更高水平，但本身不會(huì )阻止腳本注入式的攻擊。
如果在啟用 AJAX 的應用程序的環(huán)境中使用事件驗證，則可能造成問(wèn)題。在這類(lèi)應用程序中，某些客戶(hù)端工作可以臨時(shí)創(chuàng )建新的輸入元素，因而可能會(huì )由于出現未知元素而導致下一個(gè)回發(fā)失敗。最好的應對方法是，一旦可能就在服務(wù)器上生成所有用戶(hù)界面，并使用級聯(lián)樣式表顯示屬性在客戶(hù)端上隱藏它。這樣，您要使用的任何用戶(hù)界面都將注冊到事件驗證字段。如果編寫(xiě)自定義控件，則應當用 SupportsEventValidation 屬性設置該控件，以啟用此功能。
回發(fā)機制
圖 1 中的 ASP.NET 頁(yè)會(huì )在用戶(hù)單擊按鈕時(shí)執行回發(fā)操作。這是因為 <asp:Button> 標記將轉換為 HTML 的提交 <input> 元素。單擊提交輸入字段時(shí)，瀏覽器將觸發(fā) HTML 客戶(hù)端事件 onsubmit，然后根據所提交表單的內容來(lái)準備提交到服務(wù)器的新請求。所發(fā)送的 HTTP 請求包括一部分其他信息，用于計算按鈕 ID。
頁(yè)類(lèi)將掃描 HTTP 請求的正文，以確定所發(fā)布的字段中是否有任何字段與 ASP.NET 頁(yè)中按鈕控件的 ID 匹配。如果找到匹配項，將調用該按鈕控件以運行與它的 Click 事件關(guān)聯(lián)的任何代碼。更準確地說(shuō)，頁(yè)類(lèi)將檢查并確定所匹配的按鈕控件是否實(shí)現了 IPostBackEventHandler 接口。如果是，它將調用該接口的 RaisePostbackEvent 方法。對于按鈕控件，該方法將引發(fā)服務(wù)器端的 Click 事件。
到此為止，一切順利。但如果頁(yè)面中包含 LinkButton 控件，情況會(huì )怎么樣？
圖 5 顯示的 ASP.NET 頁(yè)的標記與
圖 1 中的頁(yè)相同，只不過(guò)使用的是 LinkButton 而不是 Submit 按鈕?？梢钥吹?，標記包括另外兩個(gè)隱藏字段（__EVENTTARGET 和 __EVENTARGUMENT）和一些 JavaScript 代碼。鏈接按鈕的 href 目標綁定到 __doPostback 腳本函數，這意味著(zhù)一旦檢測到客戶(hù)端上有點(diǎn)擊該元素的操作，就將調用這個(gè)函數。通過(guò)生成 LinkButton 控件的代碼，__doPostback 函數在頁(yè)中發(fā)出。它用合適的信息填充 __EVENTTARGET 和 __EVENTARGUMENT 字段，然后通過(guò)腳本觸發(fā)回發(fā)。這種情況下，HTTP 回發(fā)請求的正文只包含頁(yè)中的輸入域，并且所回發(fā)的數據不引用 Submit 按鈕。
ASP.NET 如何識別負責處理回發(fā)的控件？如果在請求正文中引用的所有控件都未實(shí)現 IPostBackEventHandler 接口，則頁(yè)類(lèi)將查找 __EVENTTARGET 隱藏字段（如果有）。字段的內容假定為導致回發(fā)的控件的 ID。如果此控件實(shí)現了 IPostBackEventHandler 接口，則調用 RaisePostbackEvent 方法。對于 LinkButton 控件，這將導致調用 Click 服務(wù)器事件。
分析類(lèi)代碼
.aspx 標記定義 ASP.NET 頁(yè)的布局，并確定成員控件的大小、樣式和位置。但除了可能包含某些客戶(hù)端腳本代碼和任何 Visual Basic 或 C# 內嵌代碼以外，它不包含邏輯。初始化代碼、事件處理程序和任何幫助器例程通常在單獨的附帶文件中提供，這些文件叫做代碼隱藏文件：public partial class Test : System.Web.UI.Page{protected void Page_Load(object sender, EventArgs e){...}protected void Button1_Click(object sender, EventArgs e){...}}
代碼文件中的類(lèi)直接或間接從 System.Web.UI.Page 繼承。代碼文件和標記都表示必要的信息，但二者又截然不同。若要完全表示 ASP.NET 頁(yè)，它們必須組合在一起以形成頁(yè)類(lèi)，在其中將代碼文件的邏輯和標記文件的布局數據合并在一起。代碼文件類(lèi)已經(jīng)是頁(yè)類(lèi)，但它缺少兩部分關(guān)鍵的信息：用于填充用戶(hù)界面的子服務(wù)器控件的列表，以及用于標識各種服務(wù)器控件的類(lèi)成員的聲明。
在 ASP.NET 1.x 中，頁(yè)面創(chuàng )建人員每次將控件拖到 Web 表單上時(shí)，Visual Studio .NET 2003 都會(huì )在代碼文件中自動(dòng)添加新的行，以創(chuàng )建用于處理剛才拖動(dòng)的服務(wù)器控件的類(lèi)成員。這是使所有內容保持同步的非常好的步驟，但開(kāi)發(fā)人員經(jīng)常會(huì )碰到由于缺少類(lèi)成員或存在無(wú)效的類(lèi)成員而導致的編譯錯誤。
在 ASP.NET 2.0 中，這個(gè)問(wèn)題已經(jīng)得到了妥當的解決?？梢暂斎氩糠诸?lèi)，即通過(guò)源代碼級、程序集受限且非面向對象的方式來(lái)擴展類(lèi)的行為。在 .NET Framework 2.0 中，類(lèi)定義可以跨越兩個(gè)或更多個(gè)文件。每個(gè)文件都包含最終的類(lèi)定義的一部分內容，編譯器會(huì )考慮到合并各個(gè)部分定義，以形成單個(gè)統一的類(lèi)。所有定義部分都必須有相同的簽名，并且最終的類(lèi)定義必須保證語(yǔ)法正確。
下一步，將動(dòng)態(tài)生成第二個(gè)部分類(lèi)，以列出所有控件成員。兩個(gè)部分類(lèi)將在編譯時(shí)合并。系統將分析 .aspx 標記文件，以創(chuàng )建臨時(shí) ASP.test_aspx 類(lèi)，此類(lèi)繼承自其最終版本的組合代碼文件。 如果 ASP.NET 頁(yè)未綁定到代碼文件，但包含它的內嵌代碼，則動(dòng)態(tài)頁(yè)類(lèi)將繼承 System.Web.UI.Page，并在它的正文中包括所有內嵌代碼。
有關(guān)動(dòng)態(tài)頁(yè)的編譯機制還有很多內容有待了解，這些內容會(huì )在以后的專(zhuān)欄中介紹，本文權作拋磚引玉。
