企业官网建设流程全解析

简介：这是一份基于 ASP 技术的网上报修系统源码压缩包，面向需要快速搭建维修管理流程的企事业单位、学校及物业场景，帮助普通用户在线提交报修请求，并由后台管理员统一分配、跟踪与处理。压缩包共 52 个文件，约 793KB，其中以 34 个 ASP 动态页面为主体，配合 JavaScript、CSS 完成前端交互与样式，另含 JPG/GIF 图标素材、使用说明及数据库连接配置，结构比较简单，适合部署在 IIS 环境下使用。系统覆盖用户注册登录、报修单提交、留言反馈、维修记录管理、后台管理等功能模块，代码文件命名直观，便于二次开发与定制。目前已有 89 人学习浏览，对于想熟悉经典 ASP 开发流程，或需要为内部搭建轻量报修工具的读者，这份代码提供了一个可运行的基础版本，后续可结合自身需求完善权限控制、通知提醒与数据统计等细节。

1. 这套 baoxiu.rar 报修系统：先判断值不值得拆

公司打印机坏了走 OA 流程要等两天审批，学校机房二十台电脑报修靠手写登记表，这种场景下，一个能在线提交、后台统一处理的报修系统就是刚需。baoxiu.rar 这套压缩包，解压出来是一个用经典 ASP + Access 写的网上报修系统，代码风格明显是十几年前的老活，但报修业务该有的链路它都有：用户注册、在线提交报修单、后台处理派工、留言反馈。判断它值不值得拆，关键不是技术新旧，而是这套源码里的流程逻辑有没有你要的东西——用户角色怎么分、工单状态怎么流转、后台权限怎么控。适合想在内部快速搭一个报修入口、又不想被 SaaS 平台绑定的人，也适合老 ASP 项目的接手者拿它当活教材。

2. 从压缩包文件名单反推系统架构：15 个关键 asp 文件把报修链路串起来

解压 baoxiu.rar 之后，你会得到一个 baoxiu 目录，里面是几十个 .asp、.css、.js、.jpg 文件。先别急着拖进 IIS，花十分钟把文件名单过一遍，这套系统的脾气就摸清一半。我注意到一个关键点：文件列表里没有 .mdb 数据库文件，这意味着要么数据库被压缩时精简掉了，要么需要你按使用说明.txt 自己建库。这个先记在心里，后面部署时会变成第一个坎。

2.1 先把文件分堆：前台页面、后台管理、公共组件与静态资源

把文件名按用途归类，是拆解老系统最快的方式。这套报修系统的文件虽然多，但按职责能分成四堆，我挑最有代表性的列出来：

这种命名风格是典型的拼音缩写，dele_yh.asp 是“删除用户”（yong hu），dele_jlb.asp 是“删除记录”（ji lu biao），lyedit.asp 是“留言编辑”（liu yan）。看懂这套命名规律，整个系统的功能边界就清楚了。同时注意 uersedit.asp 这个文件——把 users 拼成了 uers，这种笔误在老系统里非常普遍，后面排查问题时会成为干扰项，但也是识别“这是作者手写代码、不是框架生成”的有力证据。

2.2 命名规律里藏着业务边界：part 开头的是报修工单核心

文件名单里有一串 part 开头的文件：part_star.asp、part_staredit.asp、partyxs.asp、partyok.asp、partyeditok.asp。为什么会有两种近似前缀？这种不一致在老系统里太常见了，conn2.asp 表示第二套连接，uers 是 users 的笔误，作者写代码时命名靠手感。理解了这点，part 系列就是报修工单的主流程：partyxs.asp 应该是报修单列表（xs 是“显示”的拼音首字母），partyok.asp 是提交成功后的回执页，partyeditok.asp 是编辑成功后的回执页，part_star.asp 和 part_staredit.asp 负责工单状态里“星级”或“派工状态”的读取和编辑。我猜这套系统里报修单有一个“加星标”或“星级重要性”的字段，作业人员通过这两个文件更新它的值。这个推断不一定全对，但顺着这个思路去读代码，比挨个文件打开看要快得多。

