On 9/5/19 16:58, Schimweg, Luca wrote:
> unique-id-format 
> %[rand,hex,bytes(8,8),lower]-%[rand(65536),hex,bytes(12,4),lower]-4%[rand(4096),hex,bytes(13,3),lower]-%[rand(16384),add(32768),hex,bytes(12,4),lower]-%[rand(65536),hex,bytes(12,4),lower]%[rand,hex,bytes(8,8),lower]

This is going to be very nit-picky (I apologize): that comes close but
isn't actually guaranteed to produce an RFC 4122 version 4 UUID (the
"random" UUID).

You're right about the 4 at the beginning of the third group of hex
digits. But the first digit of the fourth group is required to be one of
8, 9, a or b. I've never understood why, but there it is.

Whether or not that matters, it seems to me, depends on requirements. If
you just need 16 bytes of randomness for a request ID, why not just
generate that? base64 encoding would be shorter, by the way -- 25 chars
for base64 with padding, 36 for the UUID format.

But if someone has an interoperability requirement dictating a UUID that
has to meet the standard format, then I agree that a fetch that gets it
just right would be warranted.

** * * UPLEX - Nils Goroll Systemoptimierung

Scheffelstraße 32
22301 Hamburg

Tel +49 40 2880 5731
Mob +49 176 636 90917
Fax +49 40 42949753


Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to