개발자 도구 · UUID 생성기
UUID 문자열을 올바른 형식으로 만드는 이유와 검사기가 알 수 없는 것
· 작동 방식
uuid 암호화 브라우저 API
대문자, 중괄호, 항아리: 접두사 및 누락된 하이픈은 모두 실제 입력에 표시됩니다. 이 게시물은 표준 형식을 정의하고, 관대한 검증자가 수용해야 하는 사항을 보여 주며, Well-Formed와 존재를 분리합니다.
404이어야 하는 400 — 엉성한 UUID 검증이 혼란스러운 API 오류를 생성하는 방법
API 엔드포인트는 클라이언트로부터 식별자({12345678-90AB-CDEF-1234-567890ABCDEF})를 받습니다. 유효성 검사 코드는 /[0-9a-f]{32}/와 일치하는지 확인하고 유효하지 않은 것으로 거부합니다. 클라이언트는 404 찾을 수 없음을 의미하는 400 잘못된 요청을 받습니다. 식별자는 올바른 형식입니다. 중괄호 형식의 유효한 UUID이지만 유효성 검사기가 너무 엄격합니다. 반대로, 32 문자 16진수 문자열(대시 제외)을 허용하는 엔드포인트는 123456789012345678901234567890123456을 허용하고 유효한 것으로 구문 분석하여 오타를 놓칩니다. RFC 9562는 표준 텍스트 표현을 정의하지만 실제 입력은 5가지 다른 형식으로 도착하며 표준 형식만 허용하는 유효성 검사기는 의도한 입력의 1 ~ 5%를 거부합니다.
표준 텍스트 형식 — 32 소문자 16진수 8-4-4-4-12, 표준이 출력에 대해 지정하는 대로 정확히 36 문자
표준 텍스트 형식은 하이픈으로 구분된 5개 그룹의 32 소문자 16진수입니다: 8-4-4-4-12. 550e8400-e29b-41d4-a716-446655440000로 표시됩니다. 표준에서는 출력 시 소문자를 요구합니다. 입력 시 대소문자를 구분하지 않는 일치가 권장됩니다. 이 형식은 모호하지 않고 모든 플랫폼에서 동일한 방식으로 바이트로 구문 분석되며 모든 UUID 라이브러리가 기본적으로 출력하는 형식입니다. CSPRNG에서 새로운 UUID을 생성하는 경우 표준 형식은 사용자가 생성해야 하는 것과 ToolAcre가 생성하는 것입니다. 실제 입력은 예측 가능한 방식으로 벗어납니다. 대문자 식별자(550E8400-E29B-41D4-A716-446655440000)는 기본값이 대문자인 시스템에서 일반적입니다. 이는 동일한 바이트를 나타내며 소문자로 정규화한 후에 허용되어야 합니다.
실제로 만나게 될 변형 — 대문자 16진수, {braces}, urn:uuid: 접두어 및 32 문자 하이픈 없는 형식, 표준에서 허용하도록 명시한 변형
중괄호 형식({550e8400-e29b-41d4-a716-446655440000})은 Python의 uuid 모듈과 Microsoft 시스템의 표준 출력입니다. 중괄호를 제거하면 유효한 표준 형식이 제공됩니다. URN 접두사(urn:uuid:550e8400-e29b-41d4-a716-446655440000)는 통일된 리소스 이름에 대해 RFC 8141에 의해 정의됩니다. 구성표와 제거 식별자 접두사를 제거하면 정식 형식이 남습니다. 하이픈 없는 형식(550e8400e29b41d4a716446655440000)은 구조가 없는 32 16진수입니다. 유효한 바이트이지만 버전 및 변형을 읽을 수 있게 만드는 8-4-4-4-12 그룹화가 손실됩니다. 이러한 변형은 모두 동일한 128비트 값에 매핑됩니다. RFC 9562 섹션 3에는 입력 시 대문자 변형이 허용되어야 한다고 명시되어 있습니다. 다른 변형을 금지하지 않습니다. 출력 시 표준 소문자 형식을 사용해야 한다고 나와 있습니다.
버전 및 변형 상태 — 세 번째 그룹이 0로 시작하거나 네 번째 그룹이 f로 시작하는 UUID을(를) 거부할지 여부
잘 구성된 유효성 검사기는 다음을 수행해야 합니다. 소문자 또는 대문자로 된 정식 8-4-4-4-12 형식을 허용합니다. Braced 및 urn: 변형을 제거하고 핵심 형식을 검증하여 변형을 허용합니다. 하이픈 없는 32자리 16진수 문자열을 허용하고 비교를 위해 표준 형식으로 지정합니다. 16진수 숫자가 잘못되었거나 16진수가 아닌 문자가 포함된 문자열을 거부합니다. 가장 흔한 실수는 유효성 검사기가 표준 형식에만 일치하도록 직접 작성되었기 때문에 대문자 또는 중괄호 입력을 거부하는 것입니다. 버전 및 변형에 대한 온전성 검사를 통해 오타를 발견할 수 있습니다. 세 번째 그룹이 0 또는 9로 시작하는 경우 UUID은 유효하지 않거나 예약되어 있습니다. 네 번째 그룹이 e 또는 f로 시작하는 경우 변형은 RFC 9562가 아닙니다.
작업된 예 — 6개의 후보 문자열이 각각 통과 또는 실패하는 이유와 함께 엄격한 검사와 관대한 검사를 거칩니다.
관대한 유효성 검사기는 이러한 값을 허용합니다. 엄격한 검증자는 이를 거부할 수 있습니다. ToolAcre의 올바른 형식 검사는 엄격한 유효성 검사를 수행합니다. 올바른 위치에 대시가 있는 정식 36 문자 형식을 확인하고 모든 위치의 16진수를 확인하며 버전 및 변형 비트가 범위 내에 있는지 확인합니다. UUID이 데이터베이스에 존재하는지 또는 암호화된 보안 소스에서 생성되었는지는 확인하지 않습니다. 이는 애플리케이션 로직에 의해 수행되는 별도의 검사입니다. 잘 형성된 것은 실제와 동일하지 않습니다. 모양에 따라 올바르게 구문 분석되는 UUID 문자열은 데이터베이스의 어떤 행도 식별하지 못할 수 있습니다.
잘 구성된 것은 실제가 아닙니다. 구문적으로 완벽한 UUID이 데이터에 존재하지 않는 이유와 검사기가 인증 레이어가 되어서는 안되는 이유
완벽하게 구성된 UUID은(는) 추측되었거나 잘못 복사하여 붙여넣었을 수 있습니다. 형식 유효성 검사가 첫 번째 관문입니다. 존재 확인과 권한 확인이 두 번째와 세 번째입니다. 모든 형식이 잘못된 입력에 대해 데이터베이스를 조회하는 것은 낭비입니다. 데이터베이스 쿼리 전에 형식이 잘못된 입력을 거부하면 시간이 절약됩니다. ToolAcre 생성기는 표준 36 문자 UUID를 출력합니다. 자체 유효성 검사기를 구축하는 경우 실제 입력과 일치하도록 중괄호 및 urn: 변형을 허용하고 데이터베이스에 요청하기 전에 기본 모양 규칙을 위반하는 문자열을 거부하세요. 엄격한 유효성 검사기를 구현하려면 정규식과 극단적인 경우 처리가 필요합니다. 표준 형식은 간단합니다: /^[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$/i(대소문자를 구분하지 않음). 중괄호 형식은 중괄호를 추가합니다: /^\{[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}\}$/i. urn: 변형은 체계를 추가합니다: /^urn:uuid:[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$/i.
여기서 다루지 않는 내용 — 저장을 위한 ID 정규화 및 열 유형 선택은 별도의 결정입니다.
모든 변형을 처리하는 단일 정규식은 읽기 쉽지 않지만 가능합니다. 대부분의 유효성 검사기는 먼저 정규화합니다. 중괄호와 urn: 접두사를 제거하고 소문자로 변환한 다음 표준 패턴을 일치시킵니다. 버전 및 변형 비트는 403 문서에 설명된 대로 14 위치와 19 위치를 검사하여 패턴 일치 후 확인할 수 있습니다. 유효하지 않은 입력을 적절하게 처리하는 것은 유효성 검사 설계의 일부입니다. 클라이언트가 잘못된 형식의 UUID을 제출하는 경우 오류 메시지에 정규식 패턴이나 내부 유효성 검사 규칙을 노출하지 마세요. 명확한 오류를 반환합니다. "잘못된 UUID 형식입니다. 8-4-4-4-12 형식이 필요합니다(예: 550e8400-e29b-41d4-a716-446655440000). " 시도하지 마세요. 입력을 수정하세요. 고객에게 다시 제출하도록 요청하세요.
요약: 모양을 조기에 검증하고 별도로 존재 여부를 조회합니다. ToolAcre 검사는 데이터베이스를 터치하기 전에 브라우저에서 모양을 확인합니다.
일부 시스템은 보안 감사(삽입 시도 또는 형식 혼동 공격 감지)를 위해 잘못된 입력을 기록합니다. ToolAcre 유효성 검사기는 명확한 오류 메시지와 함께 비정규 양식을 거부하고 자동 수정을 시도하지 않습니다. 상호 운용성에 있어 정식 형식이 중요한 이유: 한 시스템에서 UUID를 하이픈 없는 16진수로 저장하고 다른 시스템에서는 UUID를 정식 8-4-4-4-12로 저장하는 경우 동등성을 비교하려면 정규화가 필요합니다. 대문자와 소문자 비교에는 대소문자를 구분하지 않는 비교가 필요합니다. Braced와 bare는 스트리핑이 필요합니다. 이러한 변형으로 인해 대량 작업(가져오기, 마이그레이션, 비교)이 더 어려워집니다. 표준 형식을 출력하는 표준 도구는 마찰을 줄입니다. ToolAcre 생성기는 항상 36 문자 소문자 표준 형식을 출력합니다. 다른 시스템에서 UUID를 가져올 때 일관성을 보장하기 위해 ETL 프로세스에서 UUID를 이 형식으로 정규화하세요.