企业官网建设流程全解析

简介：这份资源面向JSP入门学习者与小型Web项目开发者，聚焦JSP通过JDBC-ODBC桥连接ACCESS数据库并读取数据的基础实践，帮助读者理解Java Web早期数据交互的完整链路。包内为1个doc文档，压缩包约31KB，以图文与代码示例结合的方式呈现，便于边看边在本地环境复现。文档围绕建立test.mdb数据库与username表、将数据库文件放入Tomcat指定目录、编写JDBCAccess.jsp完成连接与结果集遍历展开，并给出加载驱动、建立连接、创建语句对象、关闭资源的完整代码与异常处理写法，同时提示ACCESS在企业级应用中的局限及向MySQL等数据库迁移时的差异。已有241人学习，适合需要快速跑通第一个JSP数据库示例、理解JDBC基本流程的读者参考。

1. 从一份老 JSP 连 Access 的代码说起：它到底能跑在哪

翻到一份用 JSP 连 Access 数据库的示例代码，第一反应往往是「这玩意儿还能用吗」。答案是：能，但边界很窄。它解决的是小型 Web 项目、课程实践、内网工具里「不想装 MySQL、不想配数据源、只想让页面读出几条记录」的诉求。核心链路就三步：Access 建库建表、把.mdb放进 Web 应用可访问目录、JSP 里用 JDBC-ODBC 桥把页面和库连起来。适合谁？手上有 Tomcat、要交一个能演示数据读写的作业、或者维护一套十年前遗留的展示页的人。不适合高并发、不适合生产环境、更不适合当现代 Web 开发的入门范式。下面按「先跑通、再讲清、最后避坑」的顺序拆。

2. 把 Access 库和 Tomcat 目录对齐：路径与驱动的前置条件

这套方案能不能跑起来，八成取决于两个前置条件：.mdb文件放对位置，以及运行环境里还有没有 JDBC-ODBC 桥驱动。很多人代码抄得一字不差却报「找不到驱动」，问题几乎都出在这两处，而不是 SQL 写错了。

2.1 建库建表：字段类型和命名要跟代码对得上

先在 Access 里新建一个数据库文件，命名成test.mdb（老版本 Access 用.mdb，新版本默认.accdb，两者驱动不同，这点后面避坑章会细说）。在里面建一张表username，两个字段uid和pwd，类型都选「文本」。字段名不要用中文、不要带空格，因为 JSP 里rs.getString("uid")是硬编码取列名的，名字对不上就是空值或异常。

建好后随手插两条测试数据，比如admin / 123456、test / abc。这一步看着琐碎，但它是后面判断「连接成功但读不到数据」和「连接本身失败」的分水岭——页面能打印出这两行，说明整条链路是通的；打印出「恭喜连接成功」却没有数据行，那是表名或字段名的问题，不是连接问题。

2.2 文件落位：application.getRealPath到底解析到哪

示例里把库放在webapps/ROOT/data/test.mdb，代码里写的是相对路径data/test.mdb，再用application.getRealPath(spath)转成物理路径。这里的关键是理解getRealPath的基准：它相对于当前 Web 应用的根目录，也就是webapps/ROOT/。所以data/test.mdb最终解析成.../webapps/ROOT/data/test.mdb，和文件实际位置必须严格一致。

常见做法是把data目录直接建在ROOT下，把.mdb丢进去。如果你的应用不是部署在ROOT而是某个独立 context（比如webapps/myapp/），那getRealPath("data/test.mdb")解析的就是webapps/myapp/data/test.mdb，文件也得跟着挪。这一步没有捷径，路径错一位就是连接失败，而且报错信息往往只给一句笼统的驱动错误，容易误导人往驱动方向查。

提示：调试阶段可以在 JSP 里先out.print(dbpath)把解析出的物理路径打出来，拿这个路径去资源管理器里核对文件是否真实存在，比盲猜快得多。

2.3 驱动与连接串：JDBC-ODBC 桥的组成

连接串是这套方案的技术核心，拆开看是两段：

// 连接串由「ODBC 驱动名」+「DBQ 物理路径」拼成 String url = "jdbc:odbc:Driver={Microsoft Access Driver (*.mdb)};DBQ=" + dbpath; // 加载 JDBC-ODBC 桥驱动 Class.forName("sun.jdbc.odbc.JdbcOdbcDriver"); Connection conn = DriverManager.getConnection(url);

