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
