巧用 Base62 解决字段太短的问题

最近银联一纸 259 号改造通知，所有支付机构开始改造支付交易，上传终端信息。

不知道其他支付机构的小伙伴针对这次改造是否开始了？

由于这次银联给的时间非常少，我们这边改动涉及到相关上游一起改造，所以我们已经开始设计，马上投入代码改造中。

这次改造，支付机构内部需要维护交易发生的终端信息。在银联的改造文档中，支付机构内部需要为每一台终端分配一个唯一的终端设备号。

银联侧规定这个字段是 String(8)，可以使用英文字母以及数字，即 a-z/A-Z/0-9。

由于我们内部发号器，只能产生纯数字的序号，按照 8 位长度，从 0 开始最多只能有 99,999,999 。

当前看来没什么问题，但是千万级数字还是太小，一不小心就没了。为了后续系统的稳定性，所以我们需要设计一种满足银联的规则终端号生成方法。

发号器现状

先来介绍先，我们这边的发号器现状，应该跟很多公司做法都比较类似。

我们这边发号器，有两种生成策略：

simple
snowflake

第一种策略simple 类型，这种策略方式非常简单，类似 MySQL ID 自增策略，可以指定从某个数字开始递增。

这种方适用于表ID 等场景，只需要保证唯一，不需要保证顺序。

第二种策略 snowflake 类型，即使用雪花算法。

这种方式适用于订单ID 等需要保留时间信息的场景。

这两种发号器都存在一定的问题，没办法直接适用于银联终端号的场景。

simple 类型发号器问题

这个类型发号器只能发纯数字的序号，按照 8 位长度，从 0 开始最多只能有 99,999,999 。

由于发号器虽然是单调递增的，但是可能存在机房配置，存在跳号的情况，这就导致可能可以用的序号少于 99,999,999 。

所以不能拿来直接使用。

snowflake 类型发号器的问题

snowflake 类型发号器的发出来的序号是 64 bit，格式如下：

这里就不解释 snowflake 策略具体的原理，举一个 snowflake生成的序号：

170916032679263329

可以看到 snowflake 发号器生成这个 64 bit 整数非常大，位数也远远大于 8 位。

设备号生成方法

上面说到设备号生成规则是允许英文字母，即 a-z/A-Z/0-9。

如果我们仅仅使用数字，那么我们仅仅只有 10^8-1= 99,999,999。

那我们转换一种思路，我们把英文字母也用，那么我们总共可以有62^8-1=218,340,105,584,895

可以看到这个数字已经很大，未来很长一段时间都不可能超过（除非后续开展银地球外的服务）。

那怎么生成一个带有英文字母的序号呢？难道需要重写一个发号器吗？

其实我转换一下思路，设备号规则可以使用a-z/A-Z/0-9，设备号每一位都有 62 个选择，那站在数学的角度，这不就是 62 进制的吗？

那现在我们使用发号器生成的序号只能是整数，那站在数学角度，是一个十进制的数。

那我们只要把这个10 进制数转成 62 进制数，这不就可以解决问题了吗！

所以这里我们使用 simple 类型的发号器，从 0 开始递增。

拿到发号器生成的序号之后，我们只需要将其转为 62 进制就可以了。

10 进制转 62 二进制的代码示例如下：

public class TermInfoUtils {

    /**

     * https://en.wikipedia.org/wiki/Base62#/

     * wiki 上的标准

     */

    private final static char[] charArray = "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz".toCharArray();

    private static final int BASE_62_SCALE = 62;

    /**

     * base10 转 base 62

     *

     * @param base10

     * @return

     */

    public static String fromBase10ToBase62(long base10) {

        int scale = 62;

        StringBuilder sb = new StringBuilder();

        long remainder = 0;

        do {

            remainder = base10 % scale;

            sb.append(charArray[(int) remainder]);

            base10 = base10 / scale;

        }

        while (base10 > scale - 1);

        sb.append(charArray[(int) base10]);

        // 倒序

        return sb.reverse().toString();

    }

    /**

     * 产生银联终端号

     * @param base10

     * @return

     */

    public static String generateUnionDeviceId(long base10) {

        String base62 = fromBase10ToBase62(base10);

        // 往左补 0

       return StringUtils.leftPad(base62,8,"0");

    }

}

代码原理非常简单，类似 10 进制转二进制，除二取余，然后倒序排列，高位补零。转62进制也类似，不断除以62取余数，然后倒序。

最后，为了我们生成的序号长度统一，我们定一个规则，如果生成的 62 进制小于 8 位，那左边补 0 ，直到整个长度为 8 位。

## Base62 其他妙用

除了上面这个应用之外，其实现实也有很多应用也是使用 Base62 解决。

比如，我们现在常用的短网址服务，随便生成一个短网址。

https://tinyurl.com/y8jvg3eb

我们可以看到短网址最后都有一串字符串，那其实就是 Base62。

ps：有些短网址采用的是 Base64，即 a-z/A-Z/0-9/_- ,但是原理类似。

再比如，B 站现在使用的 BV 号，其实也是 Base62 的应用。

ps：按照网上说法，BV 号实际上是 Base58，去除用数字"0"，字母大写"O"，字母大写"I"，和字母小写"l"，以及"+"和"/"符号。

那实际上，上面这两种方式都是将 Base62 当做一个唯一 ID。这种方式有一个非常明显的优点，可以用一个只有几位长度字符串，容纳超多超多的 ID。

我们对比一下，通常使用纯数字形式 ID，即 Base10与 Base62 。

当 ID 长度为 4 位的时候，Base10 可以容纳的数字：

$$

10^4-1=9999

$$

而 Base62 可以容纳

$$

62^4-1=14776335

$$

而当 ID 长度到达 5 位的时候，Base10 可以容纳：

$$

10^5-1=99999

$$

而 Base 62 可以有：

$$

62^5-1=916132831

$$

通过对比我们可以发现，Base62 可以容纳数字远远超过 Base10，并且根本不是一个量级的。

另外假设 5 位长度 Base62 用完了，只要加上一位，又可以容纳 62 倍数字，几乎很难再用完。

说完优点，我们再来聊聊 Base62 的缺点，不容易记忆。

B 站以前还是 AV 号的时候，采用的是 Base10 ，这个非常容易记忆。

比如 B 站镇站之宝：av170001

以前我们可以通过弹幕直接发送 AV 号，感兴趣就可以直接输入跳转到那条视频。

但是现在 10 位 BV 号，几乎难以记忆，在弹幕中输入 BV 号都很困难。

哎，少了当初的快乐的。