JSP六道上机题复盘：中文乱码、JavaBean与forward避坑-开发者社区

简介：《JSP上机实习报告》文档面向JSP开发技术课程的初学者与需要完成上机实验的学生，围绕基础语法、JavaBean应用和简单Web交互整理了一份课程实践参考。包内共1个doc文件，约38KB，内容以实验题目、实现代码和心得总结为主，适合在Eclipse环境中对照练习。文档涵盖JSP中Java代码计算并输出结果、留言输入与展示、BookInfo JavaBean属性封装、DoString字符串尖括号转义工具类，以及基于admin/000的登录判断与页面转发等六类上机任务，并附有开发环境搭建、页面跳转和代码调试的体会。已有102人学习或浏览，可用于复盘实验步骤、理解JSP表达式与JavaBean规范，也可作为课程报告撰写和排错思路的参考。

1. 第一次交 JSP 上机实习报告，六道题全跑通，答辩时一句话就被问住了

那份 JSP 上机实习报告我至今留着。六道题从1+1到 BookInfo、DoString，再到登录判断和留言板，页面全都能跑，截图也齐。结果被问了一句「你这个 pageEncoding 为什么写了三遍，还各不一样」，我卡了十几秒没答上来。后来才发现，报告这种东西最怕的不是写错，是不知道自己为什么这么写。

这份文档资料的价值不在「有答案」，而在它把 JSP 那套老派但必须懂的东西摆成了一条线：表达式和脚本片段的边界、JavaBean 的三条硬规矩、forward 和 redirect 的差别、中文乱码到底从哪来。下面按六道题的顺序拆，写给正在做课设、要交报告、或者想把 JSP 补齐的人看。新手照着能复现，熟手能对一下自己的判断依据。

2. 六道题的考点对照：难度曲线比代码本身更值得看

六道题摆在纸面上像是从易到难，真实的难度曲线并不是均匀上升的。前两题几乎不用思考，第三、四题开始考验「你懂不懂容器怎么和你的类打交道」，第五题考的是安全意识，第六题才开始碰请求流转。把这个曲线看清楚，比把六段代码抄对重要得多。

2.1 一张表看清每道题到底考什么

我把报告里的题目和自己的实现重新对了一遍，按「表面要求、实际考点、翻车点」三列整理。这张表是我后来复习 JSP 时翻得最多的一页，因为每一行的「实际考点」都比题目描述要深一层。

题号	表面要求	实际考点	最容易翻车的地方
第一题	用 Java 代码算`1+1`并显示	`<%@ page %>`指令、脚本片段与表达式的分工	pageEncoding 写了多份且互相冲突
第二题	页面输出与基本 HTML 结构	JSP 本质是「会执行的 HTML」，输出流顺序	把`<% %>`当成模板占位符
第三题	留言输入页	表单 method、action、name 属性三件套	表单字段 name 与后台取值拼写不一致
第四题	BookInfo JavaBean	无参构造、私有字段、getter/setter 命名规范	类名大小写、包名与 useBean 的 class 属性对不上
第五题	DoString 转义工具	字符串字面替换与正则替换的区别	用 replaceAll 却不转义，或转义顺序做反
第六题	登录判断与页面转发	request 域、转发与重定向、空指针防护	forward 之后没有 return，两个页面都输出

看着这张表你会发现，六道题里真正写业务逻辑的只有最后一题的equals那一行，其余全是「框架约定」的考题。这也是为什么很多人代码能跑、被问就答不上：跑通说明你运气好，踩对了约定；讲不清说明你没把约定当成知识。

我一般会这么判断一份 JSP 报告的水平：不看它有几个页面，看它有没有把「为什么这么写」写进注释。比如<%@ page %>那一行，有人写pageEncoding="ISO-8859-1"，有人写UTF-8，两者的差别在中文页面上会立刻暴露。报告里如果连这个都没解释，那基本可以判断是照抄的。

2.2 第四题和第五题才是分水岭

前三个题属于「语法热身」，第四题开始进入容器协作。JavaBean 不是一个普通的类，它是一份契约：无参构造函数、私有字段、按getXxx/setXxx命名的访问器。容器要靠反射去 new 它、去调 setter，任何一条不满足，你在 JSP 里就会拿到 null 或者直接抛异常。

我在这一题上翻过一次车：类写在hbe包下，JSP 里class="hbe.BookInfo"写成了class="BookInfo"，页面不报错，只是属性永远是 null。找了半小时，最后把useBean的class属性打印出来才看明白——容器找不到类时不会大声喊，它只是安静地给你一个空对象。这种「静默失败」在后来的实际项目里也会反复出现，值得在实习阶段就记住。