再配合 conn.asp 和 conn2.asp 两个连接文件，可以推测系统可能用了双库设计：一个库放用户和报修主表，另一个放留言或日志。老系统用双库常见的原因是把频繁读写的留言表和核心报修表隔离，避免 Access 单文件在多并发下锁死。这个细节在你接手后决定要不要合并库时有用。

2.3 四条业务链路：注册登录、报修提交、后台处理、留言反馈

看完文件分堆之后，把页面按调用关系串起来，就是四条业务链路。第一条是注册登录：reg.asp 注册页 → regsubmit.asp 处理提交 → regok.asp 返回成功 → login.asp 登录 → index.asp 进入首页。第二条是报修主流程：weixiu.asp 填表 → jiaru.asp 执行写入 → partyok.asp 提示成功，之后用户在 partyxs.asp 看到自己的历史报修记录。第三条是后台管理：houtai.asp 是入口 → jlbedit.asp 编辑报修记录 → dele_jlb.asp 删除记录 → partyeditok.asp 返回结果。第四条是留言反馈：yijian.asp 提交意见 → lyedit.asp 后台编辑 → dele_ly.asp 删除。

四条链路合起来看，这套系统就是一个小而全的工单系统：用户侧能报修、能查记录，管理侧能增删用户、能处理工单、能删留言。它没有复杂的流程引擎，也没有通知机制，但核心闭环是完整的。接手后如果要加功能，最先改的就是 partyxs.asp 这个列表页——加搜索、加状态筛选都从这里下手。理解了这个架构，下一步就可以动手部署了。

3. 在 IIS 上把 ASP+Access 跑起来：父路径、数据库权限和连接字符串三件事

老 ASP 系统的部署从来不是拷进去就能跑，卡点就三个：IIS 的 ASP 功能没开、Access 数据库权限不对、连接字符串里的路径写死。把这三件事按顺序处理掉，系统就能在 Windows 上站住。环境我用的是 Windows Server 2019，Windows 10 专业版步骤也一样，只是部分菜单名字略有出入。

3.1 环境准备：Windows 启用 IIS 与 ASP 功能的两个关键开关

打开“控制面板 → 启用或关闭 Windows 功能”，勾选“Internet Information Services”，然后在“应用程序开发功能”里勾选“ASP”。这一步是基础，很多人漏勾 ASP 子项，结果 IIS 装好了，.asp 文件打开却是下载或纯文本。装完后在浏览器访问 http://localhost/，能看到 IIS 默认页就说明 Web 服务起来了。

接着打开 IIS 管理器，选中你要挂载报修系统的站点，双击中间列表里的“ASP”图标，在“行为”分类下找到“启用父路径”，设为 True。这一步不做，后面访问页面时会报“ASP 0131 包含文件的父路径访问被禁用”错误，因为老代码里普遍用 这种相对路径引用公共文件。顺手把“启用会话状态”也确认一下，必须在 True，否则登录功能会直接失效。压缩包里那个 iis.exe 不是系统运行的必要件，老系统习惯附带一个 IIS 辅助小工具，杀软偶尔会误报，不用管它。

3.2 解压与目录权限：给 IUSR 和 IIS_IUSRS 一个干活的环境

把 baoxiu 目录解压到 C:\inetpub\wwwroot\baoxiu，然后在 baoxiu 文件夹上右键 → 属性 → 安全 → 编辑 → 添加。在“选择用户或组”里输入 IIS_IUSRS，点检查名称，确认后给它勾上“修改”权限。很多老系统部署后页面能打开，但一写数据就报错，绝大多数是这里没给权限。

如果你用的是 64 位 Windows，还有第二个权限层面的坑：默认应用程序池跑在 64 位模式下，而 Access 的 JET OLEDB 4.0 驱动是 32 位的，页面一查数据库就报“未找到提供程序”。解决办法是选中对应的应用程序池 → 高级设置 → 把“启用 32 位应用程序”改为 True。这一步在 32 位系统上可以跳过，但现在的机器基本全是 64 位，建议直接改。还要检查 baoxiu 目录下如果存在子目录 data 或 database，确认 IIS_IUSRS 对这个子目录也要有写权限，Access 的读写机制是直接操作 .mdb 文件的，目录只读 = 只能看不能写。

