ASP.NET中實現頁面間的引數傳遞

 

編寫人：CC阿爸

2013-10-27

l  近來在做泛微OA與公司自行開發的系統整合登入的問題。在研究泛微頁面間傳遞參為引數，綜合得了解了一下現行頁面間傳引數的方式

經過在網大致可以歸類為以下幾種情況，現記錄下來。供日後參考

一、             使用QueryString:

使用QueryString在頁面間傳遞值是一種非常常見的方法，我們在ASP中就常常用到。

優點和缺點
    優點：
    1.使用簡單，對於安全性要求不高時傳遞數字或是文字值非常有效。
    缺點：
    1.缺乏安全性，由於它的值暴露在瀏覽器的URL地址中的。
    2.不能傳遞物件。

a)        
使用方法
    1在源頁面的程式碼中用需要傳遞的名稱和值構造URL地址。
    2.在源頁面的程式碼用Response.Redirect(URL);重定向到上面的URL地址中。
    3.在目的頁面的程式碼使用Request.QueryString["name"];取出URL地址中傳遞的值。

b)     
可能出現的問題
1在處理Resonse.QueryString函式漢字引數傳遞時，發生不能完整傳遞引數的具體值的錯誤，解決有兩個方法。

方法一：需要重新設定Web.config中的encoding和全球化設定。

1、首行：<?xml
version="1.0" encoding="utf-8" ?>
更改為： <?xml
version="1.0" encoding="GB2312" ?>
2、<!-- 全球化   此節設定應用程式的全球化設定。   
-->
    <globalization
           
requestEncoding="utf-8"
           
responseEncoding="utf-8"
   />
更改為：
<!-- 全球化         
此節設定應用程式的全球化設定。   
-->
    <globalization
           
requestEncoding="GB2312"
           
responseEncoding="GB2312"
   />

    方法二：使用Server.UrlEncode和Server.UrlDecode對漢字或者特殊字元進行編碼和解碼。

二、        
使用Application變數是在頁面間傳遞值。

Application變數在整個應用程式生命週期中都是有效的，類似於使用全域性變數一樣，所以可以在不同頁面中對它進行存取。它和Session變數的區別在於，前者是所有的使用者共用的全域性變數，後者是各個使用者獨有的全域性變數。
 舉個例子來解釋：
 網站訪問的計數器變數一般採用Application變數，多個請求訪問時共享這一個變數，均可對它進行操作，該變數可以被整個應用程式的各個頁面直接使用。   使用者登陸的帳號名一般採用Session變數，多個請求訪問時有各自的Session變數，只能對自己的該Session變數進行操作，整個應用程式的各個頁面直接使用這個變數來獲得使用者的基本資訊。

(1)優點和缺點

優點：
    1.使用簡單，消耗較少的伺服器資源。
    2.不僅能傳遞簡單資料，還能傳遞物件。
    3.資料量大小是不限制的。

缺點：
    1.作為全域性變數容易被誤操作。

(2)使用方法

  1. 在源頁面的程式碼中建立你需要傳遞的名稱和值構造Application變數:Application["Nmae"]="Value(Or
    Object)";
  2. 在目的頁面的程式碼使用Application變數取出傳遞的值。Result = Application["Nmae"]

三、        
使用Session變數

使用Application變數是在頁面間傳遞值的第三種方式。Session變數和Application變數非常類似，它們的區別也已經在上面關於,Application變數時提到了。

(1)優點和缺點
    優點：
    1.使用簡單，不僅能傳遞簡單資料型別，還能傳遞物件。
    2.資料量大小是不限制的。

缺點：
    1.在Session變數儲存大量的資料會消耗較多的伺服器資源。

(2)使用方法

1.在源頁面的程式碼中建立你需要傳遞的名稱和值構造Session變數:Session["Nmae"]="Value(Or
Object)";

2.在目的頁面的程式碼使用Session變數取出傳遞的值。Result = Session["Nmae"]

四、        
使用Cookie物件

使用Cookie物件是在頁面間傳遞值的第四種方式。Cookie用於在使用者瀏覽器上儲存小塊的資訊，儲存使用者的相關資訊，比如使用者訪問某網站

時使用者的ID，使用者的偏好等，使用者下次訪問就可以通過檢索獲得以前的資訊。所以Cookie也可以在頁面間傳遞值。Cookie通過HTTP頭在瀏覽器

和伺服器之間來回傳遞的。Cookie只能包含字串的值，如果想在Cookie儲存整數值，那麼需要先轉換為字串的形式。
可以通過遍歷Request物件的Cookie集合可以獲得所有的瀏覽器所有的Cookie。方法如下：
foreach (string strKey in Request.Cookies)
{
     lblCookies.Text += strKey + "=" +
Request.Cookies[ strKey ].Value;
}

(1)優點和缺點

優點：
    1.使用簡單，是保持使用者狀態的一種非常常用的方法。比如在購物網站中使用者跨多個頁面表單時可以用它來保持使用者狀態。

缺點：
    1.常常被人認為用來收集使用者隱私而遭到批評。

(2)使用方法

1.在源頁面的程式碼中建立你需要傳遞的名稱和值構造Cookie物件:
    HttpCookie objCookie = new
HttpCookie("myCookie","Hello,Cookie!");
    Response.Cookies.Add(cookie);
    2.在目的頁面的程式碼使用Cookie物件取出傳遞的值：Result = Request.Cookies[ "myCookie" ].Value;

五、        
使用Server.Transfer

使用Server.Transfer變數是在頁面間傳遞值的第五種方式。上面的四個方法我們在ASP中常常使用，但是這個方法是在ASP.NET中新出現的

