来自 Win32 UuidToString() 调用的意外字符串
我有一个简单的类，它通过调用 CoCreateGuid() 生成 GUID。然后我将结果传递给 UuidToString()。
大多数时候我得到的字符串格式如下：
e0e3e4b5-6f13-4043-b6c6-488c8b85cbd1
但是，在一些机器上结果看起来像这样：
0-40:61:86:C2:4E:4F
谁能解释一下这种意想不到的行为？第二种形式是 GUID 吗？
更新：我找到了错误的根源，结果发现 UuidToString() 没有返回我认为的字符串。
感谢所有的答案。
I have a simple class that generates a GUID by calling CoCreateGuid(). I then pass the result to UuidToString().
Most of the time I get a string in the format:
e0e3e4b5-6f13-4043-b6c6-488c8b85cbd1
However, on a few machines the result looks something like this:
0-40:61:86:C2:4E:4F
Can anybody explain this unexpected behavior? Is the second form even a GUID?
UPDATE: I have found the source of the error and it turns out that UuidToString() is not returning the string I thought it was.
Thanks for all the answers.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
警告：这只是一个猜测！
您所拥有的内容看起来非常像 MAC 地址。
CoCreateGuid基本上使用UuidCreate。该用户可以使用计算机网络适配器创建本地唯一的 UUID。
我的猜测是，在这些机器上，它们的某些网络配置触发了“错误”或其他东西，因此返回了中间字符串。
您可以尝试直接使用
UuidCreate并使用RPC_S_UUID_NO_ADDRESS标志http://msdn.microsoft.com/en-us/library/aa379205(v=vs.85).aspx
Warning: This is only a guess!
What you have there looks very much like an MAC-Address.
CoCreateGuidbasically usesUuidCreate.That one can use the computers network adapter to create a locally unique UUID.
My guess is, that on these machines something of their network configuration triggers a "bug" or something, and therefore the intermediate string is returned.
You could try using
UuidCreatedirectly and using theRPC_S_UUID_NO_ADDRESSflaghttp://msdn.microsoft.com/en-us/library/aa379205(v=vs.85).aspx
严格来说，这两种形式都不是 GUID，因为 GUID 是 128 位数字，而不是字符串。我从未见过第二种形式，但我可以想象一种将其定义为有效的实现。通常 UuidCreate、UuidFromString 等是在 rpcrt4.dll 中实现的，但我想你可以有一个替代的实现。将字符串传递给 UuidFromString 并检查该函数的返回值。确保它与最初为您提供此可疑 GUID 的 UuidCreate 和 UuidToString 在同一 DLL 中实现。
Strictly speaking neither form /is/ a GUID because a GUID is a 128-bit number, not a string. I've never seen the second form but I can imagine an implementation where it would be defined as valid. Normally UuidCreate, UuidFromString etc. are implemented in rpcrt4.dll but I suppose you could have an alternative implementation. Pass the string to UuidFromString and check that function's return value. Be sure that it's implemented in the same DLL as the UuidCreate and UuidToString that gave you this suspicious GUID in the first place.
奇怪的。不过，RPC 是一个奇怪的 API，它非常古老，并且保留了大量的怪癖。我建议您改用 StringFromGUID2() 。有两种方法来完成同一件事总是一个明显的迹象，越晚越好。
Bizarre. RPC is an oddball API though, it's very old and quirks are heavily preserved. I'd recommend you use StringFromGUID2() instead. Having two ways to accomplish the same thing is always a telltale sign, later is better.