企业官网建设流程全解析

1. 先把预期摆正：一小时能拿下的到底是哪一部分 ASP

很多人搜 ASP基础知识，心里想的其实是同一件事：手上有一套跑了很多年的老系统，页面后缀是 .asp，出问题了没人敢动，或者临时要补个小功能，翻文档发现全是二十年前的资料，看完还是不知道怎么下手。我自己也走过这条路，一开始把它当成一门要系统学的新语言，结果花了两天时间看语法，真正打开编辑器那一刻还是懵的。后来才想明白，经典 ASP 根本不是一门需要"学完"的技术，它是一套运行在服务端的脚本环境，语法简单到有点寒酸，难的地方从来不在语言本身，而在于它跟 Web 服务器、跟数据库、跟老代码习惯的耦合方式。

先把概念钉死：ASP（Active Server Pages）是服务端页面技术，页面文件后缀 .asp，里面混着 HTML 和 VBScript。浏览器请求一个 .asp 文件时，服务器先把里面的脚本跑完，把Response.Write出来的东西和原本的 HTML 拼成一整块，再把纯 HTML 结果吐给浏览器。所以你在浏览器里"查看源代码"，永远看不到 ASP 的逻辑代码，只能看到它生成的结果。这一点跟后来的各种服务端渲染方案是一个思路，只是 ASP 出现得早，工具链原始得多。

一小时的合理目标是什么？我的判断是：能独立把环境跑起来，能看懂一个中等复杂度的 .asp 页面在干什么，能用内置对象接收表单、读写 Session，能连上数据库把一张表渲染成 HTML 表格，并且遇到 500 错误时知道去哪儿找线索。这些够你接手维护、够你补小功能、也够你判断这段老代码该修还是该重写。至于性能调优、组件注册、COM 对象开发这些，一小时碰都不要碰，碰了只会打击信心。

下面这套路线是我自己整理过好几遍的顺序，从环境到语法到对象到数据库，每一步都是"能立刻看到结果"的，不做纯理论铺垫。

1.1 为什么老项目里还留着 ASP，而不是全换掉

先说清楚这件事，避免你学完觉得"这玩意儿早该淘汰了"。经典 ASP 之所以在很多内部系统里活到今天，原因很现实：它的部署成本几乎为零。一台装了 IIS 的服务器，把文件拷进目录，浏览器一开就能跑，没有编译、没有依赖包、没有构建产物、没有 node_modules。对于那种"五年没人动、一年改两次"的内部管理系统来说，这个特性太香了。重写一套要评估、要排期、要迁移数据、要做回归测试，而这些成本远比"继续让它跑着"高得多。

另一个原因是它的调试路径短。页面出问题，错误信息直接打在浏览器上，行号都给你标出来，不需要翻日志、不需要断点、不需要重启服务。对于小工具型的内部页面，这个体验其实相当友好。我见过不少运维同事用 ASP 写临时的数据导出页、状态查询页，十几行代码搞定，用完就扔，比折腾一套现代框架快得多。

所以这篇内容面向的人群很明确：需要维护历史系统的开发者、要临时写内部小工具的技术人员、以及想搞明白"这堆老文件到底怎么运转"的接手人。如果你是要从零学一门服务端语言做新项目，那这一小时花在别处更值。

1.2 一小时的取舍清单：学什么、跳过什么

时间有限，必须做减法。我把内容分成三档，你按需取用。

这张表的核心逻辑是：按"打开一个页面到它显示结果"这条链路来排序。链路上必须经过的环节先学，旁支末节后补。很多人学不下去就是因为从语法书第一页开始啃，啃到数组那一章已经忘了自己要干什么了。

2. 环境与第一个页面：十分钟跑通最小闭环

2.1 在 Windows 上把 IIS 和 ASP 功能打开

经典 ASP 只能跑在 IIS 上，这一点没有第二条路。IIS 是 Windows 自带的组件，不需要额外下载。开启路径在"控制面板 → 程序和功能 → 启用或关闭 Windows 功能"，展开"Internet Information Services"，注意别只勾最外层那个框，一定要往下展开到这三层：

