二维码问题上的一些思考

微信扫码调研

调研微信的扫码功能发现如今微信对于自家的二维码有几种扫码模式。

一种是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，那都是按需操做的事情了。

以上就是关于二维码问题的思考，若是有对这个问题有更好的想法的能够提出来你们碰撞下。