CODEWITHSUNDEEP
encodingbase64standardsuuid
Michael G.
Michael G.

Reputation: 163

Is there a standard or alternative for shorter UUIDs?

The UUID standard has several versions. Version 4 for example is based on a completely random input. But it still encodes the version information and only uses 125bits of the possible 128 bits.

But for transferring these via HTTP, it is more efficient to encode them in BASE64. There are libraries for this (https://github.com/skorokithakis/shortuuid).

But what I am wondering: Is there an alternative standard for shorter ID-strings? Of course I could slap together a version-byte + n random bytes and encode them BASE64, having my own working 'short, random ID scheme', but I wonder if there is any alternative that someone already specified before I make my own.

Upvotes: 10

Views: 9992

Answers (3)

Tony
Tony

Reputation: 359

A quick and dirty alternative is mktemp, depending on your requirements for security, uniqueness and your access to a shell.

Use the form mktemp -u XXXXXXXX

  • -u: dry-run, don't create a file
  • XXXXXXXX is the format, in this case eight random characters
$ echo `mktemp -u XXXXXXXX`
KbbHRWYv
$ echo `mktemp -u XXXXXXXX`
UnyO2eH8
$ echo `mktemp -u XXXXXXXX`
g6NiTfvT

Upvotes: 3

Michael G.
Michael G.

Reputation: 163

I have just found https://github.com/ai/nanoid

It it not really a 'standard', but at least not an arbitrary scheme that I would come up with myself. It is shorter through smarter encoding (larger alphabet) and faster.

Upvotes: 4

StephenS
StephenS

Reputation: 2136

There is no standard for anything shorter.

Numerous folks have asked the same question and all come to the same conclusion: UUIDs are overkill for their specific requirements. And they developed their own alternatives, which essentially boil down to a random string of some length (based on the expected size of their dataset) in a more efficient encoding like base64. Many of them have published libraries for working with these strings. However, all of them suffer from the same two problems:

  1. They cannot handle arbitrarily large datasets (the reason UUIDs are so big)
  2. They are not standardized, which means there is no real interop.

If neither of these problems affect you, then feel free to pick any of the various schemes available or roll your own. But do consider the future costs if you discover you're wrong about your requirements and whether the cost of having to change justifies whatever minuscule advantage in space or complexity you get by not using a proven, universal system from the start.

Upvotes: 16

Related Questions