二維碼問題上的一些思考

微信掃碼調研

調研微信的掃碼功能發現如今微信對於自家的二維碼有幾種掃碼模式。

一種是http/https鏈接，這種鏈接的話微信會經過瀏覽器調用而後再作信息注入（有必要的話）。 如微信網頁二維碼登陸：

其二維碼對應的內容爲： https://login.weixin.qq.com/l/gbhwtYZltA==

另外一種是經過特殊協議，也能夠叫Scheme URL，如微信支付中，二維碼對應內容爲：

wxp://f2f0PGHjdQNdT3lenn6DVlwq_Sg0aDGIE_Ia

而對於第三方二維碼，微信的處理方式是斷定是否是一個網址，若是是網址就會跳轉瀏覽器，若是不是網址則直接將二維碼對應內容顯示出來。

延伸

對於登錄，仍是這個連接https://login.weixin.qq.com/l/gbhwtYZltA==，當你用瀏覽器打開時你會發現跳轉到一個顯示沒法識別的二維碼的頁面，而後點擊上面的如今升級，接下來神奇的事情發生了，它竟然直接轉向蘋果的AppStore，但是我這是個Android設備，UA都是Android。

看過一篇文章說微信二維碼功能設計的妙處，就是經過UA來斷定要進行下一步的操做，在微信聯繫人二維碼中，若是斷定到是微信客戶端則直接調起添加聯繫人，若是斷定到是Android設備就會跳轉微信下載apk的地址，那篇文章你們能夠去看看。

產品經理小技術（三）：二維碼這把利刃，產品應該用到極致 - 簡書

只是如今微信已經不支持這麼幹了，我直接使用MIUI瀏覽器掃聯繫人二維碼時只出現瞭如下這個畫面:

改進點思考

對於微信的二維碼，看似是退步了，畢竟以前識別UA的方式會更加完善各類使用場景，但也許微信是出於安全考慮去掉了這種方式。這裏不討論微信的問題，而討論下怎麼去完善二維碼的使用場景。

應對外部掃碼說明網頁

首先，經過UA智能判斷場景是一種方式，這種方式上面提到的文章中也已經闡述地很清楚了，這裏就不細說了。

另外一種方式是對UA智能判斷的拓展。

首先須要一個二維碼說明/app下載介紹的網頁，譬如這個網頁是：https://www.baidu.com/code （舉個例子，不要當真） 那麼用戶訪問這個網頁的時候，就會看到app的下載信息，這個時候用戶能夠點擊下載（UA就派上用場了，判斷UA是Android或iPhone來跳轉對應下載頁面）。

而後這就完了？

並無。

定義須要在二維碼攜帶的信息結構

須要在二維碼中定義一些只有自家APP來識別的信息，實現相似微信掃付款碼就自動調起支付功能。

對信息進行分組是第一步，先按信息類型，來分組不一樣的action。

用微信的場景分析，假定有三個場景以下：

場景value	場景說明
pay	支付的動做
contact	添加聯繫人的動做
login	掃碼登錄的動做

有對應的動做（action），那麼確定也會有這些動做須要攜帶的參數，以微信自身二維碼爲例，開頭提到的兩個二維碼攜帶的信息分別以下：

• 掃碼登錄：https://login.weixin.qq.com/l/gbhwtYZltA==
• 微信支付：wxp://f2f0PGHjdQNdT3lenn6DVlwq_Sg0aDGIE_Ia

注意我加了強調的部分，這部分很明顯是這個二維碼攜帶信息的相當重要的點，我把它理解爲uid。

因此一個二維碼不只要攜帶action來標識要客戶端掃碼後的相應的動做，還須要攜帶這個動做所須要的參數uid，固然上述場景的action只用到了uid，若是換成別的場景，好比跳轉一個小遊戲的網頁，那麼攜帶過來的參數就是一個url了。

固然參數不是固定的，能夠根據自身項目的參數結構進行適當調整，抽出一個通用跳轉動做的結構。

回到剛剛提到的結構，根據上述說明能夠把結構整理成json數據以下：

{
"action":"wxp",
"uid":"gbhwtYZltA==",
"url":null
}
複製代碼

將攜帶的信息整合進URL

前面應對外部掃碼說明網頁一節中提到的url：https://www.baidu.com/code ，這裏再次提出來，而後咱們須要將上述二維碼攜帶的信息結構整合進這個url，就獲得以下結果：

https://www.baidu.com/code?param={"action":"wxp","uid":"gbhwtYZltA==","url":null}

很明顯，這確定不能做爲url存在，有種方式是對param的內容作urlencode，客戶端解析後再對相應內容進行decode。

還有種方式，對param參數後面的內容進行base64處理，待處理的內容爲：

{"action":"wxp","uid":"gbhwtYZltA==","url":null}

base64處理後的內容爲： eyJhY3Rpb24iOiJ3eHAiLCJ1aWQiOiJnYmh3dFlabHRBPT0iLCJ1cmwiOm51bGx9

有了這串內容後，整合後的url結果就是這樣滴：

https://www.baidu.com/code?param=eyJhY3Rpb24iOiJ3eHAiLCJ1aWQiOiJnYmh3dFlabHRBPT0iLCJ1cmwiOm51bGx9

最後再用這個url生成個二維碼：

掃碼後的處理

掃碼後處理分兩種形式：

1. 自有客戶端掃碼
2. 第三方app掃碼

自有客戶端掃碼

由於規則是本身定的，因此在客戶端裏面掃碼，只須要按照規則解析，拿到最終二維碼想要給客戶端的信息作進一步操做就能夠了。

對於自產二維碼步驟大體以下：

1. 客戶端掃碼，解析二維碼
2. 判斷到url是客戶端專有二維碼連接（具體可利用正則，甚至簡單粗暴字符串匹配，但規則最好由服務端下發，保證可更新性），解析對應param參數的值
3. base64 decode param參數
4. 解析param參數的json字符串，組裝結構，根據action和參數作進一步操做

但既然客戶端作了掃碼功能，說不定用戶就會拿起客戶端直接用這個功能掃別家的二維碼，這個時候也許是一個網址，也許是一個特殊協議的url，這個時候能夠根據自身需求作網頁跳轉處理或者不處理。

第三方app掃碼

針對這種狀況，一個有效的能夠訪問的網址就排上用場了，以上述例子網址爲例，第三方app掃碼後只要是發現是http或https協議的，通常都會跳轉到內置/外置瀏覽器打開，那麼只要保證https://www.baidu.com/code這個地址能訪問就ok了，至於這個網址你是放個「此二維碼不受外部應用支持」，仍是放個app下載介紹，仍是根據UA直接重定向到下載apk地址/appStore，那都是按需操做的事情了。

以上就是關於二維碼問題的思考，若是有對這個問題有更好的想法的能夠提出來你們碰撞下。