1. 先把概念理清：ASP 不是一门语言，也不是那个带 .NET 的东西

接手一套跑了很多年的老站点，打开目录一看，满屏.asp后缀，文件里 HTML 和<% %>混着写，第一反应往往是"这玩意儿跟 ASP.NET 是一回事吧"。我最早也是这么以为的，结果在配置文件里找了半天web.config的路由规则，最后发现人家根本没走那套东西——它就是一个把脚本嵌进 HTML、由服务器在返回页面之前逐行执行掉的老式页面引擎。搞清楚这一点，后面的一小时才不会白花。

ASP（Active Server Pages）本质上是一个服务端的脚本执行环境，它不是一个编程语言，也不是一个框架。语言是 VBScript（默认）或 JScript，ASP 只负责一件事：浏览器请求一个.asp文件时，服务器不把文件原样吐出去，而是先把里面<% ... %>包住的代码跑一遍，把结果拼进 HTML，再把拼好的纯 HTML 发给浏览器。所以你在浏览器里"查看源代码"，永远看不到一句服务端脚本——这是它和纯静态页最直观的区别。

这套东西适合谁看？三类人：一是维护老系统的，手上有一堆二十年历史的内部站点要改要补；二是学 Web 原理的，想搞明白"服务端渲染"最原始的样子是什么；三是做迁移评估的，得先读懂旧代码才能决定怎么搬。如果你是要新起一个项目，那我的建议很直接——不要选它，工具链、生态、安全性都不在今天的主流选择里。但读懂它，成本极低，一小时足够。

1.1 和 ASP.NET 的分界线画在哪里

这两个名字长得像，实际是两代完全不同的东西。区分的标志看一眼文件后缀和目录结构就够：

记住一句：看到<% %>但文件是.asp，那是老 ASP；看到<%@ Page Language="C#" %>，那是 ASP.NET。很多人卡住就是因为把两者的语法混着写，比如在.asp里写runat="server"，那当然不会生效。

1.2 一次请求进来，服务器到底做了哪几步

理解这条链路，后面所有"为什么这样写"都有了解释。客户端发起请求 → 服务器识别.asp扩展名，把它交给对应的脚本引擎（这一步在服务器管理界面里是一个"应用程序映射"配置）→ 引擎加载文件，遇到 HTML 原样输出，遇到<% %>就执行 → 执行过程中如果调用了数据库或文件系统，就在这一步发生 → 全部跑完后，缓冲区里已经是一段完整 HTML → 加上响应头返回给浏览器。

这里有两个关键推论。第一，ASP 页面是无状态的，HTTP 本身不记事，所以上一页填的表单，这一页要靠Request去拿，或者靠Session存起来，没有第三种魔法。第二，代码执行顺序就是文件从上到下的顺序，没有"页面生命周期"帮你调度，你把数据库查询写在 HTML 后面，它就真的在输出完 HTML 之后才查。这两点想通了，很多"怎么会这样"的困惑会自动消失。

1.3 一小时到底该学哪部分，不该学哪部分

时间有限，必须有取舍。我给的分配是这样的：

明确不学的：COM 组件注册、邮件发送组件、文件上传的无组件实现、图表组件这些。它们属于"用到再查"的范畴，原理上都是一句Server.CreateObject，没必要占用这一小时。同理，样式和前端交互也不用花时间，那跟 ASP 没关系。

2. 把第一个 .asp 文件跑起来：环境这一步最容易耗掉半小时

我在教别人的时候发现，卡人的从来不是语法，是环境。语法写错了报个错改一下就好，环境没配对，页面直接给你一个白屏或者 500，连错在哪都不告诉你，人就懵了。所以这一节我按"最小可验证"的思路来排：先让它跑起来，再谈别的。

2.1 Windows 上开启服务端脚本支持

在老式的 Windows 服务器系统上，这个能力是通过"服务器角色"里的 Web 服务器组件提供的；在桌面版系统上，则是在"启用或关闭系统功能"里勾选。关键不是勾不勾，而是勾选的时候要展开子项，很多人只勾了最外层，结果脚本引擎根本没装，.asp文件被当成普通文件直接下载下来——这个现象特别有辨识度：浏览器弹下载框，而不是显示页面。

需要额外确认的三个子项：