• 万维网服务 → 常见 HTTP 功能：至少勾上"默认文档""静态内容""HTTP 错误""目录浏览"（调试时很有用）
• 万维网服务 → 应用程序开发功能：勾上ASP，这一项是关键，很多人漏了它，结果 .asp 文件直接被当静态文件下载下来
• Web 管理工具 → IIS 管理控制台：方便后面改配置

勾完点确定，系统会装一两分钟。装完打开浏览器访问http://localhost，看到 IIS 的默认欢迎页就说明服务起来了。如果你的机器上装了其他占 80 端口的服务，访问会失败，这时候去 IIS 管理器里把默认站点的端口改掉，或者先停掉冲突的服务。

注意：ASP 这一项如果不勾，浏览器请求 .asp 文件时不会执行脚本，而是弹出下载框，或者返回 404。这是新手最常踩的第一个坑，表现形式还很迷惑，容易被误判成"文件放错目录了"。

站点目录默认在C:\inetpub\wwwroot。我一般不在系统盘里做实验，会在 D 盘建一个D:\asp-lab目录，然后在 IIS 管理器里右键"网站 → 添加网站"，物理路径指向它，端口给个 8080 之类的，避免跟别的服务打架。这样做的另一个好处是文件权限干净，不用去动系统目录的 ACL。

权限这一块要提一句。IIS 的工作进程身份是IIS_IUSRS组，如果你的目录在非系统盘，默认继承的权限可能不够，表现是访问页面报 401.3 或者 500。最省事的做法是给这个目录加上IIS_IUSRS的读取和执行权限。右键目录 → 属性 → 安全 → 编辑 → 添加 → 输入IIS_IUSRS→ 确定 → 勾上"读取和执行""列出文件夹内容""读取"。写权限只在需要上传文件或者写日志的目录上单独开，别整个站点开写权限。

2.2 第一个 .asp 文件：三种输出方式的差别

在站点根目录建一个hello.asp，写入下面内容：

<%@ Language="VBScript" CodePage="65001" %> <% Response.Charset = "utf-8" Dim userName, nowTime userName = "world" nowTime = Now() %> <!DOCTYPE html> <html> <head><meta charset="utf-8"><title>第一个页面</title></head> <body> <h1>Hello, <%= userName %>!</h1> <p>服务器时间：<%= nowTime %></p> <p>当前文件物理路径：<%= Server.MapPath("hello.asp") %></p> </body> </html>

保存的时候有个细节必须注意：文件编码选 UTF-8 无 BOM，或者直接存成 ANSI。如果存成 UTF-8 带 BOM，BOM 那三个字节会在<%@ %>之前被当成输出内容，页面顶部就会多出一行空白甚至乱码，而且报错信息会很莫名。编辑器里一般会明确标出"UTF-8 with BOM"，选错就改回来。

这段代码展示了 ASP 的三种输出手法，实际项目中它们是混着用的：

跑起来之后，你会看到页面正常显示中文、时间和物理路径。到这一步，环境就算通了。我建议你在这里故意制造一个错误，比如把Server.MapPath拼错成Server.MapPat，看看浏览器返回什么——大概率是一个只说"500 - 内部服务器错误"的白板页面。原因后面第 7 章会讲，这里先留个印象。

2.3 打开详细错误：让报错说人话

默认配置下，IIS 为了"安全"，会把详细错误信息藏起来，只给一个笼统的 500。开发阶段这样完全没法干活。打开 IIS 管理器，选中你的站点，双击"错误页"功能，右侧点"编辑功能设置"，选"详细错误"；或者更彻底一点，在站点根目录的web.config里写：

<configuration> <system.webServer> <httpErrors errorMode="Detailed" existingResponse="PassThrough" /> <asp scriptErrorSentToBrowser="true" /> </system.webServer> </configuration>

改完立刻生效，不需要重启。再访问刚才那个错误页面，你就能看到具体是哪一行、什么错误，比如"类型不匹配: 'Server.MapPat'"。这个开关只在开发环境开，上线前记得关掉，因为它会把文件物理路径、代码行号全部暴露给访问者。

提示：web.config放错位置不生效是个高频问题。它必须放在站点根目录或者应用目录下，IIS 是按目录层级继承配置的。改完不生效，先确认文件位置，再确认是不是被上层目录的配置覆盖了。

3. VBScript 基本功：够用就好的六件事

3.1 变量声明与 Option Explicit：别让拼写错误藏起来

