Java Web 2023 题型和复习提纲（二）6、简述servlet进行中文处理的方法。 Servlet 处理中文主要

6、简述servlet进行中文处理的方法。

Servlet 处理中文主要涉及到两个方面：中文数据的接收和发送。在接收时，需要确保正确解析 HTTP 请求中的中文参数；在发送时，要保证响应的内容可以被客户端准确地解码。

Servlet 中文处理常用的一些方法如下：

接收中文数据

GET 请求：在 GET 请求中，参数通常是通过 URL 传递的。由于 Servlet API 会使用容器的默认字符集来解码 URL（和参数），这可能会导致中文乱码。如果使用的容器是 Tomcat，可以通过修改 server.xml 文件中的 <Connector> 标签，设置 URIEncoding="UTF-8" (或其他适合的字符集)，来保证使用 UTF-8 来解码 URL 和 Query String。
POST 请求：对于 POST 请求，可以使用 request.setCharacterEncoding("UTF-8") 方法来告诉 Servlet 以 UTF-8 字符集来解析请求体中的参数。但这必须在请求参数被读取之前调用。

java
复制代码
request.setCharacterEncoding("UTF-8");
String value = request.getParameter("param"); // "param" 是你要接收的参数名

发送中文数据

设置响应字符集：在发送中文数据时，应设置响应头的字符集为 UTF-8（或其他适当的字符集），以确保客户端能正确解码。

java
复制代码
response.setContentType("text/html; charset=UTF-8");
// 或者分开设置
response.setCharacterEncoding("UTF-8");
response.setContentType("text/html");

PrintWriter 使用：在发送响应时，可能会通过 PrintWriter 发送数据。此处应确保 PrintWriter 使用正确的字符编码。设置了正确的 response.setCharacterEncoding("UTF-8") 后，使用 response.getWriter() 获取的 PrintWriter 会自动采用这一编码。

java
复制代码
PrintWriter out = response.getWriter();
out.println("中文数据"); // 发送的中文不会乱码

示例代码

java
复制代码
protected void doPost(HttpServletRequest request, HttpServletResponse response)
        throws ServletException, IOException {
    // 处理接收数据的字符集
    request.setCharacterEncoding("UTF-8");

    // 处理发送数据的字符集
    response.setContentType("text/html; charset=UTF-8");

    // 处理业务逻辑
    String chineseContent = request.getParameter("chinese");
    PrintWriter writer = response.getWriter();
    writer.println("接收到的中文内容是：" + chineseContent);
    writer.close();
}

使用这种方式，可以确保 Servlet 处理中文时不出现乱码问题。但也需要确保前端页面发送请求时，对中文内容进行了适当的编码（通常是用 encodeURIComponent 函数对 URL 中的参数编码），并且 HTML 页面的编码设置也是 UTF-8（或者与你所设置的编码相同）。

7、include的两种实现方式的区别?

在 Java Servlet 编程中，include 操作是将一个资源的内容插入到另一个资源的响应内容中，实现资源的复用。这个功能可以通过两种方式实现：RequestDispatcher 的 include 方法和 JSP 的 <jsp:include> 动作。这两种方式的基本目标是相同的，但执行细节和适用场合有所不同。

1. `RequestDispatcher` 的 `include` 方法

这是一个 Servlet API 中的功能，允许从一个 Servlet 在服务器端包含另一个资源（例如另一个 Servlet、JSP 页面或 HTML 文件）的内容。这种包含是透明的，即包含的资源的输出被直接插入到调用 include 方法的地方。

java
复制代码
RequestDispatcher dispatcher = request.getRequestDispatcher("includedServlet");
dispatcher.include(request, response);

特点：

请求和响应对象（request 和 response）在包含资源的执行过程中被共享，这使得可以在不同的资源之间共享请求参数和属性。
因为响应是直接写入到输出流中的，所以被 include 的资源不应该设置响应头或调用任何可能影响响应的方法（比如设置 Content-Length）。
调用 include 方法不会改变原始请求的 URL。

2. JSP 的 `<jsp:include>` 动作

这是 JSP 页面中的标准动作，它也可以将另一个资源的输出包含到当前 JSP 页面中。与 RequestDispatcher 的 include 方法不同，<jsp:include> 可以在执行时动态地执行另一个页面，并将该页面的结果输出到当前页。

