爲什麼UUID以格式「8-4-4-4-12」(數字)顯示?我已經查明瞭原因,但無法找到需要它的決定。格式化爲十六進制字符串UUID的UUID格式:8-4-4-4-12 - 爲什麼?
示例: 58D5E212-165B-4CA0-909B-C86B9CEE0111
爲什麼UUID以格式「8-4-4-4-12」(數字)顯示?我已經查明瞭原因,但無法找到需要它的決定。格式化爲十六進制字符串UUID的UUID格式:8-4-4-4-12 - 爲什麼?
示例: 58D5E212-165B-4CA0-909B-C86B9CEE0111
它由time, version, clock_seq_hi, clock_seq_lo, node
分離,如在RFC followoing指示。
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
格式在IETF RFC4122在第3節所定義的輸出格式定義它說: 「UUID = ...」
3.-命名空間登記模板
命名空間ID:UUID註冊信息: 註冊日期:2003-10-01
JTC 1/SC6(ASN.1報告人組)句法結構的聲明::210
聲明的名稱空間的註冊 甲UUID是一個標識符,是跨越空間和時間兩者, 獨特相對於所述所有UUID的空間。由於UUID的大小是固定的,並且包含時間字段,所以可能出現 翻轉的值(在A.D. 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"
爲什麼時間戳分成三部分? – immibis
字段的生成方式取決於UUID版本。首選方法不使用時間,因爲它揭示了ID生成的時間(潛在的安全問題)。 http://en.wikipedia.org/wiki/Universally_unique_identifier#Variants_and_versions – pmont
@pmont「首選」? –