Validar UUID

Un UUID son 128 bits, escritos habitualmente como 32 dígitos hexadecimales en cinco grupos separados por guiones. De una cadena así se pueden comprobar tres cosas: si la forma es correcta, qué versión declara el decimotercer carácter y qué variante indican los primeros bits del cuarto grupo.

Lo que no se puede comprobar es si el identificador se ha asignado alguna vez. No hay registro ni dígito de control — un UUID no lleva información sobre si es real. Quien necesite saber si existe un registro tiene que preguntárselo a su base de datos; esta página responde la pregunta anterior, la de si merece la pena preguntar.

El número de versión es el primer carácter del tercer grupo, o sea el decimotercer dígito hexadecimal. Un `4` ahí significa aleatorio, un `1` basado en tiempo, un `7` ordenable en el tiempo según el nuevo RFC 9562, y el `3` y el `5` corresponden a las variantes basadas en nombre con MD5 y con SHA-1.

Se lee a simple vista en cuanto se sabe dónde mirar, y es la forma más rápida de confirmar una sospecha. Quien vea un identificador que en esa posición no lleva ninguna cifra conocida tiene delante o un UUID anterior a la versión, o algo que solo lo parece.

El primer carácter del cuarto grupo tiene que ser `8`, `9`, `a` o `b`. Esos cuatro dígitos comparten los bits iniciales `10`, que son la variante que el RFC 4122 reclama para sí; cualquier otro valor pertenece a esquemas antiguos o reservados.

En la práctica: un identificador con la versión correcta pero con una `c` o una `f` en esa posición no lo generó una biblioteca conforme. La causa habitual son los generadores caseros que encadenan 32 dígitos aleatorios y pasan por alto las dos posiciones fijas — un fallo que puede vivir años sin que nadie lo note.

La especificación exige minúsculas al generar y tolerancia con las mayúsculas al leer. En la práctica aparecen las dos: .NET y muchas herramientas de Windows escriben tradicionalmente en mayúsculas, la mayoría de lo demás en minúsculas.

A eso se suman dos envoltorios frecuentes: las llaves, de la notación del registro de Windows, y un `urn:uuid:` delante, del espacio de nombres URN. Ambos se reconocen aquí y se ignoran. Quien compare por su cuenta debe normalizar antes, o dos identificadores idénticos fallarán la comparación por su forma de escribirse.

Un UUID versión 1 contiene el instante de creación con precisión de 100 nanosegundos y, en el último grupo, tradicionalmente la dirección MAC de la tarjeta de red. Las dos cosas son reconstruibles por quien tenga el identificador.

No es teórico: fue la vía por la que en 1999 se identificó al autor del virus Melissa, porque Word escribía la MAC en los identificadores de documento. Donde un identificador se ve desde fuera, la versión 4 es la elección correcta; las bibliotecas modernas, además, ponen un nodo aleatorio en lugar de la dirección real.

La versión 7 antepone una marca de tiempo en milisegundos y rellena el resto con azar, de modo que los identificadores quedan ordenados en el tiempo por su propio valor — y eso resuelve el problema por el que muchos equipos evitaban los UUID como clave primaria.

La causa es el índice de la base de datos. Las claves aleatorias escriben en puntos siempre cambiantes de un árbol B, lo que parte páginas y desperdicia la caché; en tablas grandes cuesta rendimiento de escritura medible. Una clave creciente escribe al final. La contrapartida es que el instante de creación vuelve a ser legible.

Un identificador de solo ceros es el UUID nil, previsto expresamente en la especificación y formalmente válido aunque no lleve ni versión ni variante. Significa «ninguno» y aparece donde un campo no puede ser nulo pero debe estar vacío.

Desde el RFC 9562 existe su contrario, el UUID max, de solo `f`. Los dos superan la comprobación de aquí y se identifican como lo que son. Quien encuentre un UUID nil en datos de producción debería desconfiar: casi nunca es un marcador puesto a propósito, sino un generador que ha fallado en silencio.

Los fallos más habituales son triviales: 31 dígitos en vez de 32 porque al copiar se perdió uno, un espacio al final procedente de una celda de hoja de cálculo, o una cadena de 32 dígitos sin guiones. Lo último es una forma de almacenamiento corriente y perfectamente normal en una columna, solo que no es la forma textual.

En esos casos aquí se dice qué ha fallado, en vez de limitarse a «no válido». Ese es el valor real: quien recibe un identificador dentro de un mensaje de error quiere saber si ha perdido un carácter o si la otra parte ha enviado algo que nunca fue un UUID.

Un UUID no es por sí mismo un dato personal, pero suele ser la llave que lleva a uno: un identificador de usuario, una clave de sesión, un número de expediente de un sistema de soporte. Como la comprobación ocurre en la página, nada de eso se nos comunica.

Con los identificadores versión 1 se añade que llevan información dentro: el instante y, posiblemente, la MAC del equipo que los creó. Mandar precisamente esos valores por un formulario ajeno sería la peor idea — y es la razón por la que aquí el análisis se hace donde el identificador ya está.