guid - DocumentDB 自动生成的 ID : GUID or UUID? 哪个变体？

Question

TL;博士: DocumentDB 自动生成的 ID 应该是 GUID 还是 UUID，实际上有区别吗？如果它们是 UUID，那么 UUID 的变体/版本是什么？
背景:如果您不提供 ID，某些 DocumentDB 客户端库将自动为您生成一个 ID。我在 Azure blog 中看到了它。并在 several related questions生成的 ID 是 GUID。我知道有 some discussion是否超过GUIDs是 UUIDs ，很多人说他们是。
问题:但是，我注意到 DocumentDB 自动生成的一些 ID 不遵循 UUID RFC ，它只允许“版本”半字节中的数字 1-5( V in xxxxxxxx-xxxx-Vxxx-xxxx-xxxxxxxxxxxx )。 DocumentDB 使用该半字节中的任何十六进制数字生成 ID，例如 d981befd-d19b-ee48-35bd-c1b507d3ec4f ，其版本半字节是第一个 e的 ee48 .
这可能取决于用于创建文档的客户端。在我们的 DocumentDB 数据库中，我们有第三组文档 dde5 , 627a , fe95 ， 等等。这些文档是通过调用 Collection.createDocument() 从存储过程中存储的。带有选项 {'disableAutomaticIdGeneration': false} .我通过第三方创建的其他文档 DocumentDB Studio申请总是有4xxx在第三组中，这是一个有效的 UUID 版本。但是，我通过 Azure portal 创建的文档有非标准的第三组，如 b359 .
问题:自动生成的 DocumentDB ID 应该是 GUID 还是 UUID，实际上有区别吗？如果是 UUID，那么是哪个变体？

Answer 1

翻阅 GitHub 上的源代码，我发现各种客户端和服务器端库使用几种不同的方法来创建它们所谓的 GUID(在某些库中)或 UUID(在其他库中)。

nodejs客户，Javascript client , 和 server-side library通过连接一系列十六进制数字和连字符来制造他们所谓的 GUID。请注意，这些是随机的，但不符合创建 RFC4122 版本 4 UUID 的规则。

Python client和 Java client调用各自的标准library methods生成随机(版本 4)UUID。

.NET 客户端可通过 NuGet 获得，但 source code尚未发布。

概括:

Microsoft 没有在其客户端库中区分 GUID 和 UUID。他们交替使用这些术语。

您获得的 GUID/UUID 取决于您在创建文档时用于调用 DocumentDB 的客户端库。