3.3 数据库连接字符串：conn.asp 里怎么改路径、改成什么

打开 baoxiu 目录下的 conn.asp，这是全系统的数据库连接入口。老系统的病根在于把数据库路径写成了绝对路径，比如 C:\Inetpub\wwwroot\baoxiu\data\baoxiu.mdb，换台机器就当场崩。常见做法是改成用 Server.MapPath 做相对路径映射：

<% ' conn.asp 数据库连接 - 按实际路径修改 Dim conn, connstr, db_path db_path = Server.MapPath("data/baoxiu.mdb") connstr = "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=" & db_path Set conn = Server.CreateObject("ADODB.Connection") conn.Open connstr %>

这段代码里，Server.MapPath 的作用是把相对路径转成服务器绝对路径，这样整个网站迁移到任何盘符都不用改代码。Provider 用的 JET.OLEDB.4.0 对应 Access 2003 及以前的 .mdb 格式，如果你的库是 Access 2007 之后的 .accdb 格式，要换成 ACE.OLEDB.12.0。如果压缩包里确实没有 .mdb 文件，你就需要新建一个 Access 库，然后在里面建用户表、报修表、留言表。建表结构可以从使用说明.txt 或页面报错信息反推——最常见的做法是拿原站备份，或者按页面访问时提示的字段名一个个补，这个过程建议先看下 conn2.asp 是否指向另一个库，别只建了一个就开跑。

验证部署是否成功，按三个步骤走：先访问 http://localhost/baoxiu/default.asp，确认没有语法报错；再打开首页看验证码图片是否正常显示；最后注册一个测试账号提交一条报修单，确认能写进库。这三步通过，系统就活了。

4. 把报修主流程走通：用户提交、后台派工与记录跟踪的三个关键环节

系统跑起来之后，下一步是用真实数据走一遍主流程。报修系统能不能用，就看三个环节顺不顺：用户能不能顺利注册登录、报修单能不能正常提交、后台能不能有效处理。这套老系统三个环节都做了简化，读懂它的实现方式，你就知道该在哪里加功能。

4.1 注册与登录：普通用户和后台管理员的分界

打开 reg.asp，表单字段一般是用户名、密码、确认密码、联系方式这几项。提交后由 regsubmit.asp 处理写入，写入的用户表里通常有一个用户类型字段来区分普通用户和管理员。这套系统的后台登录大概率走同一个 login.asp，只是登录后跳转目标不同：普通用户进 index.asp，管理员进 houtai.asp。判断逻辑一般写在登录处理页里，根据查询结果里的用户类型字段决定跳转地址。

这里有个老系统通病：文件列表里没有 md5.asp 之类的加密文件，说明密码极可能是明文存储的。别惊讶，那个年代很多系统就是这么干的。所以拿到系统后第一件事就是检查用户表密码字段，如果是明文，建议改成 MD5 存储。改密逻辑不复杂，在 regsubmit.asp 里把密码字段包一层 MD5 函数，login.asp 里比对时也做同样处理，注意两边加密规则必须一致，否则老用户全部登录失败。

4.2 提交一张报修单：weixiu.asp 的表单字段与 jiaru.asp 的写入逻辑

weixiu.asp 是报修单填写页，字段通常包含设备名称、故障描述、报修人、联系方式、紧急程度。提交后由 jiaru.asp 执行写入，这类写入代码的风格可以直接看出来——字符串拼接 SQL。常见写法是：

<% ' jiaru.asp 报修单写入示例 Dim rs Set rs = Server.CreateObject("ADODB.Recordset") sql = "INSERT INTO baoxiu(bx_title, bx_content, bx_user, bx_time, bx_status) VALUES('" & Request("title") & "', '" & Request("content") & "', '" & Session("username") & "', Now(), '0')" conn.Execute sql Response.Redirect "partyok.asp" %>