• ASP 支持：这是脚本引擎本体，默认在较新版本里是不勾选的，必须手动开。
• 默认文档：不装这个，访问目录路径时不会自动找index.asp或default.asp。
• 父路径：如果你的<!--#include file="../inc/conn.asp"-->用了相对上级目录的写法，不开这个会直接报错。

开完记得重启一下服务，别问为什么，改了组件不重启，配置不生效是常态。

2.2 站点目录、默认文档与权限的三个坑

坑一：目录权限。脚本是以一个受限账户身份运行的，如果你的站点放在某个用户目录下，那个账户往往没有读权限，表现是 401 或者 500。稳妥做法是把站点放在一个独立的、权限清晰的目录里，给运行账户"读取和执行"以及必要的"写入"（只有需要写文件或写数据库时才给写入）。

坑二：默认文档顺序。列表里如果index.html排在default.asp前面，而你两个文件都有，那访问首页永远走 html。这个坑会在你改了 asp 却"没生效"的时候浪费大量时间。把.asp相关的默认文档往上挪。

坑三：32 位与 64 位。这是老项目迁移里最经典的一条。早期的一些数据库驱动只有 32 位版本，跑在 64 位的工作进程里就会报"未找到提供程序"。解决办法是在应用程序池的高级设置里把"启用 32 位应用程序"设为 True。判断依据很简单：连数据库报提供程序找不到，但连接字符串明明是对的，先怀疑这个。

2.3 用五行代码验证环境真的通了

新建一个test.asp，内容就这几行：

<% Response.Charset = "utf-8" Response.Write "环境正常，服务器时间：" & Now() %>

访问它。三种结果对应三种问题：显示时间和中文 → 一切正常；显示乱码 → 编码配置没对齐，见后面第 6 节；报 500 且没有细节 → 详细错误没打开，同样见第 6 节。

再加一段验证表单和状态：

<% Session("hits") = Session("hits") + 1 %> <p>这是你在本会话中的第 <%=Session("hits")%> 次访问</p>

刷新几次，数字递增，说明 Session 是通的。这一步花不了一分钟，但能一次性排除掉后面 80% 的环境类怀疑。养成习惯：每换一个环境，先跑这两个文件，再动业务代码。

3. VBScript 够用的子集：能读懂别人的代码就赢了

老项目的代码你不用会"写得多漂亮"，但要能读懂。VBScript 的语法坑不算多，但有几个地方和今天的语言习惯差别很大，不知道就会反复栽跟头。

3.1 变量、隐式声明与 Option Explicit 的取舍

VBScript 默认允许变量不声明直接用，拼错了也不报错——它只会默默创建一个新变量，值为空。这是老代码里最阴险的 bug 来源：userNmae拼错了，你查半天为什么值是空的。

页面顶部加一句就能堵住这个口子：

<% Option Explicit %> <% Dim userName, total, i ' 从此以后所有变量必须 Dim 声明，拼错立刻报错 %>

注意Option Explicit必须是文件里的第一句脚本，前面不能有任何输出（包括 BOM 和空格换行之外的字符），否则会报"必须出现在第一行"。

变量本身还有几点要知道：

• 只有一种数据类型：Variant。它内部会自动区分是数字还是字符串，"1" + 1和"1" & 1结果完全不同，前者是加法得 2，后者是拼接得 "11"。&永远是拼接，+在字符串场景下会试图转数字，这是排错时要盯的第一个点。
• 大小写不敏感。UserName和username是同一个变量，这跟今天大部分语言相反。
• 空值和空字符串不是一回事。数据库里没填的字段读出来是Null，Null & "abc"结果是"abc"，但Null + 1还是Null，参与比较时更是全返回假。判断必须用IsNull(x)，不能写x = ""。
• Empty、Null、Nothing三个别混。未赋值的变量是Empty；数据库空值是Null；对象释放后是Nothing，判断对象用Is Nothing。

3.2 六种语句结构覆盖九成场景

不用背全语法，这六种够用：