jdbc:odbc:表示走 JDBC-ODBC 桥；Driver={Microsoft Access Driver (*.mdb)}指定底层用哪个 ODBC 驱动，这个名字必须和系统 ODBC 数据源管理器里显示的驱动名一字不差；DBQ=后面跟.mdb的绝对物理路径。Class.forName那行是显式加载桥驱动，老代码里必须写，因为桥驱动不会自动注册。

参数上还有两个容易被忽略的点：user和password在示例里是空串，因为 Access 库没设密码；如果你的库加了密码，得在连接串里补;PWD=xxx，或者用getConnection(url, user, pwd)传进去。另外createStatement那两个参数TYPE_SCROLL_SENSITIVE和CONCUR_UPDATABLE是给结果集声明「可滚动、可更新」的，纯读取场景其实用默认的createStatement()就够，写全了反而对某些 ODBC 驱动兼容性更差。

3. JSP 页面里的读写闭环：从查询到资源释放

代码跑通只是第一步，真正决定这套东西能不能维护的，是页面里那段 try-catch 的结构是否规范。示例代码把连接、查询、输出、关闭全塞在一个 try 里，能演示，但离「能改」还有距离。

3.1 查询与遍历：ResultSet的取值逻辑

核心查询就三行：拼 SQL、executeQuery、while(rs.next())逐行取。取值用rs.getString("uid")按列名取，比按索引getString(1)可读性好，但要求列名和表结构严格一致。输出时示例直接out.print拼 HTML，中文环境下要保证页面contentType和数据库里的编码一致，否则读出来是乱码——这也是老项目里最常见的「数据没错但显示成问号」的根源。

