记录常见的问题：encodeURICompnent 解码过程中出现空格 以及 第三方app中使用schema 唤起app

• window.location.href 跳转的时候使用了encodeURIComponent编码了部分参数，但是在第三方app中出现了编码过后的参数换行和空格的情况(部分第三方应用或者java程序）

  代码如下

  const domain = this.app.isProd()?"https://xfkh.foundersc.com/":'https://kaihu-dev-cstest.fzzqxf.com/'
  
  window.location.href = domain + "api/result/resultDesc?token=" + encodeURIComponent(this.app.getToken());
  

    **解决方案**
  
    在`encodeURIComponent(this.app.getToken())`外面再包一层`encodeURIComponent`
  
    全部代码如下：
  

const domain = this.app.isProd()?"https://xfkh.foundersc.com/":'https://kaihu-dev-cstest.fzzqxf.com/'
window.location.href = domain + "api/result/resultDesc?token=" + encodeURIComponent(encodeURIComponent(this.app.getToken()));

	** 原理查看**

		1.猜测是跳转过程中	`token` 内部含有`+`号，在报文传递的时候`+`号会自动变成空格，所以再次使用`encodeURIComponent`进行二次编码，将`+`号转换成`%20F`这样的十六进制编码的unicode字符，这样报文在后端拿到的时候就不会出现`空格`

		2.但是我很好奇，为什么第一次转码的时候还能有`+`号剩余，明明我第一次就用了`encodeURIComponent`这个步骤，为何还会出现`+`号,而且为什么+号在服务端拿到的时候就变成了`空格`,两个编码/解码方式不一样吗 `#todo`

		3.使用`encodeURICompnent`的原因，由于在url请求过程中为了防止`参数中携带一些歧义字符，比如传参的?号或者并列符号&甚至是等号`或者是为了避免在`url访问过程中非ascill编码字符在请求过程中的转码编码差异`所以在传输特殊字符或者非`asscill`编码字符的时候需要使用`encodeURIComponent`这个方法将参数编码，但是一般发生在`get`中比较多，因为`get`请求的参数是直接携带在`url`上面表示，而使用`post`请求参数可以以`报文`的形式进行传递，就可以避免这个问题

		4.至于服务端或者第三方应用为什么会把`+`转义成`空格`：服务端在拿到`url`参数的时候也会进行`decode`这个过程中`+`号会被decode成`空格`???还是有点强行解释

• 第三方浏览器无法用schema唤起app以及schema到底是个啥

  在移动端浏览器中通过schema协议唤起app，schema就是一个类似http的页面跳转协议，andriod和ios都支持该协议，但支持该协议需要浏览器进行一定的规则设置，部分第三方浏览器没有实现或者限制了这个schema的跳转能力

  schema协议和http协议的规则类似，是一种页面之间的跳转协议，不仅适用于app之间跳转也适用于h5跳转app

  这种通过 scheme 打开本地应用的方式并不是所有浏览器都支持，尤其是在微信浏览器中是不支持使用 scheme 打开应用的，除非微信官方添加了白名单。QQ浏览器中倒是支持。

而且一些浏览器会询问用户是否打开，而另外一些则直接打开应用。

一般的做法是，判断当前浏览器是否为微信，如果是微信的话，则弹出一个遮罩层，提示用户使用其他浏览器打开。

还有就是在微信浏览器中使用应用宝的微下载，将当前页面重定向到应用宝的下载页面，不过这种方式的转化率很低。

有一个好消息是，在IOS9.0以上的系统中，可以使用 universal links 打开本地应用，不过Android不支持。

另外一个备选方案是，在微信浏览器中，使用iframe的方式打开一个包体地址(.apk结尾的url)进行下载时，会拉起一个选择框，让你选择打开的应用。不过这种方式对于某些域名无效，对于一些特殊的下载文件无效，如不能下载.rar的文件。而且对于已经安装了应用的用户来说，用户体验也不好。

使用这种技术的同时，考虑到其不确定性，应该做好备选方案。充分考虑到该页面的用户群体是否主要为新用户，以及访问的浏览器分布，从而制定相应的对用户来说比较友好的引导和备选方案。