DocumentDB 自动生成的 ID：GUID 还是 UUID？哪个变体？
DocumentDB auto generated ID: GUID or UUID? Which variant?
TL;DR: DocumentDB 自动生成的 ID 应该是 GUID 还是 UUID，实际上有区别吗？如果它们是 UUID，那么 UUID 的 variant/version？
背景： 如果您不提供 ID，某些 DocumentDB 客户端库将自动为您生成一个 ID。我看到Azure blog and in several related questions that the generated IDs are GUIDs. I know there is some discussion over whether GUIDs are UUIDs里面提到了，很多人都说是。
问题： 但是，我注意到 DocumentDB 自动生成的一些 ID 不遵循 UUID RFC, which allows only the digits 1-5 in the "version" nibble (V in xxxxxxxx-xxxx-Vxxx-xxxx-xxxxxxxxxxxx). DocumentDB generates IDs with any hex digit in that nibble, for example d981befd-d19b-ee48-35bd-c1b507d3ec4f，其版本半字节是第一个 e 共 ee48。
这可能取决于使用哪个客户端创建文档。在我们的 DocumentDB 数据库中，我们有第三个分组 dde5、627a、fe95 等的文档。这些文档是通过使用选项 {'disableAutomaticIdGeneration': false} 调用 Collection.createDocument() 从存储过程中存储的。我通过第三方 DocumentDB Studio application always have 4xxx in the third grouping, which is a valid UUID version. However, documents that I create through the Azure portal 创建的其他文档具有非标准的第三方分组，例如 b359.
问题： 自动生成的 DocumentDB ID 应该是 GUID 还是 UUID，实际上有区别吗？如果是 UUID，那么是哪个变体？
查看 GitHub 上的源代码，我发现各种客户端和服务器端库使用几种不同的方法来创建他们所谓的 GUID（在某些库中）或 UUID (在其他图书馆）。
nodejs client, Javascript client, and server-side library 通过连接一系列十六进制数字和连字符来制造他们所谓的 GUID。请注意，这些是随机的，但不符合创建 RFC4122 版本 4 UUID 的规则。
Python client and Java client call their respective standard library methods 生成随机（版本 4）UUID。
可通过 NuGet, but the source code 获得的 .NET 客户端尚未发布。
总结：
- Microsoft 未在其客户端库中区分 GUID 和 UUID。他们互换使用这些术语。
- GUID/UUID 的效果取决于您在创建文档时使用哪个客户端库来调用 DocumentDB。
TL;DR: DocumentDB 自动生成的 ID 应该是 GUID 还是 UUID，实际上有区别吗？如果它们是 UUID，那么 UUID 的 variant/version？
背景： 如果您不提供 ID，某些 DocumentDB 客户端库将自动为您生成一个 ID。我看到Azure blog and in several related questions that the generated IDs are GUIDs. I know there is some discussion over whether GUIDs are UUIDs里面提到了，很多人都说是。
问题： 但是，我注意到 DocumentDB 自动生成的一些 ID 不遵循 UUID RFC, which allows only the digits 1-5 in the "version" nibble (V in xxxxxxxx-xxxx-Vxxx-xxxx-xxxxxxxxxxxx). DocumentDB generates IDs with any hex digit in that nibble, for example d981befd-d19b-ee48-35bd-c1b507d3ec4f，其版本半字节是第一个 e 共 ee48。
这可能取决于使用哪个客户端创建文档。在我们的 DocumentDB 数据库中，我们有第三个分组 dde5、627a、fe95 等的文档。这些文档是通过使用选项 {'disableAutomaticIdGeneration': false} 调用 Collection.createDocument() 从存储过程中存储的。我通过第三方 DocumentDB Studio application always have 4xxx in the third grouping, which is a valid UUID version. However, documents that I create through the Azure portal 创建的其他文档具有非标准的第三方分组，例如 b359.
问题： 自动生成的 DocumentDB ID 应该是 GUID 还是 UUID，实际上有区别吗？如果是 UUID，那么是哪个变体？
查看 GitHub 上的源代码，我发现各种客户端和服务器端库使用几种不同的方法来创建他们所谓的 GUID（在某些库中）或 UUID (在其他图书馆）。
nodejs client, Javascript client, and server-side library 通过连接一系列十六进制数字和连字符来制造他们所谓的 GUID。请注意，这些是随机的，但不符合创建 RFC4122 版本 4 UUID 的规则。
Python client and Java client call their respective standard library methods 生成随机（版本 4）UUID。
可通过 NuGet, but the source code 获得的 .NET 客户端尚未发布。
总结：
- Microsoft 未在其客户端库中区分 GUID 和 UUID。他们互换使用这些术语。
- GUID/UUID 的效果取决于您在创建文档时使用哪个客户端库来调用 DocumentDB。