DocumentDB自动生成ID:GUID还是UUID？哪个变种？

Question

TL; DR: DocumentDB自动生成的ID应该是GUID还是UUID,实际上有区别吗？如果它们是UUID,那么UUID的哪个变体/版本？

背景:如果您没有提供ID,某些DocumentDB客户端库将自动为您生成ID.我已经看到它在Azure博客中提到并且在几个 相关 问题中生成的ID是GUID.我知道有一些关于GUID是否是UUID的讨论,有很多人说它们是.

问题:但是,我注意到DocumentDB自动生成的一些ID不遵循UUID RFC,它只允许"version"半字节(Vin xxxxxxxx-xxxx-Vxxx-xxxx-xxxxxxxxxxxx)中的数字1-5 .DocumentDB与该半字节的任何十六进制数字,例如生成的ID d981befd-d19b-ee48-35bd-c1b507d3ec4f,其版本半字节是第一e的ee48.

这可能取决于使用哪个客户端来创建文档.在我们的数据库DocumentDB,我们与第三组文件dde5,627a,fe95,等等.通过Collection.createDocument()使用选项调用,这些文档存储在存储过程中{'disableAutomaticIdGeneration': false}.我通过第三方DocumentDB Studio应用程序创建的其他文档始终具有4xxx第三个分组,这是一个有效的UUID版本.但是,我通过Azure门户创建的文档具有非标准的第三组b359.

问题:自动生成的DocumentDB ID应该是GUID还是UUID,实际上是否存在差异？如果是UUID,那么哪个变种？

Answer 1

在GitHub的源代码中,我发现各种客户端和服务器端库使用几种不同的方法来创建他们称之为GUID(在某些库中)或UUID(在其他库中)的内容.

该的NodeJS客户端,JavaScript客户端和服务器端库制造什么,他们通过连接一系列的十六进制数字和连字符调用一个GUID.请注意,这些是随机的,但不符合创建RFC4122版本4 UUID的规则.

在Python客户端和Java客户端调用各自的标准库 方法生成随机(第4版)UUID.

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

摘要:

• Microsoft没有在其客户端库中区分GUID和UUID.他们可以互换地使用这些术语.
• 您获得的GUID/UUID取决于您在创建文档时使用哪个客户端库来调用DocumentDB.