Spring 当 @PathVariable 遇上 【. # /】等特殊字符

@PathVariable注解应该不是新鲜东西了Spring3.0就开始有了

URL中通过加占位符把参数传向后台

举个栗子,如下比较要说的内容比较简单就大概齐的写一下

画面侧

$.ajax({
type : "GET",
url : /test/code1,
dataType : "html",
success : function(data, status, xhr) {
//TODO
},
error : function(XMLHttpRequest, status, errorThrown) {
//TODO
}
});

这里的code1 就是你要传入的参数了

Contoller侧

@RequestMapping(value = "/test/{code}", method = RequestMethod.GET)
public String getTestName(@PathVariable String code) {
//TODO
}

[{code}]在URL中的占位符,用@PathVariable注解来做映射
※这里有一个注意点就是 url 中的 code 参数名 要和 @PathVariable 注解的这个 code 参数名要一致
背景算是说完了,现在就可以拿着用了
接下来说遭遇的问题 先说[#]
如果你入力的内容中包含#号那么就是悲剧了
要么404 要么找的不对然后画面崩溃

如果你没报出404的情况有可能是因为他找到了初期化的那个函数并非你期待的那个

比如,如下

Spring 当 @PathVariable 遇上 【. # /】等特殊字符

虽然的url是/mst_users/#/

但它找的是/mst_users后面的#号被无视了

Spring 当 @PathVariable 遇上 【. # /】等特殊字符

我们期待的是下面的这个函数

@RequestMapping(value = "/mst_users/{userId}", method = RequestMethod.GET)
@ResponseBody
public String getSkuName(@PathVariable("userId") String userId,HttpServletRequest request) {

这时候的解决方案就是转码
先找到了escape()函数还有如下
【该特性已经从 Web 标准中删除,虽然一些浏览器目前仍然支持它,但也许会在未来的某个时间停止支持,请尽量不要使用该特性。
废弃的 escape() 方法生成新的由十六进制转义序列替换的字符串. 使用 encodeURI 或 encodeURIComponent 代替.】
虽然不推荐但可以先试试

Spring 当 @PathVariable 遇上 【. # /】等特殊字符

现在已经明显看到 # 被编译成 %23 ok继续走

Spring 当 @PathVariable 遇上 【. # /】等特殊字符

果然这次进到了我们期待的函数了且 %23也自动解码成#了

ps encodeURIComponent函数也试过了没问题这里就不贴代码了

他们的主要的区别就是各个函数的编码和不编码的范围不一样需要的自己查一下吧

继续说当遇到[.]

这个也比较有意思 如果你传入的类似 1.2 、a.b 这样的那么 后天接收到的可能是这样的

1.2  → 1

a.b →  a

Spring 当 @PathVariable 遇上 【. # /】等特殊字符

Spring 当 @PathVariable 遇上 【. # /】等特殊字符

即使用了转码函数也没用因为刚刚说的那个两个函数都不会都【.】进行转码的

找到了两个解决方法

①在URL得占位参数后面加上【:.+】

  比如  /mst_users/{userId} → /mst_users/{userId:.+}

②在原本的后面加【.{ext}】当然你的函数列表里也得追加 【@PathVariable("ext") String ext】

  就是把【.】前后分成了两个参数来接收

看一下①的效果吧

Spring 当 @PathVariable 遇上 【. # /】等特殊字符

Spring 当 @PathVariable 遇上 【. # /】等特殊字符

②就不贴图了 说一下问题吧

①和②都有的问题 就是 如果只输入 【.】的话都会报错还是找不到对的函数

这是比较郁闷的就是说即使用了这些解决办法还是不能接受任意的输入

可能还是要配合相应的check来使用吧...

ps:【/】同【.】就不赘述了...

------------------------------------------------------------------------------------------------

如果你是任性期待可以接收任意输入的 也不是绝对不行

比如 自己定义 把【.】【/】对应的转换特定的字符然后到后台在转换出来

但是呢 这样吧 一是不够哦优雅或者直接可以说成笨拙 二就是有个bug

既然你已经任性的可以输入任意了那么别人的输入就是你的特定字符这就尴尬

所以必要的check还是少不了的 仅是私以为 如果有什么好的也请告知,学习

------------------------------------------------------------------------------------------------

最后的比较靠谱的解决方案

一就是上面写的两个解决方法 + 对应的check

二就是这种URL里传值的方式就被放弃之间 换成传统的json 传输吧

这些都是很个人的想法,如果有更好的请不吝分享

上一篇:混沌数学之CircuitChaotic(二维离散电路混沌系统)


下一篇:【神经网络篇】--基于数据集cifa10的经典模型实例