VBScript 里所有变量都是Variant类型，用Dim声明，不声明也能直接用。听起来很方便，实际上是灾难的开始：一个变量名拼错，VBScript 会默默给你创建一个新变量，值是空，然后你的逻辑就在没有任何报错的情况下跑偏了。

所以我的习惯是，每个文件第一行（在<%@ %>之后）加一句：

<% Option Explicit %>

这句的作用是强制所有变量必须先Dim才能用，拼错立刻报"变量未定义"。代价是多打几个字，收益是省掉半小时的排查。老代码里经常没有这句，你新加代码的时候自己加上，不会影响原有逻辑。

变量作用域只有两级：过程内和全局。在Sub/Function里Dim的是局部变量，在文件顶层Dim的是页面级变量，页面内所有脚本块共享。这里有个容易忽略的点：同一页面的多个<% %>块共享顶层变量，所以你可以在这块里定义、在下面那块里用，这在写模板式的老页面里非常常见。

<% Dim pageTitle pageTitle = "订单明细" %> <h2><%= pageTitle %></h2> <% ' 下面这块仍然能访问 pageTitle Response.Write "标题长度：" & Len(pageTitle) %>

3.2 类型转换的坑：Variant 不是万能的

虽然变量都是 Variant，但值是有子类型的：字符串、整数、浮点、日期、布尔、空、Null。麻烦就出在Null和Empty上。数据库里取出来的空字段是Null，Null参与任何运算结果还是Null，Null & "abc"得到的是"abc"（字符串拼接例外），但Null + 1得到Null，然后你在页面上就看到一片空白，查半天不知道问题在哪。

常见转换函数有这么几个，必须形成肌肉记忆：

我的实战写法是先兜底再转换：

<% Dim amount, amountNum amount = rs("amount") If IsNull(amount) Or Not IsNumeric(amount) Then amountNum = 0 Else amountNum = CDbl(amount) End If %>

这种"先判空再转"的模式在老代码里会重复出现几十次，看着啰嗦，但它是唯一稳妥的做法。后来我干脆写了一个SafeNum函数放在公共文件里，所有页面<!--#include file="common.asp"-->引进来用，省事很多。

3.3 分支、循环与字符串处理：老代码的三大高频区

分支就两种，If...Then...Else...End If和Select Case。多层判断用Select Case更清爽，尤其是处理状态码这种场景：

<% Select Case orderStatus Case 0 statusText = "待付款" Case 1 statusText = "已付款" Case 2, 3 statusText = "已发货" Case Else statusText = "未知状态" End Select %>

循环有For...Next（计数）、For Each...Next（遍历集合）、Do...Loop（条件）。遍历 Recordset 用的是Do While Not rs.EOF ... rs.MoveNext ... Loop，这个模式你必须背下来，因为它是所有数据列表页的骨架。

字符串函数是 VBScript 里最实用的部分，实际项目中出现频率最高的就这几个：Len求长度、Mid(s, start, len)截取、InStr(s, sub)找位置、Replace(s, a, b)替换、Split(s, delim)拆分、Join(arr, delim)合并、Trim/LTrim/RTrim去空格、UCase/LCase大小写。做表单校验、拼接 SQL、生成 HTML 片段，全靠它们。

这里有个细节值得单独说：Mid的第二个参数是从 1 开始计数的，不是 0。从其他语言转过来的人第一次用必踩。同理InStr返回的位置也是从 1 开始，找不到返回 0。写判断的时候要用If InStr(s, "x") > 0 Then，不能写If InStr(s, "x") Then，因为返回 0 在布尔判断里是 False，但返回 1 才是 True，逻辑上碰巧对，可一旦有人把返回值和 -1 比较就全乱了。养成用> 0的习惯。

3.4 Sub 与 Function：代码复用的最小单位

Sub不返回值，Function返回值用函数名 = 值赋值。调用 Sub 用Call或者直接写名字，调用 Function 必须用括号接返回值。

<% ' 公共函数：HTML 转义，防止 XSS 和显示错乱 Function H(s) If IsNull(s) Then H = "" Else H = Server.HTMLEncode(CStr(s)) End If End Function ' 公共函数：格式化金额，保留两位 Function Money(v) If IsNull(v) Or Not IsNumeric(v) Then Money = "0.00" Else Money = FormatNumber(CDbl(v), 2, -1, 0, 0) End If End Function %>

