UUID 형식 : 8-4-4-4-12-이유가 무엇입니까?


84

UUID가 "8-4-4-4-12"(숫자) 형식으로 표시되는 이유는 무엇입니까? 이유를 둘러 보았지만 필요한 결정을 찾을 수 없습니다.

16 진 문자열로 형식화 된 UUID의 예 : 58D5E212-165B-4CA0-909B-C86B9CEE0111


11
실제로 그 16 진 문자열 예제는 올바르지 않습니다. UUID 사양이 필요 것을 UUID는 값을 나타내는 16 진수 문자열이 있어야소문자 . 또한 사양에는 대문자 또는 대소 문자가 혼합 된 문자열을 구문 분석 할 수있는 구현이 필요하지만 소문자 만 생성 할 수 있습니다. 안타깝게도 일반적인 구현은 Apple, Microsoft 등의 규칙을 포함하여이 규칙을 위반합니다.
Basil Bourque

1
재미있는 바질, 감사
피델

답변:


65

time, version, clock_seq_hi, clock_seq_lo, node다음 rfc에 표시된대로로 구분됩니다 .

로부터 IETF RFC4122 :

4.1.2.  Layout and Byte Order

   To minimize confusion about bit assignments within octets, the UUID
   record definition is defined only in terms of fields that are
   integral numbers of octets.  The fields are presented with the most
   significant one first.

   Field                  Data Type     Octet  Note
                                        #

   time_low               unsigned 32   0-3    The low field of the
                          bit integer          timestamp

   time_mid               unsigned 16   4-5    The middle field of the
                          bit integer          timestamp

   time_hi_and_version    unsigned 16   6-7    The high field of the
                          bit integer          timestamp multiplexed
                                               with the version number  

   clock_seq_hi_and_rese  unsigned 8    8      The high field of the
   rved                   bit integer          clock sequence
                                               multiplexed with the
                                               variant

   clock_seq_low          unsigned 8    9      The low field of the
                          bit integer          clock sequence

   node                   unsigned 48   10-15  The spatially unique
                          bit integer          node identifier

   In the absence of explicit application or presentation protocol
   specification to the contrary, a UUID is encoded as a 128-bit object,
   as follows:

   The fields are encoded as 16 octets, with the sizes and order of the
   fields defined above, and with each field encoded with the Most
   Significant Byte first (known as network byte order).  Note that the
   field names, particularly for multiplexed fields, follow historical
   practice.

   0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          time_low                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       time_mid                |         time_hi_and_version   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |clk_seq_hi_res |  clk_seq_low  |         node (0-1)            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         node (2-5)                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

11
타임 스탬프가 세 부분으로 분할 된 이유는 무엇입니까?
user253751

4
필드 생성 방법은 UUID 버전에 따라 다릅니다. 선호하는 방법은 ID가 생성 된 시간을 나타내므로 시간을 사용하지 않습니다 (잠재적 인 보안 문제). en.wikipedia.org/wiki/…
pmont

1
@pmont "선호"?
Basil Bourque

2
@brocoli 동의하지 않습니다. V4 는 V1 UUID에서 볼 수 있듯이 단순히 MAC 주소 , 현재 순간 및 증가하는 임의의 숫자 를 잡는 것보다 잘 구축하기 가 훨씬 더 어려운 암호 학적으로 강력한 난수 생성기에 의존합니다 . 더욱이 V1의 구현은 일반적으로 오픈 소스이며 수년 전에 구축되어 업계 전반에 걸쳐 많이 사용되었으며 현재는 잘 착용되었습니다. V1이 "부분적 오류가 발생하기 쉽다"는 주장은 어리석은 일입니다. V1 UUID는 장애에 대해 걱정해야하는 시스템의 마지막 부분입니다.
Basil Bourque

2
@BasilBourque 컨테이너 및 컨테이너 네트워킹의 확산으로 현재 볼 수있는 문제 중 하나는 MAC 주소 충돌입니다. 일반적으로 컨테이너와 VM은 제한된 범위의 가능한 MAC 주소에서 가져옵니다. IIRC Hyper-V는 기본적으로 256 개의 가능한 MAC 주소 풀에서만 가져옵니다.
Nathan Clayton

12

형식은 섹션 3의 IETF RFC4122 에 정의되어 있습니다 . 출력 형식은 "UUID = ..."라고 표시된 곳에 정의됩니다.

3.- 네임 스페이스 등록 템플릿

네임 스페이스 ID : UUID 등록 정보 : 등록 날짜 : 2003-10-01

네임 스페이스 등록자 선언 : JTC 1 / SC6 (ASN.1 Rapporteur Group)

구문 구조의 선언 : UUID는 모든 UUID의 공간과 관련하여 공간과 시간 모두에서 고유 한 식별자입니다. UUID는 고정 된 크기이고 시간 필드를 포함하므로 값이 롤오버 될 수 있습니다 (사용 된 특정 알고리즘에 따라 AD 3400 주변). UUID는 수명이 매우 짧은 개체에 태그를 지정하는 것부터 네트워크에서 매우 지속적인 개체를 안정적으로 식별하는 것까지 다양한 용도로 사용할 수 있습니다.

  The internal representation of a UUID is a specific sequence of
  bits in memory, as described in Section 4.  To accurately
  represent a UUID as a URN, it is necessary to convert the bit
  sequence to a string representation.

  Each field is treated as an integer and has its value printed as a
  zero-filled hexadecimal digit string with the most significant
  digit first.  The hexadecimal values "a" through "f" are output as
  lower case characters and are case insensitive on input.

  The formal definition of the UUID string representation is
  provided by the following ABNF [7]:

  UUID                   = time-low "-" time-mid "-"
                           time-high-and-version "-"
                           clock-seq-and-reserved
                           clock-seq-low "-" node
  time-low               = 4hexOctet
  time-mid               = 2hexOctet
  time-high-and-version  = 2hexOctet
  clock-seq-and-reserved = hexOctet
  clock-seq-low          = hexOctet
  node                   = 6hexOctet
  hexOctet               = hexDigit hexDigit
  hexDigit =
        "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9" /
        "a" / "b" / "c" / "d" / "e" / "f" /
        "A" / "B" / "C" / "D" / "E" / "F"

4

128 비트

"8-4-4-4-12"형식은 사람이 읽기위한 것입니다. UUID는 정말입니다 128 비트 번호입니다.

문자열 형식이 저장되거나 메모리에있을 때 128 비트 숫자보다 두 배의 바이트가 필요하다는 점을 고려하십시오. 내부적으로 번호를 사용하고 UI에 표시하거나 파일로 내 보내야하는 경우 문자열 형식을 사용하는 것이 좋습니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.