无论从安全性还是前后端数据处理的便捷性来说,使用POST请求会是绝大多数程序猿的首选。
不过有时候中途投入某些项目的时候,你会发现整个项目的前后端结构已经固化。
程序猿在时间不充裕的情况下只能去适应项目的现有风格。
使用GET请求直接传递关键参数至服务端是比较不安全的做法,考虑到这个WEB项目是内网工程,倒也无可厚非。
因此问题出现了,GET请求直接携带中文,后台接受时会出现乱码。
处理中文参数乱码的第一个步骤是在前端界面对参数进行encodeURI编码。
实验表明需要编两次,具体原因似乎是编码类型。
第二次编码的数据无论你原来是什么编码类型,都会变成UTF-8。
//请求url拼接
var url = "www.mebugs.com/getUser.go?id="+id+"&name="+encodeURI(encodeURI(name));
题外话:假设页面端输入的中文是一个“中”,按照下面步骤进行解:
第一次encodeURI,按照utf-8方式获取字节数组变成[-28,-72-83],对字节码数组进行遍历,把每个字节转化成对应的16进制数,这样就变成了[E4,B8,AD],最后变成[%E4,%B8,%AD],此时已经没有了多字节字符,全部是单字节字符。
第二次encodeURI,进行编码会把%看成一个转义字符,并不编码%以后字符,会把%编码成%25.把数组最后变成[%25E4,%25B8,%25AD]然后就把处理后的数据[%25E4,%25B8,%25AD]发往服务器端。
应用服务器调用getParameter方法,getParameter方法会去向应用服务器请求参数。
应用服务器最初获得的就是发送来的[%25E4,%25B8,%25AD],应用服务器会对这个数据进行URLdecode操作进行解码,不管是按照UTF-8,还是GBK,还是ISO-8859,都能得到[%E4,%B8,%AD],因为都会把%25解析成%,并把这个值返回给getParameter方法。
再用UTF-8解码一次,就得到"中"了。
如果不编码两次,当服务器自动解码的时候,假如是按照ISO-8859去解码UTF-8编码的东西,就是会出现乱码。
服务端使用URLDecoder.decode对get请求携带的参数进行解码。
String name = "";
try{
name = URLDecoder.decode(request.getParameter("name")!=null?request.getParameter("name"):"","UTF-8");
} catch (UnsupportedEncodingException e)
{
//追加捕获异常的后续处理逻辑
}
非常不建议在GET请求中传递重要的参数,特别是中文类的参数。
我们在编码过程中必然会遇到GET请求的地方,建议用于传递ID类的主键参数。
当前还没有观点发布,欢迎您留下足迹!
Spring就像一个大家族,里面包含了很多衍生产品,其中最为出名的就是SpringMVC和SpringBoot,那么这三者之间是什么关系呢?SpringMVC和SpringBoot又专门用来做什么呢?
在JAVA的WEB工程中我们可以将JSP页面文件放在WEB-INFO中限制用户进行URL直接访问,但静态资源如js、css文件却是需要被外部直接访问的,直接对外暴露又不太安全,可以通过自定义过滤器处理
SpringMVC框架是围绕DispatcherServlet(前端控制器)展开的,本文描述SpringMVC的优点、各个核心类(角色)作用,并说明用户请求数据到最终视图返回完整的数据传输过程
SpringBoot 的 MyBatis 默认采用 hikari 连接池,druid (德鲁伊) 连接池由阿里开源,它不仅仅是一个连接池,更是代理、过滤器、解析器、插件、监控、优化等实用功能组件库,更在阿里生产环境得到验证,所以 Lets Do It
Struts2框架以WebWork优秀的设计思想为核心,吸收了 Struts框架的部分优点,提供了一个更加整洁的MVC设计模式实现的Web应用程序框架,本文主要是与Spring整合关键配置和实例
scope属性主要用于控制依赖范围,主要分为编译、打包、运行、测试、依赖传递等各个常见,scope不同于optional提供了更多可选择的配置参数用于应对不同的依赖场景。