ASP编程中如何连接数据库并显示查询结果

经典 ASP 通常指运行在 IIS 上、以 VBScript 编写的 Active Server Pages。它不像 ASP.NET 那样内置数据库框架，常见做法是通过 ADO（ActiveX Data Objects）调用 OLE DB 或 ODBC 提供程序，再把查询结果输出为 HTML。

这套方式仍适用于维护旧网站、运行环境受限的内部系统，以及必须兼容经典 ASP 的项目。新项目通常应优先考虑仍受支持的平台和数据库访问技术；经典 ASP 已是遗留技术，实际可用的数据库驱动、IIS 版本与系统环境需要单独确认。

本文将从一个可改造的查询页出发，说明连接、查询、参数化、结果输出和资源释放的完整流程，并介绍实际部署中常见的错误。示例使用 SQL Server 和 ADO；连接字符串、表名及字段名需按实际环境调整。

一、ADO 查询的基本流程

一个典型的经典 ASP 数据库页面，通常按以下顺序工作：

1. 配置响应编码，并读取、限制和校验请求参数。
2. 创建 ADO Connection，连接数据库。
3. 创建 ADO Command，设置 SQL 和参数。
4. 执行查询，逐行读取 Recordset。
5. 对输出到 HTML 的内容进行编码。
6. 关闭并释放 Recordset、Command 和 Connection。

这些步骤中的职责不能混为一谈。例如，限制搜索词长度有助于控制输入范围，但不能代替 SQL 参数化；参数化查询能降低 SQL 注入风险，却不能代替 HTML 输出编码。

二、准备数据库和运行环境

示例假设 SQL Server 中有一张 Products 表，至少包含以下字段：

CREATE TABLE dbo.Products
(
    ProductId   int            NOT NULL PRIMARY KEY,
    ProductName nvarchar(100)  NOT NULL,
    Price       decimal(10, 2) NOT NULL
);

还需要确认服务器具备以下条件：

• IIS 已启用经典 ASP 功能，应用程序池的配置与目标系统相容。
• 服务器安装了可用的 SQL Server OLE DB 提供程序，并且提供程序的名称与连接字符串一致。下面使用 MSOLEDBSQL 作为示例；是否可用取决于服务器是否安装了相应版本的 Microsoft OLE DB Driver for SQL Server。
• IIS 应用程序池使用的身份有权连接数据库，并具有执行所需查询的最小权限。
• SQL Server 网络连接、防火墙和身份验证方式已正确配置。

ADO 是客户端编程接口，实际的连接能力由安装的提供程序和数据库驱动决定。仅仅在 ASP 代码中写出提供程序名称，并不会自动安装驱动。部署前应在目标服务器上实际测试连接。

三、连接字符串与凭据管理

连接字符串包含服务器、数据库、身份验证方式等信息。下面给出两种常见形式，实际使用时只选一种。

方式一：Windows 集成身份验证

Provider=MSOLEDBSQL;
Data Source=SQL01;
Initial Catalog=Shop;
Integrated Security=SSPI;

使用集成身份验证时，数据库看到的是发起连接的 Windows 身份。网站部署后，通常与 IIS 应用程序池身份、匿名身份配置以及服务器环境有关，不一定是开发者当前登录的账户。应给实际使用的身份授予必要权限，而不是直接授予服务器管理员权限。

方式二：SQL Server 用户名和密码

Provider=MSOLEDBSQL;
Data Source=SQL01;
Initial Catalog=Shop;
User ID=web_reader;
Password=请替换为真实密钥;

此方式需要在 SQL Server 中启用并配置相应的 SQL Server 身份验证。不要把真实密码提交到公开代码仓库，也不要把包含密码的配置文件放在可由浏览器直接访问的目录中。应限制文件访问权限，并优先使用受保护的配置、部署环境变量或平台提供的密钥管理方案。

连接字符串也可以写成单行。分行展示只是为了便于阅读，具体格式应遵循所用提供程序的要求。生产环境还应结合部署环境检查加密连接、证书校验和网络访问策略；不能为了绕过证书问题而长期关闭验证。

四、可运行的经典 ASP 查询页面

以下示例保存为 products.asp 后，可以在配置好的 IIS 环境中运行。它读取 URL 参数 q，按商品名称搜索，并以表格显示商品编号、名称和价格。请先替换连接字符串中的服务器和数据库信息。

示例使用 SQL Server OLE DB 提供程序的参数占位符 ?。在这类 ADO 用法中，参数通常按出现顺序绑定；不能假设 SQL 中写出的参数名称会自动决定绑定关系。

