U8SDK——U8Server订单号压缩

最近因为有客户游戏是网游， 但是游戏类型是捕鱼和棋牌，在一些渠道平台审核的时候， 会被强制作为单机类型， 同时需要接入对方的单机SDK。 这两天，在接百度单机SDK的时候， 其中有一个地方有点坑。 使用u8sdk的同学应该知道， U8SDK调用渠道支付接口之前会去U8Server下单， 下单之后U8Server生成一个long类型的订单号(19位)，然后这个订单号会放到渠道支付接口的回传参数中， 在渠道平台支付回调通知U8Server的时候， U8Server再用这里的回传参数(u8自己的订单号)去数据库中查找下单时生成的订单。

但是百度单机这里，要求这个回传参数最大长度是11位，那么就和U8Server生成的19位long类型的订单号有冲突了。这里有两种方案， 一个是单独为百度这个渠道生成一个11位的订单号， 下单的时候传给客户端， 同时保存在订单表中的渠道订单号字段中。另一种方案是想办法将U8Server生成的19位订单号压缩成不超过11位，然后回调通知到U8Server的时候， 再反过来解析成19位订单号。

这里优先考虑第二种方案， 因为第二种方案，通过算法解决，处理起来简单， 少一步更新数据库的操作。 这里优先想到的就是进制转换。将19的纯数字订单号，转换为11位的字符。在测试了几种进制转换之后， 发现达到62进制之后， 生成的字符串不会超过11位。

所以， 这里算法就简单了， 下单的时候， 将u8server生成的订单号进行62进制转换(这里为了以防万一，我们采用70进制， 让生成的字符串更短)， 然后支付回调到u8server的时候， 再将70进制的字符串转换为10进制的long类型的订单号。算法代码如下：

技术大大在做这个时， 还发生了一个小插曲， 之前encode方法里面， 他除法是这么写的：

然后encode和decode始终对不起来，每次都是最后几位不同。 后来想到可能是精度或者写法问题。 其实很简单，这里直接除即可：

对于long类型来说， 同样的ten值， 这两种计算出来的结果是不同的， 上面那种计算出来的结果有误差。