記錄常見的問題：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的文件。而且對於已經安裝了應用的用戶來說，用戶體驗也不好。

使用這種技術的同時，考慮到其不確定性，應該做好備選方案。充分考慮到該頁面的用戶羣體是否主要爲新用戶，以及訪問的瀏覽器分佈，從而制定相應的對用戶來說比較友好的引導和備選方案。