Validador UUID

Cuando el resultado es correcto, devuelve la forma canónica normalizada en minúsculas, la variante codificada en los bits de secuencia de reloj y la versión codificada en el UUID. Admite letras hexadecimales mayúsculas o minúsculas, pero no acepta silenciosamente llaves, cadenas compactas, separadores mal colocados ni caracteres no hexadecimales.

Qué comprueba este validador de UUID

Un UUID contiene 128 bits, aunque las personas y los sistemas suelen intercambiarlo como 36 caracteres visibles distribuidos en cinco grupos: ocho caracteres hexadecimales y, después, cuatro, cuatro, cuatro y doce, separados por guiones. Este validador comprueba exactamente esa representación. Verifica la longitud total, confirma que cada separador ocupa la posición correcta y rechaza cualquier carácter que no sea un dígito hexadecimal o un guion. Las letras hexadecimales pueden escribirse en mayúsculas o minúsculas porque el uso de mayúsculas no altera los bits subyacentes. No se eliminan silenciosamente espacios, llaves, prefijos URN, valores compactos de 32 caracteres ni signos finales. Esta delimitación estricta resulta útil al probar el contrato de una API o de un campo de base de datos: la entrada coincide con la forma UUID documentada o recibe una explicación que señala el problema estructural. Una respuesta correcta incluye valid con valor verdadero y una cadena canónica en minúsculas apta para comparaciones estables, claves de caché, datos de prueba y registros. La validación es determinista y no consulta registros, genera sustitutos ni afirma que el UUID exista en un sistema externo.

Cómo se decodifican la variante y la versión

Los metadatos de un UUID están codificados en el propio identificador y no se consultan externamente. La versión corresponde al dígito hexadecimal situado al principio del tercer grupo; el validador convierte ese dígito en un entero de 0 a 15 y lo devuelve directamente. Entre las versiones asignadas habituales se encuentran la versión 1 basada en tiempo, las versiones 3 y 5 basadas en nombres, la versión 4 aleatoria, la versión 6 con tiempo reordenado, la versión 7 con tiempo Unix y la versión 8 personalizada. La variante se obtiene de los bits iniciales del cuarto grupo. Un bit inicial cero se informa como ncs; el patrón 10 se informa como rfc_4122, la familia empleada por los diseños UUID modernos; 110 se informa como microsoft; y 111 como future. Informar de los bits no equivale a imponer un perfil de aplicación. Un UUID estructuralmente correcto puede contener una versión reservada o una variante heredada, por lo que esta herramienta describe lo codificado en vez de suponer que todo valor válido debe ser de versión 4. Después, su aplicación puede aplicar su propia política a los campos devueltos.

Canonicalización, errores y uso práctico

La canonicalización solo modifica el uso de mayúsculas en las letras hexadecimales: los cinco grupos y todos los dígitos permanecen intactos, mientras que de A a F pasan a minúsculas. Así, dos grafías admitidas del mismo valor de 128 bits producen exactamente la misma cadena canónica. El validador no recorta espacios ni repara un valor casi correcto, pues una limpieza automática podría ocultar un límite de serialización defectuoso. En su lugar, un valor vacío, un valor que no sea una cadena, una cantidad de caracteres incorrecta, guiones mal colocados o caracteres ilegales producen mensajes explicativos distintos. Este comportamiento hace que la capacidad sea apropiada para controles de importación, diagnósticos de formularios, datos de prueba y herramientas de soporte donde la causa importa tanto como el resultado afirmativo o negativo. Envíe un candidato en el campo text; también se admiten los alias uuid y value para facilitar la integración. La operación cuesta $0.002 por elemento mediante la API y se ejecuta sin red, aleatoriedad, reloj, modelo ni almacenamiento persistente. Solo comprueba sintaxis y metadatos incrustados; no determina unicidad, propiedad, presencia en una base de datos ni idoneidad para un protocolo concreto.