CouchDB 中的 UUID
我想知道 CouchDB 中默认表示的 UUID 格式。虽然 RFC 4122 描述了诸如 550e8400-e29b-11d4-a716-446655440000 之类的 UUID，但 CouchDB 使用诸如 3069197232055d39bc5bc39348a36417 之类的连续字符。我在他们的维基和文档中搜索了一段时间，这实际上是什么，但是没有任何结果。
您知道这是否是省略所有 - 的不符合 RFC 的格式，还是完全不同的 128 位表示形式。
背景是我正在使用 Java UUID，其格式如 RFC 中所述。我看到了 CouchDB 风格的优点，它可能更方便地构建内部树，但我想确保使用一致的实现。
I am wondering about the format UUIDs are by default represented in CouchDB. While the RFC 4122 describes UUIDs like 550e8400-e29b-11d4-a716-446655440000, CouchDB uses continuously chars like 3069197232055d39bc5bc39348a36417. I've searched some time in both their wiki and their documentation what this actually is, however without any result.
Do you know whether this is either a non RFC-conform format omitting all - or is this a completely different representation of the 128 bits.
The background is that I'm using Java UUIDs which are formatted as noted in the RFC. I see the advantage that the CouchDB-style is probably more handy for building internal trees, but I want to be sure to use a consistent implementation.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
从技术上讲，正如您所注意到的，我们不使用 uuid 的 rfc 标准。版本 4 uuid 保留了类似四位的内容来指定 uuid 的版本。我们也不使用其他实现中常见的连字符来格式化它们。
CouchDB uuid 是十六进制格式的 16 个随机字节。粗略地说，这是一个 v4 uuid，但不符合 rfc。
不管具体情况如何，在实践中确实没有太大问题。通常，除非您尝试进行某种带外分析，否则您不应尝试解释 uuid。 CouchDB 永远不会解释 uuid，我们只依赖其中涉及的随机性属性。
最重要的是不要担心它，只需将它们视为一代又一代的字符串。
Technically we don't use the rfc standard for uuids as you've noticed. Version four uuids reserve something like four bits to specify the version of uuid. We also don't format them with the hyphens that are generally seen in other implementations.
CouchDB uuids are 16 random bytes formatted as hex. Roughly speaking that's a v4 uuid but not rfc compliant.
Regardless of the specifics, there's really not much of an issue in practice. You generally shouldn't try to interpret a uuid unless you're trying to do some sort out-of-band analysis. CouchDB will never interpret uuids, we only rely on the properties of randomness involved therein.
Bottom line would be to not worry about it and just treat them as strings after generation.
KI 可以从文档网站提供一些 2019 年的参考：“在任何情况下，提供自己的 uuid 都是更好的选择”——https://docs.couchdb.org/en/latest/best-practices/documents.html?highlight=uuid
我遇到了这个问题，因为（爱好）数据库我正在尝试作为第一个编程任何东西，处理确实生成并使用4122兼容的uuids的应用程序，并且我正在咀嚼指甲，担心剥离“-”位并将它们重新检索。
在我意识到 couchdb 用作 doc _id 的 uuid 是一个字符串而不是数字之前... doh。因此，我使用应用程序创建对象时生成的 uuid 来 _id 文档。没有随机重复的 uuid。
K I can provide some 2019 reference from the doc site: "it's in any case preferable to provide one's own uuids" -- https://docs.couchdb.org/en/latest/best-practices/documents.html?highlight=uuid
I ran slap bang into this because the (hobby) db I'm attempting as a first programming anything, deals with an application that does generate and use 4122 -compliant uuids and I was chewing my nails worrying about stripping the "-" bits out and putting them back on retrieval.
Before it hit me that the uuid that couchdb uses as the doc _id is a string not a number... doh. So I use the app's uuid generated when it creates an object to _id the document. No random duplicated uuids.