Variants and Versions:
A UUID has variants and versions.
The 4 in this case tells you, that it is the version 4. Other versions range from 1 to 5.
Those versions have variants 8, 9, A and B, therefore the z in your UUID tells you which variant it is.
The variant is used for telling which layout the UUID has. Variants are also important when it comes to backwards compatibility.
Lenght of the strings:
As to why the strings have different lengths, a UUID has a certain parts, that you can use to generate a UUID depending on various parameters:
UUID = time-low "-"
clock-seq-and-reserved | clock-seq-low "-"
time-low has 16 bits,
time-mid has 8 bits, ... The lengths were historically constructed so that they fit into the following scheme:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
| time_low |
| time_mid | time_hi_and_version |
|clk_seq_hi_res | clk_seq_low | node (0-1) |
| node (2-5) |
So this should give you an idea, why the lengths of the strings are different.
UUIDs and security:
Usually UUIDs are not secure: https://littlemaninmyhead.wordpress.com/2015/11/22/cautionary-note-uuids-should-generally-not-be-used-for-authentication-tokens/ ... and see Michael Kjörling's comment for further examples and explanations.
UUIDs were not built to be cryptohraphically secure, so you should use something else made especially for that purpose.
The RFC for UUIDs even has a section, about security, warning users to misuse UUIDs for that:
- Security Considerations
Do not assume that UUIDs are hard to guess; they should not be used
as security capabilities (identifiers whose mere possession grants
access), for example. A predictable random number source will
exacerbate the situation.
See the RFC for the technical details: https://www.rfc-editor.org/rfc/rfc4122