jsp
复制代码
<jsp:include page="includedPage.jsp" />

或者使用属性传递参数：

jsp
复制代码
<jsp:include page="includedPage.jsp">
    <jsp:param name="paramName" value="paramValue" />
</jsp:include>

特点：

这种包含是在运行时动态完成的，使得每次包含操作时都可以获取最新内容，适合动态页面的包含。
<jsp:include> 标签可以传递参数，并且它也共享相同的 request 对象，但可以指定局部参数。
它更适用于 JSP 页面间的包含，而不是 Servlet 间。

区别总结

执行方式：RequestDispatcher.include 是在服务器内部完成的; <jsp:include> 会导致另一个页面被执行，然后将执行结果包含进来。
动态 vs 静态：<jsp:include> 更适合包含页面内容动态变化的情况；RequestDispatcher.include 则适合内容相对静态，不需要重新执行的包含。
适用范围：RequestDispatcher 可用于 Servlet 和 JSP 两者之间的包含；<jsp:include> 主要用在 JSP 页面中。
效率：直接使用 RequestDispatcher 的方式通常效率更高，因为它不需要额外的页面调用过程。

8、cookie和session区别?

Cookie 和 Session 都是 Web 开发中用于保持用户状态的技术。它们有各自的机制和用途，以下是它们的主要区别：

存储位置

Cookie：存储在客户端的浏览器上。每次客户端发起请求到服务器时，Cookie 会被自动附加到请求头中发送到服务器。
Session：存储在服务器端。服务器为每个用户会话创建一个唯一的 Session 对象，并且会发给客户端一个唯一的标识符（通常是名为 JSESSIONID 的 Cookie），用于在后续请求中识别这个 Session。

生命周期

Cookie：可以设置长时间保留（例如，一个月、一年或更久），直到到达设定的过期时间，或者被用户手动清除。
Session：通常依赖于单个浏览器会话的生命周期。当用户关闭浏览器或者服务器端程序指定 Session 过期时，Session 会结束。但 Session 的实际过期时间可以被服务器配置。

安全性

Cookie：由于存储在客户端，可能会被用户禁用或者篡改，安全性较低。敏感信息不应以明文保存在 Cookie 中。
Session：由于存储在服务器端，相比 Cookie 更安全，难以被外部访问，适合存储敏感信息。

性能影响

Cookie：每次 HTTP 请求都会发送到服务器，因此如果 Cookie 过多或体积过大，会增加请求的负担，影响性能。
Session：存储在服务器内存中，可以优化为存储在文件、数据库或缓存中。过多的 Session 可能会占用较多的服务器资源。

适用场景

Cookie：适用于存储客户端的个性化设置，如界面风格、语言选择等，或是进行用户追踪（如广告追踪）。
Session：适用于存在用户登录状态、保存用户购物车信息等重要状态信息的场景。

可扩展性

Cookie：因为是存储在客户端，不依赖服务器资源，所以可扩展性较好。
Session：存于服务器，如果涉及到集群配置，需要考虑 Session 的共享问题，可能需要使用 Session 一致性保持机制，如 Session 副本、数据库存储或持久化 Session。

数据容量限制

Cookie：每个域名下存储的 Cookie 数量和大小都有限制，不同浏览器有不同的限制，但一般大小限制为4KB左右。
Session：理论上没有大小限制，但过多的数据会影响性能和服务器资源。

综上所述，Cookie 和 Session 各有利弊，在实际的 Web 开发中，通常会组合使用它们来实现更加完整和安全的用户状态管理。

9、MVC模式的特点。

MVC（Model-View-Controller）模式是一种软件设计典范，用于组织代码以实现业务逻辑、用户界面和输入控制之间的分离。MVC 模式的核心理念是将软件分成三个基本组件，每个组件有各自的职责。下面是 MVC 模式的主要特点：

分离关注点（Separation of Concerns）

MVC 模式将一个应用程序分为三个核心组件：

Model（模型） ：代表应用程序的数据结构，通常负责在数据库和类对象之间转换数据（如 ORM 技术）。
View（视图） ：负责展示数据（用户界面），并将用户指令传送到控制器。
Controller（控制器） ：解释用户输入，通过调用模型的方法来处理数据，并选择视图来显示。

