Hey, actually, I am doing that, I generate a random number from 0-16383 and after that I add 32768 onto it. 32768 is 0x8000, 32768+16383=49151 is 0xBFFF. I cannot really come up with a reason why this is too, but the specification is fulfilled.
And yeah, we could definitely generate any other format to, but UUIDs are a standardized format, so I cannot imagine why it is that hard using it, because there are probably many people that want to use it. Best regards Luca On 05.09.19, 17:38, "Geoff Simmons" <ge...@uplex.de> wrote: 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