【问题标题】:UUID format: 8-4-4-4-12 - Why?UUID 格式:8-4-4-4-12 - 为什么?
【发布时间】:2012-05-28 02:04:43
【问题描述】:

为什么 UUID 以“8-4-4-4-12”(数字)格式显示?我已经四处寻找原因,但找不到需要它的决定。

格式化为十六进制字符串的 UUID 示例: 58D5E212-165B-4CA0-909B-C86B9CEE0111

【问题讨论】:

  • 其实那个十六进制字符串的例子是不正确的。 UUID spec requires,表示 UUID 值的十六进制字符串必须小写。该规范还要求实现能够解析大写或混合大小写的字符串,但只能生成小写。不幸的是,常见的实现违反了这条规则,包括 Apple、Microsoft 和其他公司的实现。
  • 有趣的罗勒,谢谢

标签: format guid uuid


【解决方案1】:

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)                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

【讨论】:

  • 为什么时间戳被分成三部分?
  • 如何生成字段取决于 UUID 版本。首选方法不使用时间,因为这会显示生成 ID 的时间(潜在的安全问题)。 en.wikipedia.org/wiki/…
  • @pmont “首选”?
  • @brocoli 我不同意。 V4 依赖于强大的加密随机数生成器,它构建起来比简单地获取MAC address、当前时刻和递增的任意数要难于构建,如 V1 UUID 中所示。此外,V1 的实现通常是开源的,并且是多年前构建的,在整个行业中得到了广泛的应用,现在已经很流行了。声称 V1“容易出现部分故障”是愚蠢的。 V1 UUID 是系统中最后一个需要担心失败的部分。
  • @BasilBourque 随着容器和容器网络的普及,您现在可以看到的问题之一是 MAC 地址冲突。通常,容器和虚拟机从有限范围的可能 MAC 地址中提取。默认情况下,IIRC Hyper-V 仅从 256 个可能的 MAC 地址池中提取。
【解决方案2】:

格式在第 3 节的IETF RFC4122 中定义。输出格式在“UUID = ...”处定义。

3.- 命名空间注册模板

命名空间 ID:UUID 注册信息: 注册日期:2003-10-01

命名空间的声明注册者: JTC 1/SC6(ASN.1 报告人组)

语法结构声明: UUID 是在空间和时间上唯一的标识符, 关于所有 UUID 的空间。由于 UUID 是固定的 大小并包含一个时间字段,值可以是 翻转(大约公元 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"

【讨论】:

    【解决方案3】:

    128 位

    “8-4-4-4-12”格式仅供人类阅读。 UUID 实际上是一个 128-bit 号码。

    考虑到当存储或在内存中时,字符串格式需要的字节数是 128 位数字的两倍。我建议在内部使用该数字,当需要在 UI 上显示或导出到文件中时,请使用字符串格式。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2021-02-14
      • 2014-11-20
      • 1970-01-01
      • 2016-01-13
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2013-05-14
      相关资源
      最近更新 更多