通过这样的分离，应用程序的内部业务逻辑可以独立于用户界面，也就是说，同一个模型可以使用不同的视图来展示，而控制器则协调模型和视图。

易于维护和扩展

由于不同组件独立分工，各自关注不同的逻辑，因此在修改和扩展应用程序时不太可能影响到其他组件。这就降低了维护成本，并且使得应用程序更加易于扩展。

复用性

在 MVC 模型中，特别是模型组件，通常不和特定的输出表示或输入处理逻辑直接关联，因此模型可以在不同的系统中复用。

多视图支持

由于视图和模型是解耦的，可以为同一个模型创建多个视图。举个例子，一份数据可以以 HTML、PDF或 Excel格式呈现给不同的用户。

开发角色划分

MVC 允许不同的开发人员专注于他们擅长的领域：后端开发人员可以专注于模型和控制器的编写，而前端开发人员则可以专注于视图的开发。

测试的便利

MVC 模式中组件的分离，使得单元测试和功能测试变得更容易。特别是对模型逻辑进行测试，因为它不依赖视图层或控制器层。

适应多种架构风格

MVC 不仅应用于传统的桌面应用程序，也广泛应用于 Web 应用程序和移动应用程序。这种模式容易适配不同的技术和架构风格，比如 RESTful 应用程序、单页应用（SPA）或传统的动态网站。

潜在的缺点

尽管 MVC 模式有许多优点，但它也有一些潜在的缺点。例如，如果控制器过于臃肿，可能会违反单一职责原则，这会导致代码难以维护。此外，对于一些非常简单的应用程序来说，使用 MVC 可能会过于复杂，造成不必要的工程。

总的来说，MVC 模式强调了关注点分离，使得应用程序的组织更加清晰、结构更加鲜明，这有助于开发大型应用程序和团队协作开发。然而，选择适合的架构模式应该基于应用程序的具体需求来确定。

10、MVC可以用哪些技术实现？

在提交表单请求时，HTTP 协议定义了几种不同的方法来处理数据，其中最常用的是 GET 和 POST。以下是这两种方法的主要区别：

1. 数据传输方式

GET：参数通过 URL 编码后附加在 URL 后面进行发送，用户可以在浏览器的地址栏中看到提交的参数。
POST：参数放置在 HTTP 请求的消息体（Body）中，用户无法在浏览器地址栏中见到，这样更为隐蔽。

2. 数据大小限制

GET：由于数据是附在 URL 后，因此受 URL 长度限制，不同的浏览器和服务器限制不同，但通常有长度限制（例如 Internet Explorer 限制在 2048 个字符）。
POST：理论上没有大小限制，可以传输大量数据，受限于服务器配置的最大请求体大小。

3. 安全性

GET：由于提交的数据在 URL 中完全暴露，容易被截取和篡改，不适合传递敏感信息。
POST：相对于 GET 来说更安全一些，因为数据不会出现在 URL 中，但真正的安全性还需要通过 HTTPS 加密等方式来实现。

4. 缓存和历史记录

GET：请求可以被浏览器缓存，参数也会保存在浏览器历史记录中，用户可以进行书签收藏。
POST：由于数据在请求体中，一般不会被缓存，也不会保存在浏览器历史记录中，不能被收藏为书签。

5. 数据类型

GET：只允许 ASCII 字符。
POST：可以发送二进制数据，例如文件上传等操作。

6. 适用场景

GET：适用于查询字符串、请求显示某个资源或者无副作用的搜索操作。
POST：适合需要服务器进行数据处理的操作，如表单提交、文件上传、通过请求来改变服务器上的状态等。

7. 请求副作用

GET：设计为无副作用和幂等的，意味着多次执行同一个 GET 请求，资源的状态和副作用是不变的。
POST：设计为有副作用的操作，每次请求都可能在服务器上引起状态改变，例如提交订单。

8. 请求回放

GET：如果用户尝试刷新页面，浏览器通常会无需警告地重新发起 GET 请求。
POST：刷新页面时，浏览器通常会警告用户数据会被重新提交。

在实际的 Web 开发实践中，应根据数据处理的具体需求选择使用 GET 还是 POST 方法。对于发送大量数据或包含敏感信息的情形，或者是对服务器数据或状态产生变化的场景，推荐使用 POST 方法。而对于简单的数据检索，可以使用 GET 方法。

Java Web 2023 题型和复习提纲（二）