<% ' 1. 条件 If score >= 60 Then Response.Write "及格" ElseIf score >= 40 Then Response.Write "补考" Else Response.Write "重来" End If ' 2. 多分支（比一堆 ElseIf 好读） Select Case level Case 1 : Response.Write "初级" Case 2 : Response.Write "中级" Case Else : Response.Write "其他" End Select ' 3. 计数循环 Dim i For i = 1 To 10 Step 1 Response.Write i & "<br>" Next ' 4. 集合遍历（处理 Request.Form 和 Recordset 最常用） Dim key For Each key In Request.Form Response.Write key & " = " & Request.Form(key) & "<br>" Next ' 5. 条件循环 Do While Not rs.EOF Response.Write rs("title") rs.MoveNext Loop ' 6. 提前退出 For i = 1 To 100 If arr(i) = target Then Exit For Next %>

这里有个必须提的坑：For Each遍历Request.Form的时候，取到的是控件名，值要再用Request.Form(key)取一次。很多人写成For Each item In Request.Form然后直接用item当值，结果输出了一堆字段名，自己还纳闷。

3.3 字符串、数字与日期：格式化最常翻车的地方

字符串处理是老 ASP 项目里的重头戏，因为模板引擎不存在，全靠手拼。

<% Dim s, arr, n s = " 张三,李四,王五 " s = Trim(s) ' 去首尾空格，非常常用 arr = Split(s, ",") ' 拆成数组 Response.Write UBound(arr) ' 上界，元素个数是 UBound+1 Response.Write Join(arr, " | ") ' 再拼回去 Response.Write Len(s) ' 长度 Response.Write Left(s, 2) ' 左取 Response.Write Mid(s, 3, 2) ' 中间取 Response.Write InStr(s, "李") ' 查找位置，找不到返回 0 Response.Write Replace(s, "李四", "李四四") n = 3.14159 Response.Write FormatNumber(n, 2) ' 3.14 Response.Write Round(n, 2) ' 3.14 Response.Write FormatPercent(0.256, 1) ' 25.6% Response.Write Year(Now()) & "-" & Month(Now()) & "-" & Day(Now()) Response.Write FormatDateTime(Now(), 1) ' 按系统格式输出日期时间 %>

InStr找不到返回 0 而不是 -1，这个和今天大部分语言相反，判断时写If InStr(s, "x") > 0 Then，别写<> -1。

还有一条血泪经验：拼接 SQL 之前一定要处理单引号。用户输入里带一个'，整条语句就断了，报语法错误；带两个，就可能是注入。正确做法是用Replace(str, "'", "''")做转义，但更正确的做法是根本不用拼接，见第 5 节的参数化。

3.4 数组和字典：从一堆请求参数里捞出你想要的那条

VBScript 的数组是定长的，要动态扩容得用ReDim Preserve，但Preserve只能改最后一维，多维数组用起来很别扭。所以实际项目里，稍微复杂一点的数据结构都用字典：

<% Dim d Set d = Server.CreateObject("Scripting.Dictionary") d.CompareMode = 1 ' 1 = 忽略大小写 d.Add "name", "张三" d("age") = 28 ' 这种写法也能加 If d.Exists("name") Then Response.Write d("name") End If Response.Write d.Count Dim k For Each k In d.Keys Response.Write k & " => " & d(k) & "<br>" Next Set d = Nothing ' 对象用完必须释放 %>

注意Set关键字：给对象赋值必须用Set，漏了会报"Object required"或者更诡异的类型不匹配。这是新手最高频的报错之一，看到这个错先检查是不是漏了Set。

数组和字典的区别，用一句话记：数组按位置取（arr(0)），字典按键取（d("name")）。做表单字段收集、做配置项缓存，用字典；做列表顺序处理，用数组。

4. 五个内建对象：整篇文章的实际工作量都在这里

ASP 之所以能干活，全靠这五个对象。它们不用创建，进了页面就有。我把它们的作用压成一句话：Request 是"进来的"，Response 是"出去的"，Session 是"你这个人的"，Application 是"所有人的"，Server 是"工具箱"。

4.1 Request：四种取值方式别用串

Request("x")这种省略集合名的写法在老代码里到处都是，它会按 QueryString → Form → Cookies → ServerVariables 的顺序挨个找。方便是方便，但有安全隐患，因为客户端可以用查询串覆盖你的预期来源。规范写法是明确指定：

<% Dim uid, kw uid = Request.QueryString("id") ' 从 URL ?id=123 取 kw = Request.Form("keyword") ' 从 POST 表单取 Dim token token = Request.Cookies("token") ' 从 Cookie 取 ' 取值一定要判空 If Len(uid) = 0 Then Response.Write "缺少参数" Response.End End If %>