String sql = "select * from username"; ResultSet rs = stmt.executeQuery(sql); while (rs.next()) { // 按列名取值，列名必须与表结构一致 out.print("用户名:" + rs.getString("uid")); out.print(" 密码:" + rs.getString("pwd") + "<br>"); }

select *在演示里没问题，但字段一多、表结构一改，getString("uid")就可能抛「列未找到」。稳妥做法是显式列出字段：select uid, pwd from username，让 SQL 和取值代码形成对应关系，改表时一眼能看出哪里要同步改。

3.2 资源释放：为什么关闭顺序不能乱

示例里rs.close()、stmt.close()、conn.close()是按「结果集 → 语句 → 连接」的顺序关的，这个顺序不能颠倒。连接是底层资源，语句依附于连接，结果集依附于语句，先关连接再关结果集，某些驱动会抛异常或静默失败。更规范的做法是把关闭放进finally，保证异常发生时也能释放：

Connection conn = null; Statement stmt = null; ResultSet rs = null; try { Class.forName("sun.jdbc.odbc.JdbcOdbcDriver"); conn = DriverManager.getConnection(url); stmt = conn.createStatement(); rs = stmt.executeQuery("select uid, pwd from username"); while (rs.next()) { out.print("用户名:" + rs.getString("uid") + "<br>"); } } catch (Exception e) { out.print("错误：" + e.getMessage()); } finally { // 逆序关闭，每个都单独 try，避免一个失败阻断后续 try { if (rs != null) rs.close(); } catch (Exception e) {} try { if (stmt != null) stmt.close(); } catch (Exception e) {} try { if (conn != null) conn.close(); } catch (Exception e) {} }

这段结构比原示例长，但它是「能改、能查错」的基础。原示例把close写在 try 末尾，一旦查询中途抛异常，三个close全被跳过，连接就泄漏了。小项目里连接泄漏不明显，页面刷新几十次之后 Tomcat 开始报连接数耗尽，那时候再回头查就费劲了。

3.3 编码与输出：gb2312之外的选择

示例页面声明的是gb2312，这在当年是标配，现在新建项目建议统一用UTF-8。但要注意，改页面编码不是改一行contentType就完事：JSP 文件本身的保存编码、pageEncoding、响应头、以及 Access 里文本字段的存储编码，四者要一致。老.mdb里的中文数据如果是以 GBK 存进去的，页面强行用 UTF-8 输出照样乱码。稳妥的排查顺序是：先确认数据库里存的是什么，再确认 JSP 文件保存编码，最后看响应头，逐层对齐。

4. 避坑与排查：五条血泪经验

这套方案年代久远，坑都很具体，而且报错信息普遍不友好。下面五条是按「现象 → 原因 → 解决」整理的，基本覆盖了九成翻车场景。

4.1 报ClassNotFoundException: sun.jdbc.odbc.JdbcOdbcDriver

现象：页面直接抛驱动类找不到，连接代码一行没执行到。 原因：JDK 8 之后 JDBC-ODBC 桥被移除了，sun.jdbc.odbc.JdbcOdbcDriver这个类在新 JDK 里根本不存在。很多人以为是 jar 没导，其实是运行环境版本问题。 解决：要么把运行环境降到 JDK 8 及以下（仅限本地演示），要么放弃桥接方案，改用 UCanAccess 这类纯 Java 的 Access 驱动，连接串和驱动类都要换。这是这套方案最大的时代边界，绕不过去。

4.2 报[Microsoft][ODBC 驱动程序管理器] 未发现数据源名称并且未指定默认驱动程序

现象：驱动类加载成功，但getConnection抛 ODBC 相关错误。 原因：连接串里的 ODBC 驱动名和系统里实际注册的名字不匹配，或者系统是 64 位而 Tomcat 跑在 32 位 JVM 下，位数对不上导致驱动不可见。 解决：打开系统的 ODBC 数据源管理器，核对驱动名是否精确为Microsoft Access Driver (*.mdb)；再确认 Tomcat 用的 JVM 位数和 Office/Access 驱动位数一致。32 位和 64 位驱动是两套，混用必挂。

4.3 连接成功但页面没有任何数据行

现象：不报错，甚至打印了「恭喜连接成功」，但while循环一次没进。 原因：表名或字段名和代码不一致，或者.mdb里根本没插数据，或者getRealPath解析到的其实是另一个同名空库。 解决：先把 SQL 改成select count(*) from username看总数；再把dbpath打印出来核对文件；最后检查表名大小写和字段拼写。Access 对表名大小写不敏感，但字段名拼错一定取不到。

4.4 中文全部显示为乱码或问号

现象：数据能读出来，但中文变成???或方块。 原因：JSP 页面编码、响应头编码、数据库存储编码三者不一致，最常见的是页面用 UTF-8 而库里的数据是 GBK 存的。 解决：先固定一套编码（建议 UTF-8），把 JSP 文件另存为对应编码，contentType和pageEncoding同步改；如果库是老数据，考虑读出后做一次编码转换，而不是反复改页面声明。

4.5 页面刷新几次后 Tomcat 报连接耗尽

现象：刚开始正常，多点几次或多人访问后页面卡死，日志里出现连接池或句柄相关错误。 原因：异常路径下close没执行，连接泄漏；或者每次请求都Class.forName加新建连接，没有复用。 解决：按 3.2 的结构把关闭放进finally；演示场景下每次请求新建连接可以接受，但要保证必关。真要做多用户访问，这套直连模式本身就不合适，得换连接池加正式数据库。

5. 从能跑到能验：一套自检清单和一个替代思路

把上面这些串起来，我给这套方案配一个上线前的自检动作，按顺序走一遍，基本能定位问题出在哪一层。第一步，单独写一个最小 JSP，只做Class.forName和getConnection，不查任何表，能连上说明驱动和路径没问题；第二步，加一条select count(*)，能返回数字说明表名对；第三步，再换成select *遍历输出，这一步才涉及字段名和编码。三层分开验，比一上来就跑完整页面高效得多，因为完整页面的异常信息会被 try-catch 吞成一句笼统提示。

如果自检卡在第一层且环境是新 JDK，那就别再跟桥驱动较劲了，直接换纯 Java 驱动是更省时间的路。以 UCanAccess 为例，把几个 jar 放进WEB-INF/lib，驱动类和连接串换成下面这样，其余查询逻辑几乎不用动：

// 纯 Java 驱动，不依赖系统 ODBC，新 JDK 也能跑 Class.forName("net.ucanaccess.jdbc.UcanaccessDriver"); // 注意路径要用绝对路径，且 .mdb 不能被其他进程占用 String url = "jdbc:ucanaccess://" + dbpath; Connection conn = DriverManager.getConnection(url);

参数上唯一要留意的是dbpath必须是绝对路径，UCanAccess 不像桥驱动那样接受相对路径拼接；另外.mdb文件不能被 Access 客户端同时打开，否则会报文件锁。这套替代方案的好处是彻底摆脱 ODBC 和位数问题，代价是多几个依赖 jar，部署包会大一点。

我自己的习惯是：凡是碰这种老技术栈的示例代码，先不急着改业务逻辑，而是按上面三层自检把环境跑通，再动一行代码。因为这类项目的报错信息太会骗人，一句「驱动错误」背后可能是路径、位数、JDK 版本任意一个，盲目改代码只会把问题搅得更乱。从那以后我每次复现这类老示例，都强制先打路径、先验连接、再谈查询。希望帮到你。

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