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などによるものを含め、このルールに違反しています。
バジルバーク2018

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
タイムスタンプが3つの部分に分割されたのはなぜですか?
user253751 2014年

4
フィールドの生成方法は、UUIDのバージョンによって異なります。IDが生成された時刻が明らかになるため、推奨される方法では時刻を使用しません(潜在的なセキュリティ上の懸念)。 en.wikipedia.org/wiki/...
pmont

1
@pmont「優先」?
バジルバーク2017

2
@brocoli私は反対しなければなりません。V4は、暗号的に強力な乱数ジェネレーターに依存しています。これは、V1 UUIDに見られるように、MACアドレス、現在の瞬間、および任意の数の増分を取得するよりも、うまく構築するのがはるかに困難です。さらに、V1の実装は一般にオープンソースであり、何年も前に構築され、業界全体で多く使用されており、現在では使い古されています。V1が「部分的な障害が発生しやすい」と主張するのはばかげています。V1 UUIDは、障害を心配する必要があるシステムの最後の部分です。
バジルバーク2018

2
@BasilBourqueコンテナとコンテナネットワークの急増で現在見られる問題の1つは、MACアドレスの衝突です。通常、コンテナとVMは、限られた範囲の可能なMACアドレスからプルします。IIRC Hyper-Vは、デフォルトで256の可能なMACアドレスのプールからのみプルします。
ネイサンクレイトン

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ビット数の2倍のバイトが必要であると考えてください。内部で番号を使用することをお勧めします。UIに表示したり、ファイルにエクスポートしたりする必要がある場合は、文字列形式を使用してください。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.