第五题的分水岭意义在于它第一次出现了「安全」这个词。把<和>换成<和>，表面是字符串处理，本质是输出编码。你在留言板上原样输出用户输入的内容，浏览器就会把它当标签解析，这就是最原始的一种注入。很多同学做完这题只记住了replace这个 API，没记住「用户输入不可信」这条原则，那就白做了。

第六题反而是纸老虎。登录判断本身只有一行equals，难的是弄清楚「校验放在哪、结果怎么传、页面怎么跳」。这题做完，你对一次 HTTP 请求在容器里怎么走，就算有了第一遍完整认知。

2.3 我给自己定的验收标准：跑通、讲清、能改

报告交上去之前，我会强迫自己过三道关。第一关是跑通，这个最容易，清缓存重新部署一次，六个页面全部点一遍。第二关是讲清，随便挑一段代码，合上屏幕复述它做了什么、为什么不用另一种写法。第三关是能改，比如把1+1改成从表单接收两个数再相加，把 BookInfo 加一个属性，把登录判断改成从数据库查。三关都过，才算真的会了。

第三关最容易被跳过，也最有用。我第一次做「改成从表单接收两个数」的时候，立刻撞上了request.getParameter返回字符串、需要Integer.parseInt的问题，顺手又学会了空值判断。这些连锁反应是抄代码永远碰不到的。

另外提一句，报告整理了六道题的完整代码和自己的实现过程，当成一份可以对照的文档资料来读，比零散搜帖效率高，因为它的顺序就是一条学习路径。但别只读，一定要在自己的环境里跑一遍。

3. 环境与第一个 JSP：1+1 跑起来要先避开三件事

第一题看起来是最简单的，实际上它一次性把三个最容易出错的地方全暴露了：项目结构、编码声明、脚本写法。这三件事在后面的五道题里会反复出现，所以值得在第一步就弄清楚，而不是等页面出乱码了再回头补。

3.1 动态 Web 项目的目录结构：WebContent 与 WEB-INF 的分工

在 Eclipse 里建一个 Dynamic Web Project，目录会长成这个样子：src放 Java 源码，WebContent（新版也可能是src/main/webapp）放 JSP、HTML、CSS 和图片，WebContent/WEB-INF放web.xml和编译后的类文件。

关键认知是：WEB-INF下面的东西浏览器直接访问不到。你把 JSP 放进WEB-INF，用户输入地址是打不开的，只能由服务器内部转发过去。这个特性在后面做登录拦截时非常有用——把「欢迎页」和「失败页」放进WEB-INF，用户就没法绕过校验直接访问。

第一次建项目最常见的错误是把 JSP 建在src目录下。文件确实创建成功了，编辑器也认识，但部署之后访问就是 404。原因很简单，src里的东西会被编译进classes，不会被当成静态资源对外暴露。

另外建议第一题就习惯用包名。类分门别类放，Bean 放一个包、工具类放另一个包。这不是洁癖，是为了让useBean的class属性有一个稳定的全限定名可以写。

3.2 pageEncoding 与 contentType：两个东西不能混着写

我在第一题代码里看到过pageEncoding出现好几遍、而且值不一样的情况，这在实习报告里很典型。这两个属性的分工要说清楚：

pageEncoding告诉容器「这个 JSP 文件本身是用什么编码保存的」，它影响的是 JSP 源码被读进来时的解码方式。
contentType="text/html; charset=UTF-8"告诉浏览器「我发给你的内容是 UTF-8」，它影响的是响应的解码方式。

一个管读，一个管写。两边不一致，中文就会变成问号或者乱码。最省事的写法是让它们保持一致，并且都写UTF-8：

<%@ page language="java" contentType="text/html; charset=UTF-8" pageEncoding="UTF-8"%> <!DOCTYPE html> <html> <head> <meta charset="UTF-8"> <title>第一个 JSP 页面</title> </head> <body> <%-- 脚本片段负责算，表达式负责输出，两件事分开写 --%> <% int a = 1; int b = 1; int sum = a + b; out.print("脚本片段输出：" + sum + "<br>"); %> 表达式输出：<%= sum %> </body> </html>

这段代码里pageEncoding="UTF-8"保证文件被正确读取，contentType里的charset=UTF-8保证浏览器正确显示，<meta charset="UTF-8">是给 HTML 兜底。三处一致，中文基本不会出问题。如果只有一处写错，症状通常是「页面其他中文正常，某一处乱码」，或者干脆整页问号。

ISO-8859-1是老教材里常见的默认值，它只有单字节，装不下中文。看到这个值就该警惕，尤其是页面里出现了中文标题或表单。

