最近银联一纸 259 号改造通知，所有支付机构开始改造支付交易，上传终端信息。
不知道其他支付机构的小伙伴针对这次改造是否开始了？
由于这次银联给的时间非常少，我们这边改动涉及到相关上游一起改造，所以我们已经开始设计，马上投入代码改造中。
这次改造，支付机构内部需要维护交易发生的终端信息。在银联的改造文档中，支付机构内部需要为每一台终端分配一个唯一的终端设备号。
银联侧规定这个字段是 String(8)，可以使用英文字母以及数字，即 a-z/A-Z/0-9。
由于我们内部发号器，只能产生纯数字的序号，按照 8 位长度，从 0 开始最多只能有 99,999,999 。
当前看来没什么问题，但是千万级数字还是太小，一不小心就没了。为了后续系统的稳定性，所以我们需要设计一种满足银联的规则终端号生成方法。
先来介绍先，我们这边的发号器现状，应该跟很多公司做法都比较类似。
我们这边发号器，有两种生成策略：
第一种策略simple 类型，这种策略方式非常简单，类似 MySQL ID 自增策略，可以指定从某个数字开始递增。
这种方适用于表ID 等场景，只需要保证唯一，不需要保证顺序。
第二种策略 snowflake 类型，即使用雪花算法。
这种方式适用于订单ID 等需要保留时间信息的场景。
这两种发号器都存在一定的问题，没办法直接适用于银联终端号的场景。
这个类型发号器只能发纯数字的序号，按照 8 位长度，从 0 开始最多只能有 99,999,999 。
由于发号器虽然是单调递增的，但是可能存在机房配置，存在跳号的情况，这就导致可能可以用的序号少于 99,999,999 。
所以不能拿来直接使用。
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 解决。
比如，我们现在常用的短网址服务，随便生成一个短网址。
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 号都很困难。
哎，少了当初的快乐的。