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. Best, Geoff -- ** * * UPLEX - Nils Goroll Systemoptimierung Scheffelstraße 32 22301 Hamburg Tel +49 40 2880 5731 Mob +49 176 636 90917 Fax +49 40 42949753 http://uplex.de
signature.asc
Description: OpenPGP digital signature
