文档数据库自动生成的ID：GUID还是UUID？哪个变体？

Question

TL;DR：由DocumentDB自动生成的ID应该是GUID还是UUID，它们之间有什么区别？如果它们是UUID，则是哪个变体/版本的UUID？

背景：如果您没有提供ID，一些DocumentDB客户端库将自动生成一个ID。我在Azure博客和几个相关的问题中看到有提到生成的ID是GUID。我知道有一些讨论关于GUID是否是UUID，很多人说它们是。

问题：然而，我注意到DocumentDB自动生成的一些ID并未遵循UUID RFC，该标准仅允许在“版本”半字节（V在xxxxxxxx-xxxx-Vxxx-xxxx-xxxxxxxxxxxx中）中使用数字1-5。DocumentDB生成的ID在该半字节中使用任何十六进制数字，例如d981befd-d19b-ee48-35bd-c1b507d3ec4f，其版本半字节为ee48中的第一个e。

这可能取决于用于创建文档的客户端。在我们的DocumentDB数据库中，我们有第三组dde5、627a、fe95等文档。这些文档是通过调用Collection.createDocument()并使用选项{'disableAutomaticIdGeneration': false}在存储过程内存储的。我通过第三方DocumentDB Studio应用程序创建的其他文档始终在第三个分组中具有4xxx，这是有效的UUID版本。但是，我通过Azure portal创建的文档具有非标准的第三组，例如b359。 问题：自动生成的DocumentDB ID应该是GUID还是UUID？如果是UUID，则是哪个变体？

- shoover

Answer 1

我在GitHub的源代码中查找，发现各种客户端和服务器端库使用几种不同的方法来创建所谓的GUID（在某些库中）或UUID（在其他库中）。 nodejs客户端、Javascript客户端和服务器端库通过连接一系列十六进制数字和连字符来制造所谓的GUID。请注意，这些是随机生成的，但不符合创建RFC4122版本4 UUID的规则。

Python客户端和Java客户端调用各自标准的库 方法来生成一个随机的（版本4）UUID。

.NET客户端可通过NuGet获得，但源代码尚未发布。

摘要：

• Microsoft在其客户端库中没有区分GUID和UUID。他们交替使用这些术语。
• 当您使用不同的客户端库调用DocumentDB创建文档时，所获得的GUID / UUID取决于您使用的客户端库。

- shoover