。Server.Transfer是從當前的ASPX頁面轉到新的ASPX頁面，伺服器端執行新頁並輸出,在新頁面中通過Context.Handler來獲得前一個頁面傳遞

的各種資料型別的值、表單資料、QueryString.由於重定向完全在伺服器端完成，所以客戶端瀏覽器中的URL地址是不會改變的。
    呼叫Server.Transfer時，當前的ASPX頁面終止執行，執行流程轉入另一個ASPX頁面，但新的ASPX頁面仍使用前一ASPX頁面建立的應答流。

[2]

在這裡比較一下Server.Transfer和在“一”中使用的Response.Redirect的區別。
    (1)Server.Transfer在伺服器端完成，所以客戶端瀏覽器中的URL地址是不會改變的；Response.Redirect是客戶端完成，向伺服器端提出

新的頁面處理請求，所以客戶端瀏覽器中的URL地址是會改變的。
     (2)Server.Transfer在伺服器端完成,不需要客戶端提出請求，減少了客戶端對伺服器端提出請求。[2]
    (3)Server.Transfer只能夠轉跳到本地虛擬目錄指定的頁面,也就是工程專案中的頁面，而Response.Redirect則十分靈活,可以跳轉到任何

URL地址。
    (4)Server.Transfer可以將前一個頁面的各種型別的值傳到新的頁面；Response.Redirect則只能藉助URL中帶引數或是結合上面四種辦法

把各種型別的值傳到新的頁面。
  
    繼續我們的Server.Transfer用法。

(1)優點和缺點

優點：
    1.直接在伺服器端重定向，使用簡單方便，減少了客戶端對伺服器端提出請求。
    2.可以傳遞各種資料型別的值和控制元件的值。

缺點：
    1.客戶端瀏覽器中的URL地址是不改變，會導致在新的頁面可能出現一些意想不到的問題。比如如果源頁面和目的頁面不在同一個虛擬目錄

或其子目錄下，那麼使用相對路徑的圖片、超連結都會導致錯誤的指向。[3]

(2)使用方法

1.在源頁面的程式碼中，使用Page類的Server.Transfer跳到另一個頁面傳遞頁面資料：
   
Server.Transfer("destinationWebForm.aspx","false")。

2.在目的頁面中，使用Context.Handler來接收資料：
    FormerPage formerPage = (FormerPage)Context.Handler;
    然後用formerPage的屬性和方法來獲取前一個頁面的值，或者直接用
    Context.Items["myParameter "]
    來獲取前一個頁面的值。

需要注意的是獲取這些值必須在新的頁面首次載入時,才能正確獲取上一頁面的各種資料型別或是控制元件的值。在以後的postback時,就無法

獲取上一頁面的各種資料型別或是控制元件的值了，因為此時得到的當前頁面的例項. 所以需要在新頁面(destinationWebForm.aspx)的Page_Load ()事件中使用if(!IsPostBack)把獲取前一個頁面的值的程式碼包含起來，才能獲得前一個頁面傳遞的各種資料型別的值、表單資料、QueryString。

六、        
使用POST方式來傳遞引數值（泛微即採用該模式傳整合登入中設定的使用者名稱和密碼）

先簡單的介紹一下get與post

l  Get：是以實體的方式得到由請求URI所指定資源的資訊，如果請求URI只是一個數據產生過程，那麼最終要在響應實體中返回的是處理過程的結果所指向的資源，而不是處理過程的描述。

l  Post：用來向目的伺服器發出請求，要求它接受被附在請求後的實體，並把它當作請求佇列中請求URI所指定資源的附加新子項，Post被設計成用統一的方法實現下列功能：

1.  對現有資源的解釋

2.  向電子公告欄、新聞組、郵件列表或類似討論組發信息。

3.   提交資料塊

4.   通過附加操作來擴充套件資料庫

從從上面描述可以看出，Get是向伺服器發索取資料的一種請求；而Post是向伺服器提交資料的一種請求，要提交的資料位於資訊頭後面的實體中。

HTTP請求：get與post方法的區別

l  相同點;

Get與post（對於“post”除非相應裡有cache-control或者expires頭域指示其相應不可快取）請求的相應是可快取的；

l   不同點：

1.  Get是從伺服器上獲取資料，post是向伺服器傳送資料

2.  Get是把引數資料佇列加到提交表單的action屬性所指定的URL中，值和表單中各個欄位一一對應，在URL中可以看到，post是通過HTTP post機制，將表單內各個欄位與其內容放置在html header內一起傳送到action屬性所指的URL地址，使用者看不到這個過程；

3.  get傳送的資料量較小，不能大於1024kb；post傳送的資料量較大，一般被預設為不受限制的。但理論上，2G

4.  get安全性非常低；post安全性較高；

5.  get適用於多請求，而保留post僅用於更新站點；

6.  在form提交的時候，如果不指定method，則預設為get請求，form中提交的資料將會附加在url之後，以？與URL分開。字母數字字元原樣傳送，但空格轉換為“+”號，其它符號轉換為%xx，其中xx為該符號為16進製表示的ASCII（或ISO Latin-1）值；

7.  get請求提交的資料放置在HTTP請求協議頭中，而post提交的資料則放在實體資料資料中；

在表單中適用“post”和“get”區別

在form裡面，可以適用post也可以適用get。它們都是method的合法取值。但是，post和gei方法在適用上至少兩點不同；

1.   get方法通過URL請求來傳遞使用者的輸入。Post方法通過另外的形式。

2.   get方式的提交需要用Request.QueryString來取得變數的值，而post方式提交時，必須通過Request.Form來訪問提交的內容，如：

Request.Form["引數名"] 、Request["引數名"]、Request.Param["引數名"]