一、适用场景
无法使用从数据库中返回的自增长数字,给上传图片重命名。
这是图片或文件上传的流程决定的。一般图片上传处理过程是,先上传图片到服务器,重命名之后,插入到数据库。
也就是说,在数据库中非常容易获得的自增长id,无法用于给上传的图片重命名,来避免文件名称的重复,而采用从数据库中获取最大id加1的方式,增加了数据库连接的次数,不适用于高并发和数据量巨大的情况。
二、常规方案
1、guid:32 字符十六进制数
格式:GUID 的格式为“xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx”,其中每个 x 是 0-9 或 a-f 范围内的一个32位十六进制数。例如:6F9619FF-8B86-D011-B42D-00C04FC964FF 即为有效的 GUID 值。
优点:几乎不会重复;
缺点:对于给上传的图片重命名,还是过长了。
用法:
2、MD5
与guid一样会输出32字符十六进制数,区别是guid是随机产生的,md5需要根据输入的数据生成。
例子:
输出:
8b1a9953c4611296a827abf8c47804d7
优点:可以根据输入的种子数据来控制输出的数值,如果种子数据是规律性不重复的,通过md5可以对数据进行保护,产生很大的混淆作用;
缺点:32位字符过长;需提供不重复的种子数据;
用法:高并发,以秒为种子数据,仍然会出现重复现象。
3、uniqid():返回13或23位字符串
对于我们目的来说,uniqid()像是md5()的改进版,尤其是我们可以采用差异性标识作为字符串前缀,可以降低重复命名出现的几率。
对于非高并发等极端情况,推荐使用此函数,已经可以满足一般性需求。
详细说明:
定义:uniqid() 函数基于以微秒计的当前时间,生成一个唯一的 ID;
用法:uniqid(prefix,more_entropy);
说明:prefix可以为输出的字符串添加前缀,示例如下,more_entropy参数为true时,将输出23位字符串。
输出结果为:
string(13) "51734aa562254" string(14) "a51734aa562257"
优点:13位字符串长度,是可以接受的文件命名长度;可以添加前缀,结果包含数据混淆,能够避免反推原始数据;
缺点:同md5相似,高并发,以秒为种子数据,仍然会出现重复现象。
三、升级版方案
1、fast_uuid:返回17位数字
有点像uniqid()的不完全定制版,这个函数里面出现的“种子数开始时间”概念很有启发性。
time()和uniqid()中默认用到的时间都是从1970年开始计算的,长度有十位(1366512439),采用“种子数开始时间”能够缩小这个数值,因为我们实际上需要的,仅仅是一个能够自动增长的数值即可。
起始时间自定义以后,除了减少长度,还能够起到混淆的作用。
输出:
29832412631099013
2、time()+随机数
上例中已经出现了随机数的使用,是为了解决一秒下发生的多次请求。
提供两个函数:
四、最终方案
思路:userid+秒+随机数。其中“userid+秒”10进制转64进制,缩减位数。
说明:
1、userid: 64进制最大值“ZZZZ”转换为十进制等于”16777215“,”ZZZ“转换为十进制最大值等于”262143“;
2、秒:设置自己的时间起点。
$less=time()-strtotime(’2012-4-21′) 转换为64进制”1SpRe“,5位
$less=time()-strtotime(’2013-3-21′) 转换为64进制”_jHY“,4位
3、随机数:使用random(3)生成3位随机数。
最终结果:4位userid+4位秒+3位随机数=11位字符串。虽然与uniqid()结果看上去相似,但是强壮度有所提高。