The valid characters are defined in KugaFC 7230 and 福睿斯FC 3九八陆

前言

参照:https://blog.csdn.net/qq\_28165595/article/details/79686681

普普通通费用中平时碰到有个别不叁不四的小难点,举个例子将在上线的花色在线上特别报错,但是在该地确能够常常运作。往往这猝比不上防的小惊奇,真是让大家猿猿欲哭无泪啊。这里大约总计一下在IE浏览器上高出的一个小坑,在此以前就因为那个小坑,着实慌了一把。

非常音信:

 信息: Error parsing HTTP request header
 Note: further occurrences of HTTP header parsing errors will be logged at DEBUG level.
java.lang.IllegalArgumentException: Invalid character found in the request target. The valid characters are defined in RFC 7230 and RFC 3986
    at org.apache.coyote.http11.InternalAprInputBuffer.parseRequestLine(InternalAprInputBuffer.java:235)
    at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1028)
    at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:637)
    at org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.doRun(AprEndpoint.java:2549)
    at org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.run(AprEndpoint.java:2538)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
    at java.lang.Thread.run(Thread.java:748)

tomcat新本子分歧意U昂科拉L里富含普通话,须要先进行编码,再请求,请求进程中tomcat会举办解码。

坑的案由

率先瞅瞅那坑长啥样子。如下图所示 
图片 1

下面的图片中,大家鲜明看到那般①行Invalid character found in the request
target. The valid characters are defined in HummerH二FC 7230 and 帕杰罗FC
3⑨八陆,那句话的大概意思乃是请求头中包罗了 途睿欧FC 7230 and QX56FC
3玖八陆正规中定义的违规字符。在这种气象下就能促成页面报400那3个。 
接触下面报这种极其的代码片如下,只是1个回顾的get请求

图片 2

 

 

接下去大家来看看XC60FC 3986中到底是怎么标准的

索罗德FC3玖捌陆文书档案规定,Url中只同意包罗英文字母(a-zA-Z)、数字(0-九)、-_.~伍个特殊字符以及独具保留字符。福特ExplorerFC398陆文书档案对Url的编解码难题做出了详实的提出,提议了如何字符须要被编码才不会引起Url语义的扭转,以及对怎么那几个字符供给编码做出了相应的分解。

US-ASCII字符聚集未有对应的可打字与印刷字符:Url中只允许行使可打字与印刷字符。US-ASCII码中的拾-七F字节全都表示调控字符,这个字符都无法间接出现在Url中。同期,对于80-FF字节(ISO-885玖-一),由于已经超(英文名:jīng chāo)出了US-ACII定义的字节范围,由此也不可以献身Url中。

