asp腳本的執(zhí)行挨次具體說(shuō)明_

1、asp腳本的執(zhí)行挨次具體說(shuō)明_ 首先我們先來(lái)了解一下asp頁(yè)面執(zhí)行的流程 1.iis找到asp文件，提交給asp引擎(一般是asp.dll)處理。 2.引擎打開(kāi)這個(gè)asp文件，找出%和%之間的內(nèi)容，當(dāng)然還有script runat=server和對(duì)應(yīng)的/script之間的內(nèi)容，這些內(nèi)容稱為腳本塊。只有腳本塊里的內(nèi)容被引擎解析，其他內(nèi)容不管，作為沒(méi)有意義的字符插在腳本塊之間。有必要說(shuō)明一下的是，其實(shí)被解析的內(nèi)容還不止這些，!-#include *-類的服務(wù)器端包含文件也是由引擎包含進(jìn)來(lái)并加以處理的。假如你讀的程序比較多，你還會(huì)知道有的runat屬性標(biāo)注為server的object對(duì)象也是會(huì)被處理

2、的，這里不做深化商量。 3.引擎執(zhí)行腳本塊中的腳本，這些服務(wù)器端的腳本是作為一個(gè)整體被執(zhí)行的，也就是說(shuō)，可以寫出如下的代碼： 代碼如下: % dim i for i=1 to 5 % hello world! % next % 引擎并不會(huì)將這些腳本塊分開(kāi)解析，而使兩個(gè)腳本塊都發(fā)生語(yǔ)法錯(cuò)誤。所以我們得到如下結(jié)論：并非全部非服務(wù)器腳本的代碼都會(huì)被發(fā)送到客戶端，有可能這段非服務(wù)器腳本的代碼被腳本塊限制了。服務(wù)器是肯定不會(huì)操勞客戶端腳本的執(zhí)行問(wèn)題的，但是可以通過(guò)服務(wù)器端的腳本輸出不同的客戶端腳本。 4.最終引擎產(chǎn)生了一個(gè)文本流，或者說(shuō)是腳本的執(zhí)行結(jié)果，可以認(rèn)為這是一個(gè)字符串，就是發(fā)送到客戶端掃瞄器的網(wǎng)

3、頁(yè)的代碼。客戶端掃瞄器將頁(yè)面顯示出來(lái)，此時(shí)頁(yè)面的源代碼（源文件）是不包含服務(wù)器端的腳本的，但包含了服務(wù)器端腳本的執(zhí)行結(jié)果（這是明顯的）。 % % 與 script runat=server/script 它們都是服務(wù)器端的腳本，同時(shí)被處理執(zhí)行。他們執(zhí)行時(shí)是作為一個(gè)整體的。 % % 與 script language=/script 前者是服務(wù)器端腳本，后者是客戶端腳本。前者先執(zhí)行，后者后執(zhí)行。 其實(shí)也不盡然，二者的腳本是有可能在同時(shí)被執(zhí)行的，但空間不同，仍舊是：前者在服務(wù)器上執(zhí)行，后者在客戶端掃瞄器里執(zhí)行。前者在規(guī)律上肯定提前于后者執(zhí)行。同時(shí)我們也得到結(jié)論：在同一個(gè)頁(yè)面的執(zhí)行中，客戶端腳本無(wú)論

4、如何不能反饋給服務(wù)器端腳本，也就是說(shuō)，客戶端掃瞄你的留言本并且提交新留言或者是任何客戶端腳本獵取的值都不行能在同一次服務(wù)器響應(yīng)中被處理。 關(guān)于組件的調(diào)用 留意服務(wù)器端腳本和客戶端腳本都是腳本，自然都可以創(chuàng)建xmlhttp組件、adodb.connection組件等，但是并不是放在哪里都可以的。 xmlhttp假如用于服務(wù)器的抓取網(wǎng)頁(yè)（比如采集）就要在服務(wù)器腳本里創(chuàng)建了，而假如是用于客戶端的ajax無(wú)刷新而后臺(tái)訪問(wèn)服務(wù)器端的頁(yè)面，那么就是運(yùn)行于客戶端的了，自然在客戶端創(chuàng)建。 adodb.connection組件用于訪問(wèn)數(shù)據(jù)庫(kù)，一般來(lái)說(shuō)在服務(wù)器端創(chuàng)建，到底是服務(wù)器端的asp程序在跑數(shù)據(jù)庫(kù)的數(shù)據(jù)，但

5、假如你的數(shù)據(jù)庫(kù)真的是在客戶端連接的，那么就毫無(wú)疑問(wèn)在客戶端腳本里創(chuàng)建了。 總之，沖突著的事物及其每一個(gè)側(cè)面各有其特點(diǎn)。不同事物有不同的沖突；同一事物在進(jìn)展的不同過(guò)程和不同階段上有不同的沖突；同一事物中的不同沖突、同一沖突的兩個(gè)不同方面各有其特別性（看不懂的可以略去不看）。這一原理要求我們堅(jiān)持具體問(wèn)題具體分析原則，在沖突普遍性原理的指導(dǎo)下，具體分析沖突的特別性，并找出解決沖突的正確方法。反對(duì)一模一樣地采納一種方法解決不同事物的沖突?！耙话谚€匙開(kāi)一把鎖，到什么山唱什么歌”講的就是這個(gè)道理。 服務(wù)器端vbscript腳本創(chuàng)建對(duì)象用法server.createobject(classname)方法，客