H这个函数我强烈建议每个项目都备一个。老代码里最常见的毛病就是直接把数据库字段Response.Write出去，字段里有<或者双引号，页面布局立刻崩，还可能被注入脚本。所有输出点统一走H()包一层，五分钟能改完一个页面，收益极大。

FormatNumber的参数顺序要记准：FormatNumber(表达式, 小数位数, 是否显示前导零, 是否用括号表示负数, 是否用千分位)。第三个参数传 -1 表示用系统默认，第四个传 0 表示负数用减号而不是括号，第五个传 0 表示不加千分位逗号（加逗号在表格里容易看花眼，按需选）。

4. 五大内置对象：ASP 的真正骨架

语法是皮，内置对象才是骨。ASP 提供Request、Response、Server、Session、Application五个对象，几乎所有功能都围绕它们展开。老代码里你会反复看到Request("xx")、Session("user")这种写法，看不懂就完全没法维护。

4.1 Request：数据从五个口袋里掏

Request是"入"，负责接收浏览器端传来的所有东西。它内部有五个集合，按固定顺序查找：

直接写Request("id")会按上面顺序依次找，找到就返回。看起来很省事，实际上是隐患：如果同一个名字在 QueryString 和 Form 里都有，你拿到的可能不是你以为的那个。我接手代码时看到Request("xx")一律改成明确的集合名，尤其是涉及权限判断的变量，绝对不能让它有歧义。

ServerVariables里有两个字段值得记住：REMOTE_ADDR拿客户端 IP，HTTP_USER_AGENT拿浏览器标识。前者常用于写操作日志，后者偶尔用于兼容性判断。注意如果系统前面有反向代理，REMOTE_ADDR拿到的是代理的地址，真实 IP 要看HTTP_X_FORWARDED_FOR，但这个头可以被伪造，只能用于展示，不能用于安全判断。

<% Dim clientIp, ua clientIp = Request.ServerVariables("REMOTE_ADDR") ua = Request.ServerVariables("HTTP_USER_AGENT") %>

还有一个高频场景是判断"这个参数有没有传"。用Request.QueryString("id")在参数不存在时返回Empty，IsEmpty()可以判断。但更稳妥的写法是先取出来再判断长度：

<% Dim id id = Trim(Request.QueryString("id") & "") If id = "" Then Response.Write "缺少参数 id" Response.End End If If Not IsNumeric(id) Then Response.Write "参数 id 格式不正确" Response.End End If %>

& ""这个小技巧很实用，它能同时把Null和Empty变成空字符串，让后面的判断逻辑变得干净。Response.End会立刻终止页面执行，是参数校验失败后最直接的退出方式。

4.2 Response：控制输出的每一个细节

Response是"出"，除了最常用的Write，还有几个属性和方法必须知道：

• Response.Buffer = True：开启缓冲，页面内容先攒着，全部跑完再一次性发送。IIS 默认已开启，一般不用管，但如果代码里要Redirect或中途改变ContentType，就必须先缓冲。
• Response.ContentType：告诉浏览器返回的是什么类型。默认text/html，返回 JSON 要设成application/json，返回图片要设成image/jpeg。
• Response.Charset：指定字符集，UTF-8 页面写utf-8。这一句必须在任何输出之前执行，晚了就无效。
• Response.Redirect url：跳转。它会给浏览器发 302 状态码，后面的代码仍会执行，所以后面一定要跟Response.End。
• Response.End：立即停止执行并输出已缓冲的内容。
• Response.Cookies("name") = value：写 Cookie，设置过期时间用Response.Cookies("name").Expires = DateAdd("d", 7, Now)。
• Response.Clear：清空缓冲区，常用于出错时丢弃已生成的内容再输出错误页。

<% Response.Buffer = True Response.Charset = "utf-8" Response.ContentType = "application/json" ' 组装 JSON（手写，经典 ASP 没有内置序列化） Dim json json = "{""code"":0,""msg"":""ok"",""data"":[]}" Response.Write json Response.End %>

