likes
comments
collection
share

二维码问题上的一些思考

作者站长头像
站长
· 阅读数 3

微信扫码调研

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

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

以上就是关于二维码问题的思考，如果有对这个问题有更好的想法的可以提出来大家碰撞下。