UUID validator

The shape can be checked completely: thirty-two hexadecimal digits in groups of eight, four, four, four and twelve, with the version in one nibble and the variant in the top bits of another. All of that is decidable from the string alone, and it is what "valid UUID" means.

What cannot be checked is whether it was generated properly. A version 4 UUID made from `Math.random` has the correct shape, the correct version nibble and the correct variant bits — it is weak, and nothing about the string says so. Validation is a syntax check, and no syntax check can see entropy.

The thirteenth hexadecimal digit — the first of the third group — is the version. A 4 there means the identifier is random. A 1 or a 6 means it embeds a timestamp and a node identifier, so it discloses roughly when and on what it was made. A 3 or a 5 means it is a hash of a name in a namespace, and therefore reproducible from that name.

A 7 is the newer time-ordered version, increasingly used for database keys because it inserts sequentially. Anything else is either a UUID from a scheme predating the versioning rules or, far more often, a random hexadecimal string that somebody formatted to look like a UUID.

The top bits of the seventeenth digit say which UUID layout the rest follows. Effectively everything generated today is the RFC 4122 variant, where those bits are `10`. The others are historical: the Apollo NCS layout, Microsoft original GUID layout with its different byte order, and a reserved range.

It is worth reading when an identifier is being rejected by a strict parser that a lenient one accepted. A value with historical variant bits is well formed and is not what a modern library expects, and that mismatch is invisible unless something tells you which variant you are holding.

Thirty-two zeros is a valid UUID with a defined meaning: no value. It appears where a nullable column could not be null, where a default was never replaced, and where a client sent a placeholder it meant to fill in.

It is reported separately here because it is the one value that passes every check and is almost always a bug in context. A row whose identifier is the nil UUID is a row nothing generated an identifier for.

Windows tooling — the registry, COM, PowerShell `New-Guid` — writes UUIDs wrapped in braces. RFC 4122 defines a URN form with a `urn:uuid:` prefix. Both are ordinary ways to encounter one, and a validator that rejected either would be refusing the thing it exists to inspect on a formatting technicality.

What is not accepted is the form with the dashes removed. That is common in URLs and in some databases, and it is genuinely ambiguous: thirty-two hexadecimal digits could be a UUID, or an MD5, or half a SHA-256. Reporting it as a UUID would be a guess dressed up as a verdict.