为什么.NET GUID中有破折号?

为什么.NET GUID中有破折号? 在大多数GUID的实现中是否有破折号,还是仅仅是微软的东西?

签,

741ecf77-9c92-4435-8e6b-85975bd13452

从技术上讲, GUID中没有“破折号”。 GUID是一个128位的值,通常以下面的方式存储(这里用C#来表示结构):

public struct Guid { public ulong Data1; public ushort Data2; public ushort Data3; public fixed byte Data4[8]; } 

破折号在GUID的string表示中。

破折号是可选的,在GUID的string表示中不是必需的。

也就是说, 破折号的位置与GUID是如何产生有关,而历史语义不再适用, 这是有历史原因的 。

在UUID(通用唯一标识符)规范的初始版本中,每个数据元素都有一个语义含义:

{ time_low } – { time_mid } – { time_high_and_version } – { clock_seq_and_reserved clock_seq_low } – { node_id }

这些元素被devise为提供时间(时间比特)和空间(主机比特)的唯一性。

版本历史

由于2 ^ 1024个随机位的密钥空间中的碰撞的math概率被认为是天文上不可能的,因此出于安全和隐私的原因,UUID规范的后续版本已经淘汰了时间和主机数据。

唯一保留任何含义的元素是版本位和保留位。

版本3的UUID来源于URI或其他可分辨名称的MD5哈希。

版本4是随机数据生成的,目前是最常见的实现,你会看到在野外。

版本5来自SHA1哈希。

存储格式

由于在RFC中规定了用于UUID的ASCII格式的连字符,即使各个部分不再保留其原始含义,如果您需要互操作性,它们仍然是必需的。

UUID有时也被存储为base64或ascii85编码的string,以节省空间用于传输不是二进制安全的传输,并且不需要遵守RFC。

 Ascii:3F2504E0-4F89-11D3-9A0C-0305E82C3301
 Base64:7QDBkvCA1 + B9K / U0vrQx1A
 Ascii85:5:$ Hj:Pf \ 4RLB9%kU \ Lj

参考文献:
RFC4122 (有关UUID格式的ABNF描述,请参见第3页)
维基百科GUID UUID

连字符表示Guid的字节结构。

 typedef struct _GUID { DWORD Data1; WORD Data2; WORD Data3; BYTE Data4[8]; } GUID; 

对于:

 (XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXX) 

您可以在保存之前剥离它们。 至less在.NET中,Guidtypes的构造函数将从string表示中初始化一个Guidvariables,而不pipe连字符是否存在或被删除。

这只是一个方便。

http://en.wikipedia.org/wiki/GUID

你可以用各种格式得到你的guid。

假设你正在使用c#:

 Guid guid = Guid.NewGuid(); Console.WriteLine(guid.ToString("N")) 

63be6f7e4e564f0580229f958f492077

 Console.WriteLine(guid.ToString("D")) 

63be6f7e-4e56-4f05-8022-9f958f492077

 Console.WriteLine(guid.ToString("B")) 

{63be6f7e-4e56-4f05-8022-9f958f492077}

 Console.WriteLine(guid.ToString("P")) 

(63be6f7e-4e56-4f05-8022-9f958f492077)

这是一个分块的例子,就像电话号码,信用卡号码等

这是一个很好的维基百科关于它的文章。

几乎所有我看到的guid的视觉表示都使用了虚线格式。 在眼睛上更容易。

.NET的Guid类可以识别一系列不同的格式:破折号为分隔符,不带分隔符,括号作为分隔符,括号作为分隔符,不带分隔符等

连字符用于分隔每个数字

E93416C5-9377-4A1D-8390-7E57D439C9E7

 Hex digits Description 8 Data1 4 Data2 4 Data3 4 Initial two bytes from Data4 12 Remaining six bytes from Data4 

这只是为了方便。 GUID由16个字节组成,它们以hex文本表示forms组成32个字符。 没有连字符GUID很难被人类感知,难以被识别为GUID,而不是一些随机性的16字节数字。

如果你想在某个地方存储一个GUID,那么把它存储为一个16字节的数组,而不是它的文本表示。 您将节省大量的空间,并不会出现连字符的问题。

GUID实际上只是一个数字。 连字符显示了各种组件是如何分解的,但不是数字的一部分。 这就像一个IP地址 – 你可以存储一个32位的数字,或者你可以存储一个string的string,它们是等价的。

超级对于数值的唯一性或随机性绝对没有影响。 它们仅仅是从GUID的定义中保留下来的,并在视觉上将组成GUID的四个不同部分的数据分开。