Herramientas de desarrollo · UUID generador
Qué hace que una cadena UUID esté bien formada y qué no puede saber un verificador
· Cómo funciona
uuid criptografía APIS del navegador
Mayúsculas, llaves, urna: los prefijos y los guiones faltantes aparecen en la entrada real. Esta publicación define la forma canónica, muestra lo que debe aceptar un validador indulgente y separa la buena formación de la existencia.
El 400 que debería haber sido un 404: qué descuidada la validación de UUID produce errores de API confusos
Un punto final API recibe un identificador de un cliente: {12345678-90AB-CDEF-1234-567890ABCDEF}. El código de validación comprueba si coincide con /[0-9a-f]{32}/ y lo rechaza por no ser válido. El cliente recibe una 400 Solicitud incorrecta donde se refería a 404 No encontrado. El identificador está bien formado (es un UUID válido en formato entre llaves), pero el validador es demasiado estricto. Por el contrario, un punto final que acepta cualquier cadena hexadecimal de 32 caracteres (sin guiones) aceptará 123456789012345678901234567890123456, lo analizará como válido y omitirá el error tipográfico. RFC 9562 define la representación textual canónica, pero la entrada del mundo real llega en cinco formatos diferentes, y un validador que solo acepta la forma canónica rechazará del 1 al 5 por ciento de la entrada bien intencionada.
La forma textual canónica: 32 dígitos hexadecimales en minúsculas en 8-4-4-4-12, exactamente 36 caracteres, como lo especifica el estándar para la salida
La forma textual canónica es 32 dígitos hexadecimales en minúsculas en cinco grupos separados por guiones: 8-4-4-4-12. Representado como 550e8400-e29b-41d4-a716-446655440000. El estándar exige minúsculas para la salida; en la entrada, se recomienda la coincidencia que no distinga entre mayúsculas y minúsculas. Este formulario no es ambiguo, se analiza en bytes de la misma manera en todas las plataformas y es lo que genera cada biblioteca UUID de forma predeterminada. Si está generando un nuevo UUID a partir de un CSPRNG, la forma canónica es lo que debe producir y lo que produce ToolAcre. Los aportes del mundo real se desvían de maneras predecibles. Los identificadores en mayúsculas (550E8400-E29B-41D4-A716-446655440000) son comunes en los sistemas que usan mayúsculas de forma predeterminada; representan los mismos bytes y deben aceptarse después de la normalización a minúsculas.
Variantes habituales: hexadecimal en mayúsculas, {braces}, el prefijo urn:uuid: y formas de 32 caracteres sin guiones, además de cuáles exige aceptar el estándar.
La forma entre llaves ({550e8400-e29b-41d4-a716-446655440000}) es la salida estándar del módulo uuid de Python y los sistemas de Microsoft; quitar las llaves da una forma canónica válida. El prefijo URN (urn:uuid:550e8400-e29b-41d4-a716-446655440000) está definido por RFC 8141 para nombres de recursos uniformes; eliminar el esquema y el prefijo identificador de eliminación deja la forma canónica. La forma sin guiones (550e8400e29b41d4a716446655440000) es 32 dígitos hexadecimales sin estructura; son bytes válidos pero pierde la agrupación 8-4-4-4-12 que hace que las versiones y variantes sean legibles. Todas estas variantes se asignan al mismo valor de 128 bits. La sección 3 del RFC 9562 establece que en la entrada, DEBEN aceptarse variantes en mayúsculas. No prohíbe otras variantes; dice que en la salida, DEBE usarse la forma canónica en minúsculas.
Versión y variante de cordura: si se debe rechazar un UUID cuyo tercer grupo comienza con 0 o cuyo cuarto grupo comienza con f
Un validador bien formado debe: aceptar la forma canónica 8-4-4-4-12 en minúsculas o mayúsculas; acepte variantes braced y urn: eliminándolas y validando la forma principal; acepte cadenas hexadecimales de 32 dígitos sin guiones y formatéelas como canónicas para compararlas; rechazar cadenas con un número incorrecto de dígitos hexadecimales o caracteres no hexadecimales. El error más común es rechazar la entrada en mayúsculas o entre llaves porque el validador fue escrito a mano para coincidir únicamente con la forma canónica. Una verificación de cordura de la versión y variante puede detectar errores tipográficos. Si el tercer grupo comienza con 0 o 9, el UUID no es válido o está reservado; si el cuarto grupo comienza con e o f, la variante no es RFC 9562.
Ejemplo resuelto: seis cadenas candidatas pasan por una verificación estricta y otra indulgente, con las razones por las que cada una pasa o falla
Un validador indulgente acepta estos valores; un validador estricto puede rechazarlos. La verificación bien formada de ToolAcre realiza una validación estricta: confirma la forma canónica del carácter 36 con guiones en los lugares correctos, verifica los dígitos hexadecimales en cada posición y verifica que los bits de versión y variante estén dentro del rango. No verifica que UUID exista en su base de datos o que haya sido generado a partir de una fuente criptográficamente segura; esas son comprobaciones independientes realizadas por la lógica de su aplicación. Bien formado no es lo mismo que real. Es posible que una cadena UUID que se analice correctamente según su forma no identifique ninguna fila en su base de datos.
Bien formado no es real: por qué es posible que no exista un UUID sintácticamente perfecto en sus datos y por qué el verificador nunca debería ser su capa de autorización
Un UUID que está perfectamente formado puede haber sido adivinado o copiado incorrectamente. La validación del formato es la primera puerta; Los controles de existencia y los controles de autorización son el segundo y el tercero. Realizar una búsqueda en la base de datos para cada entrada con formato no válido es un desperdicio; rechazar entradas con formato no válido antes de realizar consultas a la base de datos ahorra tiempo. El generador ToolAcre genera UUID estándar de 36 caracteres; Si está creando su propio validador, acepte las variantes braced y urn: para que coincidan con la entrada del mundo real y rechace las cadenas que no cumplan con las reglas de forma básicas antes de consultar su base de datos. La implementación de un validador estricto requiere expresiones regulares y manejo de casos extremos. La forma canónica es sencilla: /^[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$/i (no distingue entre mayúsculas y minúsculas). La forma entre llaves agrega llaves: /^\{[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}\}$/i. La variante urn: agrega un esquema: /^urn:uuid:[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$/i.
Lo que esto no cubre: normalizar los ID para el almacenamiento y elegir un tipo de columna, que son decisiones independientes.
Una única expresión regular que maneje todas las variantes es menos legible pero posible. La mayoría de los validadores normalizan primero: eliminan las llaves y el prefijo urn:, convierten a minúsculas y luego coinciden con el patrón canónico. Los bits de versión y variante se pueden verificar después de la coincidencia de patrones examinando la posición 14 y la posición 19 como se describe en el artículo 403. Manejar con elegancia las entradas no válidas es parte del diseño de validación. Cuando un cliente envía un UUID con formato incorrecto, no exponga el patrón de expresiones regulares ni las reglas de validación interna en el mensaje de error. Devuelve un error claro: "Formato UUID no válido. Se esperaba el formato 8-4-4-4-12, como 550e8400-e29b-41d4-a716-446655440000". corregir la entrada; Pídale al cliente que vuelva a enviarlo.
Conclusión: valide la forma con anticipación, busque la existencia por separado: la verificación de ToolAcre confirma la forma en el navegador antes de tocar una base de datos
Algunos sistemas registran entradas no válidas para la auditoría de seguridad (detectando intentos de inyección o ataques de confusión de formato). El validador ToolAcre rechaza formularios no canónicos con un mensaje de error claro y no intenta realizar la autocorrección. Por qué la forma canónica es importante para la interoperabilidad: si un sistema almacena UUID como hexadecimal sin guiones y otro los almacena como canónico 8-4-4-4-12, compararlos para determinar su igualdad requiere normalización. Mayúsculas y minúsculas requieren una comparación que no distinga entre mayúsculas y minúsculas. Arriostrado versus desnudo requiere desmontaje. Estas variaciones dificultan las operaciones masivas (importaciones, migraciones, comparaciones). Las herramientas estándar que generan forma canónica reducen la fricción. El generador ToolAcre siempre genera 36 caracteres en forma canónica en minúsculas; Cuando importe UUID de otros sistemas, normalícelos a este formato en su proceso ETL para garantizar la coherencia.