手机没网了，却还能支付，这是什么原理？

这个过程商家后台系统是需要调用的支付宝条码支付的接口，完成支付。

「由于商家后台需要在线联网与支付宝后台通讯，所以说付款码的离线支付，指的是客户端没有的网络的情况，商家端其实必须实时联网在线。」

一次付款码接口调用流程如图所示：

]

来自支付宝官网

通过上面两张图，我们整体了解付款码交互流程。

付款码的技术方案其实可以分为客户端在线与离线的两种情况，下面我们来看下两种方案具体实现方式。

三、在线码方案

客户端在线码的方案，这个应该比较容易想到，只要支付宝/微信在登录的情况下，点击付款按钮，客户端调用后台系统的申请付款码接口。

后台系统受到请求之后，生成一个付款码，然后在数据库保存付款码与用户的关系，并且返回给客户端。

只要客户端在有效期内展示该付款码，就可以完成支付，否则该二维码就将会过期。

使用这种方案，相对来说比较安全，因为每次都是服务端生成码，服务端可以控制幂等，没有客户端伪造的风险的。

另外即使需要对付款码规则调整，比如付款码位数增加一位，我们只要调整服务端代码即可，客户端都无需升级。

「不过这种方案缺点也比较明显，客户端必须实时在线联网，没有网络则无法获取付款码。」

另外，现在有一些智能设备也开始支持支付宝支付，这些设备中很大一部分是没有联网的功能（比如小米手环四），那这种情况是没办法使用在线码方案。

基于这种情况，所以开始有了离线码方案。

离线码方案

说起离线码大家可能比较陌生，但是实际上你如果仔细观察，其实很多场景都用到了离线码。

比如说以前去黑网吧玩梦幻西游的时候，账号总是被盗。

没办法，花了一笔重资买了一个网易将军令，每次登录的时候，除了输入用户名与密码以外，还需要输入动态口令。从此账号就很少被盗了。

又比如说每次网易支付的时候，我们除了输入银行卡密码以外，还需要输入网银盾上动态码，这样才能完成支付。

❝画外音：

这里又要吐槽一下，网银盾以前真的超难用，动不动就驱动不兼容。还记得当初用网银充值黄钻，搞了一下午都没有成功–！❞

当然上面这些可能已经是_老古董_了，很多人都可能没用过，现在比较流行是**「手机验证器APP」**，比如 「Google Authenticator」 等。

这种令牌器，动态产生一次性口令（「OTP, One-time Password」），可以防止密码被盗用引发的安全风险。

其实付款码离线方案技术原型就是基于这种方案，所以下面我们就基于 Google Authenticator，来了解一下这其中的原理。

1.动态口令技术原理

首先如果我们需要使用 「Google Authenticator」，我们需要在网站上开启二次验证功能，以

Google 账号为例，在设置两步验证的地方可以找到如下设置：

当我们点击设置，将会弹出一个二维码，然后使用 「Google Authenticator」 APP 扫码绑定。

当我们绑定之后， 「Google Authenticator」 APP 将会展示动态码。

我们来解析一下这个二维码，对应下面这个字符串：

otpauth://totp/Google%3Ayourname@gmail.com?secret=xxxx&issuer=Google

上面的字符串中，最重要就是这一串密钥 secret，这个是一个经过 「BASE32」 编码之后的字符串，真正使用时需要将其使用**「BASE32」** 解码，处理伪码如下：

original_secret = xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx

secret = BASE32_DECODE(TO_UPPERCASE(REMOVE_SPACES(original_secret)))

「这个密钥客户端与服务端将会同时保存一份，两端将会同样的算法计算，以此用来比较动态码的正确性。」

我们以客户端为例，生成一个动态码，首先我们需要经过一个签名函数，这里 **Google Authenticator **采用的 「HMAC-SHA1」，这是一种基于哈希的消息验证码，可以用比较安全的单向哈希函数（如 SHA1）来产生签名。