手动拼 JSON 的时候，双引号要写成两个双引号，字符串里的特殊字符必须转义，否则前端JSON.parse直接报错。我一般会写一个JsonStr(s)函数专门处理：替换反斜杠、双引号、换行、制表符，最后用Server.HTMLEncode处理尖括号防注入。这套东西写一次就能复用很久。

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 的实现依赖客户端 Cookie 里的一个会话 ID，所以如果用户禁用了 Cookie，Session 就失效。另外，IIS 默认 20 分钟无操作就回收，长表单页面填到一半超时是经典事故，把Timeout调到 30 到 60 分钟是常规操作。会话存在内存里，服务器重启或者应用池回收，所有会话立刻清空，这一点要提前跟业务方说清楚，别让他们以为"登录了就该一直在线"。

Application是"全站一份"，用来存访问计数、全局配置这类共享数据。关键在于并发：多个请求同时读写同一个 Application 变量会出问题，所以必须加锁。

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

Lock和Unlock之间的代码是串行的，所以范围一定要小，只包住读写那一两行，别把查询数据库也塞进去，否则全站请求排队，性能直接崩。

提示：Application 变量同样存在内存里，应用池一回收就归零。要用它做计数器，就得接受"数据会丢"这个前提，或者定期落库。我见过有人拿它当唯一数据源做统计，结果每次重启数据就清零，被业务方追着问了半个月。

4.4 Server 对象：看着不起眼，处处都要用

Server有三个方法用得最多。Server.MapPath(相对路径)把虚拟路径转成物理路径，所有涉及文件读写的地方都要它。Server.HTMLEncode(s)转义 HTML 特殊字符，输出用户提交的内容必须包一层。Server.URLEncode(s)对 URL 参数编码，拼跳转链接时用。Server.CreateObject(progId)创建 COM 组件实例，连数据库、发邮件、处理文件都靠它。

<% Dim conn, fso, filePath filePath = Server.MapPath("/data/config.txt") Set fso = Server.CreateObject("Scripting.FileSystemObject") Set conn = Server.CreateObject("ADODB.Connection") %>

CreateObject前面加Server.的意义在于，创建出来的对象运行在服务器上下文里，能访问 ASP 的内置对象、能参与事务、能被对象池管理。有些老代码写成CreateObject("ADODB.Connection")也能跑，但少了上下文支持，在某些场景下会出问题。统一用Server.CreateObject是更稳妥的习惯。

用完对象记得释放：Set conn = Nothing。VBScript 有垃圾回收，但不及时释放会拖到页面结束才回收，高频页面里连接数很快就堆上去了。

5. 数据库打通：ADO 三板斧与注入防护

5.1 连接字符串怎么拼，为什么这么拼

经典 ASP 连数据库靠 ADO，核心对象只有三个：Connection（连接）、Recordset（结果集）、Command（命令）。先看连接字符串，这是最容易出错的地方。

连 SQL Server：

<% Dim conn, connStr connStr = "Provider=SQLOLEDB;Data Source=127.0.0.1;Initial Catalog=MyDb;User ID=sa;Password=***;" Set conn = Server.CreateObject("ADODB.Connection") conn.Open connStr %>

逐段说明：Provider指定驱动，SQL Server 用SQLOLEDB；Data Source是服务器地址，本机就写127.0.0.1或者localhost；Initial Catalog是数据库名；后面是账号密码。如果用 Windows 集成验证，就把账号密码换成Integrated Security=SSPI，但这样 IIS 的工作进程身份必须有权访问数据库，配置起来麻烦，老项目里大多还是用 SQL 账号。

连 Access：

<% Dim conn, connStr connStr = "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=" & Server.MapPath("/data/site.mdb") Set conn = Server.CreateObject("ADODB.Connection") conn.Open connStr %>

这里有个必须知道的坑：Microsoft.Jet.OLEDB.4.0只有 32 位版本。如果你的应用池跑在 64 位模式下，会报"未找到提供程序"。解决办法有两个：把应用池的"启用 32 位应用程序"设为 True，或者改用Microsoft.ACE.OLEDB.12.0（需要单独装驱动）。前者不动代码，后者要改字符串，看你手上有什么条件。

注意：连接字符串里带密码，绝对不能写死在每个页面里。我的做法是单独建一个conn.asp，里面只放连接代码，所有页面通过<!--#include file="conn.asp"-->引入。这样换服务器只改一个文件，也方便后续把密码挪到配置文件里。