这段代码里，bx_status 的 0 表示新提交状态，后台处理完再改成 1。Now() 取的是服务器当前时间，Session("username") 是当前登录用户名。Request("title") 这种拿值方式对应表单里的文本框 name 属性，改表单字段名时必须同步改这里。字符串拼接 SQL 在当年是常态，但现在接手的系统如果暴露在外网，建议改成参数化查询，不然一次 SQL 注入就能把整库拖走。内网用的话，至少也要在登录和报修两个入口做基本的输入过滤。

4.3 后台处理链路：houtai.asp 入口与工单状态流转

后台入口是 houtai.asp，进入后能看到所有报修记录的列表，每条记录后面跟着编辑和删除操作。jlbedit.asp 负责编辑记录内容，dele_jlb.asp 负责删除。老系统的“派工”概念很简单：不是像现在这样有独立的指派按钮，而是在编辑页面里把负责人字段改一下，或者像我在 2.2 节说的，通过 part_star.asp 更新工单的星标状态。这个设计对小型团队够用，但如果你想跟踪“谁处理了这张单、处理结果是什么”，就要改 jlbedit.asp 加两个字段。

后台权限判断是这一节最该检查的点。在某些版本的这类系统里，houtai.asp 只判断了“是否登录”，没有判断“是否管理员”，这意味着普通用户登录后直接访问 houtai.asp 也能进后台。我在接手老系统时吃过这个亏，所以建议你第一件事就是把 houtai.asp 开头的权限判断从“判断 Session 是否存在”改成“判断 Session 里的用户类型是否为管理员”。改起来很快，但能堵住一个非常大的洞。

5. 避坑手册：经典 ASP 报修系统的五个翻车现场

部署老系统，翻车是常态。下面五条是我在类似 ASP + Access 项目上踩过的真实坑，每一条都按现象、原因、解决三个层次写清楚，你照着排查能省下大量瞎试的时间。

5.1 页面报 ASP 0131 错误：父路径访问被禁用

现象：打开任意页面报“Active Server Pages 错误 'ASP 0131'，包含文件 'conn.asp' 的父路径访问被禁用”。原因：IIS 7 及以上版本默认禁用父路径，而老代码里普遍用 ../ 方式引用上一级目录的公共文件。解决：IIS 管理器 → 对应站点 → ASP → 行为 → 启用父路径设为 True。改完后记得在 IIS 管理器中点右侧的“应用”，不用重启站点就能生效。这条最容易遇到，也最好解决。

5.2 数据库报 80004005：操作必须使用一个可更新的查询

现象：前台提交报修单或后台删除记录时，页面报“Microsoft JET Database Engine 错误 '80004005'，操作必须使用一个可更新的查询”。原因：Access 数据库文件所在目录对 IIS 用户是只读权限，或者 .mdb 文件本身被勾选了只读属性。解决：右键 baoxiu 目录 → 属性 → 安全 → 给 IIS_IUSRS 加“修改”权限；同时检查 .mdb 文件属性，取消只读。还有一个小概率原因：有人用 Access 软件以独占模式打开了这个库，导致 IIS 进程无法写入，关掉 Access 再试。

5.3 64 位系统上报“未找到提供程序”

现象：页面访问数据库时报“ADODB.Connection 错误 '800a0e7a'，未找到提供程序。该程序可能未正确安装”。原因：应用程序池运行在 64 位模式，而 JET OLEDB 4.0 是 32 位驱动，64 位进程加载不了。解决：应用程序池 → 高级设置 → 启用 32 位应用程序改为 True。改完这个，再刷新页面就好了。注意 ACE 驱动（对应 2007 之后的 Access）不需要这个设置，但 JET 是必须的，先确认你的 Provider 是 JET 还是 ACE 再动手。

5.4 验证码图片不显示或永远校验失败

现象：注册页和登录页的验证码位置显示红叉或空白，或者明明输入对了却提示验证码错误。原因：可能是 yanzheng.asp 在输出图片二进制流之前意外输出了 HTML 内容，导致图片数据损坏；也可能是字体文件路径在服务器上不存在；还有可能是验证码比对用的 Session 值没写入成功。解决：先单独访问 /baoxiu/yanzheng.asp 看能否直接显示图片，如果显示乱码或空白，在 yanzheng.asp 的第一行加 Response.Buffer = True 和 Response.Expires = -1，清空输出缓冲区；如果图片正常但校验失败，检查代码里验证码比对时用的 Session 键名是否一致——写入和读取是两个文件，键名不一致是很常见的笔误。