签名函数伪码如下：

hmac = SHA1(secret + SHA1(secret + input))

上面函数中的，input 使用当前时间整除 30 的值。

input = CURRENT_UNIX_TIME() / 30

这里时间就充当一个动态变参，这样可以源源不断产生动态码。

「另外这里整除 30，是为了赋予验证码一个 30 秒的有效期。」

这样对于用户输入来讲，可以有充足时间准备输入这个动态码，另外一点客户端与服务端可能存在时间偏差，30 秒的间隔可以很大概率的屏蔽这种差异。

画外音：这个有效时间其实很考量，如果比较长，安全性就差。

如果比较短，用户体验就很差，不容易输入准备。

经过 「HMAC-SHA1」 签名函数以后，我们得到一个长度为 40 的字符串，我们还需要将其转化为 6 位数字，方便用户输入。处理的伪码如下：

four_bytes = hmac[LAST_BYTE(hmac):LAST_BYTE(hmac) + 4]

large_integer = INT(four_bytes)

small_integer = large_integer % 1,000,000

完整的算法伪码如下：

original_secret = xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx

secret = BASE32_DECODE(TO_UPPERCASE(REMOVE_SPACES(original_secret)))

input = CURRENT_UNIX_TIME() / 30

hmac = SHA1(secret + SHA1(secret + input))

four_bytes = hmac[LAST_BYTE(hmac):LAST_BYTE(hmac) + 4]

large_integer = INT(four_bytes)

small_integer = large_integer % 1,000,000

当客户端将动态码上传给服务端，服务端查询数据库获取到用户对应的密钥，然后使用同样的算法进行处理生成一个动态码，最后比较客户端上传动态码与服务端生成是否一致。

2.付款码离线方案

上面我们了解了动态口令的实现方案，付款码生成原理其实也大致如此。

不过付款码离线方案采用动态密钥的方式(「全局唯一」)，定时请求服务端更换密钥，以此保证更高的安全性。

另外在一次性动态口令方案，需要双方基于同样的秘钥，所以服务端需要明确知道这**「背后正确用户」**。以上面的登录场景为例，登录过程输入用户名,服务端就可以根据这个在数据库中查询相应的密钥。

但是在付款码的支付场景中，支付过程仅仅传递一个付款码，就可以向相应的用户扣款。不用想，这个付款码这串数字一定包含相应的用户信息。

所以付款码的相应的算法相比动态码会更加复杂，这样才可以有效保证安全性。

看到这里，不知道你们是否急切想了解这套算法那？

哈哈，开个玩笑，这种算法岂能是我们能掌握的。

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数初中级Android工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则近万的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Android移动开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Android开发知识点，真正体系化！

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！

如果你觉得这些内容对你有帮助，可以扫码获取！！（备注：Android）

资源分享

• 最新大厂面试专题

这个题库内容是比较多的，除了一些流行的热门技术面试题，如Kotlin，数据库，Java虚拟机面试题，数组，Framework ，混合跨平台开发，等

• 对应导图的Android高级工程师进阶系统学习视频
  最近热门的，NDK，热修复，MVVM，源码等一系列系统学习视频都有！

《Android学习笔记总结+移动架构视频+大厂面试真题+项目实战源码》，点击传送门即可获取！

分享

• 最新大厂面试专题

这个题库内容是比较多的，除了一些流行的热门技术面试题，如Kotlin，数据库，Java虚拟机面试题，数组，Framework ，混合跨平台开发，等

[外链图片转存中…(img-etZZrf5D-1712420458608)]

• 对应导图的Android高级工程师进阶系统学习视频
  最近热门的，NDK，热修复，MVVM，源码等一系列系统学习视频都有！

[外链图片转存中…(img-fgzywwUT-1712420458608)]

《Android学习笔记总结+移动架构视频+大厂面试真题+项目实战源码》，点击传送门即可获取！