简介
在web开发中不可避免的需要接触到JSP文件，而JSP文件的第一行基本都是
<%@ page language="java" import="java.util.*" pageEncoding="UTF-8"%>一：pageEncoding="UTF-8"
这个标识一般出现在JSP文件的第一行，如：
<%@ page language="java" import="java.util.*" pageEncoding="UTF-8"%>
<%
String basePath = new StringBuilder(request.getScheme()).append("://")
.append(request.getServerName()).append(":")
.append(request.getServerPort())
.append(request.getContextPath()).append("/")
.toString();
%>
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="renderer" content="webkit">
<meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1">
<meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1">
<meta name="apple-mobile-web-app-status-bar-style" content="black">
<meta name="apple-mobile-web-app-capable" content="yes">
<meta name="format-detection" content="telephone=no">
</head>
<body>
</body>
</html>JSP文件中的代码在调用的时候最终是要转换为servlet然后才能够响应客户端的请求，假如JSP文件中出现了中文字符，在当前开发工具中看起来是没有任何问题的，因为用于显示的编码支持中文，但是文件与文件之间相互转换的时候与显示无关，他们只会针对具体的编码进行二进制变换，假设pageEncoding="UTF-8"变为pageEncoding="ISO-8859-1"，utf-8编码格式的文件中中文“我”的编码为“11010111”（假设），但是ISO-8859-1的一个字符占用4个bit，然后“我”这个中文字符在ISO-8859-1中就变成了编码为“1101”和“0111”的两个字符，此时读取文件并显示的时候会按照文件的编码格式显示，此时“1101”和“0111”编码对应字符长什么样鬼知道，一般计算机在根据编码显示的时候对于不认识的编码会用固定的字符代替比如“？”等。
说了这么多，就是为了说明“pageEncoding="UTF-8”能够保证JSP更够根据指定编码正确转换为servlet。
二：contentType="text/html;charset=UTF-8"
首先明确：contentType="text/html;charset=UTF-8"的作用是指定对服务器响应进行重新编码的编码。
阅读上边的JSP文件内容会发现头部有这么一行
<meta charset="UTF-8">在浏览器的开发者工具中查看响应头部有这么一行
Content-Type: application/json;charset=UTF-8
三：response.setCharacterEncoding("UTF-8")
首先明确：response.setCharacterEncoding("UTF-8")的作用是指定对服务器响应进行重新编码的编码。
由“二”可知，JSP可以在head中指定响应内容的编码格式，但还有一种情况就是，我们不通过jsp返回内容，而是通过servlet直接返回响应数据，此时就可以用response.setCharacterEncoding("UTF-8")指定返回数据的编码格式。那么通过servlet返回数据时不指定编码格式服务器会使用什么编码？答：以前遇到过，具体忘了，暂时略过。
注意：有时候我们可能会对同一个页面采用多种方式设置响应的编码格式，此时服务器会根据设定的优先级来决定最终的编码格式，优先级如下：
response.setCharacterEncoding—contentType—pageEncoding四：request.setCharacterEncoding("UTF-8")
首先明确：request.setCharacterEncoding("UTF-8")的作用是设置对客户端请求进行重新编码的编码。
既然服务器可以决定响应数据的编码格式，那么客户端发送过来的编码格式又是什么呢？
题外话：这里又要理解一点，客户端发送过来的请求肯定有URL，不管携带的参数是什么，URL肯定会指定具体的服务器域名和应用，这些都是英文的，所以不用在意编码问题，到达服务器以后服务器会拦截请求并且响应对应的页面，就算客户端携带了各种奇葩参数，服务器完全可以当做不认识，只要客户端发过来了请求，不管你参数是什么服务器有权响应想要响应的内容，也就是说，只要你的请求到了服务器，服务器都会给你第一个页面。
明白了上述内容，接下来说我们关注的这个知识点。假设浏览器发送过来的请求携带了参数，服务器在解读的时候肯定需要知道对应的编码，而request.setCharacterEncoding("UTF-8")就是告诉服务器，解读这些数据所要使用的编码（举个栗子：我给你发了一段英文，你本来应该用英文去解读，可你偏偏用中文去解读，结果很明显，你看不懂，request.setCharacterEncoding("UTF-8")就相当于有一个人来告诉你，你一定要用英文去解读）。
虽然request.setCharacterEncoding("UTF-8")可以很方便的指定解读请求参数所用的编码，但是存在一个问题，我们如何知道客户端发送的数据所采用的编码？而且同一个应用如果用的编码一样，这样多次指定显然很费劲也很麻烦。同一个应用的实际交互逻辑为：当第一个页面数据响应给客户端时就已经指定了当前页面所采用的编码，客户端在请求同一个应用的另一个页面的时候就会根据这个编码来发送对应的参数。
还有一个问题：采用get方式请求在URL中携带的参数request.setCharacterEncoding("UTF-8")某些情况下不起作用，具体原因暂时不清楚，待后期补充。
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