3.3 表达式 <%= %> 与脚本片段 <% %>：别把输出和逻辑混在一起

第 1 章那个1+1，最简写法其实只有一行<%= 1 + 1 %>。表达式标签会把计算结果转成字符串直接塞进输出流，末尾不要加分号。而<% ... %>是脚本片段，里面写的是普通 Java 语句，必须加分号，要输出得自己调out.print。

这两个东西混用是新手最常见的错误之一。比如在脚本片段里写<%= int a = 1; %>，编译直接报错，因为表达式标签里只能是表达式，不能是语句。反过来在表达式里写out.print也没意义，会把print的返回值（void）当字符串输出，实际什么也没有。

JSP 页面被翻译成 Servlet 的时候，脚本片段原样进入_jspService方法体，表达式变成out.print(...)。理解这一层翻译关系，你就能预判哪些写法会报错：局部变量可以声明在脚本片段里，方法不能——你不能在一个方法里再定义一个方法。

这也是为什么后来的 JSP 规范越来越不推荐在页面里写大量脚本片段。逻辑应该进 Java 类，页面只负责展示。第四题的 JavaBean 和第六题的转发，本质上都是在往这个方向上引导。第一题就应该有意识：能用一个表达式解决的，别开脚本片段。

4. JavaBean 两道题：BookInfo 练封装，DoString 练转义

第四题和第五题看着是两类题，其实考的是同一件事——把逻辑从页面里搬出去。BookInfo 把数据搬出去，DoString 把处理搬出去。搬出去之后，页面才可能变干净，代码才可能被复用和测试。这两题的实现细节值得逐行看。

4.1 BookInfo：四个 String 属性背后是三条硬规矩

题目要求建一个名为 BookInfo 的 JavaBean，有name、price、stock、author四个简单属性，类型都是String。看着是个纯数据类，但容器要用它，就得守规矩。

