简介面向初学 Java Web 开发者的 JSP 连接 ACCESS 数据库实践文档聚焦小型项目与教学练习中最基础的数据交互场景通过 JDBC-ODBC 桥驱动让 JSP 页面读取 ACCESS 库中的数据。文档按三个环节组织内容建立 test.mdb 数据库将库文件放入 Tomcat 站点目录以及编写 JDBCAccess.jsp。文中完整给出页面指令、驱动加载、连接字符串、语句对象创建、结果集遍历与资源关闭的示例代码并逐段注释说明各步骤作用可直接对照调试。压缩包共 1 个文件为 doc 格式文档体积约 31KB内容轻便、容易获取适合边看边改。目前已有 240 人学习下载。对想弄清 JDBC 连接流程、异常捕获与连接释放规范的读者来说这份文档可帮助快速搭起可运行的演示环境文中还延伸到 MySQL、Oracle、SQL Server 等常见数据库的驱动替换思路便于由此过渡到更主流的数据库开发。1. 一段老代码的真实处境JSP 与 ACCESS 数据库连接卡住的地方从来不在 SQL 上JSP 连接 ACCESS 数据库这套组合今天还出现在两类现场一类是课程设计、实训周那种明确要求“不许用 MySQL”的作业另一类是十年前上线、至今还挂在某台内网服务器上的小系统需要临时改一版。原料给的是一段能直接粘进 Tomcat 的 JDBCAccess.jsp配一个 test.mdb、一张 username 表跑通只要十几分钟。但它真正的门槛不在代码而在驱动sun.jdbc.odbc.JdbcOdbcDriver这条 JDBC-ODBC 桥在 JDK 8 就被移除了很多人拿着新装的 JDK 照着老教程抄第一行Class.forName就抛 ClassNotFoundException然后开始怀疑数据库路径写错了。下面按“建库放文件 → JSP 读写 → 换驱动 → 排错”的顺序拆开先把能跑的那条路走完再说清楚它什么时候不该用。2. 从 test.mdb 到 Tomcat 目录文件放对位置连通只完成一半这一步看着最没技术含量实际是翻车率最高的地方。Access 数据库是一个文件不是服务JSP 要读到它必须同时满足三件事文件在一个 JVM 进程有权限读取的绝对路径上、ODBC 驱动能在系统里找到、连接串里的驱动名和系统里注册的名字一字不差。三者缺一个报错信息都长得不一样这也是为什么很多人对着同一段代码有人一次过、有人卡一下午。2.1 建表字段类型和保留字先定死在 Access 里新建一个空的.mdb文件存成 Access 2002-2003 格式。注意别手滑存成.accdb原料里的连接串写的是Driver{Microsoft Access Driver (*.mdb)}这个驱动名只认 mdb要读 accdb 得换成(*.mdb, *.accdb)那个驱动名两者不能混用。然后在库里建表username两个字段uid、pwd类型都选“文本”长度给 50 就够Access 的“文本”等价于其他库的 VARCHAR长度上限 255。如果习惯用 SQL 建Access 的 DDL 通过 ODBC 也能执行写法比标准 SQL 稍微土一点-- Access 的 TEXT 必须带长度不带长度的 TEXT 在部分驱动版本下会退化成备注型 CREATE TABLE username ( uid TEXT(50), pwd TEXT(50) ); -- 先塞两条测试数据避免页面空白时误判成“查询没执行” INSERT INTO username (uid, pwd) VALUES (admin, 123456); INSERT INTO username (pwd, uid) VALUES (test, test);这里有个容易被忽略的点Access 有一批保留字password、date、level、value、order都在列。原料用pwd避开了password是运气也是经验。如果你自己改成password字段SQL 里必须写成[password]否则报“语法错误操作符丢失”而这个报错完全不会提示你是字段名的问题。我在类似项目上见过有人查了两个小时最后发现就是少了一对方括号。建完表记得把文件从 Access 里关掉。Access 打开文件时会在同目录生成一个同名的.ldb锁文件只要它还在JVM 那边连上去大概率拿到“文件已被另一用户使用”或者干脆卡住。2.2 放文件webapps/ROOT/data 与 getRealPath 的物理路径转换原料把 test.mdb 放在TOMCAT安装目录/webapps/ROOT/data下JSP 里用application.getRealPath(data/test.mdb)把它转成物理路径。这个设计的意思是数据库文件跟着 Web 应用走部署到哪台机器都能用相对位置找。命令行操作大概是这样# CATALINA_HOME 一般由 Tomcat 启动脚本导出没有就写死绝对路径 echo $CATALINA_HOME mkdir -p $CATALINA_HOME/webapps/ROOT/data cp test.mdb $CATALINA_HOME/webapps/ROOT/data/test.mdb ls -l $CATALINA_HOME/webapps/ROOT/datagetRealPath的行为需要说清楚它把 Web 应用内的资源路径映射成服务器文件系统上的绝对路径前提是这个资源真实存在于解压后的目录里。所以有两个坑。第一参数建议写成/data/test.mdb带前导斜杠不带斜杠时不同容器实现的行为不完全一致有的会按当前请求的目录去拼。第二如果 Tomcat 的server.xml里把unpackWARs设成false应用以 war 包形式直接运行、不解压getRealPath会返回null拼出来的连接串就变成DBQnull报的却是“找不到文件”非常有迷惑性。还有个更隐蔽的在 IDE 里调试时应用往往被部署到工作空间的临时目录而不是你手工复制文件的那个webapps/ROOT。结果就是命令行部署能跑、IDE 里跑不了。判断方法很简单页面里把dbpath直接打印出来看一眼路径对不对一眼就清楚比猜快得多。2.3 连接串三种写法与驱动加载顺序Access 的 JDBC-ODBC 连接串有三种常见形态对应三种不同的系统配置状态写法连接串示例依赖的系统配置适用场景无 DSN推荐jdbc:odbc:Driver{Microsoft Access Driver (*.mdb)};DBQC:\...\test.mdb只需装 Access ODBC 驱动单机部署、路径固定有 DSNjdbc:odbc:testDSN需在 ODBC 管理器里预建同名数据源多应用共用同一库带账号密码在无 DSN 串后追加;UID;PWD同无 DSN库设了密码时原料用的是第一种。Driver{...}里的大括号和空格都是语法的一部分驱动名必须和“ODBC 数据源管理器 → 驱动程序”列表里显示的名字完全一致多一个空格都会报[IM002] 未找到数据源名称且未指定默认驱动程序。驱动加载这行Class.forName(sun.jdbc.odbc.JdbcOdbcDriver)的作用是触发类加载把驱动注册进DriverManager。JDBC 4 之后支持 SPI 自动发现但 JDBC-ODBC 桥不走这套机制所以这一行删不掉。在动手改 JSP 之前我更建议先写一个独立的 Java main 方法验证连接比在页面里反复刷新快十倍import java.sql.*; public class AccessProbe { public static void main(String[] args) throws Exception { // 换成你机器上的真实绝对路径注意反斜杠在 Java 字符串里要转义 String db C:/Program Files/Apache Software Foundation/Tomcat 6.0/webapps/ROOT/data/test.mdb; String url jdbc:odbc:Driver{Microsoft Access Driver (*.mdb)};DBQ db; // 驱动类不存在时这一行会直接抛 ClassNotFoundException和路径无关 Class.forName(sun.jdbc.odbc.JdbcOdbcDriver); try (Connection conn DriverManager.getConnection(url); Statement stmt conn.createStatement(); ResultSet rs stmt.executeQuery(SELECT uid, pwd FROM username)) { while (rs.next()) { System.out.println(rs.getString(uid) / rs.getString(pwd)); } System.out.println(driver conn.getMetaData().getDriverName()); } } }这段代码的价值在于把“驱动类加载失败”和“数据源找不到”两类错误分开暴露。如果Class.forName就炸了说明 JDK 版本太高后面所有关于路径的排查都是白费如果getConnection炸了才轮到查 ODBC 驱动和路径。运行方式用javac AccessProbe.java java -cp . AccessProbe不需要 Tomcat 参与。3. 把 JDBCAccess.jsp 拆开连接、语句、结果集三段各自在做什么原料那段 JSP 结构其实很清晰try 块里先拼路径、再加载驱动、建连接、建语句对象、查数据、遍历输出最后依次关三个资源catch 里把异常信息打到页面上。问题集中在三处——语句对象的两个参数、字符集声明、以及关闭动作放在 try 里而不是 finally 里。这三点在数据量为两条时都不会暴露一旦数据多几条或者中间出一次异常就开始出问题。3.1 六行连接代码逐行对照把原料的连接部分拆成六步看spath是相对资源路径dbpath是getRealPath转换后的物理路径user和dbname两个变量声明了但根本没进连接串url是最终拼接结果Class.forName触发驱动注册DriverManager.getConnection建立物理连接。其中user、dbname两行是历史遗留Access 无密码时本来就是空串删掉不影响运行留着反而让人以为需要填。真正要改的是这一行// 原料写法 Statement stmt conn.createStatement(ResultSet.TYPE_SCROLL_SENSITIVE, ResultSet.CONCUR_UPDATABLE);TYPE_SCROLL_SENSITIVE要求结果集可前后滚动且能感知他人修改CONCUR_UPDATABLE要求结果集可直接更新。这两个能力在 JDBC-ODBC 桥上支持得很勉强多数驱动版本会悄悄降级成只读、不可滚动但某些版本会直接抛SQLException。如果你的代码根本没用到rs.previous()或rs.updateString()用无参的createStatement()最稳Statement stmt conn.createStatement();参数不是越大越好能力声明超出驱动实际支持范围报错信息往往只有一句[Microsoft][ODBC 驱动程序管理器] 驱动程序不支持所请求的属性看不出是哪一行触发的。3.2 结果集遍历与 gb2312 的连带问题原料页面指令写的是contentTypetext/html; charsetgb2312同时又用meta http-equiv声明了一遍。这段代码是从 GBK 编码的编辑器里写出来的年代产物在当年没问题。今天把文件另存成 UTF-8 再跑页面中文就全变问号——因为 JSP 编译时按pageEncoding解码源文件没写pageEncoding时按contentType里的 charset 推断容器拿 gb2312 去解一份 UTF-8 文件中文自然碎掉。新版写法把两个声明都摆出来并且统一成 UTF-8% page contentTypetext/html; charsetUTF-8 pageEncodingUTF-8 languagejava importjava.sql.* %这里有个连带效应值得注意out.print输出的是字符容器按contentType里的 charset 编码成字节发给浏览器。声明和文件实际编码一致页面才不乱码。另外 gb2312 字符集本身覆盖不全遇到生僻字或某些符号会变成?改成 UTF-8 顺手把这个坑也填了。% page contentTypetext/html; charsetUTF-8 pageEncodingUTF-8 importjava.sql.* % % String dbpath application.getRealPath(/data/test.mdb); String url jdbc:odbc:Driver{Microsoft Access Driver (*.mdb)};DBQ dbpath; 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()) { String uid rs.getString(uid); String pwd rs.getString(pwd); // 输出前判空Access 里空字符串和 NULL 是两回事getString 可能返回 null out.print(用户名 (uid null ? : uid)); out.print( 密码 (pwd null ? : pwd) br); } } catch (Exception e) { // 把异常类名一起打出来光看 message 经常分不清是驱动问题还是路径问题 out.print(连接失败 e.getClass().getName() - e.getMessage()); } finally { if (rs ! null) try { rs.close(); } catch (SQLException ignore) {} if (stmt ! null) try { stmt.close(); } catch (SQLException ignore) {} if (conn ! null) try { conn.close(); } catch (SQLException ignore) {} } %这段代码相较原料动了四处字符集统一 UTF-8、去掉两个无用变量、语句对象改无参、关闭动作挪进 finally。四处改动都对应一个真实故障模式不是为了好看。3.3 关闭顺序为什么 rs/stmt/conn 要放进 finally原料把rs.close()、stmt.close()、conn.close()写在 try 块末尾。问题在于只要executeQuery或循环中任何一行抛异常控制流直接跳到 catch三行关闭代码一行都不会执行连接就泄漏了。Access 是文件型数据库连接泄漏的表现比 MySQL 更直接——.ldb锁文件不被释放之后所有写操作都失败甚至读也读不了重启 Tomcat 才好。关闭顺序必须是结果集 → 语句 → 连接反过来关连接时驱动内部还要去清理子对象某些驱动版本会抛SQLException: 连接已关闭。每个 close 单独包一层 try-catch 也是必要的第一次关闭失败不应该阻断后面的关闭。上面的 JSP 代码已经按这个模式写了照抄即可。如果 JDK 是 7 及以上可以改成 try-with-resources 让语法更短try (Connection conn DriverManager.getConnection(url); Statement stmt conn.createStatement(); ResultSet rs stmt.executeQuery(SELECT uid, pwd FROM username)) { while (rs.next()) { // 业务逻辑 } } catch (Exception e) { e.printStackTrace(); }注意 try-with-resources 的关闭顺序是声明的逆序正好是 rs → stmt → conn符合要求。但这条语法糖和 JDBC-ODBC 桥有个版本冲突桥驱动在 JDK 7 还能用JDK 8 就被移除了所以这段写法在“原生支持 ODBC 桥”的环境里只能用 JDK 7 这一档取舍得自己权衡。4. 驱动换代sun.jdbc.odbc 消失之后的两条落地路线这是整套方案里唯一一个绕不过去的时代问题。sun.jdbc.odbc.JdbcOdbcDriver在 JDK 7 被标记为废弃JDK 8 正式移除。也就是说如果你的环境已经是 JDK 8、11、17这段 JSP 在Class.forName那一行就结束了后面所有代码都是死代码。这时候有两条路选哪条取决于你要不要动系统环境。4.1 路线一UCanAccess 纯 Java 驱动不改系统环境UCanAccess 是一个纯 Java 的 Access 驱动直接读写.mdb/.accdb文件不依赖系统 ODBC。它通过 Jackcess 解析文件格式所以不需要装任何 Access 相关组件也不区分 32 位 64 位扔进WEB-INF/lib就能用。对“我只是想把这段课设代码在新电脑上跑起来”的场景这条路最省事。需要准备的 jar 大致是这几类UCanAccess 主包、Jackcess、commons-lang3、commons-logging部分版本还要 hsqldb用于memorytrue时的内存缓存。这几家的官网和中央仓库页面都有依赖清单以页面上的最新版为准别从第三方网盘抓一堆不知道版本的 jar 拼进去很容易出NoClassDefFoundError。jar 放好之后JSP 里只改两行% // 必须用绝对路径UCanAccess 不认 Web 应用的相对资源路径 String dbpath application.getRealPath(/data/test.mdb); // memoryfalse 表示不把整个库读进内存库稍大时这个参数很关键 String url jdbc:ucanaccess:// dbpath ;memoryfalse;immediatelyReleaseResourcestrue; try (Connection conn DriverManager.getConnection(url); Statement stmt conn.createStatement(); ResultSet rs stmt.executeQuery(SELECT uid, pwd FROM username)) { while (rs.next()) { out.print(用户名 rs.getString(uid) 密码 rs.getString(pwd) br); } } catch (Exception e) { out.print(连接失败 e.getMessage()); } %这里不需要Class.forNameUCanAccess 走 JDBC 4 的 SPI 自动注册jar 在 classpath 上就能被DriverManager发现。memory参数的含义是把库文件整体载入内存还是按需读取默认值偏向内存模式读得快但库大了会吃堆内存几十兆以上的库建议显式关掉。需要注意 UCanAccess 的 SQL 方言比标准 SQL 窄一些SELECT TOP n、日期函数、部分联合查询的写法都有限制。原来的SELECT * FROM username这种简单语句完全没问题一旦上复杂查询先在独立的 Java 程序里跑通再搬进 JSP。4.2 路线二装 Access Database Engine 走系统 DSN位数必须对齐第二条路线是保留 JDBC-ODBC 桥的写法把系统侧的 ODBC 驱动补上。这条路只适合一种情况你的 JDK 还停留在 6 或 7跑不了 UCanAccess 的新版本或者所在环境不允许往WEB-INF/lib里加第三方 jar。在这种前提下问题从“驱动类不存在”变成了“ODBC 数据源找不到”。Windows 上有两个 ODBC 管理器入口64 位的odbcad32.exe在System32下32 位的在SysWOW64下。名字一样功能完全不同各自管理各自位数的数据源。JVM 是 64 位就必须配 64 位驱动JVM 是 32 位就必须配 32 位驱动否则连接串写得再对也是[IM002]。装 Microsoft Access Database Engine 时可执行文件的位数也要和 JVM 对齐装错了不会报错只是那个位数的 ODBC 列表里看不到 Access 驱动。配置走完之后连接串可以简化成 DSN 形式// DSN 名必须与 ODBC 管理器里创建的名字完全一致大小写不敏感但空格敏感 String url jdbc:odbc:testDSN; Connection conn DriverManager.getConnection(url);DSN 方案的好处是连接串里不出现文件路径换机器只要重建同名 DSN 就行坏处是多了一层系统配置依赖换台机器部署就得重新配一遍容器化部署基本不可行。4.3 两条路线的选型对照对比项原生 JDBC-ODBC 桥UCanAccess系统 DSN依赖 JDK 版本仅 6/7无限制仅 6/7依赖系统组件需 Access ODBC 驱动不需要需 ODBC 驱动 手工建 DSN32/64 位问题有容易踩无有更容易踩部署可移植性中高低支持 accdb需换驱动名原生支持需换驱动名复杂 SQL 兼容性取决于 Access 引擎有方言限制取决于 Access 引擎按我的经验新起的练习项目直接上 UCanAccess老系统维护且 JDK 已经是 8 以上也建议换 UCanAccess改两行代码的成本远低于降 JDK 的连带风险。只有一种情况值得保留桥驱动整个项目的构建链锁死在 JDK 6 上动不了那就老老实实把 ODBC 位数对齐。5. 排错对照五类高频故障的现象、成因与改法下面五条是这类项目里重复出现率最高的。每条按“看到什么 → 为什么 → 怎么改”组织报错信息直接拿去搜也能对上。5.1 现象java.lang.ClassNotFoundException: sun.jdbc.odbc.JdbcOdbcDriver这是最常见的一条也是误判最多的一条。页面能正常渲染说明 JSP 编译成功、Tomcat 正常但执行到Class.forName就抛异常。此时数据库文件在不在、路径对不对、ODBC 驱动装没装全都不重要因为类根本没加载到。原因只有一个运行这个 JSP 的 JVM 版本是 JDK 8 或更高JDK 里已经不含 JDBC-ODBC 桥的实现类。原料那段代码写于 Tomcat 6 时代配套的 JDK 通常是 1.5 或 1.6那个年代这类写法完全合法。解决办法按优先级排换成 UCanAccess改两行连接串jar 放进WEB-INF/lib如果项目能锁定 JDK降级到 JDK 7 也能恢复但要接受安全更新停止的代价不建议在新项目上这么做。改之前先确认 Tomcat 用的是哪个 JDK命令行执行java -version注意有些机器上JAVA_HOME指向的和你PATH里的不是同一个看 Tomcat 启动日志开头那几行最准。5.2 现象[IM002] 未找到数据源名称且未指定默认驱动程序这个报错说明驱动类加载成功了连接也发起出去了但系统在 ODBC 层面找不到对应驱动。三种成因按概率从高到低驱动名拼写和系统注册名不一致、装了 32 位驱动但 JVM 是 64 位或反过来、根本没装 Access 的 ODBC 驱动。核对顺序是先看驱动名。打开对应位数的 ODBC 管理器切到“驱动程序”页把Microsoft Access Driver (*.mdb)这一行原样复制包括括号和星号前面的空格。手敲极容易多或少一个空格肉眼看不出来。再看位数任务管理器里看 Tomcat 进程是不是带*32标记或者直接用java -version的输出判断。最后确认驱动是否安装如果 ODBC 列表里空空如也装一个对应位数的 Access Database Engine。顺带提一句Office 安装包里带的通常只是 32 位驱动很多人机器上装了 Office 就以为驱动齐了结果 Tomcat 跑在 64 位 JVM 上照样报 IM002。这是这个技术栈里最经典的血泪经验之一。5.3 现象连接成功、页面也出了但查不到数据或报“找不到文件”页面没抛异常只打印了一行空内容或者异常信息里明确提到文件路径不存在。这种情况下先把dbpath打印出来看out.print(dbpath)一行就够。原因通常是getRealPath返回的路径和你以为的不是同一个。IDE 调试时应用部署到工作空间临时目录容器可能配置了unpackWARsfalse这两种情况都会让application.getRealPath(/data/test.mdb)指向一个没有 test.mdb 的目录甚至返回null。返回null时拼出来的连接串是DBQnullODBC 会把它当文件名处理报的错误和“文件不存在”一模一样。改法有两个方向调试阶段直接把绝对路径写死先跑通再说部署阶段把数据库文件放到 Web 应用目录之外路径从环境变量或配置文件读避免被重新部署冲掉。后面第 6 章会给出参数外置的具体做法。5.4 现象数据库里中文正常页面上全是问号或方块数据和查询都没问题问题出在编码链路上。JSP 页面有两次编码决策源文件按pageEncoding解码输出按contentType的 charset 编码。两处不一致、或者声明与实际保存编码不一致就会出现中文乱码。排查顺序先确认文件本身存成了什么编码编辑器状态栏一般能看到再把pageEncoding和contentType里的 charset 改成同一个值推荐 UTF-8最后检查有没有别的地方覆盖了响应编码比如在 JSP 中间调用response.setCharacterEncoding(gb2312)。三者统一之后基本就不会再有乱码。还有一个隐蔽情况out.print之前已经有一部分内容被 flush 出去了后面再设编码不生效。所以编码相关的设置必须放在页面最前面中间不要再动。5.5 现象跑一段时间后连不上或者重启后数据没了前者通常是.ldb锁文件残留或者连接泄漏后者是文件被重新部署覆盖了。Access 的文件锁机制比较原始一个进程打开写另一个进程就只能读异常退出时锁文件不一定被清理。表现是原本能用的页面突然开始报“文件已被另一用户使用”或者操作超时。处理办法是先停 Tomcat手工删掉同目录下的.ldb文件再启动。根治要靠连接管理不要在 JSP 里每次请求都新建连接又忘了关控制并发写必要时加一个简单的同步块把写操作串起来。数据丢失的情况更冤枉数据库放在webapps/ROOT/data下重新部署 war 包时整个目录被覆盖test.mdb 直接没了。所以只要进入实际使用阶段数据库文件就必须挪到 Web 应用目录之外比如CATALINA_HOME/data或者一个独立的数据目录靠配置项指过去。6. 让这段代码可交付参数外置与一次性探针页能跑通只是第一步交付给别人还得让路径和驱动名可改。做法很土但有效在web.xml里挂全局参数JSP 用application.getInitParameter读改配置不用动代码。!-- WEB-INF/web.xml参数名保持和 JSP 里读取的一致 -- context-param param-nameaccess.dbPath/param-name !-- 相对 Web 应用根目录也可以用绝对路径 -- param-value/data/test.mdb/param-value /context-param context-param param-nameaccess.driverName/param-name param-valueMicrosoft Access Driver (*.mdb)/param-value /context-param读取方式% String rel application.getInitParameter(access.dbPath); String drv application.getInitParameter(access.driverName); String dbpath application.getRealPath(rel); // 探针输出部署后第一件事就是打开页面看这两行对不对 out.print(dbpath dbpath br); out.print(driver drv br); out.print(jdbcDrivers ); java.util.Enumerationjava.sql.Driver ds java.sql.DriverManager.getDrivers(); while (ds.hasMoreElements()) { out.print(ds.nextElement().getClass().getName() | ); } %这段探针页值得单独存一个文件部署完先跑它不要直接开业务页。它一次性回答三个问题物理路径到底落在哪、驱动名有没有被改坏、DriverManager里到底注册了哪些驱动。第三个尤其有用换 UCanAccess 之后如果忘了放某个依赖 jar这里根本看不到net.ucanaccess.jdbc.UcanaccessDriver一眼就能定位是依赖缺失而不是代码写错。探针输出说明下一步dbpath null资源没解压或路径写错检查相对路径前导斜杠与 unpackWARs驱动列表里没有JdbcOdbcDriverJDK 已移除桥驱动换 UCanAccess驱动列表里没有UcanaccessDriverjar 未进WEB-INF/lib补依赖dbpath指向临时目录IDE 部署目录与手工目录不一致改用绝对路径从那以后我每次接这类老项目都是先把这个探针页跑一遍再动业务代码路径、驱动、注册状态三行输出摆在那儿比对着异常信息猜快太多。这套流程同样适用于任何“文件型数据库 容器部署”的组合换个库名照样能用。希望帮到你。本文还有配套的精品资源点击获取