Request.ServerVariables是一组只读的服务器环境信息，排错时很有用：REMOTE_ADDR拿客户端地址，SERVER_NAME拿主机名，HTTP_USER_AGENT拿浏览器标识，URL和QUERY_STRING拿当前地址。日志里想记一笔"谁在什么时候访问了什么"，用这几个就够了。

判断请求方法的写法：If Request.ServerVariables("REQUEST_METHOD") = "POST" Then。这是区分"首次打开表单"和"提交表单"的标准做法，一个文件里两种逻辑共存。

4.2 Response：输出、跳转、缓冲与编码

Response.Write是最常用的，但写多了页面会很难看，可以简写成<%=变量%>。真正容易出问题的是另外几个：

<% Response.Buffer = True ' 开启缓冲，必须在任何输出之前 Response.Charset = "utf-8" ' 告诉浏览器用什么编码解析 Response.ContentType = "text/html" ' ...一堆处理逻辑... If errFlag Then Response.Clear ' 清掉之前所有输出 Response.Write "出错了" Response.End ' 立刻停止 End If Response.Redirect "list.asp" ' 跳转，注意它默认会结束响应

关于Response.Redirect有个经典陷阱：如果在跳转之后还有代码，某些配置下代码仍会继续执行。稳妥写法是跳转后面紧跟一句Response.End。我见过一段代码在跳转后还在往数据库写日志，结果日志重复记录，查了很久才发现是这个原因。

Response.Buffer = True的意义在于：先攒着，攒够了再发。这样你才能在输出到一半的时候决定清空重来，或者中途改响应头。如果缓冲关着，页面已经开始往外发了，再改Charset就没用了——这是中文乱码的头号成因，下面第 6 节还会展开。

4.3 Session 和 Application：状态放哪儿，什么时候会丢

Session是"一个人的抽屉"，每个访问者一份，互不干扰。典型用法是登录后存用户标识：

<% ' 登录成功后 Session("userID") = rs("id") Session("userName") = rs("name") Session.Timeout = 30 ' 单位是分钟，默认 20 ' 其他页面校验 If IsEmpty(Session("userID")) Then Response.Redirect "login.asp" Response.End End If ' 退出 Session.Abandon ' 主动销毁 %>

Application是"全站共用的公告板"，所有人都看同一份。因为多个请求可能同时改它，所以必须加锁：

<% Application.Lock Application("onlineCount") = Application("onlineCount") + 1 Application.Unlock %>

锁的范围要尽可能小，只包住真正需要互斥的那一句。锁里去做数据库查询，等于让全站请求排队，性能会直接崩掉。

关于Session丢失，我在实际维护中遇到过三种原因：一是超过Timeout没活动，正常过期；二是应用程序池被回收或者站点重启，进程内的 Session 全部清零；三是应用程序池配了多个工作进程（俗称"网络园"），请求被分发到不同进程，各自有各自的 Session，表现就是"一会儿登录一会儿掉线"。前两种只能接受或调超时，第三种必须把工作进程数改回 1，或者把 Session 存到进程外的地方——但那属于架构级改动，一小时里不用展开。

4.4 Server 对象：整个工具箱就记四个方法

Server.CreateObject是创建 COM 组件的唯一入口，数据库连接、字典、文件操作全靠它。Server.MapPath把相对路径转成服务器上的物理路径，读写文件、指定数据库文件位置时必须用它。

Server.HTMLEncode是安全底线：任何用户输入回显到页面上之前，必须过一遍这个。不然人家提交一段带脚本的内容，你直接输出，就是典型的跨站脚本问题。

<% Response.Write Server.HTMLEncode(Request.Form("content")) Response.Write Server.URLEncode("搜索关键词") Response.Write Server.MapPath("./data/db.mdb") Server.ScriptTimeout = 120 ' 单位秒，长任务要调大 %>

还有一个Server.Execute，可以在当前页面里执行另一个 asp 文件并把输出嵌进来，效果类似 include 但更动态。老项目里用它做"局部模板"，不过现在看，这种写法对调试不友好，我一般不建议新增。

5. 连数据库：从能查到能改，中间隔着一层安全