package hbe; public class BookInfo { private String name; private String price; private String stock; private String author; // 规矩一：必须有无参构造，容器靠反射 new 出实例 public BookInfo() { } // 规矩二：字段私有，对外只暴露 getter/setter // 规矩三：命名必须是 getXxx / setXxx，Xxx 首字母大写 public String getName() { return name; } public void setName(String name) { this.name = name; } 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; } }

三个地方值得多说两句。一是this.name = name里的this不能省，省了就是自己赋给自己，属性永远是 null。原始报告里这一行被截断成= name;，如果真按这个写，编译器直接报错，算是运气好；真正难查的是写成name = name;，能编译，但值永远传不进去。

二是price和stock用String是题目要求，实际项目里前者通常是BigDecimal、后者是int。用String的好处是省掉类型转换，坏处是从此没人拦着你往价格里填「abc」。这一点在自己的报告里可以写一句反思，比单纯抄代码有价值。

三是包名。类放在hbe包下，useBean就必须写全限定名hbe.BookInfo。少了包名，容器找不到类，不会抛异常，只会给你一个空对象——这是踩过一次就忘不掉的坑。

4.2 DoString：字符串转义为什么不能直接 replaceAll

第五题要一个工具类，把字符串里的<和>换成<和>。这题最容易被写成一行replaceAll，然后在校验的时候被问「如果用户输入里带正则元字符怎么办」。

package hby; public class DoString { // 纯字面替换，不需要考虑正则语法，这是首选 public static String change(String str) { if (str == null) { return null; // 工具类先挡空值，调用方少写一堆判空 } return str.replace("<", "&lt;").replace(">", "&gt;"); } }

replace(CharSequence, CharSequence)是字面替换，你传什么就匹配什么，不涉及正则。replaceAll(String, String)第一个参数是正则表达式，第二个参数里$和\有特殊含义。对一个只换尖括号的需求，用replaceAll纯属给自己找事，一旦将来要转义&、"、'这些字符，正则元字符的问题会立刻冒出来。

顺序也有讲究。安全实践中正确的顺序是先转&，再转<和>，否则先转出来的<里那个&会被二次转义成&lt;，页面显示出来反而是一串实体码。这题只要求尖括号，所以顺序不影响结果，但这个思考过程值得写进报告——它说明你想过「如果需求扩大怎么办」。

还有一个细节是空值处理。工具类被调用的地方可能传 null 进来，null.replace(...)直接 NPE。一行判空省掉调用方无数麻烦，这是工具类的基本素养。

4.3 在 JSP 里接上 Bean：useBean、setProperty 与 EL

Bean 写好了，得在页面上用起来。传统写法是三条指令：

<%@ page language="java" contentType="text/html; charset=UTF-8" pageEncoding="UTF-8"%> <%-- id 是页面内变量名，class 必须是全限定名，scope 决定它活多久 --%> <jsp:useBean id="book" class="hbe.BookInfo" scope="request" /> <jsp:setProperty name="book" property="name" value="JSP 实践" /> <jsp:setProperty name="book" property="price" value="59.00" /> <jsp:setProperty name="book" property="stock" value="10" /> <jsp:setProperty name="book" property="author" value="某开发者" /> <p>书名：<jsp:getProperty name="book" property="name" /></p> <p>价格：<jsp:getProperty name="book" property="price" /></p>

scope有四个取值：page、request、session、application，作用域依次扩大。page只在当前页面有效，request在一次请求内有效（转发后还能拿到），session跟会话走，application全应用共享。选错了会有很诡异的症状，比如设了值却在下一个页面读不到。

用 EL 表达式会更清爽：${book.name}等价于getBook之后调getName，找不到时会安静地输出空串而不是抛异常。EL 里还有一个细节，属性名首字母大小写和方法名的对应关系是容器处理的，${book.name}会去找getName()，找不到再找isName()。

这题真正想让你体会的是「页面只负责展示」这件事。数据准备和业务处理都在 Java 类里，JSP 只用几个标签把值贴上去，页面从此可以交给不写 Java 的人去调样式。

4.4 登录判断与页面转发：forward 之后记得 return

第六题要求判断用户名是不是admin、密码是不是000，是就转发到欢迎页，否则转发到失败页。核心代码就这几行，但陷阱不少：

<%@ page language="java" contentType="text/html; charset=UTF-8" pageEncoding="UTF-8"%> <% // POST 中文必须先设编码，且要在第一次 getParameter 之前 request.setCharacterEncoding("UTF-8"); String username = request.getParameter("username"); String password = request.getParameter("password"); // 常量在前，避免 username 为 null 时抛 NPE boolean ok = "admin".equals(username) && "000".equals(password); if (ok) { request.getRequestDispatcher("/WEB-INF/welcome.jsp").forward(request, response); return; // 关键：转发之后立刻 return，否则后面的代码还会继续执行 } else { request.getRequestDispatcher("/WEB-INF/fail.jsp").forward(request, response); return; } %>

三个点。一是"admin".equals(username)的顺序，反过来写成username.equals("admin")，用户没填就直接 NPE，这是最常见的一类线上事故。

二是forward之后必须return。转发只是把请求交给另一个资源处理，当前 JSP 并不会因此停下，后面的代码照跑。少了return，两个页面的内容可能同时出现在响应里，表现成「欢迎登录」下面跟着半截失败提示。

三是把目标页放进WEB-INF，用户就没法直接敲地址绕过校验。这是把 3.1 说的目录权限用起来的地方，也是这题唯一一个「超出题目要求但很有必要」的改动。

如果想再进一步，可以把这段判断从 JSP 搬到 Servlet 或者 Filter 里。页面里的脚本片段越少，后面越好维护。这一步在实习阶段不强制，但值得在报告的「心得」里提一句，说明你知道有更好的做法。

5. 排查记录：五个把我卡到凌晨的现场

JSP 的问题有个共同特点——报错信息往往指向别处，真正的错在另一个文件里。下面五条是我自己踩过、也见过别人反复踩的，按「现象 → 原因 → 解决」列出来，遇到时可以直接对号入座。

5.1 中文全变问号：三处编码没对齐

现象是页面上的中文全部显示成问号，英文和数字正常，重启服务也没用。

原因基本锁定在编码不一致上。JSP 文件本身可能是 GBK 保存的，pageEncoding却写了 UTF-8；或者文件是 UTF-8，contentType里没写charset，浏览器按默认编码解析。还有一种情况是 POST 提交的中文乱码，那是request.setCharacterEncoding没设或者设晚了。

解决按顺序排查：先确认文件的保存编码（编辑器右下角一般有显示），再确认pageEncoding与之一致，然后确认contentType带了charset=UTF-8，最后在接收参数的地方补一句request.setCharacterEncoding("UTF-8")，而且必须放在第一次getParameter之前。已经取过参数再设编码是无效的，这一点坑过很多人。

5.2 useBean 拿到的属性永远是 null

现象是页面不报错，<jsp:getProperty>输出空白，EL 输出空串，但 Java 类本身单测没问题。

原因有三个层次。最外层是class属性没写全限定名，少了包名；中间一层是类名大小写和文件名不一致，Windows 上不敏感，换到别的环境就炸；最里层是没有无参构造函数，你手写了带参构造，编译器就不再自动生成无参的那个，容器反射实例化直接失败。

解决是先用Class.forName("hbe.BookInfo").newInstance()在普通 main 方法里试一次，能过说明类没问题，问题在 JSP 的配置上；过不了就是类本身缺东西。另外检查<jsp:setProperty>的name属性是不是和useBean的id一致，这两个名字对不上也会静默失败。

5.3 改了代码刷新没变化

现象是明明改了 JSP，浏览器刷新还是老样子，有时候清缓存也没用。

原因是热部署没生效。Eclipse 默认可能没开自动构建，或者部署的是旧的 class 文件。Java 类改动尤其明显——JSP 文件改了通常能立刻反映，但.java文件如果不重新编译、不重新部署，容器用的还是旧版本。

解决是养成「改完 Java 就 Project → Clean，然后重启 Tomcat」的习惯。另一个排查手段是看 Tomcat 的work目录，JSP 翻译出来的 Servlet 源码就放在那里，打开看一眼就知道容器到底拿到了哪个版本。这个目录后来成了我排查 JSP 问题的黑匣子，比看日志直观。

5.4 表单提交后地址栏出现密码

现象是登录页点提交，浏览器地址栏变成了login.jsp?username=admin&password=000。

原因是<form>没写method，默认就是 GET。GET 把参数拼在 URL 上，会进浏览器历史、进服务器访问日志，密码等于明文公开。这题虽然只是课堂练习，但这个习惯必须从一开始就纠正。

解决是表单显式写method="post"，后台按 POST 取值。顺带检查一下action的路径，写相对路径时注意当前页面所在目录，别把请求发到自己身上。另外可以在报告里补一句：真做登录，密码不能明文比对，至少要做哈希——这句话能体现你知道练习和生产之间的差距。

5.5 转发之后样式全丢了

现象是登录成功后跳到欢迎页，页面结构在，但 CSS 和图片全部 404。

原因是相对路径的基准变了。转发之后浏览器地址栏还是原地址，但页面内容来自另一个目录下的 JSP，里面的css/style.css会按原地址去解析，自然找不到。重定向不会有这个问题，因为地址栏真的变了。

解决办法有三个：一是把资源路径写成以/开头的绝对路径（应用内绝对路径），二是用<%=request.getContextPath()%>拼前缀，三是把样式直接内联。实习阶段推荐第二种，虽然啰嗦一点，但不管怎么转发都不会错。顺带记住这个区别：转发是服务器内部行为，浏览器不知道；重定向是让浏览器再发一次请求，地址栏会变。

6. 交报告之前，我会固定跑一遍这套自检

把六道题全部重做一遍之后，我给自己定了一套提交前的固定动作，五分钟能跑完，能挡掉八成的低级问题。第一步是清空work目录重新部署，从第一题到第六题按顺序点一遍，确认没有 404、没有空白页。第二步是打开浏览器开发者工具，看 Network 里每个请求的状态码和响应头里的Content-Type，确认charset是 UTF-8。第三步是搜索整个项目里的编码声明，一条命令就能列全：

# 列出所有 JSP 里的编码声明，重点看有没有 ISO-8859-1 或者缺失 charset grep -rn "pageEncoding\|contentType" src/main/webapp --include=*.jsp # 顺便确认文件本身的真实编码，输出里出现 GBK 就要警惕 file -i src/main/webapp/*.jsp

第一条命令把每个 JSP 的pageEncoding和contentType都列出来，哪一行没写charset、哪一行还是ISO-8859-1，一眼就能看到。第二条命令看文件本身的实际编码，如果file报的是iso-8859-1或者unknown-8bit，说明文件保存格式就有问题，改声明没用，得先转存。这两条加起来，能覆盖掉 5.1 里说的绝大部分乱码场景。参数上没什么可调的，路径按自己的项目结构换一下就行，--include限定只搜 JSP，避免把编译产物也扫进来。

第四步是挨个检查「静默失败」的地方：useBean的class是不是全限定名、表单method是不是 post、forward后面有没有return、工具类有没有判空。这四项都不报错，出了问题最难查，所以必须主动看而不是等它报错。

回过头看，我当年那份报告最大的问题不是代码错，是「不知道自己为什么对」。第一次做的时候，我把pageEncoding抄了三遍，每次抄的值还不一样，居然也能跑，于是默认它不重要。直到答辩被问住，才回头把那一行指令的两个属性拆开看，才明白读和写是两件事。从那以后我每次碰 JSP 或者任何带编码声明的模板文件，都强制先跑一遍上面那两条命令，确认三处编码对齐了再往下写。这个习惯后来帮我省掉的排查时间，远比当时花的那五分钟多。希望帮到你。

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