DocumentDB自动生成的ID：GUID或UUID？ 哪个变种？
TL; DR： DocumentDB自动生成的ID应该是GUID还是UUID，实际上有区别吗？ 如果它们是UUID，那么UUID的哪个变体/版本？
背景：如果您没有提供一个DocumentDB客户端库，某些DocumentDB客户端库将自动为您生成一个ID。 我已经看到它在Azure博客和几个相关问题中提到过，生成的ID是GUID。 我知道有一些关于GUID是否是UUID的讨论，有很多人说他们是。
问题：不过，我注意到，有些ID的那个DocumentDB自动生成不遵循RFC UUID，只允许数字中的“版本”半字节（1-5 V在xxxxxxxx-xxxx-Vxxx-xxxx-xxxxxxxxxxxx ）。 DocumentDB使用该半字节中的任何十六进制数字生成ID，例如d981befd-d19b-ee48-35bd-c1b507d3ec4f ，其版本半字节是ee48的第一个e 。
这可能取决于使用哪个客户端来创建文档。 在我们的数据库DocumentDB，我们与第三组文件dde5 ， 627a ， fe95 ，等等。 这些文档是通过使用选项{'disableAutomaticIdGeneration': false}调用Collection.createDocument()从存储过程中存储的。 我通过第三方DocumentDB Studio应用程序创建的其他文档在第三个分组中始终具有4xxx ，这是一个有效的UUID版本。 但是，我通过Azure门户创建的文档具有非标准的第三组，如b359 。
问题：自动生成的DocumentDB ID应该是GUID还是UUID，实际上有区别吗？ 如果UUID，那么哪个变种？
在GitHub上的源代码中，我发现各种客户端和服务器端库使用几种不同的方法来创建它们调用GUID（在某些库中）或UUID（在其他库中）。
nodejs客户端，Javascript客户端和服务器端库通过连接一系列十六进制数字和连字符来制造他们称之为GUID的内容。 请注意，这些是随机的，但不符合创建RFC4122版本4 UUID的规则。
Python客户端和Java客户端调用它们各自的标准库方法来生成随机（版本4）UUID。
.NET客户端可通过NuGet获得，但源代码尚未发布。
概要：
上一篇: DocumentDB auto generated ID: GUID or UUID? Which variant?