<%@ Language="VBScript" CodePage="65001" %>
<%
Option Explicit

Response.CodePage = 65001
Response.Charset = "utf-8"
Response.ContentType = "text/html"

' ADO 常量。直接定义可避免依赖 adovbs.inc。
Const adCmdText = 1
Const adParamInput = 1
Const adVarWChar = 202

Dim conn, cmd, rs
Dim q, sql, connectString
Dim htmlError

q = Trim(CStr(Request.QueryString("q")))

' 限制搜索词长度。这里的长度限制是输入范围控制，
' 不是 SQL 注入防护；注入防护由参数化查询承担。
If Len(q) > 100 Then
    q = Left(q, 100)
End If

connectString = "Provider=MSOLEDBSQL;" & _
                "Data Source=SQL01;" & _
                "Initial Catalog=Shop;" & _
                "Integrated Security=SSPI;"

sql = "SELECT ProductId, ProductName, Price " & _
      "FROM dbo.Products " & _
      "WHERE ProductName LIKE ? " & _
      "ORDER BY ProductName"

Set conn = Nothing
Set cmd = Nothing
Set rs = Nothing
htmlError = ""

On Error Resume Next

Set conn = Server.CreateObject("ADODB.Connection")
conn.Open connectString

If Err.Number = 0 Then
    Set cmd = Server.CreateObject("ADODB.Command")
    Set cmd.ActiveConnection = conn
    cmd.CommandType = adCmdText
    cmd.CommandText = sql

    ' 问号占位符对应的参数按出现顺序传入。
    ' 参数长度应与查询设计及字段长度相匹配。
    cmd.Parameters.Append cmd.CreateParameter( _
        "searchName", adVarWChar, adParamInput, 100, "%" & q & "%")

    If Err.Number = 0 Then
        Set rs = cmd.Execute
    End If
End If

If Err.Number <> 0 Then
    ' 详细错误只写入服务器日志或受保护的诊断系统。
    ' 不将连接字符串、数据库地址或驱动错误直接回显给访问者。
    htmlError = "暂时无法读取商品数据，请稍后再试。"
    Err.Clear
End If

On Error GoTo 0
%>
<!doctype html>
<html lang="zh-CN">
<head>
  <meta charset="utf-8">
  <title>商品查询</title>
</head>
<body>
  <h1>商品查询</h1>

  <form method="get" action="products.asp">
    <label for="q">商品名称：</label>
    <input id="q" name="q" type="text"
           maxlength="100"
           value="<%= Server.HTMLEncode(q) %>">
    <button type="submit">搜索</button>
  </form>

  <% If htmlError <> "" Then %>
    <p><%= Server.HTMLEncode(htmlError) %></p>
  <% ElseIf Not rs Is Nothing Then %>
    <table border="1">
      <thead>
        <tr>
          <th>编号</th>
          <th>商品名称</th>
          <th>价格</th>
        </tr>
      </thead>
      <tbody>
        <%
        If rs.EOF Then
        %>
          <tr>
            <td colspan="3">没有找到符合条件的商品。</td>
          </tr>
        <%
        Else
            Do Until rs.EOF
        %>
          <tr>
            <td><%= Server.HTMLEncode(CStr(rs("ProductId"))) %></td>
            <td><%= Server.HTMLEncode(CStr(rs("ProductName"))) %></td>
            <td><%= Server.HTMLEncode(CStr(rs("Price"))) %></td>
          </tr>
        <%
                rs.MoveNext
            Loop
        End If
        %>
      </tbody>
    </table>
  <% End If %>
</body>
</html>
<%
' 无论查询是否返回记录，都应释放已创建的对象。
On Error Resume Next

If Not rs Is Nothing Then
    If rs.State <> 0 Then rs.Close
End If
Set rs = Nothing
Set cmd = Nothing

If Not conn Is Nothing Then
    If conn.State <> 0 Then conn.Close
End If
Set conn = Nothing

On Error GoTo 0
%>

五、理解参数化查询的边界

1. 参数值和 SQL 结构不是一回事

示例中的 ? 用于绑定一个数据值，即搜索词。输入内容不会被拼接成 SQL 语句的一部分，数据库会把它作为参数处理。这是防止输入被当作 SQL 代码执行的重要措施。

但参数通常不能用来替代表名、字段名、排序方向或 SQL 关键字。例如，下面这种写法不能因为把表名绑定为参数就变成可用且安全的动态表名：

SELECT * FROM ?