5.5 登录成功却马上跳回登录页

现象：登录后页面跳转到 index.asp，但一刷新就回到 login.asp，后台更是怎么都进不去。原因：Session 没有正常工作，或者权限判断的键名写错。Session 失效常见于 IIS 的“会话状态”没启用；键名写错则是作者笔误，比如登录时写 Session("UserType")，后台判断时读 Session("usertype")，大小写不一致在某些配置下也会出问题。解决：IIS 站点 → ASP → 服务 → 会话状态设为 True；然后用浏览器开发者工具确认 Cookie 没有被禁用；最后打开 login.asp 和 houtai.asp 逐行比对 Session 键名。

6. 一个压箱底技巧：忘密码直接改 Access 库，顺手补一道审计日志

老系统最尴尬的时刻不是功能崩溃，而是管理员密码失效。文档没留、前人已离职、密码是十年前设的——这种时候别去猜密码，直接改库是最快的后悔药。

6.1 密码重置：Access 里一条 UPDATE 解决

先找到 .mdb 文件，用 Microsoft Access 打开（没有的话装个 Access 2007 或更高版本，只用它改数据）。在用户表里找到管理员记录，如果密码是明文，直接手工改掉；如果是 MD5，就把密码字段更新成 123456 的 MD5 值：

UPDATE users SET password = 'e10adc3949ba59abbe56e057f20f883e' WHERE username = 'admin';

这段 SQL 在 Access 的查询设计视图里以 SQL 模式执行。e10adc3949ba59abbe56e057f20f883e 是 123456 的 MD5 值，改完保存后用这个密码登录，进去第一件事就是把密码改成真正的强密码。如果用户表名不叫 users，就去系统里搜索 conn.asp 或登录处理页里 Insert 语句用的表名，老系统里常见的表名有 admin、userinfo、baoxiu_user 几种。注意改库前先备份一份 .mdb，改坏了还能恢复。

6.2 审计日志：一个通用的 WriteLog 过程

老系统普遍没有操作日志，谁删了报修记录、谁改过用户权限，全凭记忆。补一个通用审计日志不需要改造数据库，只需要一个公共过程加几行调用：

<% ' audit.asp 通用审计日志，后台页面 include 它 Sub WriteLog(action) Dim fso, f, logPath logPath = Server.MapPath("logs/" & Year(Date) & "-" & Month(Date) & "-" & Day(Date) & ".log") Set fso = Server.CreateObject("Scripting.FileSystemObject") Set f = fso.OpenTextFile(logPath, 8, True) f.WriteLine Now() & " | " & Request.ServerVariables("REMOTE_ADDR") & " | " & action f.Close Set f = Nothing Set fso = Nothing End Sub %>

把这个文件保存为 audit.asp，放在公共目录里，然后在 adduser.asp、dele_jlb.asp、dele_yh.asp 这些后台处理页开头加上 ，并在执行操作前调用一行 WriteLog "delete_jlb: id=" & Request("id")。OpenTextFile 的第二个参数 8 表示追加模式，第三个参数 True 表示文件不存在时自动创建，这样日志文件会按天生成，不会无限膨胀。REMOTE_ADDR 拿的是客户端 IP，配合时间戳足够追踪是谁在什么时间做了什么操作。

我吃过一次亏：接手一个报修系统，管理员密码对不上，好不容易从数据库里改出来，又发现后台随便一个普通账号都能进。当时顺着代码查下去，发现权限判断只看了“是否登录”，根本没查用户类型。从那以后我每次接手这类老 ASP 系统，第一件事就是打开 Access 把管理员密码重置成已知值，再把后台权限判断补上，顺手挂上这道审计日志。这套动作我强制自己走一遍，不急着看业务代码。希望帮到你。

本文还有配套的精品资源，点击获取