5.2 Recordset 遍历：所有列表页的共同骨架

拿到连接就可以查数据了。最基础的写法：

<% Dim rs, sql sql = "SELECT id, title, amount, createTime FROM orders WHERE status = 1 ORDER BY id DESC" Set rs = Server.CreateObject("ADODB.Recordset") rs.Open sql, conn, 1, 1 ' 1=adOpenKeyset, 1=adLockReadOnly %> <table border="1" cellpadding="6"> <tr><th>编号</th><th>标题</th><th>金额</th><th>时间</th></tr> <% Do While Not rs.EOF %> <tr> <td><%= rs("id") %></td> <td><%= H(rs("title")) %></td> <td><%= Money(rs("amount")) %></td> <td><%= rs("createTime") %></td> </tr> <% rs.MoveNext Loop %> </table> <% rs.Close Set rs = Nothing conn.Close Set conn = Nothing %>

这段骨架请务必背熟，因为老项目里 80% 的页面都是它的变体。几个参数解释一下：rs.Open的第三个参数是游标类型，1 表示键集游标，能读能改；第四个是锁定类型，1 表示只读。只读场景就传1, 1，性能最好。如果只是查一次就丢，也可以传0, 1（仅向前），速度更快，但不能RecordCount。

rs.RecordCount在仅向前游标下返回 -1，这是很多人踩过的坑，明明有数据却显示"共 -1 条"。要用它必须先rs.CursorLocation = 3（客户端游标）再rs.Open，或者换键集/静态游标。数据量大时客户端游标会把整个结果集拉到内存，慎重。

分页在经典 ASP 里也是手工活。rs.PageSize = 20配合rs.AbsolutePage = pageNo是原生支持的方式，但同样依赖游标类型和 RecordCount。数据量大的表，我更倾向自己拼TOP加NOT IN的子查询，或者直接用ROW_NUMBER()，把分页压力交给数据库。

5.3 参数化查询：这条线不能省

拼接 SQL 是经典 ASP 最容易出问题的地方。看这段代码：

<% Dim sql, keyword keyword = Request.QueryString("kw") sql = "SELECT * FROM article WHERE title LIKE '%" & keyword & "%'" %>

如果keyword传进来是' OR 1=1 --，SQL 直接变成WHERE title LIKE '%' OR 1=1 --%'，全表数据全部返回。更糟的写法能直接删表。这不是理论风险，是真实存在的老系统漏洞，我接手过的项目里至少一半存在这个问题。

正确做法是使用Command对象加参数：

<% Dim cmd, param, sql Set cmd = Server.CreateObject("ADODB.Command") cmd.ActiveConnection = conn cmd.CommandType = 1 ' adCmdText sql = "SELECT id, title FROM article WHERE title LIKE ? AND status = ?" cmd.CommandText = sql cmd.Parameters.Append cmd.CreateParameter("kw", 200, 1, 200, "%" & keyword & "%") ' 200=adVarChar, 1=adParamInput cmd.Parameters.Append cmd.CreateParameter("st", 3, 1, 4, 1) ' 3=adInteger Set rs = cmd.Execute %>

参数化的本质是把"SQL 结构"和"数据值"分开传输，数据库不会把数据当成语句的一部分解析，注入就无从谈起。这套常量不好记，我一般会在公共文件里定义好：

<% Const adCmdText = 1 Const adParamInput = 1 Const adVarChar = 200 Const adInteger = 3 Const adDouble = 5 Const adDBTimeStamp = 135 %>

提示：LIKE 查询的参数要自己在值里加%，不要在 SQL 里写LIKE ?%，那是语法错误。另外参数长度要和字段长度匹配，adVarChar的 size 传小了会截断，传大了浪费。

改造老代码时不用一次全改完，可以按"用户输入是否进入 SQL"来筛，凡是Request取的值拼进 SQL 的，优先改。改一个页面大概十几分钟，但能彻底消除一类风险。

6. 一个完整小例子：留言板从零到能跑

6.1 表结构与文件划分

光看零散片段很难串起来，用一个留言板把前面的东西全用上。数据库里建一张表（SQL Server 语法，Access 把INT IDENTITY换成AUTOINCREMENT）：

