首先我们先来了解一下ASP页面执行的流程
1.IIS找到ASP文件，提交给ASP引擎(一般是ASP.DLL)处理。
2.引擎打开这个ASP文件，找出<%和%>之间的内容，当然还有<script runAt=”server”>和对应的</script>之间的内容，这些内容称为脚本块。只有脚本块里的内容被引擎解析，其他内容不管，作为没有意义的字符插在脚本块之间。有必要说明一下的是，其实被解析的内容还不止这些，<!–#include ***–>类的服务器端包含文件也是由引擎包含进来并加以处理的。如果你读的程序比较多，你还会知道有的runAt属性标注为”Server”的<object>对象也是会被处理的，这里不做深入讨论。
3.引擎执行脚本块中的脚本，这些服务器端的脚本是作为一个整体被执行的，也就是说，可以写出如下的代码：
代码如下:
<%
Dim i
For i=1 to 5
%> Hello World!
<% Next %>
引擎并不会将这些脚本块分开解析，而使两个脚本块都发生语法错误。所以我们得到如下结论：并非所有非服务器脚本的代码都会被发送到客户端，有可能这段非服务器脚本的代码被脚本块限制了。服务器是一定不会操心客户端脚本的执行问题的，但是可以通过服务器端的脚本输出不同的客户端脚本。
4.最终引擎产生了一个文本流，或者说是脚本的执行结果，可以认为这是一个字符串，就是发送到客户端浏览器的网页的代码。客户端浏览器将页面显示出来，此时页面的源代码（源文件）是不包含服务器端的脚本的，但包含了服务器端脚本的执行结果（这是显然的）。
<% … %> 与 <script runat=”server”>…</script>
它们都是服务器端的脚本，同时被处理执行。他们执行时是作为一个整体的。
<% … %> 与 <script language=”…”>…</script>
前者是服务器端脚本，后者是客户端脚本。前者先执行，后者后执行。
其实也不尽然，二者的脚本是有可能在同时被执行的，但空间不同，仍然是：前者在服务器上执行，后者在客户端浏览器里执行。前者在逻辑上一定提前于后者执行。同时我们也得到结论：在同一个页面的执行中，客户端脚本无论如何不能反馈给服务器端脚本，也就是说，客户端浏览你的留言本并且提交新留言或者是任何客户端脚本获取的值都不可能在同一次服务器响应中被处理。
关于组件的调用
注意服务器端脚本和客户端脚本都是脚本，自然都可以创建xmlhttp组件、ADODB.Connection组件等，但是并不是放在哪里都可以的。
xmlhttp如果用于服务器的抓取网页（比如采集）就要在服务器脚本里创建了，而如果是用于客户端的ajax无刷新而后台访问服务器端的页面，那么就是运行于客户端的了，自然在客户端创建。
ADODB.Connection组件用于访问数据库，一般来说在服务器端创建，毕竟是服务器端的asp程序在跑数据库的数据，但如果你的数据库真的是在客户端连接的，那么就毫无疑问在客户端脚本里创建了。
总之，矛盾着的事物及其每一个侧面各有其特点。不同事物有不同的矛盾；同一事物在发展的不同过程和不同阶段上有不同的矛盾；同一事物中的不同矛盾、同一矛盾的两个不同方面各有其特殊性（看不懂的可以略去不看……）。这一原理要求我们坚持具体问题具体分析原则，在矛盾普遍性原理的指导下，具体分析矛盾的特殊性，并找出解决矛盾的正确方法。反对千篇一律地采用一种方法解决不同事物的矛盾。“一把钥匙开一把锁，到什么山唱什么歌”讲的就是这个道理。
服务器端VBScript脚本创建对象使用Server.CreateObject(className)方法，客户端VBScript脚本创建对象使用CreateObject(className)方法。
典型错误
代码如下:
<%
Function TSize(b)
‘这是我自定义的函数
TSize=”中国”
end function
%>
<a href=”javascript:<%TSize(‘变量’)%>” >点这里要使用我定义的函数</a>
错误分析：
混淆了服务器端脚本和客户端脚本的区别。实际执行时我们会发现，客户端根本没有收到什么TSize之类的代码，因为TSize是服务器端的程序，被引擎处理之后（注意引擎对于函数的处理，纯粹是给服务器端脚本调用的，不会发回到客户端）就消失了，不可能在客户端起作用。这就是说，客户端脚本无法直接调用服务器端脚本的函数。
事实上，这个程序是有语法错误的，引擎处理这段内容的时候先找到了<%和%>之间的内容，也就是<%TSize(‘变量’)%>，显然这段内容不符合VBScript的语法规则。嗯，改成<%=TSize(“变量”)%>在服务器端脚本就没有语法错误了，这时TSize函数可以正常返回值”中国”，于是客户端收到的href属性是这样写的：”javascript:中国”，是无法执行的。
服务器端脚本对客户端脚本的影响
前面已经说过了，服务器端脚本在逻辑上是提前于客户端脚本的执行的，因此这样的代码是可行的：
代码如下:
<%
Dim i
For i=1 to 5
Response.Write “<script type=””text/javascript””>” _
& “alert(‘Hello World!” & i & “‘)</script>”
Next
%>
关于Response.Redirect与javascript的执行问题
注意以下代码的写法是错误的：
代码如下:
<%
Response.Redirect “index.asp”
Response.Write “<script type=””text/javascript””>” _
& “alert(‘密码错误!’)</script>”
%>
这是一种常见的错误，编写者常常以为，这样写代码可以使客户端先弹出“密码错误”的提示然后转向到index.asp，事实上这不可能发生，即使将两行代码顺序交换，也不可能达到这种效果。
究其原因，和服务器对于两行代码的处理方式有关。这两行代码不可能同时起作用。
Response.Write是向客户端发送一段文本，这段文本的内容可以是一段脚本，那么客户端浏览器收到后可以执行这段脚本，注意，要收到之后才能执行。
而Response.Redirect是向客户端发送了一个HTTP头信息(什么是HTTP头信息？这么说吧，比如对客户端Cookies的写入是HTTP头信息，HTTP头信息在HTTP的主体之前发回客户端浏览器，这就是为什么有时我们把服务器的缓冲关闭之后修改Cookies会出错的原因，因为主体已经开始传送，不允许发送HTTP头信息了。)，信息的内容告诉客户端浏览器应该跳转页面浏览，注意，这个Redirect信息是立刻起作用的，也就是说这个Redirect信息具有排他性，在缓冲打开的情况下，无论已经使用Response.Write向缓冲里写入了多少内容，一旦调用Response.Redirect，将会清空缓冲，并且向客户端浏览器发送这个头指令。如果动态跟踪一下程序的执行，我们还会发现，在调用了Response.Redirect之后，程序停止执行了，所以注意服务器端程序在调用Response.Redirect之前要做好数据连接的关闭等操作。
那么上面的例子应该怎样修改呢？如果你不愿意修改那个index.asp以加入脚本提示的话，那么只能将转向指令放到客户端脚本中执行，就像这样：
代码如下:
<%
Response.Write “<script type=””text/javascript””>” _
& “alert(‘!’);location.href=’index.asp'</script>”
%>