如果确实需要动态选择排序字段，应将用户输入映射到代码中预先允许的固定选项，再把映射结果放入 SQL 结构。不要直接把请求值拼接到 SQL 中。

Dim sortKey, orderBy

sortKey = LCase(Trim(CStr(Request.QueryString("sort"))))

Select Case sortKey
    Case "name"
        orderBy = "ProductName"
    Case "price"
        orderBy = "Price"
    Case Else
        orderBy = "ProductName"
End Select

sql = "SELECT ProductId, ProductName, Price " & _
      "FROM dbo.Products " & _
      "WHERE ProductName LIKE ? " & _
      "ORDER BY " & orderBy

这里放入 SQL 的 orderBy 只能来自代码中的固定白名单。搜索词仍然应作为参数传入。这种做法只适用于确有动态排序需求的场景，不应被误解为可以任意拼接用户输入。

2. 参数顺序、类型和长度要匹配

ADO 的参数类型需要与数据库列和查询预期相协调。示例使用 adVarWChar，表示可变长 Unicode 字符串，适合与 SQL Server 的 nvarchar 字段配合。参数长度设置为 100，是根据示例字段及搜索输入范围给出的选择，并非适用于所有数据库和字段的固定值。

使用问号占位符时，应按 SQL 中占位符出现的顺序追加参数。如果一个查询有多个问号，参数顺序不正确可能导致结果错误或类型转换问题。不同 ADO 提供程序对于命名参数、数据类型及特定 SQL 类型的支持可能不同；遇到兼容性问题，应查阅目标提供程序的文档，并在实际 IIS 服务器上验证。

参数化能够保护参数值免受 SQL 语句拼接风险，但不能保证查询一定高效，也不会自动校验业务规则。数据库仍需合适的索引、字段约束和权限设置。

3. LIKE 的通配符行为

参数化并不会改变 SQL Server 中 LIKE 的语义。示例将搜索词包在百分号中，因此表示“名称中包含该词”。用户输入的百分号和下划线仍可能作为 LIKE 模式中的通配符。若业务要求这些字符只能按普通字符匹配，需要额外设计转义规则，并在 SQL 中明确指定转义字符；仅仅参数化并不能取消通配符含义。

%关键字% 这种包含式搜索通常难以利用普通 B-tree 索引完成高效定位。数据量较大时，应根据需求考虑前缀搜索、全文检索或其他索引方案，并通过实际查询计划评估性能。

六、HTML 输出编码与其他安全用途

从数据库读取的字段也不能默认视为可信内容。数据可能由用户提交、旧程序写入，或来自其他系统。如果直接将字段内容输出到网页，包含尖括号、引号等字符的内容可能被浏览器解释为 HTML 或脚本。

示例在输出字段和回填搜索框时使用 Server.HTMLEncode。它用于把文本安全地显示在 HTML 文本节点或相应的 HTML 属性位置。HTML 编码与 SQL 参数化解决的是不同问题：

• SQL 参数化：在数据库查询层将输入作为数据处理，避免把参数值直接拼成 SQL 代码。
• HTML 输出编码：在网页输出层将不可信文本转为适合 HTML 的形式，降低脚本注入风险。
• 输入限制与业务校验：控制长度、格式和业务范围，避免不合理输入；它们不能代替前两种保护。

如果输出位置不是 HTML 文本或普通属性，例如 JavaScript、URL 或 CSS 上下文，单独调用 Server.HTMLEncode 不一定适用。应根据具体输出上下文使用合适的编码方式，或避免把不可信数据直接插入这些上下文。

七、错误处理和资源释放

经典 ASP 可以使用 On Error Resume Next 暂时接管运行时错误，但它会让代码在发生错误后继续执行。若没有立即检查 Err.Number，后续代码可能操作一个尚未创建的对象，错误表现会更加混乱。示例仅在数据库操作的局部范围使用它，并在阶段后检查错误，再恢复默认错误处理。

生产系统不宜把连接字符串、服务器地址、数据库名称和详细驱动错误直接显示给访问者。应在服务器端记录足够的诊断信息，同时向用户返回有限的提示。错误日志也要按访问权限和保留策略管理，避免泄露密码、个人信息或敏感查询数据。

Recordset 和 Connection 应在请求结束前关闭并释放。释放对象有助于及时归还数据库连接，并减少长时间占用资源。示例通过检查对象是否已创建以及连接状态，再进行关闭。若在页面中间执行 Response.End、跳转或遇到未处理异常，可能跳过写在页面末尾的清理代码；这类流程应特别设计，确保资源不会长期占用。

