这样的GUID一定不会重复吗？真的是全球唯一吗？参与就有分

[cnvvv]

以下生成的GUID一定不会重复吗？真的是全球唯一吗？

header: objbase.h
lib:ole32.lib


GUID guid;
HRESULT hr = CoCreateGuid(&guid);

[shb80]

我觉得所有的回答都没有解决实际问题，COM规范本身没有约定要实现这样的函数，那么我们就抛弃COM看一下实现这个函数的官方（M$）的说法：CoCreateGuid(…)是调用RPC函数 UuidCreate（…）来产生一个全球唯一的（后来我们会看到它在Windows 2000中不能生成一个全球唯一的，因为这个函数先于Windows 2000，而后来2000出来后它也没对其更正－－这种错误M$是干过不少的）128位标识符，它只把UuidCreate（…）的返回值包装成了COM通用的HRESULT类型值。然后我们来看看UuidCreate（…），M$是这样说的：在Windows 2000中，UuidCreate（…）不再利用本机的 ethernet/token ring address 来生成uuid（在Windows NT 4.0, Windows 95, DCOM release, and Windows 98这些版本中都虑了 ethernet/token ring address，不再考虑的原因是：security ）。这样在同一台机器上产生的uuid之间也就没有什么联系了，同时M$也在Windows 2000实现了另一个函数UuidCreateSequential （…），它是考虑了本机的ethernet/token ring address。而M$自己的说法是如果没有 ethernet/token ring address产生的标识符只能保证在产生标识符的机器上是唯一的（很容易和其它没有ethernet/token ring address的机器产生的标识符冲突），但不能保证是GUID（全球唯一），也就是说不能用来标识将要发布的COM组件，所以说在Windows 2000中调用CoCreateGuid(…)产生的标识符不是全球唯一的（从理论上它就不是了）,只能叫uuid,而不能叫guid。在Windows 2000中要产生全球唯一的uuid,只能调用UuidCreateSequential （…）。

[Earthdog]

理论上是不会重复，但是如果你运气够背的话也有可能，我在公司的开发小组就遇到过一次，我们做的一个COM接口在我们的机器上用就一点事都没有，拿到有一台测试机上就出问题，后来，用VBScript写了一段代码来测试，结果输出的错误说该接口COM接口的CoClass已经有了，也就是我们生产的这个COM接口的CoClass的CLSID和那台机子上的某一个重了，我们重新生成了一个CLSID来使用结果就对了！

[iNothing]

你看，重复了吧：）

[sucker]

当然是
除非你copy

[sbsummer]

这个问题很愚蠢.

[iNothing]

CoCreateGuid(&guid);可能 n 年才会重复

但是谁能保证生成的guid系统中一定不存在呢？
因为系统中所有的guid并不是都由CoCreateGuid()产生的啊。
比如我在写一个WDM driver 的时候随便想到一个guid，就在自己的软件
中使用了，你能保证CoCreateGuid()不再使用这个id？

（不知这样理解对否？）

[duyanning]

杞人忧天,操这个心干吗?

[xunknown]

没有绝对！只有相对！

[otuotu]

理论上是地

[CaptainIII]

同意shb80

[arvid_gs]

up

[yidao]

偶然会重复，那就必然会重复，

唯物主义论中，偶然是必然的体现。

什么时间会重复呢？答案是.....3240年（我没查，不知道这个数字对不对）。

[qukai]

除非你刻意去把它弄的一样，不然这辈子你是看不到两个一样的GUID的

[Zark]

这个问题争论到最后怕是要超越编程的范围,上升到理论数学乃至哲学的领域中去了.

我们所说的"一定不会重复"是在常识范围的,是肯定有一定的误差的,比如说"一米倒底是多长",最后连巴黎的那个尺子也不够准确了,必须用幅射波长来定义,最后呢?薛定谔干脆来了个"测不准"定律.但在我们的生活中有几个人要用巴黎的那把尺来量今天买来的裤子长度是不是3尺2寸呢?又有谁会因老薛的"测不准",而无法准确地买到3尺2寸长的裤子呢?

楼主放心,GUID在大家的常识范围里是"一定不会重复"的.但假定有一天全球所有人的生命都系于某个GUID和某个GUID会不会重复的时候,我们一定不会再完全依赖这个GUID了.

[anson_program]

问的没有意义，答的更加没有意义，我说了这些没有意义的话，就是不想再看到没有意义的东西出现！

[maphy]

shb80说的是错的
根据MSDN, 不是不使用MAC地址了，而是使用新的算法，使得不能从UUID逆推出MAC地址，原因是为了安全性的考虑。

[once168]

理论和实际上重复可能性极小(两个同样IP,同一时间0.01s才可能〈还有版本信息>生成同一个ID）

但下面的重复却是有的,并且很讨厌:
如你开发了两种不同语种但同一版本的组件，当先后安装到同一台机上就会冲突（程序虽可运行,但可面目全非)
RichText控件就一个最好的例子(英文的显示不了汉字)

[shb80]

to maphy() :
说到MSDN,请理解一下函数UuidCreateSequential（…）的Remarks－－－
For security reasons, UuidCreate was modified so that it no longer uses a machine's MAC address to generate UUIDs. UuidCreateSequential was introduced to allow creation of UUIDs using the MAC address of a machine's Ethernet card.

[shb80]

to maphy() :
在MSDN中，你对In Windows 2000, the UuidCreate function generates a UUID that cannot be traced to the ethernet/token ring address of the computer on which it was generated理解得很好，可你没搞明白，UuidCreate（…）生成的UUID是怎么使得不能从UUID逆推出MAC地址的，是因为压根儿没使用 a machine's MAC address。
没搞明白请不要乱发表意见，这样很容易误导。

[shb80]

to maphy() :
还有一点，你也疏忽了，利用本机的MAC地址，目的无非是保证空间的唯一性，M$在Windows 2000中的函数UuidCreate（…）按你想的那样利用了MAC地址，只是采用一种新的算法而使得不可逆，我想问，新的算法根据唯一的MAC地址得到的结果是不是也是结果当中唯一的呢，如果不是又怎能达到当初利用MAC地址的目的，如果是你能算法而使得它不可逆吗？