|
|
1
13
我使用ascii85编码将guid以20个ascii字符写入数据库列。我已经发布了C代码,以防它有用。对于URL编码,特定的字符集可能不同,但您可以选择适合您的应用程序的字符。这里有: What is the most efficient way to encode an arbitrary GUID into readable ASCII (33-127)? |
|
|
2
8
当然,只要用一个大于64的碱基。您将不得不使用自定义字母表对它们进行编码,但您应该能够找到更多“URL安全”的可打印ASCII字符。 base64使用8对6位进行编码,因此16字节的guid值变为22字节编码。你可以减少一个或两个字符,但不会更多。 |
|
|
3
2
我不确定这是否可行,但是您可以将所有生成的guid放在一个表中,在URL中只使用表中guid的索引。 您还可以缩短guid的长度-例如,使用2个字节指示自2010年以来的天数,使用4个字节表示自当前日期开始以来的毫秒数。在同一毫秒内生成的两个guid只有冲突。您还可以再添加2个随机字节,这样做会更好。 |
|
|
4
1
你可以从另一个方向接近它。生成尽可能短的字符串表示形式并将其映射到一个guid中。 使用定义的字母表生成键,如下所示: 在伪代码中:
如果保持字符串长度<16,则只需十六进制编码结果并将其传递给guid构造函数进行分析。 |
|
|
5
1
不是针对完全相同的问题,而是非常接近的问题——我使用了CRC64,base64,得到了11个字节,CRC64已经过测试(还没有被证明)以在广泛的字符串上不产生重复。 而且,根据定义,它是64位长的,所以您得到的密钥是大小的一半。 要直接回答原始问题,您可以使用CRC64对您的guid的任何表示进行编码。 或者只需在业务密钥上运行crc64,您就可以拥有一个64位的惟一对象,然后您就可以将它作为base64。 |
|
|
6
1
我觉得这个讨论很有趣: https://www.percona.com/blog/2014/12/19/store-uuid-optimized-way/ 基本上,将36个字符转换成16个字节的二进制,但首先使用存储过程对三个时间段进行排序:
|
|
|
7
1
(很长一段时间了,但今天又有了同样的需求) UUID是128位长,由32个十六进制加4个连字符表示。 如果我们使用64(2^6)个可打印ASCII的字典,那么只需将32组4位(十六进制长度)转换为22组6位。 这是一个UUID短促。相反,36个字符得到22个字符,而不会丢失原始位。 https://gist.github.com/tomlobato/e932818fa7eb989e645f2e64645cf7a5
|