封存字符:Url能够划分成几何个零部件,协议、主机、路径等。有一对字符(:/?#[]@)是用作分隔分裂组件的。举个例子:冒号用于分隔协商谈主机,/用于分隔主机和路子,?用于分隔路线和询问参数,等等。还应该有部分字符(!$&’()*+,;=)用于在种种组件中起到分隔功用的,如=用于表示查询参数中的键值对,&符号用于分隔查询七个键值对。当组件中的普通数据包括这几个特殊字符时,须求对其进行编码。

KugaFC3玖八陆中钦点了以下字符为保留字符:! * ’ ( ) ; : @ & = + $ , / ? # [

不安全字符:还会有局地字符,当他们间接放在Url中的时候,恐怕会挑起分析程序的歧义。那几个字符被视为不安全字符,原因有为数非常多。 
空格:Url在传输的长河,可能用户在排版的长河,大概文本管理程序在拍卖Url的进程,都有异常的大可能率引进毫无干系主要的空格,或许将这么些有含义的空格给去掉。 
引号以及<>:引号和尖括号一般用于在平时文书中起到分隔Url的效率 
井号(#) 日常用于表示书签或然锚点 
%:百分号本身用作对不安全字符举行编码时行使的特殊字符,因而作者要求编码 
{}|\^[]`~:某部分网关或然传输代理会篡改那些字符

还要奥迪Q3FC 398六行业内部在tomcat七.0.7三版本中就曾经提出了,SportageFC
7230也是对前者的有个别补充只怕说是完善,所以在tomcat7.0.73及以上版本都会有这种难点。

伸手音信里面包车型地铁汉语乱码

tomcat解码默以为ISO885九-1格式,会并发乱码,须求修改配置文件conf/server.xml

<Connector port="8080" protocol="HTTP/1.1"
               connectionTimeout="20000"
               redirectPort="8443" />

修改为 UTF-8

<Connector port="8080" protocol="HTTP/1.1"
               connectionTimeout="20000"
               redirectPort="8443" URIEncoding="UTF-8"/>

也足以单个管理

param = new String (param.getBytes("iso8859-1"),"UTF-8")

什么样填坑

解决地点难题,有如下三种思路。

  • 换用低版本的tomcat,既然您是tomcat7.0.7三版本,及以上版本有这种主题素材,大家能够有的时候的躲避那个难题,选用低版本的tomcat。
  • 用post代替get请求,上边也说过了是get请求才会有这种情景,假若方便的话,大家一同能够行使post请求来促成那一个职能
  • 在前端对前者U帕杰罗L进行编码

    上面介绍一下前端对U景逸SUVL实行编码的完毕方式。 
    javascript能够动用的松手函数有

  • encodeURI()

  • encodeURIComponent() 
    他们都以用utf-八的编码方式,对于get请求,他的编码格式暗中同意是根据浏览器的编码格式实行编码的,我们能够安装浏览器的编码格式,不过每一种用户的浏览器的编码格式不容许都是一律的,那样我们的get请求的参数一时候就能够出现乱码难题,可是要是大家友还好前端对get请求利用encodeU中华VI()恐怕encodeU哈弗IComponent
    ()来归并设置成utf-八编码,这样大家在后台在用utf-捌来解码,就不会产出乱码问题。 
    这里须求注意的少数,对于get请求的华语乱码难点,若是您从未在tomcat配置文件中安装编码格式,天真的想用request.setCharacterEncoding(“UTF-8”)来在后端设置后端的解码格式,这种方式对于get请求是无用的。同临时候有个别小同伙大概会想大家得以在项指标web.xml中装置编码过滤器。抱歉这种办法对于get请求也是对事情未有什么帮助的。 
    对此这种情状我们得以应用new
    String(request.getParameter(“name”).getBytes(“iso-885九-一”),”UTF-捌”)
    来进行三回编码解码进程,这种方法就能够消除get请求汉语乱码难题,当然大家也能够在tomcat的配置文件中安装统一编码格式。
  • <Connector port=”8080″ protocol=”HTTP/1.1″
    maxThreads=”150″ connectionTimeout=”20000″ redirectPort=”8443″
    URIEncoding=”utf-8″/>
  • 。。。。。。好像有个别扯远了,回归正题,接下去大家来探视encodeU哈弗I和encodeULacrosseIComponent 
    encodeU奥德赛I(),用来encode整个UTucsonL,不会对下列字符进行编码:+
    : / ; ?&。它只会对汉语等特殊字符进行编码 
    encodeU奥迪Q5IComponent (),用来enode
    U牧马人L中想要传输的字符串,它会对全数url敏感字符进行encode 
    在对url做encode操作时,一定要凭借事态选拔不相同的艺术。 
    例如url = “testGetRequest/testSimpleGet?name=+’爱琴孩’” 
    那时能够用encodeU凯雷德I(url) 
    当您的参数中富含+ : / ; ?&请使用 encodeUQX56IComponent
    方法对那几个参数单独开始展览编码。 
    例如url =
    “testGetRequest/testSimpleGet?parm=www.baidu.com/ccc/ddd?name=abcd” 
    据此本人上面一起初境遇的难题只供给在前者编码一下就足以消除了

  • 图片 3

    本来你也能够换低版本的tomcat,这里是不提倡的!

    小结:笔者的私有化解办法

  • 前者jsp页面:这里kfname和kfname传的参数是汉字

  • 图片 4

    前端编码一回:

  • 图片 5

  • 后端解码一回(恐怕五次,我这边解码二回四回都足以);

  • 图片 6

     

  • 内需注意的一点,下边这种特别只是在IE上会出现,火狐,360,谷歌(Google)上是平素不的。 
    多留意点小细节。。。远隔猝比不上防的大悲大喜。

发表评论

电子邮件地址不会被公开。 必填项已用*标注

网站地图xml地图