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的状况有多是由于他找到了初期化的那个函数并不是你期待的那个

好比，以下

虽然的url是/mst_users/#/

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

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

 

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

 

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

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

 

果真此次进到了咱们期待的函数了且 %23也自动解码成#了

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

他们的主要的区别就是各个函数的编码和不编码的范围不同须要的本身查一下吧

继续说当遇到[.]

这个也比较有意思 若是你传入的相似 1.2 、a.b 这样的那么 后天接收到的多是这样的

1.2  → 1

a.b →  a

 

即便用了转码函数也没用由于刚刚说的那个两个函数都不会都【.】进行转码的

找到了两个解决方法

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

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

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

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

看一下①的效果吧

 

 

 

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

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

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

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

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

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

若是你是任性期待能够接收任意输入的 也不是绝对不行

好比 本身定义 把【.】【/】对应的转换特定的字符而后到后台在转换出来

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

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

因此必要的check仍是少不了的 仅是私觉得 若是有什么好的也请告知，学习

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

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

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

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

这些都是很我的的想法，若是有更好的请不吝分享