6、戶端vbscript腳本創(chuàng)建對(duì)象用法createobject(classname)方法。 典型錯(cuò)誤 代碼如下: % function tsize(b) 這是我自定義的函數(shù) tsize=中國(guó) end function % a href=javascript:%tsize(變量)% 點(diǎn)這里要用法我定義的函數(shù)/a 錯(cuò)誤分析： 混淆了服務(wù)器端腳本和客戶端腳本的區(qū)分。實(shí)際執(zhí)行時(shí)我們會(huì)發(fā)覺(jué)，客戶端根本沒(méi)有收到什么tsize之類的代碼，由于tsize是服務(wù)器端的程序，被引擎處理之后（留意引擎對(duì)于函數(shù)的處理，純粹是給服務(wù)器端腳本調(diào)用的，不會(huì)發(fā)回到客戶端）就消逝了，不行能在客戶端起作用。這就是說(shuō)，客戶端腳本無(wú)法

7、挺直調(diào)用服務(wù)器端腳本的函數(shù)。 事實(shí)上，這個(gè)程序是有語(yǔ)法錯(cuò)誤的，引擎處理這段內(nèi)容的時(shí)候先找到了%和%之間的內(nèi)容，也就是%tsize(變量)%，明顯這段內(nèi)容不符合vbscript的語(yǔ)法規(guī)章。嗯，改成%=tsize(變量)%在服務(wù)器端腳本就沒(méi)有語(yǔ)法錯(cuò)誤了，這時(shí)tsize函數(shù)可以正常返回值中國(guó)，于是客戶端收到的href屬性是這樣寫的：javascript:中國(guó)，是無(wú)法執(zhí)行的。 服務(wù)器端腳本對(duì)客戶端腳本的影響 前面已經(jīng)說(shuō)過(guò)了，服務(wù)器端腳本在規(guī)律上是提前于客戶端腳本的執(zhí)行的，因此這樣的代碼是可行的： 代碼如下: % dim i for i=1 to 5 response.write script type

8、=text/javascript _ alert(hello world! i )/script next % 關(guān)于response.redirect與javascript的執(zhí)行問(wèn)題 留意以下代碼的寫法是錯(cuò)誤的： 代碼如下: % response.redirect index.asp response.write script type=text/javascript _ alert(密碼錯(cuò)誤!)/script % 這是一種常見(jiàn)的錯(cuò)誤，編寫者經(jīng)常以為，這樣寫代碼可以使客戶端先彈出“密碼錯(cuò)誤”的提示然后轉(zhuǎn)向到index.asp，事實(shí)上這不行能發(fā)生，即使將兩行代碼挨次交換，也不行能達(dá)到這種效果。

9、究其緣由，和服務(wù)器對(duì)于兩行代碼的處理方式有關(guān)。這兩行代碼不行能同時(shí)起作用。 response.write是向客戶端發(fā)送一段文本，這段文本的內(nèi)容可以是一段腳本，那么客戶端掃瞄器收到后可以執(zhí)行這段腳本，留意，要收到之后才能執(zhí)行。 而response.redirect是向客戶端發(fā)送了一個(gè)http頭信息(什么是http頭信息？這么說(shuō)吧，比如對(duì)客戶端cookies的寫入是http頭信息，http頭信息在http的主體之前發(fā)回客戶端掃瞄器，這就是為什么有時(shí)我們把服務(wù)器的緩沖關(guān)閉之后修改cookies會(huì)出錯(cuò)的緣由，由于主體已經(jīng)開(kāi)頭傳送，不允許發(fā)送http頭信息了。)，信息的內(nèi)容告訴客戶端掃瞄器應(yīng)當(dāng)跳轉(zhuǎn)頁(yè)面掃瞄，留意，這個(gè)redirect信息是立即起作用的，也就是說(shuō)這個(gè)redirect信息具有排他性，在緩沖打開(kāi)的狀況下，無(wú)論已經(jīng)用法response.write向緩沖里寫入了多少內(nèi)容，一旦調(diào)用response.redirect，將會(huì)清空緩沖，并且向客戶端掃瞄器發(fā)送這個(gè)頭指令。假如動(dòng)態(tài)跟蹤一下程序的執(zhí)行，我們還會(huì)發(fā)覺(jué)，在調(diào)用了response.redirect之后，程序停止執(zhí)行了，所以留意服務(wù)器端程序在調(diào)用response.redirect之前要做好數(shù)據(jù)連接的關(guān)閉等操作。 那么上面的例子應(yīng)當(dāng)怎樣修改呢？假如你不情愿修改那個(gè)