개발자 도구 · UUID 생성기
128 비트에서 36 문자까지: UUID 텍스트 인코딩 작동 방식
· 작동 방식
uuid 암호화 브라우저 API
UUID은(는) 16바이트이지만 익숙한 형식은 36자입니다. 이 게시물에서는 16진수 이중화, 하이픈, 대소문자 규칙 및 표준 형식이 너무 길 때 사람들이 사용하는 더 짧은 인코딩에 대해 설명합니다.
열이 값보다 넓은 이유 — 텍스트에서 36 문자의 비용이 드는 16바이트 값과 URL 및 저장소에 대한 의미
UUID 형식을 선택하면 저장소 열 너비가 폭발합니다. 128 비트 값은 16 바이트이지만 텍스트 표현은 인코딩에 따라 다릅니다. 16진수(하이픈이 있는 36 문자, 없는 32), base64url(22 문자), base58(22–23 문자), Crockford base32(26자). 스키마가 UUID를 VARCHAR(36)로 저장하는 경우 모든 행에서 36 문자를 사용하게 됩니다. 10억 개의 행이 있고 다른 열은 없는 테이블에서 이는 16기가바이트의 바이너리에 비해 36기가바이트의 텍스트 오버헤드입니다. 선택은 단지 미용적인 것이 아닙니다. 이는 쿼리 크기, 네트워크 왕복 및 캐시 압력에 영향을 미칩니다. 표준 형식은 36 문자입니다: 8개의 16진수, 하이픈, 4개의 16진수, 하이픈, 4개의 16진수, 하이픈, 4개의 16진수, 하이픈, 12개의 16진수.
16진수는 모든 것을 두 배로 늘립니다. 각 바이트는 2개의 문자가 되고 4개의 하이픈이 36를 완성합니다.
각 바이트는 정확히 2개의 16진수 문자(0–9, a–f)가 됩니다. 하이픈은 UUID가 처음 지정되었을 때부터 가독성과 레거시 이유로 존재합니다. 16진수 인코딩은 바이트 수를 두 배로 늘립니다. 16 바이트는 32 16진수와 4 하이픈이 됩니다. 가장 느리고 가장 긴 인코딩이지만 사람이 읽을 수 있고 모든 곳에서 지원됩니다. 대소문자 규칙: RFC 9562는 표준 출력에 대해 소문자를 요구하지만 입력은 대소문자를 구분하지 않습니다. 대문자를 저장하면 정규화 기회가 낭비되므로 소문자를 저장하고 입력 시 대소문자를 구분하지 않고 비교하세요. Base64url 인코딩은 64 문자 알파벳(A–Z, a–z, 0–9, 마이너스, 밑줄)을 사용하여 3바이트를 4자로 나타냅니다. 16바이트는 21 문자와 1개의 패딩 문자가 되어 총 22 문자가 됩니다. Base64url은 URL에 예약된 패딩과 표준 문자(더하기 및 슬래시)를 제거합니다.
대소문자 규칙 — 출력 시 소문자, 입력 시 대소문자 구분, 대소문자 혼합 비교로 인해 자동 불일치가 발생하는 이유
base64url 형식의 UUID는 16진수에 비해 14 문자를 저장하며 백분율 인코딩이 없는 URL에서 유효합니다. 단점: 읽기가 어렵습니다(소문자는 숫자처럼 보입니다. b, 8, B 및 8은 혼동하기 쉽습니다). Base58은 비트코인 및 기타 블록체인에서 사용되며 모호한 문자(0, O, I, l)를 제거하여 읽을 수 있는 상태에서 결과를 22–23 문자로 만듭니다. Crockford base32(체크섬 ISBN 유사 형식용으로 설계됨)는 26 문자를 사용하고 간결함보다 정확성을 우선시합니다. Microsoft GUID 바이트 순서 트랩은 일부 데이터베이스의 UUID 스토리지에 적용됩니다. RFC 9562는 모든 바이트에 대한 네트워크 바이트 순서(빅 엔디안)를 지정합니다. 일부 Microsoft SQL Server 구성에서는 처음 세 필드에 리틀 엔디안 바이트 순서로 GUID를 저장합니다.
더 짧은 인코딩 — 22 문자의 base64url, base58 및 Crockford base32(가독성과 복사-붙여넣기 안전성의 절충안 포함)
빅엔디안과 리틀엔디안에 저장된 동일한 128비트 값은 서로 다른 16진수 문자열을 생성합니다. Microsoft GUID로 저장된 UUID 550e8400-e29b-41d4-a716-446655440000는 00840e55-9be2-d441-a716-446655440000(바이트 0–3 및 4–5 및 6–7 역순). 시스템이 RFC 호환 시스템과 Microsoft 시스템을 연결하는 경우 이를 인지하고 경계에서 정규화하거나 각 열에서 사용 중인 형식을 문서화해야 합니다. 작업된 예: 16진수로 된 v4 UUID 9b2e4f1a-4f3e-4c1a-8a7d-1b2c3d4e5f60은 36 문자를 차지합니다. 16 바이트이므로 9b 2e 4f 1a 4f 3e 4c 1a 8a 7d 1b 2c 3d 4e 5f 60입니다. base64url에서: 3바이트 청크로 분할하고, base64로 변환하고, 패딩 제거: my5PGk8-TBqKfRssPTRPX2A. 하이픈 없는 16진수: 9b2e4f1a4f3e4c1a8a7d1b2c3d4e5f60 (32 문자).
Microsoft 바이트 순서 트랩 — GUID의 처음 세 필드가 리틀 엔디안으로 저장되어 동일한 바이트가 두 개의 다른 문자열로 인쇄될 수 있는 방법
Base64url은 14 문자를 저장합니다. base58은 거의 동일하게 저장됩니다. 16진수가 표준입니다. 사용 사례에 따라 선택하세요. 식별자가 URL에 표시되고 모든 문자가 중요한 경우 base64url을 사용하세요. 사람이 읽는 로그와 UI에 표시되면 16진수 표준 형식을 사용하세요. 체크섬이 중요한 블록체인 시스템이나 분산 시스템을 구축하는 경우 base58 또는 Crockford base32를 사용하세요. 열 유형을 선택할 때 실제 액세스 패턴에 최적화된 값을 저장하세요. UUID를 자주 쿼리하고 대소문자를 구분하지 않는 일치가 필요한 경우 바이너리(16)를 저장하고 데이터베이스가 표현을 처리하도록 하세요. 하위 문자열로 쿼리하는 경우(접두어로 시작하는 UUID 검색) 디버그 출력에서 16진수를 더 쉽게 읽을 수 있습니다.
작업된 예 — 각 변환 단계를 보여주는 바이트, 표준 16진수 및 단축 형식으로 작성된 하나의 식별자
CSV로 내보내고 기술 지식이 없는 사용자에게 이메일을 보내는 경우 16진수를 더 쉽게 알아볼 수 있습니다. 공간이 제한된 경우(로컬 캐시가 있는 모바일 앱) base64url 또는 base58을 사용하면 대역폭이 절약됩니다. ToolAcre 생성기는 표준 36 문자 16진수 형식을 출력합니다. 다른 인코딩이 필요한 경우 형식을 확인하기 전에 유효한 표현을 정규화하므로 올바른 형식의 검사가 계속 작동합니다. 수백만 개의 UUID를 인코딩하거나 디코딩할 때 성능 고려 사항이 중요합니다. 16진수 인코딩은 간단합니다. 각 바이트를 바이트당 O(1) 시간 내에 두 문자로 변환합니다. 디코딩도 똑같이 간단합니다. Base64 인코딩 및 디코딩은 조회 테이블을 사용하며 약간 느립니다(하드웨어 및 구현에 따라 바이트당 16진수보다 대략 2–3배 느림). Base58은 본질적으로 진수 변환이고 모듈식 산술이 필요하기 때문에 상당히 느립니다.
여기서 다루지 않는 내용 — 기본 UUID 유형과 바이너리(16) 등의 데이터베이스 열 선택은 별도로 다룹니다.
시스템이 핫 루프(고빈도 식별자 생성, 대량 내보내기)에서 UUID를 인코딩하거나 디코딩하는 경우 16진수가 더 빠릅니다. 인코딩이 자주 발생하지 않고 14 문자 절약이 중요한 경우 base64url을 사용하는 것이 합리적입니다. ToolAcre 생성기는 16진수를 출력하므로 호환성을 희생하지 않고도 성능 이점을 얻을 수 있습니다. 문자열 비교 의미는 인코딩에 따라 다릅니다. 16진수 UUID는 문자열로 비교할 수 있습니다: 550e8400-e29b-41d4-a716-446655440000 < 550e8400-e29b-41d4-a716-446655440001(사전식 비교가 작동함). 바이너리 UUID는 바이트 단위로 비교할 수 있습니다. 바이트 단위 비교는 숫자 비교와 동일합니다. 그러나 Base64url 및 base58로 인코딩된 UUID는 사전식 문자열 비교에서 숫자 순서를 유지하지 않습니다. 시스템이 UUID의 사전순 정렬(인덱스 또는 데이터베이스 키 작성 시 매우 일반적인 패턴)에 의존하는 경우 16진수, 2진수 또는 정렬 가능한 UUID 변형(v6 또는 v7)을 사용해야 합니다.
요점: 경계에서 표준 형식을 유지합니다. ToolAcre 생성기는 표준 36 문자 UUID를 출력하고 검사에서는 해당 형식의 문자열을 허용합니다.
ToolAcre 생성기는 현재 인코딩 순서로 정렬할 수 없는 v4 UUID를 생성합니다. 상호 운용성을 위해서는 단일 인코딩에 대한 표준화가 필요합니다. hex, base64 및 base58의 UUID를 동시에 허용하는 시스템은 처리하기 전에 모든 입력을 표준 형식으로 정규화해야 합니다. 이는 가능하지만 복잡성이 추가됩니다. 외부 API 또는 데이터베이스에는 특정 인코딩이 필요할 수 있습니다. 일부 API는 urn:uuid: 접두사가 붙은 16진수를 기대하고, 다른 API는 하이픈 없는 16진수를 기대하고, 또 다른 API는 base64url을 기대합니다. 시스템의 UUID 인코딩 기대치를 API 계약에 명확하게 문서화하세요. ToolAcre 생성기는 항상 표준 16진수를 출력합니다. 다른 인코딩이 필요한 경우 명시적으로 변환을 수행하고 팀에 절충 사항(공간, 성능, 가독성, 정렬 가능성)을 문서화하세요.