개발자 도구 · UUID 생성기
GUID 대 UUID: Microsoft의 중괄호, 바이트 순서 및 변형 설명
· 배경
uuid 암호화 브라우저 API
GUID는 UUID에 대한 Microsoft 이름이지만 중괄호, 대문자 및 바이트 순서로 인해 동일한 식별자가 플랫폼마다 다르게 보일 수 있습니다. 이번 포스팅에서는 각 차이점과 안전하게 비교하는 방법에 대해 설명합니다.
시스템 간에 일치하지 않는 동일한 ID - .NET 서비스와 Java 서비스가 하나의 레코드에 동의하지 않음
.NET 서비스는 GUID를 생성하고 이를 Java 서비스로 보냅니다. Java 서비스는 PostgreSQL의 UUID에 대한 값을 일치시키려고 시도합니다. 세 서비스 모두 동일한 기본 16 바이트로 작동하더라도 문자열 비교가 실패하고 시스템에서 식별자가 일치하지 않는다고 보고합니다. 차이점은 중괄호, 대/소문자, 바이트 순서 등 외관상의 차이로 보이지만 문자열 비교가 실패하고 경계에서 정규화되지 않는 통합 지점을 혼란스럽게 만듭니다. GUID는 RFC 9562가 UUID(동일한 비트 레이아웃을 가진 128비트 식별자)이라고 부르는 것에 대한 Microsoft 용어입니다. 두 이름은 동일한 기본 구조를 나타내지만 개발자를 놀라게 하는 방식으로 표현이 다릅니다. 혼란이 어디서 발생하는지 이해하면 통합 버그를 예방할 수 있습니다.
GUID는 UUID입니다. 공유된 128비트 형식과 이름 지정 차이의 출처
GUID는 전역 고유 식별자(Globally Unique Identifier) 및 전역 고유 식별자(Globally Unique Identifier)를 나타내며 Microsoft가 RFC 표준에서 UUID라고 부르는 이름에 사용하는 이름입니다. 128비트 레이아웃과 버전/variant 시스템은 동일합니다. RFC 4122 및 RFC 9562는 UUID 형식과 의미를 지정합니다. Microsoft는 이를 구현하고 GUID라는 용어를 사용합니다. 이름 차이는 역사적입니다. Microsoft는 IETF에서 UUID를 표준화하기 전에 GUID를 사용했으며 Microsoft 용어는 .NET 생태계 내에 갇혀 있습니다. 비트 수준에서 GUID와 UUID는 완전히 상호 교환 가능합니다. 서식 수준에서는 표시 방식이 다릅니다. .NET 코드는 중괄호와 대문자를 사용하여 GUID를 작성하는 경우가 많지만 RFC 표준 UUID는 중괄호 없이 소문자를 사용합니다.
중괄호 및 대문자 — 레지스트리 스타일 {XXXXXXXX-...} 형식 및 이를 정규화하는 방법
정식 RFC 형식의 UUID는 하이픈으로 구분된 8, 4, 4, 4 및 12개의 소문자 16진수 문자(550e8400-e29b-41d4-a716-446655440000)로 작성됩니다. .NET GUID는 일반적으로 중괄호와 대문자({550E8400-E29B-41D4-A716-446655440000})로 표시됩니다. 중괄호는 Windows 레지스트리 형식에서 나옵니다. 대문자는 표시 규칙입니다. 두 형식 모두 동일한 128 비트를 나타냅니다. .NET의 GUID를 PostgreSQL의 UUID와 일치시키려면 중괄호를 제거하고 대소문자를 정규화한 다음 문자열을 비교하십시오. ToolAcre의 올바른 형식 검사는 표준 형식을 허용하고 중괄호를 자동으로 제거합니다. 정규화는 모든 의미를 보존하는 사소한 텍스트 변환입니다.
혼합 엔디안 바이트 순서 — 처음 세 필드가 GUID 구조에서 리틀 엔디안으로 저장되는 방식 및 Guid.ToByteArray가 RFC 바이트 순서와 다른 이유
GUID와 UUID 사이의 위험한 차이점은 바이트 순서입니다. RFC 9562은 처음 세 개의 필드(8, 4 및 4 16진수 그룹)가 빅엔디안(네트워크) 바이트 순서로 저장되도록 지정합니다. .NET Guid 구조는 처음 세 개의 필드를 little-endian으로 저장합니다. 즉, 저장소에 쓰기 전에 바이트가 반전됩니다. 동일한 16 바이트가 .NET Guid.ToByteArray()로 작성되고 RFC 호환 코드로 해석되면 완전히 다른 텍스트 표현을 생성합니다. RFC 바이트 순서의 UUID 550e8400-e29b-41d4-a716-446655440000는 바이트 55 0e 84 00 e2 9b 41 d4 a7로 저장됩니다. 16 44 66 55 44 00 00.
레거시 Microsoft 변형 — 네 번째 그룹의 첫 번째 문자에 있는 c 또는 d의 의미
바이트 순서 외에도 레거시 Microsoft 식별자는 때때로 비표준 변형 필드를 사용합니다. RFC 9562에서는 네 번째 그룹의 첫 번째 문자가 8, 9, a 또는 b여야 함을 지정하지만 기존 Microsoft GUID에서는 c, d, e 또는 f를 사용할 수 있습니다. 이는 여전히 유효한 UUID이지만 RFC 표준화 이전의 레거시 변형을 따릅니다. 네 번째 그룹의 첫 번째 문자에 c 또는 d가 포함된 GUID가 나타나면 RFC 변형 비트를 따르지 않는 유효한 128비트 값이 있는 것입니다. 최신 .NET은 RFC 호환 GUID를 생성하므로 새 식별자에서는 이 문제가 발생하지 않습니다. 레거시 변형 비트는 드물지만 인식하는 것이 중요합니다.
작업된 예 — 동일한 16 바이트가 RFC 순서와 GUID 구조 순서로 렌더링되어 정확히 어떤 문자가 바뀌는지 보여줍니다.
UUID 550e8400-e29b-41d4-a716-446655440000을 가져와 리틀 엔디안 규칙을 사용하여 .NET GUID 바이트 배열 형식으로 변환합니다. RFC 순서에서 바이트는 다음과 같습니다. 첫 번째 필드(550e8400)는 55 0e 84 00, 두 번째 필드(e29b)는 e2 9b, 세 번째 필드(41d4)는 41 d4, 네 번째 및 다섯 번째는 a7 16입니다. 44 66 55 44 00 00. .NET 리틀엔디안에서: 첫 번째 필드는 00 84 0e 55가 되고, 두 번째는 9b e2가 되고, 세 번째는 d4 41이 되고, 나머지는 빅엔디안으로 유지됩니다. 전체 바이트 배열은 00 84 0e 55 9b e2 d4 41 a7 16 44 66 55 44입니다. 00 00. Java 시스템이 RFC 순서를 예상하여 이러한 바이트를 읽는 경우 이를 00840e55-9be2-d441-a716-446655440000로 해석합니다.
여기서 다루지 않는 내용 — 자체 저장소 주제인 SQL Server의 NEWSEQUENTIALID 및 순서
SQL Server NEWSEQUENTIALID 함수 동작 및 특정 식별자 순서 속성은 저장소 계층 및 데이터베이스 관련 항목입니다. 이 게시물은 애플리케이션 및 직렬화 수준의 형식 및 바이트 순서 차이점에 중점을 둡니다. 심층 데이터베이스 관련 UUID 처리 및 바이트 순서 문제는 해당 데이터베이스 플랫폼과 관련된 문서에서 가장 잘 해결됩니다. 데이터베이스 시스템마다 UUID 저장, 인덱싱, 정렬 및 기본 지원에 대한 접근 방식이 다릅니다. 일부 데이터베이스는 버전과 변형 비트를 자동으로 감지하는 반면, 다른 데이터베이스는 시스템과 스토리지 사이의 경계에서 명시적인 유형 선언과 바이트 순서 처리를 요구합니다.
요점: 경계에서 정규화 - ToolAcre 검사는 ID를 교환할 때 표준화할 모양인 표준 형식을 허용합니다.
식별자가 .NET/non-.NET 시스템 경계를 넘을 때 경계에서 정규화합니다. 중괄호를 제거하고, 대/소문자를 일관되게 정규화하고, 바이트가 .NET Guid.ToByteArray()에서 오는 경우 처음 세 필드를 바이트 교환합니다. 표준 RFC 형식은 참조 표준입니다. 하이픈이 있고 중괄호가 없으며 빅엔디안 바이트 순서가 있는 8, 4, 4, 4 및 12개의 소문자 16진수 문자입니다. .NET 시스템과 교환할 때 정규화된 형식에 동의하고 통합 코드에서 명시적으로 변환을 적용합니다. 바이트 순서 처리를 문서화하고 변환을 철저하게 테스트합니다. GUID와 UUID 간의 핵심 기본 유사점은 대부분의 128 비트가 동일하다는 것을 의미합니다.