手动更改生成的GUID并使用它有多糟糕？碰撞的可能性是否仍然微不足道，或者操纵GUID是否危险？
有时我们只是更改以前生成的GUID的一些字母并使用它。我们应该停止这样做吗？
答案 0 :(得分：6)
这取决于GUID的版本以及您进行更改的位置。让我们分析一下GUID的实际情况：
GUID有一个版本。 GUID中的第13个十六进制数字标记其版本。当前GUID通常使用版本4生成。如果向后更改版本，则可能会与已存在的GUID发生冲突。将其向前更改，您可能会与潜在的未来GUID发生冲突。
GUID也有变体。 GUID中的第17个十六进制数字是变体字段。它的某些值保留用于向后兼容，一个值保留用于将来扩展。因此，更改某些内容意味着您可能会与先前生成的GUID或将来生成的GUID发生冲突。
GUID的结构取决于版本。版本4 GUID使用（大多数情况下除了第17个十六进制数字）真正的随机或伪随机位（在大多数实现中） pseuso随机）。改变那里的东西，你的碰撞概率大致相同。
对于使用哈希的版本3和5 GUID应该非常相似，尽管我不记得在野外看到过一个。不过，对于版本1和版本2而言并非如此。那些具有结构，并且取决于你改变某些事情的地方，你会使事情变得困难。
版本1 GUID包括时间戳和计数器字段，如果在同一时钟间隔内生成两个GUID，则计数器字段会递增（因此会导致相同的时间戳）。如果更改时间戳，则可能会在先前或稍后在同一台计算机上生成的GUID发生冲突。如果您更改计数器，则可能会与同时生成的GUID发生冲突，因此需要将计数器作为“uniquifier”。
版本2 GUID在版本1上展开并包含用户ID。时间戳不太准确，包含用户或组ID，而计数器的一部分用于指示哪一个是指（但它只对发电机有意义）。因此，如果对这些部分进行更改，则可能会与同一台计算机上的其他用户生成的GUID发生冲突。
版本1和2 GUID包含MAC地址。具体而言，是生成它们的计算机的MAC地址。这可确保即使在同一时刻生成，来自不同计算机的GUID也不同。如果机器没有MAC地址但没有唯一性保证，则会出现回退。 MAC地址也有一个结构，由一个“组织唯一标识符”（OUI;由IEEE本地管理或分发）和网卡的唯一标识符组成。
如果您在OUI中进行更改，则可能会与使用其他制造商的网卡的计算机中生成的GUID发生冲突。除非您进行更改，因此第一个八位字节的第二个最低有效位为1，在这种情况下，您将切换到本地管理的OUI，并且只冒与在具有被覆盖的MAC地址的计算机上生成的GUID发生冲突的风险（可能包括大多数具有虚拟网络硬件的虚拟机。）
如果您有可能存在卡标识符，则可能会与同一制造商在其他网卡的计算机上生成的GUID发生冲突，或者再次与MAC地址被覆盖的GUID发生冲突。
到目前为止还没有其他版本，但要点如下： GUID需要其所有部分以确保唯一性;如果你改变某些东西，你可能会得到一个不一定是唯一的GUID。所以你可能更多地使用GID或其他东西。最安全的改变可能是当前的版本4 GUID（这是Windows和.NET将生成的），因为它们并不真正保证唯一性，而是使它非常非常不可能
一般来说，我会说你在生成一个新的GUID方面要好得多。这也有助于阅读它们的人，因为如果它们看起来完全不同，你可以轻易地将两个GUID区分开来。如果他们只是一个数字不同，那么一个人可能会错过这一变化，并假设GUID是相同的。
进一步阅读：
答案 1 :(得分：0)
我不知道这会如何影响GUID的唯一性，但这可能不是一个好主意。
Visual Studio有一个内置的GUID生成器，需要几秒钟才能启动并创建一个新的GUID。如果你不使用VS，那么还有其他简单的方法来创建一个新的。 This page has 2 scripts（VB脚本和PHP）将完成这项工作并here's a .net version