作者: 分类: U8SDK 发布时间: 2017-11-28 11:41 6U8SDK——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值, 这两种计算出来的结果是不同的, 上面那种计算出来的结果有误差。

本文出自 优优网事,转载时请注明出处及相应链接。

本文永久链接: http://www./?p=2187

评论功能已经关闭,请加入U8SDK技术群进行讨论和咨询:207609068
Ɣ回顶部
U8SDK技术群 x
带你装逼带你飞
点击加入