CREATE TABLE guestbook ( id INT IDENTITY(1,1) PRIMARY KEY, userName NVARCHAR(50) NOT NULL, content NVARCHAR(500) NOT NULL, createTime DATETIME NOT NULL DEFAULT GETDATE(), ip VARCHAR(50) )

文件划分就四个：

6.2 列表页与提交页的关键代码

conn.asp：

<% Dim conn, connStr connStr = "Provider=SQLOLEDB;Data Source=127.0.0.1;Initial Catalog=MyDb;User ID=sa;Password=***;" Set conn = Server.CreateObject("ADODB.Connection") conn.Open connStr %>

post.asp：

<%@ Language="VBScript" CodePage="65001" %> <!--#include file="common.asp"--> <!--#include file="conn.asp"--> <% Response.Charset = "utf-8" Dim userName, content, ip userName = Trim(Request.Form("userName") & "") content = Trim(Request.Form("content") & "") ip = Request.ServerVariables("REMOTE_ADDR") & "" If Len(userName) = 0 Or Len(userName) > 50 Then Response.Write "昵称不能为空且不超过50字" Response.End End If If Len(content) = 0 Or Len(content) > 500 Then Response.Write "内容不能为空且不超过500字" Response.End End If Dim cmd Set cmd = Server.CreateObject("ADODB.Command") cmd.ActiveConnection = conn cmd.CommandType = 1 cmd.CommandText = "INSERT INTO guestbook (userName, content, ip) VALUES (?, ?, ?)" cmd.Parameters.Append cmd.CreateParameter("u", 200, 1, 50, userName) cmd.Parameters.Append cmd.CreateParameter("c", 200, 1, 500, content) cmd.Parameters.Append cmd.CreateParameter("i", 200, 1, 50, ip) cmd.Execute Response.Redirect "list.asp" Response.End %>

这里有几个刻意为之的地方。第一，所有取参都加了& ""和Trim，杜绝Empty和前后空格带来的判断失误。第二，长度校验在服务端做，因为前端的maxlength可以绕过。第三，写库全走参数化。第四，Response.Redirect后面必须跟Response.End，否则后面的代码还会跑，虽然这里没代码，但养成习惯能避免很多诡异问题。

list.asp里的循环部分和前面 5.2 的骨架一样，只是多了分页和空数据提示：

<% If rs.EOF Then Response.Write "<p>还没有留言，来抢个沙发。</p>" Else Do While Not rs.EOF %> <div class="item"> <strong><%= H(rs("userName")) %></strong> <span><%= rs("createTime") %></span> <p><%= H(rs("content")) %></p> </div> <% rs.MoveNext Loop End If %>

注意H()的使用位置：昵称和内容都来自用户输入，必须转义。时间来自数据库，格式可控，不用包。判断顺序也重要，先判断EOF再进循环，否则空表时会直接报错。

这套代码加起来不到 100 行，但涵盖了环境、语法、内置对象、数据库、安全五个层面的核心知识点。我一般建议新手照着敲一遍，不要复制粘贴，敲的过程中你会遇到各种小报错，那些报错就是最好的教材。

7. 报错排查实录：最常见的八类坑

7.1 500 错误怎么定位

看到 500 先别慌，按这个顺序查：

还有一类是"代码没错但结果不对"，比如查询该返回 10 条只返回 1 条。这种八成是Recordset打开方式的问题，或者循环里忘了MoveNext导致死循环然后被脚本超时掐断。IIS 默认脚本超时是 90 秒，超时会返回 500，日志里能看到超时记录。临时排查可以在页面顶部加Server.ScriptTimeout = 300，但生产环境别这么干，超时说明逻辑本身有问题。

7.2 中文乱码：三个位置必须一致

乱码是经典 ASP 的头号顽疾，原因是编码涉及三个环节，任意一个不一致就出问题：

1. 文件本身的保存编码：ASP 文件必须是 ANSI 或 UTF-8 无 BOM，带 BOM 会在输出开头插入三个不可见字符。
2. 页面声明的代码页：<%@ Language="VBScript" CodePage="65001" %>和Response.Charset = "utf-8"要成对出现。
3. 数据库连接的字符集：SQL Server 用NVARCHAR字段一般不会有问题，Access 要注意.mdb的排序规则。

