您何时真正被迫使用UUID作为设计的一部分？
我真的不明白UUID的意义。我知道发生碰撞的可能性实际上是nil，但实际上nil几乎不可能。
有人可以举一个例子，您除了使用UUID别无选择。从我所看到的所有用途中，我可以看到没有UUID的替代设计。当然，设计可能会稍微复杂一些，但至少它没有非零的失败概率。
对我来说，UUID闻起来像全局变量。全局变量可以通过多种方式来简化设计，但这只是懒惰的设计。
问题答案：
我为Ruby编写了UUID生成器/解析器，因此我认为自己对该主题有足够的了解。有四个主要的UUID版本：
从加密安全的随机数生成器中抽取的第4版UUID本质上只是16个字节的随机性，并且通过一些位纠缠来标识UUID版本和变体。这些冲突极不可能发生，但是如果使用PRNG或您碰巧碰到真，真的，真的，真的，真的很倒霉，有可能发生这种情况。
版本5和版本3 UUID分别使用SHA1和MD5哈希函数，以将名称空间与一段已经唯一的数据结合起来以生成UUID。例如，这将允许您从URL生成UUID。仅当基础哈希函数也有冲突时，才可能发生冲突。
版本1 UUID是最常见的。他们使用网卡的MAC地址（除非经过欺骗，否则应该是唯一的），时间戳记以及通常的比特级更改来生成UUID。如果机器没有MAC地址，则使用加密安全的随机数生成器生成6个节点字节。如果以足够快的顺序生成两个UUID，以使时间戳与先前的UUID相匹配，则时间戳将递增1。除非发生以下情况之一，否则不应发生冲突：MAC地址被欺骗；一台运行两个不同的UUID生成应用程序的机器在完全相同的时刻生成UUID。两台没有网卡或没有用户级访问MAC地址的机器都具有相同的随机节点序列，并在同一时刻生成UUID。
实际上，所有这些事件都不会在单个应用程序的ID空间中偶然发生。除非您接受整个Internet范围内的ID，或者在不受信任的环境中接受恶意的ID冲突，否则恶意个人可能会在ID冲突的情况下做一些不好的事情，除非您不必担心。至关重要的是要了解，在大多数情况下，如果碰巧生成与我相同的版本4 UUID，则没关系。我在与您完全不同的ID空间中生成了ID。我的应用程序永远不会知道碰撞，因此碰撞无关紧要。坦白说，在没有恶意行为者的单个应用程序空间中，即使在版本4 UUID上，即使在
另外，2 ^ 64 * 16是256艾字节。像这样，在单个应用程序空间中有50％的ID冲突机会之前，您需要存储256艾字节的ID。
-
问题内容： 我需要为数据库主键列生成唯一的Long ID。 我以为我可以使用 UUID.randomUUID（）。getMostSignificantBits（）， 但是有时它会产生一些负数，这对我来说也是个问题。 是否有可能仅从UUID生成正数长？会有数十亿个条目，因此我希望每个生成的键必须唯一。 问题答案： 之所以起作用，是因为当您按位与1进行操作时，它允许按原样传递同一位数字；当您按位与0进
-
问题内容： 我玩了一段时间，发现了一些有趣的东西： 现在，错误显而易见了，将列表转换为元组就可以像开始时一样正常工作： 现在，我的问题是：为什么第 一个参数必须是str或str前缀的元组，而不是 str前缀 的列表 ？ AFAIK，其Python代码可能如下所示： 但这让我更加困惑，因为即使记住了它，列表还是元组也应该没有任何区别。我想念什么？ 问题答案： 从技术上讲，没有理由不接受其他序列类型。
-
之前了解了： 创建Django项目 数据库 模板 表格提交 admin管理页面 上面的功能模块允许我们做出一个具有互动性的站点，但无法验证用户的身份。我们这次了解用户验证部分。通过用户验证，我们可以根据用户的身份，提供不同的服务。 一个Web应用的用户验证是它的基本组成部分。我们在使用一个应用时，总是从“登录”开始，到“登出”结束。另一方面，用户验证又和网站安全、数据库安全息息相关。HTTP协议是
-
我不能部署我的应用程序在一个真实的设备上它在模拟器上正常工作，我得到部署错误，但没有在错误选项卡。 这是来自生成输出 2>生成成功。 2> ============生成：1成功，0失败，1最新，0跳过===============部署：0成功，1失败，0跳过============= 即使卸载应用程序后，我无法部署我的应用程序在我的实际设备上，其他应用程序安装精细彻底的VS。
-
有可能吗？如果是，使用消息并将消息发送到数据库的简单方式可能不安全。