页面不能只有静态内容，一涉及数据就得连库。老 ASP 项目绝大多数用 ADO 这套接口，写法上分 Connection、Recordset、Command 三个角色。理解它们的定位比背语法重要：Connection 是"电话线"，Recordset 是"结果表格"，Command 是"带参数的指令"。

5.1 连接串与连接对象的建立方式

<% Dim conn, connStr ' 文件型数据库（老项目常见） connStr = "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=" & Server.MapPath("/data/site.mdb") ' 服务型数据库 ' connStr = "Provider=SQLOLEDB;Data Source=127.0.0.1;Initial Catalog=mydb;User ID=app;Password=****;" Set conn = Server.CreateObject("ADODB.Connection") conn.Open connStr %>

连接串里的Provider决定了走哪个驱动。文件型数据库在 64 位进程下经常报"未找到提供程序"，回看第 2.2 节的 32 位设置。另外，连接串里带密码的话，别把文件放在网站目录下，.asp文件被下载走可不是闹着玩的；连接文件建议放在站点根目录之外，通过 include 引入。

连接是稀缺资源，用完必须关：

<% conn.Close Set conn = Nothing %>

一个页面开一次、用完关掉，这是最稳的模式。我在老代码里见过每个查询都Open一次 Connection 的写法，小流量看不出问题，并发一上来连接数就爆。

5.2 Recordset 的打开方式决定了你能不能翻页和取行数

<% Dim rs Set rs = Server.CreateObject("ADODB.Recordset") ' 参数顺序：SQL, 连接, 游标类型, 锁类型 rs.Open "SELECT id, title, addTime FROM news ORDER BY addTime DESC", conn, 1, 1 Do While Not rs.EOF Response.Write "<li>" & rs("title") & "</li>" rs.MoveNext Loop rs.Close Set rs = Nothing %>

第三、四个参数直接决定行为，很多人只知道填 1,1 却不知道为什么：

最常踩的坑是：用游标 1 打开，然后去取rs.RecordCount，结果返回 -1。仅向前游标不维护行数，这是设计如此。要总数就用游标 3，或者单独SELECT COUNT(*)查一次——后者其实性能更好，大表上尤其明显。

5.3 参数化查询：别再用字符串拼 SQL 了

拼接的写法长这样，看着直观，实则处处是坑：

' 反面教材，不要这么写 sql = "SELECT * FROM users WHERE name='" & Request.Form("name") & "'"

单引号、分号、注释符，任何一样都能让这条语句变形。正确姿势是用 Command 加参数：

<% Dim cmd, prm Set cmd = Server.CreateObject("ADODB.Command") Set cmd.ActiveConnection = conn cmd.CommandText = "SELECT id, name FROM users WHERE name = ? AND status = ?" cmd.CommandType = 1 ' 1 = 文本命令 ' CreateParameter(名称, 类型, 方向, 长度, 值) ' 202 = adVarWChar（宽字符），200 = adVarChar Set prm = cmd.CreateParameter("p1", 202, 1, 50, Request.Form("name")) cmd.Parameters.Append prm Set prm = cmd.CreateParameter("p2", 3, 1, , CLng(Request.Form("status"))) cmd.Parameters.Append prm Set rs = cmd.Execute %>

参数化的好处不只是防注入，还能让数据库复用执行计划，同一语句反复执行时性能更好。写新代码一律用参数化，这是没有例外的。

5.4 分页与释放：写完整才算会

列表页要分页，用静态游标配合PageSize是改动量最小的方案：

<% Dim rs, curPage, totalPage curPage = CLng(Request.QueryString("page")) If curPage < 1 Then curPage = 1 Set rs = Server.CreateObject("ADODB.Recordset") rs.PageSize = 20 rs.Open "SELECT id, title FROM news ORDER BY id DESC", conn, 3, 1 If Not rs.EOF Then totalPage = rs.PageCount If curPage > totalPage Then curPage = totalPage rs.AbsolutePage = curPage Dim i For i = 1 To rs.PageSize If rs.EOF Then Exit For Response.Write "<li>" & rs("title") & "</li>" rs.MoveNext Next End If %>