排查方法很直接：新建一个只有Response.Write "中文测试"的页面，如果这个页面正常，说明环境和文件编码没问题，问题在数据库或者表单提交环节。如果这个页面就乱，先检查文件编码，再检查CodePage。

表单提交的乱码还有一层：Request.Form的解析依赖Session.CodePage。在文件顶部加Session.CodePage = 65001，能解决大部分 POST 中文乱码。这个设置必须在读取任何表单数据之前执行，晚了就白设。

7.3 会话丢失与路径陷阱

会话突然丢，用户被踢回登录页，常见原因有三个：应用池回收（默认闲置 20 分钟回收，可以关掉闲置回收或调长时间）、Session.Timeout太短、用户在多个标签页同时操作导致会话 ID 变化。排查时可以写个诊断页，把Session.SessionID、Session.Timeout、Session("userId")打印出来，刷新几次看 ID 有没有变，变了就说明会话被重建了。

路径陷阱主要出在Server.MapPath和 include 上。<!--#include file="xxx"-->是相对当前文件的路径，<!--#include virtual="/xxx"-->是相对站点根目录的路径。子目录里的页面用file引用上级目录的文件，必须写成../common.asp，而..需要在 IIS 里开启"启用父路径"，默认是关闭的，关着就报错。我吃过这个亏，一个子目录页面死活引不进来公共文件，查了半小时才发现是父路径没开。

提示：能开父路径就开，但更省心的做法是把公共文件放到站点根目录，所有页面统一用virtual引用，路径永远不变，页面挪目录也不用改。

8. 老项目维护心得与安全加固清单

8.1 接手历史代码的检查顺序

拿到一套陌生的 ASP 项目，我不建议从第一个文件开始读，效率太低。我习惯按这个顺序摸一遍：

先看目录结构，找出公共文件（conn.asp、common.asp、inc/之类的目录），这些是所有页面的入口，读懂它们等于读懂半个项目。再看数据库连接字符串，确认连的是哪个库、用的什么账号，这直接决定你能不能在本地跑起来。然后找登录页和权限校验逻辑，搞清楚"谁能进哪个页面"，因为老项目的权限往往是在每个页面顶部手写一段If Session("xx") = "" Then Response.Redirect，没有统一入口。最后挑一个最典型的业务页面（通常是列表页）完整读一遍，把它的请求参数、SQL、输出结构理清楚，其他页面基本都是它的变体。

这个过程一般两三个小时能完成，比盲目读代码快得多。读的时候我习惯开一个记事本，把"这个页面干什么、依赖哪些表、有哪些可疑写法"记下来，后面改功能的时候直接查笔记。

8.2 加固清单：能改的立刻改

接手老系统时，下面这几件事我会优先做，因为改动小、收益大：

第一条和第二条是重中之重。我见过一个系统，后台登录页的账号密码查询是直接拼接的，输入' OR '1'='1就能进去，而那个系统里存着几万条客户信息。这种问题不需要重构，改一个函数调用就能解决，但需要有人真正去看。

另外提一个容易被忽略的点：<!--#include-->引用的文件如果放在站点目录里，是可以被直接访问的。比如conn.asp里有数据库密码，用户直接访问/conn.asp虽然看不到源码（会被执行），但如果服务器配置出错或者文件被改名成.txt，密码就全暴露了。稳妥做法是把 include 文件放到站点根目录之外的目录，用virtual引用，或者给这些文件加上访问限制。

至于要不要迁移到新平台，我的判断标准是：如果这个系统每年改动不超过五次，用户是内部员工，没有对外暴露，那么加固一下就继续用完全合理；如果它承载着对外业务、数据敏感、还要持续迭代，那迁移就是必须排期的事，安全加固只是拖延时间。这两个判断不要混在一起做，容易两头都做不好。

最后分享一个我在实际维护中养成的小习惯：每次改完一个页面，我会在文件顶部留一行注释，写上改动日期和一句话说明，格式就是' 2024-05-12 修复 XSS，输出统一走 H()。ASP 没有版本控制意识的老项目里，这行注释比什么都管用，半年后你或者别人再看这个文件，一眼就知道哪些地方被动过、为什么动。这个习惯成本几乎为零，但能省下大量"这行代码谁写的、为什么这么写"的困惑。