JSP上机实习报告复盘：编码、JavaBean与转发链路避坑清单

简介这份JSP上机实习报告文档面向学习Java Web开发与JSP技术的在校学生及初学者围绕课程实验场景整理了一套可直接参考的上机实践记录。内容覆盖在JSP页面中用Java代码完成11计算并输出结果、创建BookInfo JavaBean封装name、price、stock、author属性、编写DoString工具类转义字符串中的尖括号以及基于JavaBean接收用户名和密码并完成admin/000校验与页面转发的登录程序末尾附有环境搭建、页面跳转与调试心得。资源包共1个doc文件约38KB篇幅紧凑适合作为课程作业对照、实验报告撰写模板与知识点复盘材料。目前已有102人浏览学习可供需要快速梳理JSP基础语法、JavaBean规范与简单登录流程的读者参考。1. JSP 上机实习报告真正值钱的是那几处差点翻车的地方翻完这份《JSP 上机实习报告》最有意思的发现是六道题里没有一道是死在业务逻辑上的。11 的算术没人算错BookInfo 的四个属性也没人写漏登录判断的 admin/000 更不至于记不住。真正把人卡住一下午的是 pageEncoding 写成了 ISO-8859-1、包名和类名大小写对不上、转发路径少了一个斜杠、转义时先换了后换了。这几处踩坑点才是这份文档资料里最该被抠出来的东西。下面按报告里六道题的顺序重新走一遍先讲 11 背后的三类 Java 代码块再讲两道 JavaBean 题的规范然后是登录那条收参—判断—转发的链路中间插一章专门写排查最后给一份交作业前十分钟能跑完的自检清单。新手能照着把六道题重新做对熟手能看到每处写法背后的判断依据。2. 从 11 到页面输出JSP 里三类 Java 代码块的分工第一题表面上是最简单的一道实际上它逼着你把项目的目录结构、page 指令、三种脚本标签一次性搞清楚。这三件事任何一件没弄明白后面五道题都会以各种奇怪的方式报错而且报错信息往往指向别处特别像玄学。2.1 项目目录结构决定了你后面所有的路径写法在 IDE 里新建动态 Web 项目之后会得到一套固定骨架页面文件放在 Web 内容根目录不同 IDE 里叫 WebContent、webapp 或 WebRoot编译产物落到WEB-INF/classes第三方 jar 放WEB-INF/lib而WEB-INF本身对浏览器是不可直接访问的。这个“不可直接访问”不是限制是设计。它意味着凡是放在WEB-INF下的 JSP浏览器敲地址访问不到只能由服务端转发进去。后面第四题、第六题做页面跳转时路径到底该相对谁、该不该带斜杠全部由这套结构决定。我一般会建议在动手写第一行代码之前先在脑子里过一遍这道题这个 JSP 是要被浏览器直接敲地址打开的还是只作为转发目标答案不同放置位置和跳转写法就不同。判断依据很简单能被直接访问的页面路径相对“应用上下文根”只能被转发到的页面路径以/开头、相对上下文根来写并且可以安全地藏在WEB-INF里。很多人第一题就随便把 JSP 丢在项目根下后面做登录跳转时又照抄相对路径结果一改目录就 404。2.2 脚本片段、表达式、声明三种标签的分工与边界JSP 里嵌 Java 代码有三种写法职责完全不同混用就会出问题。标签名称编译后的位置是否直接输出典型用途% %脚本片段_jspService方法体内否需自己 out声明局部变量、写 if/for、调方法% %表达式_jspService内的out.print(...)参数是自动转字符串输出变量、表达式结果%! %声明Servlet 类的成员位置否定义成员变量或方法第一题用的是表达式因为它的目标就是把一个计算结果打到页面上。这里有两个高频错误一是表达式后面加了分号% sum; %会直接编译失败因为分号被当成表达式的一部分二是在脚本片段里用out.print输出中文却没有设置响应编码浏览器拿到的字节流按默认编码解析就变成问号。声明的坑更深。写在%! %里的变量是 Servlet 的成员变量所有请求共享同一份。第一题只算 11 看不出问题但如果换成累加器两个浏览器同时刷新就会看到互相污染的结果。上机作业可以不管但心里要清楚%! %定义的是“应用级”状态脚本片段里定义的才是“请求级”局部变量。这也是后面讲 JavaBean 作用域时的底层逻辑。2.3 把 11 打到浏览器上完整可跑的一版把上面几件事合起来第一题正确的写法大致是这样% page languagejava contentTypetext/html; charsetUTF-8 pageEncodingUTF-8 % % // 脚本片段定义请求级局部变量每个请求各自一份 int a 1; int b 1; int sum a b; % !DOCTYPE html html head meta charsetUTF-8 title计算结果/title /head body %-- 表达式结果自动转字符串并输出 --% p1 1 % sum %/p /body /htmlpage 指令里那三个属性值得逐个说清楚。language指定脚本语言实际只有 java 一个选项contentType决定响应头里的Content-Type浏览器靠它判断页面按什么编码渲染pageEncoding决定容器用什么编码去读这个.jsp源文件本身。两者都写 UTF-8才算是把“读文件”和“写响应”两头都堵住了。报告里那段代码出现了pageEncodingISO-8859-1还叠了好几个 DOCTYPE明显是多段代码拼在一份文档里被格式吞掉了。这类文档资料的常见问题就是粘贴过程中标签被吃掉、引号变成全角、import.*这种无效导入残留下来。import.*是不合法的包名正确写法要么省略要么写importjava.util.*这样的具体包。看到这一行就要意识到这份报告里的代码不能逐字复制得按语义重写一遍。验证第一题是否真的跑通不用猜。打开浏览器开发者工具看 Network找到那个 JSP 请求检查响应头里的Content-Type是否带charsetUTF-8。带了说明编码链路是通的没带或写的是别的编码后面几道题只要出现中文就一定翻车。3. BookInfo 与 DoString两道 JavaBean 题里的规范与陷阱第四题和第五题看着是两类东西——一个是数据载体一个是工具方法——但它们被放在一起讲是有道理的JavaBean 的“规范”两个字一半靠命名约定一半靠容器用反射去猜。猜错了不会报错只会静默地拿不到值这是最耗时间的一种失败。3.1 值 JavaBean 的四条硬规范缺一条反射就失灵第四题要求 BookInfo 具备 name、price、stock、author 四个 String 属性。这份报告的代码里有几处典型问题包名小写、类名小写、setter 里写成了 name少了this.。类名小写这件事在 Java 里能编译通过但和规范不符且和后面classhbe.bookinfo的写法强耦合改一个地方就全线崩。一个能被容器正确识别的 JavaBean需要同时满足下面几条规范项具体要求不满足时的后果类可见性public 类且能被容器加载反射实例化抛异常或找不到类无参构造提供一个 public 无参构造方法容器无法 new 出实例属性私有成员变量 private不符合封装约定且部分框架不识别访问器成对getXxx / setXxx 命名成对出现属性名推导失败取到 null包名完整类必须放在包内且路径与包名一致类加载失败这里最容易被忽略的是“属性名由访问器推导而不是由成员变量决定”。如果有成员变量bookName但写成getName()那么这个 Bean 的属性名就是name而不是bookName。后面用jsp:setProperty propertyname才能对上写propertybookName就会抛找不到属性的异常。属性的首字母大小写规则也是固定的getURL()推导出的属性名是URL而不是uRL。另一处值得说道的是类型选择。price 和 stock 用 String能省掉输入校验的麻烦代价是所有比较和计算前都得手工转一次Integer.parseInt或new BigDecimal而且要处理空串和非法字符。上机作业里图省事没问题但心里要留个底真做业务时这两个字段应该是数字类型把校验前移到 setter 或独立的校验层比后面满页面 try-catch 靠谱。重写后的 BookInfo 大致如下package com.demo.bean; import java.io.Serializable; public class BookInfo implements Serializable { private static final long serialVersionUID 1L; private String name; private String price; private String stock; private String author; // 容器用反射实例化时必须有无参构造 public BookInfo() { } public String getName() { return name; } public void setName(String name) { this.name name; // 少了 this. 就是自己赋给自己 } public String getPrice() { return price; } public void setPrice(String price) { this.price price; } public String getStock() { return stock; } public void setStock(String stock) { this.stock stock; } public String getAuthor() { return author; } public void setAuthor(String author) { this.author author; } }implements Serializable这一条不是必须但加上以后对象才能塞进 session 或走序列化复制上机时用不到工作里迟早用得到。serialVersionUID同理属于“现在写一行以后省一次排查”的东西。3.2 工具 JavaBean 的转义顺序DoString 这道题真正考的是什么第五题的意图是把字符串里的尖括号换掉防止内容被当成 HTML 标签解析。报告里的实现只有两行而且写法上明显丢了方法名大概率原本是str.replace(...)。这里有两个关键判断。第一个是替换顺序。必须先替换再替换和。如果先换尖括号换出来的结果里就包含再处理时会把这部分又转义一遍最终页面显示出来是一堆amp;lt;的字面量。这个错误在页面上看起来只是“多显示了一个 ”很难第一眼联想到顺序问题属于典型的血泪经验。第二个是replace和replaceAll的区别。replace(CharSequence, CharSequence)是纯字面量替换replaceAll走正则。转义场景里要用前者因为一旦用了正则版本待处理的内容里只要出现正则元字符就可能被误解释。完整一点的做法是这样package com.demo.util; public final class DoString { // 工具类不允许实例化 private DoString() { } public static String escapeHtml(String str) { if (str null) { return ; } // 顺序不能反先处理 再处理 和引号 String s str.replace(, amp;); s s.replace(, lt;); s s.replace(, gt;); s s.replace(\, quot;); s s.replace(, #39;); return s; } }方法声明为 static是因为这类工具没有状态调用方不需要先 new 一个对象。声明为 final 类加私有构造是防止被继承和误实例化。这两条都属于约定不影响编译但决定这段代码被别人复用时会不会被带偏。需要提醒的是把转义塞进 JSP 显示层只是最粗的一层防护。真正落到生产应该在输出到 HTML 上下文时统一转义而不是靠某个页面记得调用一下工具类。上机作业做到这一层已经够了但别把“我写了 DoString”当成安全措施。3.3 用 jsp:useBean 把对象放进作用域JavaBean 写完了还得让 JSP 认识它。标准动作有三个useBean负责查找或创建setProperty负责赋值getProperty负责取值。% page languagejava contentTypetext/html; charsetUTF-8 pageEncodingUTF-8 % %-- id 是作用域里的键名class 必须是全限定类名 --% jsp:useBean idbook classcom.demo.bean.BookInfo scoperequest / %-- 手工赋值 --% jsp:setProperty namebook propertyname value某图书 / jsp:setProperty namebook propertyauthor value某作者 / p书名jsp:getProperty namebook propertyname //p p作者jsp:getProperty namebook propertyauthor //p四个属性里class最容易写错必须写全限定名写成BookInfo或bean.BookInfo都会找不到类。scope决定这个对象的生命周期四种取值的判断依据是“谁需要读到它”只在当前页面用就 page要在转发链路里传就 request要跨多次请求记住就 session全局共享就 application。上机时基本都是 request。setProperty还有一个更省事的写法property*它会把请求参数按名字自动匹配到所有同名属性上。第六题登录里的用户名密码用这个动作可以省掉两行取值代码。代价是它会一次性把所有能匹配的参数都塞进去参数名和属性名对不上时静默跳过出错时不好定位。所以我更倾向在作业里手写getParameter哪怕多两行至少每一步都看得见。4. 登录判断这条链收参、比较、转发三步怎么落地第六题是整份报告里唯一一道“有流程”的题页面收参、代码判断、按结果去不同页面。它把前面几题的东西全串起来了——Bean 负责承载、脚本负责判断、转发负责跳转中间任何一环写错看到的现象都是“点了没反应”或者“跳到了奇怪的地址”。4.1 收参的三个动作和编码设置的位置接收表单参数只需要一句request.getParameter(username)但要把中文正确收进来还有两个前提动作。第一个是编码设置的位置。request.setCharacterEncoding(UTF-8)必须放在第一次读取参数之前。容器在第一次getParameter时就把请求体解析成字符串并缓存了之后再设编码不会重新解析等于白设。这个顺序问题在代码里看不出任何异常只会表现为“中文全变问号”非常容易误判成页面编码没写对。第二个是 GET 和 POST 的差别。表单默认 method 是 GET参数拼在 URL 上请求体为空setCharacterEncoding对它们不起作用——查询串的解码依赖容器对 URI 的编码配置。所以做登录这类提交表单要明确写methodpost让编码设置真正生效。这一步在报告原文里没有体现但它是中文字段能不能正确收到的前提。form actionlogin.jsp methodpost 用户名input typetext nameusername 密码input typepassword namepassword button typesubmit登录/button /form表单里两个 input 的name值必须和后面getParameter里的字符串一字不差包括大小写。这是另一个查起来最费劲的地方参数取到 null代码看起来毫无问题实际只是名字对不上。4.2 判断逻辑写在 JSP 里到底合不合适作业允许在 JSP 里直接写 if-else因为题目就是这么要求的。但从工程角度看这段逻辑有几个必须补的细节。比较字符串要用equals而不是这一点报告里写对了。更稳的写法是把常量放左边admin.equals(username)这样即使 username 是 null 也不会抛空指针只是返回 false。判断条件里如果两个都是变量一旦有一个为 null就会直接抛异常页面变成 500。% page languagejava contentTypetext/html; charsetUTF-8 pageEncodingUTF-8 % % request.setCharacterEncoding(UTF-8); // 必须在取参数之前 String username request.getParameter(username); String password request.getParameter(password); // 常量在前避免 username 为 null 时抛空指针 if (admin.equals(username) 000.equals(password)) { request.setAttribute(msg, 欢迎登录); request.getRequestDispatcher(/ok.jsp).forward(request, response); } else { request.setAttribute(msg, 登录失败); request.getRequestDispatcher(/fail.jsp).forward(request, response); } %还有一点要说明把判断逻辑放在 JSP 里等于把控制逻辑和展示混在一起页面越写越难维护。上机阶段没问题但心里要清楚正规做法是放到 Servlet 或过滤器里JSP 只负责渲染。这个迁移思路值得在报告的心得部分提一句比单纯写“学会了页面跳转”有价值得多。另外登录判断这个例子里把用户名密码硬编码在页面中只能作为练习题不能理解为真实登录实现。真实系统里密码要存哈希、要防暴力尝试、要走会话管理这几件事在这道题的范围之外但别把作业写法当成可上线方案。4.3 转发与重定向路径、作用域、地址栏三处差异第六题说“转发到页面显示”用的是RequestDispatcher.forward。它和response.sendRedirect经常被混着用因为两者在浏览器上都能看到页面变了。对比项转发 forward重定向 sendRedirect请求次数1 次服务端内部转交2 次浏览器重新发起地址栏不变变为新地址request 作用域保留可以传 attribute丢失需要靠 session 或参数路径基准以/开头时相对上下文根相对当前请求路径或写完整路径能否到达 WEB-INF 下页面可以不可以这张表里的前两行决定了如果用了重定向前面request.setAttribute(msg, ...)设的值在目标页面里一定是 null。这个现象非常迷惑人——代码没错页面就是拿不到值。判断依据是需要携带 request 级数据就必须用转发。路径那一行同样关键。转发里写getRequestDispatcher(ok.jsp)不带斜杠和写/ok.jsp带斜杠解析基准不同前者相对当前请求的目录后者相对应用根。目标页面在根目录时两种写法都能通一旦页面挪到子目录不带斜杠的写法就开始 404。我一般直接统一成带斜杠的绝对写法省得以后挪文件时重新推理一遍。还有一处容易被忽略forward之后再往响应里写内容是没有意义的因为响应已经提交了。所以转发语句之后不要跟out.print或者 HTML那些内容不会按预期出现。5. 避坑与排查上机最常卡住的五个地方这一章把六道题里反复出现的问题集中列一遍。每一条都按“看到什么现象—为什么会这样—怎么解决”来写遇到卡壳时可以按顺序对照。5.1 中文乱码三处编码只要有一处不一致就出问题现象页面上的中文变成问号、方块或者提交的中文参数在后台取出来是乱码英文数字一切正常。原因整条链路上有三处编码需要一致——JSP 源文件的读取编码pageEncoding、响应的输出编码contentType 里的 charset、请求参数的解析编码setCharacterEncoding 或容器 URI 配置。报告原文里出现过 ISO-8859-1 和 utf-8 混用的情况这种混搭在纯英文页面里看不出问题一旦出现中文就必然翻车。解决page 指令统一写contentTypetext/html; charsetUTF-8 pageEncodingUTF-8取参数前第一行写request.setCharacterEncoding(UTF-8)表单明确用 POST。三处都对齐后仍乱码就去查容器的 URI 编码配置那是 GET 请求的最后一道关口。5.2 包名、类名与实例化对不上ClassNotFound 和属性为 null现象jsp:useBean报找不到类或者类找到了但页面显示 nullsetter 明明写了却没生效。原因三种情况最常见。类名首字母小写如bookinfo、包名和目录结构不一致、class属性没写全限定名。另一种是属性名推导错位——成员变量叫bookName访问器叫getName属性名就变成了name。解决先把类名改成大驼峰、包名全小写确认WEB-INF/classes下生成的 class 路径与包名逐级对应再检查class属性里带没带包名最后核对property的值和访问器推导出的属性名是否一致。这三步走完反射相关的报错基本都能定位。5.3 转义顺序反了页面上多出一串 lt;现象本来只想把转成实体结果页面显示的是amp;lt;这种双层转义后的字面量。原因替换顺序写反了。先处理了尖括号产生的结果里含再处理时把新产生的实体又转义了一遍。解决固定顺序先再、、、。另外确认用的是replace而不是replaceAll后者按正则处理遇到内容里带正则元字符时会给出意外结果。5.4 转发之后 404 或白屏路径基准和响应提交现象判断逻辑走对了分支但浏览器显示 404或者干脆一片空白。原因404 大多是转发路径的基准搞错了不带斜杠时相对当前目录解析页面一挪位置就断白屏则通常是forward之后又写了输出或者转发目标页面本身有编译错误被吞掉了。解决转发路径统一以/开头相对上下文根把forward放在分支的最后一行后面不再写任何输出如果目标页面白屏直接单独访问一次那个页面看它自己的报错信息很多时候问题根本不在转发这一步。5.5 改了代码没生效class 没重编译或缓存还在现象改完 JavaBean 的代码刷新浏览器页面行为还是旧的清浏览器缓存也没用。原因JSP 会自动重编译但.java文件改完之后编译产物不一定同步更新到WEB-INF/classes尤其是手工放 class 的项目。另外容器对已加载的类有缓存热部署没触发时旧版本会一直生效。解决先确认WEB-INF/classes下对应 class 的时间戳是不是最新的不是就手工重新编译或让 IDE 重新发布。再不行就重启容器别在浏览器层面反复刷新浪费时间。这一条属于典型的“看起来像代码问题实际是构建问题”排查时先把构建产物放在怀疑链的第一位。6. 交报告之前一份十分钟能跑完的自检清单六道题做完别急着交。按下面这张表走一遍把能提前发现的错误在本地解决掉比交上去被退回来重做强得多。检查项合格标准出问题时先看哪儿编码一致性所有 JSP 的 page 指令都写 UTF-8响应头带 charset响应头 Content-Type类加载WEB-INF/classes下 class 路径与包名逐级对应目录结构与 package 声明Bean 规范类名大驼峰、有无参构造、访问器成对属性名推导结果转义顺序先 后尖括号用 replace 不用 replaceAll页面输出内容转发路径统一以/开头forward 后无输出目标页面能否单独访问请求方法含中文的表单用 POST取参前设编码表单 method 与 setCharacterEncoding 位置表里最后一行值得单独说一个技巧判断编码问题到底出在读取还是输出不用靠猜。打开浏览器开发者工具看响应头里Content-Type后面带的 charset如果这里是对的但页面还是乱码问题就在源文件读取或请求解析那一侧。这个判断方法只需要十秒比反复改代码试错快得多。回过头看这份上机报告里真正让我记住的不是那六段代码而是几个“当时不知道为什么、后来才想明白”的瞬间setCharacterEncoding 为什么必须写在取参之前、forward 之后为什么不能有输出、转义为什么有顺序。这些点在没有报错提示的情况下只能靠理解机制去推。从那以后我每次碰这种练习性质的项目都会强制走一遍上面那张表顺序固定、不跳步——因为它省下的是最难受的那部分时间明明觉得自己写对了却怎么都找不出错在哪。这份报告的价值也在这里它把六个小题摆在一起正好把 JSP 最基础的那条链路完整走了一遍照着复现一次比看十篇教程都实在。希望帮到你。本文还有配套的精品资源点击获取