再补一句页脚链接：Response.Write "<a href=""?page=" & (curPage+1) & """>下一页</a>"。注意 VBScript 里字符串内的双引号要写两遍，这是拼 HTML 时最容易打错的地方，我一般建议用单引号包 HTML 属性省点事。

还有一条必须强调：Recordset和Connection用完一定要Close+Set ... = Nothing。老项目跑久了变慢、连接池耗尽，很多时候就是漏了这两句。

6. 出问题时的排查链路：500、乱码、权限这三座山

老 ASP 最劝退的地方是报错信息不友好。下面三条是我这些年反复走的排查路径，直接照着走基本能定位到。

6.1 500 错误看不到详情，先打开详细错误

默认配置下，服务器只告诉客户端"发生服务器错误"，具体行号藏起来了。开启方式有两个层次：在服务器管理界面里，找到对应站点的"ASP"配置项，把"将错误发送到浏览器"设为 True；或者用调试模式。开启后刷新，就能看到类似"Microsoft VBScript 运行时错误 0x800A000D 类型不匹配: 'rs'"这样的信息，行号直接给出来，效率完全不同。

开启详细错误的顺序建议是：先看行号 → 看那一行的对象是否Set过 → 看变量是否为空 → 再怀疑 SQL。我遇到过的 500 里，一半是漏了Set，三成是 SQL 写错，剩下的才是权限和组件问题。

6.2 中文乱码：三层编码必须对齐

乱码不是"某一处没设"，而是三层编码不一致：文件保存的编码、页面声明的编码、响应头告诉浏览器的编码。三层统一到 UTF-8 就没问题：

<% @LANGUAGE="VBSCRIPT" CODEPAGE="65001" %> <% Response.Charset = "utf-8" Session.CodePage = 65001 %>

三点细节：CODEPAGE="65001"是 UTF-8 的代码页，必须写在文件第一行；文件本身要存成 UTF-8，建议不带 BOM，带 BOM 有时会在页面顶部多出看不见的字符，导致"响应头已发送"之类的怪错；如果表单提交上来的中文是乱码，检查Session.CodePage是否在读取 Request 之前就设置好了。

如果三层都是 UTF-8 还是乱码，那问题多半在数据库那一端：数据库表本身的字符集、字段类型是否用了宽字符（nvarchar而非varchar）。这条链路很长，但排查顺序是固定的：先看浏览器实际收到的字节，再看页面源码，最后看数据库存储。

6.3 权限、父路径与文件被锁的典型现象

下面这张表是我整理的"现象 → 原因"对照，遇到时照着查：

排查的核心心法是：把"我以为"换成"我能验证"。别猜，去看日志、去看实际响应、去写个最小复现页面。这一条比任何技巧都值钱。

7. 一小时的收尾动作：三个练手任务与后续该往哪走

看完全文不等于会了。我建议的练手顺序是这样，难度递增但都在一小时内能完成：

第一个任务，做一个"提交-显示"的表单页。一个文件里用REQUEST_METHOD判断首次打开还是提交，提交后用Server.HTMLEncode处理再回显。这个任务练的是 Request、Response、条件判断和编码意识。

第二个任务，加一个登录和会话校验。登录成功写Session，另一个页面开头判断IsEmpty(Session("userID"))，为空就跳回登录页。练的是状态管理和跳转后Response.End的习惯。

第三个任务，把上面两个接到数据库上：用户表查一条记录校验密码（真实项目当然要加盐哈希，这里只是跑通流程），新闻表做一个带分页的列表。练的是 Connection、Command、参数化、Recordset 释放这条完整链路。

跑完这三个，你就具备了"能接手维护"的最低水位。再往后走，方向大致三条：一是往 ASP.NET 或更现代的服务端技术迁移，把老代码的意图翻译过去；二是做安全加固，把拼接 SQL、未编码输出、明文密码这些历史遗留逐条清掉；三是做性能，从连接复用、查询索引、页面缓存入手。这三条都不在一小时的范围内，但你在这一小时里建立的那张"请求怎么走、状态存在哪、代码执行顺序是什么"的地图，是后面所有工作的地基。

最后分享一个小习惯：接手任何一个老 ASP 站点，我做的第一件事永远是新建一个probe.asp，里面输出服务器时间、Server.ScriptTimeout、当前目录路径、几个关键ServerVariables，再连一次数据库打印版本号。这个文件不删，以后每次"感觉环境不对"，打开它看一眼，比翻十次配置界面都快。