共计 4340 个字符，预计需要花费 11 分钟才能阅读完成。
当初生存曾经离不开微信 / 支付宝电子领取，平时进来吃饭、购物只有带个手机，就能够解决所有，以致于当初曾经好久没摸过真💰了。
有一次进来吃饭，排着队付钱，等着过程十分无聊，筹备插入手机来把荒野乱斗，却发现这个中央居然连不上网。
看着手机明明信号满格，然而就是显示网络无连贯，苹果手机用户痛，谁用谁晓得。
画外音: 真的要 Diss 一下应用英特尔基带的 Iphone，📶好差，没事网络就会闪断~
说回正题，因为没有网络，而我又没带钱，所以就怕付钱的时候因为手机没网，没方法应用支付宝扣款。正想着时，曾经排到了我，不管三七二十一，先用下支付宝试试，切实不行爷不吃了。
不过没想到，当商家用扫码抢扫描支付宝上付款码领取当前，尽管我的手机最终没有弹出领取胜利的页面，然而商家端显示领取胜利，并胜利打印出了小票，过了一会，我的手机收到支付宝扣款短信。
因为我最近的工作对都是与微信 / 支付宝无关，整体领取流程还是比较清楚，然而付款码为什么能离线领取的确不是很分明，所以钻研了一番，于是有了明天的文章。
科普领取形式
在聊付款码离线原理之前，咱们先给不相熟支付宝 / 微信领取形式同学先科普一下常见的两种领取形式。
微信、支付宝线下领取罕用领取形式有两种，一种是咱们关上手机，被动扫描商家提供码牌，这种领取形式个别称为主扫领取（用户被动扫码）。
以支付宝为例，付款流程如图所示：
第二种则是咱们关上手机，展现咱们的付款码，而后商家应用扫码枪等工具获取付款码实现领取，这种领取形式个别称为被扫领取（用户被扫码）。
以支付宝为例，付款流程如图所示：
对于第一种形式，须要手机端 APP 扫码，而后弹窗确认付款，这种形式是没有方法在手机没有网络的状况实现领取，所以咱们上文说的没有网络的状况特指付款码领取的场景。
付款码付款流程
在聊付款码离线领取的前提前，咱们先来来看下付款码的整体流程，以超市购物为例，一次付款码的领取信息流如图所示：
这个过程商家后盾零碎是须要调用的支付宝条码领取的接口，实现领取。
因为商家后盾须要在线联网与支付宝后盾通信，所以说付款码的离线领取，指的是客户端没有的网络的状况，商家端其实必须实时联网在线。
一次付款码接口调用流程如图所示：
通过下面两张图，咱们整体理解付款码交互流程。
付款码的技术计划其实能够分为客户端在线与离线的两种状况，上面咱们来看下两种计划具体实现形式。
在线码计划
客户端在线码的计划，这个应该比拟容易想到，只有支付宝 / 微信在登录的状况下，点击付款按钮，客户端调用后盾零碎的申请付款码接口。
后盾零碎受到申请之后，生成一个付款码，而后在数据库保留付款码与用户的关系，并且返回给客户端。
只有客户端在有效期内展现该付款码，就能够实现领取，否则该二维码就将会过期。
应用这种计划，相对来说比拟平安，因为每次都是服务端生成码，服务端能够管制幂等，没有客户端伪造的危险的。
另外即便须要对付款码规定调整，比方付款码位数减少一位，咱们只有调整服务端代码即可，客户端都无需降级。
不过这种计划毛病也比拟显著，客户端必须实时在线联网，没有网络则无奈获取付款码。
另外，当初有一些智能设施也开始反对支付宝领取，这些设施中很大一部分是没有联网的性能（比方小米手环四），那这种状况是没方法应用在线码计划。
基于这种状况，所以开始有了离线码计划。
离线码计划
说起离线码大家可能比拟生疏，然而实际上你如果仔细观察，其实很多场景都用到了离线码。
比如说以前去黑网吧玩梦幻西游的时候，账号总是被盗。
没方法，花了一笔重资买了一个网易将军令，每次登录的时候，除了输出用户名与明码以外，还须要输出动静口令。从此账号就很少被盗了。
又比如说每次网易领取的时候，咱们除了输出银行卡明码以外，还须要输出网银盾上动静码，这样能力实现领取。
画外音：
这里又要吐槽一下，网银盾以前真的超难用，动不动就驱动不兼容。还记得当初用网银充值黄钻，搞了一下午都没有胜利 –！
当然下面这些可能曾经是 老古董 了，很多人都可能没用过，当初比拟风行是 手机验证器 APP，比方 Google Authenticator 等。
这种令牌器，动静产生一次性口令（OTP, One-time Password），能够避免明码被盗用引发的平安危险。
其实付款码离线计划技术原型就是基于这种计划，所以上面咱们就基于 Google Authenticator，来理解一下这其中的原理。
动静口令技术原理
首先如果咱们须要应用 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当客户端将动静码上传给服务端，服务端查询数据库获取到用户对应的密钥，而后应用同样的算法进行解决生成一个动静码，最初比拟客户端上传动静码与服务端生成是否统一。
付款码离线计划
下面咱们理解了动静口令的实现计划，付款码生成原理其实也大抵如此。
不过付款码离线计划采纳动静密钥的形式 ( 全局惟一)，定时申请服务端更换密钥，以此保障更高的安全性。
另外在一次性动静口令计划，须要单方基于同样的秘钥，所以服务端须要明确晓得这 背地正确用户。以下面的登录场景为例，登录过程输出用户名, 服务端就能够依据这个在数据库中查问相应的密钥。
然而在付款码的领取场景中，领取过程仅仅传递一个付款码，就能够向相应的用户扣款。不必想，这个付款码这串数字肯定蕴含相应的用户信息。
所以付款码的相应的算法相比动静码会更加简单，这样才能够无效保障安全性。
看到这里，不晓得你们是否想理解这套算法那？
哈哈，开个玩笑，这种算法岂能是咱们能把握的。
支付宝外围算法咱不晓得，然而咱们能够从其他人公开设计方案理解一个皮毛。
这里二哥给你一个知乎网友 @反方向的钟答复的离线二维码实现形式，给你 look look。
付款码离线码的劣势
最初咱们来看下付款码离线计划的劣势：
第一，算法调整不灵便，如果相干算法较大的调整，可能须要降级客户端, 并且这个期间服务端还须要兼容新老算法产生的付款码。
第二，安全性问题，失常的状况相干密钥无奈被普通用户获取，然而架不住有有心之人。他们可能通过获取手机用户 Root 权限或者越狱手机，利用恶意程序获取密钥，而后随便生成付款码。
看到这一点，大家可能会放心本人的钱包平安了。不过这一点，我感觉不过过分放心，蚂蚁团体这么多大神，不是吃干饭的，他们必定有很多措施保障领取平安。
第三数据碰撞问题，A 用户生成付款码算进去与 B 用户统一，这就 Hash 算法一样，再怎么优良的算法，也有概率才生一样的额 Hash 值。
这就导致本来是扣用户 A 的钱，最初却扣了 B 用户。这样一来，的确很乌龙，对于 B 用户来讲，莫名其妙被扣钱了。
不过释怀，这种事放到当初，我感觉还是比买彩票中奖低，所以这种事还是不必过分放心了。
即便真被误扣了，释怀，支付宝这么大体量必定会跟客户赔钱的。
最初
最初总结一下，咱们平时应用付款码领取，其实原理就是商家端获取咱们手机 APP 付款码（其实就是一串数字），而后后盾调用支付宝领取接口实现扣款。
这个流程商家端后台程序必须联网在线，然而对于咱们客户端来讲能够在线，也能够离线。
如果咱们客户端在线，那就能够通过服务端向客户端发送付款码，这种形式更加平安，灵便，然而对于弱网环境下，体验就很差。
如果咱们客户端没网，那就通过客户端通过肯定算法生成付款码，服务端收到通过相干校验，确认是哪个用户，确认码有效性，并且实现扣款。这种形式，适宜客户端没有网络的状况，不过绝对不灵便，且安全性稍差。
嘿嘿，理解原理，有没有感觉还是挺有意思的~
下次排队付款钱, 如果手机没网，不要放心难堪，释怀拿出手机付钱~