示例使用客户端游标行为之外的默认执行方式，适合顺序读取结果。实际项目中不应为了方便就一次性读取任意大的结果集。应根据业务设置查询范围、分页和必要的超时，并避免在每行循环中重复打开连接或执行额外查询。

八、编码、路径与 IIS 配置

经典 ASP 项目中的编码问题可能出现在多个环节：ASP 文件本身的保存编码、页面指令的代码页、HTTP 响应字符集、数据库列类型以及数据库连接行为。示例采用 UTF-8 响应，并将页面文件以兼容的 UTF-8 方式保存。若服务器或旧组件处理编码的方式不同，应实际测试中文查询、中文结果和特殊字符。

设置 Response.CodePage 和 Response.Charset 有助于明确响应编码，但不能修复已在数据库中被错误编码的数据。对中文字段应优先使用合适的 Unicode 数据类型，并确保写入链路本身正确。

ASP 文件必须由 IIS 解释执行。直接用浏览器打开本地文件，或者把文件部署到不支持经典 ASP 的静态目录中，不会运行服务器端代码。调试时应通过 IIS 网站地址访问，并检查 IIS 是否启用了经典 ASP、匿名身份和应用程序池配置是否符合预期。

九、常见错误及排查方向

1. 提供程序未注册或找不到

常见表现包括“找不到提供程序”或“未在本机注册”。通常应先确认目标服务器是否安装了连接字符串指定的 OLE DB 提供程序，再检查 IIS 应用程序池与驱动的位数是否匹配。不要只在开发机上验证后就假设生产服务器具备相同驱动。

2. 登录失败或权限不足

集成身份验证下，实际数据库登录身份可能与预期不同；SQL Server 用户名方式下，还要核对身份验证模式、密码和用户映射。连接成功后若查询仍报权限错误，应检查该数据库用户对目标表或视图是否具有必要的读取权限。网站查询账号通常不需要数据库管理员权限。

3. 查询没有记录

先确认请求参数是否正确传入，再确认数据库、表名、字段名和当前数据是否正确。搜索条件使用 LIKE 时，大小写和排序规则行为由数据库配置等因素影响。还要检查参数类型、参数长度及问号参数的追加顺序。

4. 中文乱码

检查 ASP 文件保存编码、响应字符集、数据库列类型以及写入时的数据编码。仅在 HTML 中声明 UTF-8，不能让本来就已写坏的数据自动恢复。必要时对写入端和读取端都做端到端验证。

5. 页面显示空白或只显示通用错误

不要为了方便长期向外部用户打开详细错误输出。开发环境可在受控条件下查看 IIS 和应用日志、ADO 错误信息与 SQL Server 日志；生产环境则记录服务器端诊断，并保护日志访问。确认数据库操作出错后，代码没有在错误对象上继续读取字段。

6. 查询越来越慢

检查查询是否返回了不必要的大量行、搜索条件是否影响索引使用、是否缺少合适索引，以及是否在循环中执行重复查询。参数化解决的是值传递与安全问题，不是性能优化的替代方案。应结合数据库执行计划和真实数据规模进行优化。

十、上线前检查清单

• 目标 IIS 服务器已启用经典 ASP，所用 OLE DB 或 ODBC 提供程序确实已安装且版本、位数相容。
• 连接字符串、数据库名称与身份验证方式已替换为实际配置，凭据没有暴露在公开目录或公开仓库中。
• 数据库账号遵循最小权限原则，只具备页面实际需要的权限。
• 所有来自请求的查询值都通过参数传入；动态表名、排序字段等 SQL 结构只从固定白名单中选择。
• 搜索词有合理的长度和业务校验，查询结果规模也受到控制。
• 数据库结果和请求值在输出到 HTML 时经过适合所在上下文的编码。
• 连接失败、查询失败和空结果都经过测试，外部页面不会暴露详细数据库错误。
• Recordset 和 Connection 能在正常流程及异常流程中及时关闭。
• 对中文、特殊字符、通配符和较长输入进行了实际验证。

总结

经典 ASP 通过 ADO 连接数据库，核心步骤是创建连接、使用 Command 执行查询、读取 Recordset，并在输出后释放资源。真正可靠的实现还需要处理好参数化、HTML 编码、账号权限、错误日志和服务器依赖。

示例可作为 SQL Server 查询页面的起点，但不能不经检查地套用到所有数据库和驱动。不同提供程序对连接字符串、参数类型和参数绑定的支持可能存在差异。部署前应在目标 IIS 环境验证，并按照实际数据结构、访问规模和安全要求调整。