生成人类可读/可用的，简短但唯一的ID

Question 1

每天需要处理> 1000个但<10000个新记录
无法使用GUID / UUID，自动递增编号等。
理想情况下，长度应为5或6个字符，当然可以为alpha
希望重用现有的知名算法（如果有）

那里有东西吗？

Question 2

tinyurl和bit.ly将Base 62用作缩写URL。这是一种易于理解的方法，用于创建“唯一的”人类可读的ID。当然，您将必须存储创建的ID，并在创建时检查重复项以确保唯一性。（请参见答案底部的代码）

基于62个唯一性指标

以62为基数的5个字符将为您提供62 ^ 5个唯一ID = 916,132,832（〜10亿）如果每天使用1万个ID，您可以使用91k +天

以62为基数的6个字符将为您提供62 ^ 6个唯一ID = 56,800,235,584（56+十亿）每天以1万个ID可以运行5+百万天

基于36个唯一性指标

6个字符将为您提供36 ^ 6个唯一ID = 2,176,782,336（2+十亿）

7个字符将为您提供36 ^ 7个唯一ID = 78,364,164,096（78+十亿）

码：

public void TestRandomIdGenerator()
{
    // create five IDs of six, base 62 characters
    for (int i=0; i<5; i++) Console.WriteLine(RandomIdGenerator.GetBase62(6));

    // create five IDs of eight base 36 characters
    for (int i=0; i<5; i++) Console.WriteLine(RandomIdGenerator.GetBase36(8));
}

public static class RandomIdGenerator 
{
    private static char[] _base62chars = 
        "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz"
        .ToCharArray();

    private static Random _random = new Random();

    public static string GetBase62(int length) 
    {
        var sb = new StringBuilder(length);

        for (int i=0; i<length; i++) 
            sb.Append(_base62chars[_random.Next(62)]);

        return sb.ToString();
    }       

    public static string GetBase36(int length) 
    {
        var sb = new StringBuilder(length);

        for (int i=0; i<length; i++) 
            sb.Append(_base62chars[_random.Next(36)]);

        return sb.ToString();
    }
}

输出：

z5公斤
wd4SUp
美国
UPrGAT
UIf2IS

QCF9GNM5
0UV3TFSS
3MG91VKP
7NTRF10T
AJK3AJU7

Question 3

我建议http://hashids.org/将任何数字（例如DB ID）转换为字符串（使用salt）。

它允许将此字符串解码回数字。因此，您无需将其存储在数据库中。

具有针对JavaScript，Ruby，Python，Java，Scala，PHP，Perl，Swift，Clojure，Objective-C，C，C ++ 11，Go，Erlang，Lua，Elixir，ColdFusion，Groovy，Kotlin，Nim，VBA， CoffeeScript以及Node.js和.NET。

Question 4

我有与OP类似的要求。我研究了可用的库，但其中大多数是基于随机性的，我不希望如此。我真的找不到任何不是基于随机的但仍然很短的东西...因此，我最终基于Flickr使用的技术进行了自己的滚动，但是对其进行了修改，以减少协调并允许更长的离线时间。

简而言之：

中央服务器发布每个包含32个ID的ID块
本地ID生成器维护一组ID块，以在每次请求ID时生成一个ID。当池电量不足时，它将从服务器获取更多ID块以再次填充它。

缺点：

需要中央协调
ID或多或少是可预测的（比常规DB ID少，但它们不是随机的）

好处

保持在53位以内（JavaScript / PHP的最大大小为整数）
身份证很短
Base 36编码使人类非常容易阅读，书写和发音
可能需要很长时间在本地生成ID，然后才能再次与服务器联系（取决于池设置）
理论上没有碰撞的机会

我已经发布了用于客户端的Javascript库以及Java EE服务器实现。用其他语言实现服务器也应该很容易。

以下是项目：

suid-简短而甜美的分布式服务唯一ID

suid-server-java -Java EE技术堆栈的Suid-server实现。

这两个库都可以通过自由知识共享开放源代码许可证获得。希望这可以帮助其他人寻找简短的唯一ID。

Question 5

当我为几年前开发的应用程序解决此问题时，我使用了base 36。我需要生成一个人类可读且合理的唯一数字（无论如何在当前日历年之内）。我选择使用从当年1月1日午夜开始的毫秒数（因此，每年的时间戳都可以重复），并将其转换为基数36。如果正在开发的系统遇到致命问题，它将生成基本的36个数字（7个字符），该数字通过Web界面显示给最终用户，然后可以将遇到的问题（和数字）转发给技术支持人员（然后可以使用它在日志中找到堆栈跟踪开始的位置。像56af42g7这样的数字与2016-01-21T15：34：29.933-08：00之类的时间戳或5f0d3e0c-da96-11e5-b5d2-0a1d41d68578之类的随机UUID相比，用户阅读和中继更容易。

Question 6

我真的很喜欢仅使用Base64格式编码GUID并截断尾随==以获得22个字符的字符串的简便性（它需要一行代码，并且您始终可以将其转换回GUID）。可悲的是，它有时包含+和/字符。对于数据库来说还可以，对于URL来说不是很好，但是它帮助我理解了其他答案:-)

摘自Christiaan van Bergen的https://www.codeproject.com/Tips/1236704/Reducing-the-string-Length-of-a-Guid

我们发现，使用Base64将Guid（16个字节）转换为ASCII表示形式时，会产生仅22个字符的可用且仍然唯一的messageID。

var newGuid = Guid.NewGuid();
var messageID = Convert.ToBase64String(newGuid.ToByteArray());

var message22chars = Convert.ToBase64String(Guid.NewGuid().ToByteArray()).Substring(0,22);

例如：Guid'e6248889-2a12-405a-b06d-9695b82c0a9c'（字符串长度：36）将获得Base64表示形式：“ iYgk5hIqWkCwbZaVuCwKnA ==”（字符串长度：24）

Base64表示形式以'=='字符结尾。您可以截断它们，而不会影响唯一性。只剩下22个字符的标识符。