3

我正在 ASP.NET 中创建一个网站，并希望能够拥有一个用户配置文件，该用户配置文件可以通过最后带有用户 ID 的 URL 访问。唯一标识符显然是一个糟糕的选择，因为它很长并且（如果我错了，请纠正我）不是真正的 URL 友好。

我想知道我是否在 ASP 页面上生成了一个唯一的标识符，然后使用 CRC（或类似的东西）对其进行哈希处理，如果它仍然像 GUID 一样唯一（甚至是唯一的）。

例如：

GUID 6f1a7841-190b-4c7a-9f23-98709b6f8848 等于 CRC E6DC2D44。

谢谢

4

9 回答 9

11

GUID 的 CRC 不会是唯一的，不是。否则，那将是一些很棒的压缩算法，能够将所有内容仅放入 4 个字节。

此外，如果您的用户使用 GUID 键存储在数据库中，您将很难找到与此特定 CRC 匹配的用户。

您最好使用普通的旧整数来唯一标识用户。如果您想让 URL 不可猜测，您可以将其与随机生成的第二个票据（或令牌）参数结合使用。它不必是唯一的，因为您使用整数 ID 来识别用户。您可以或多或少地将其视为密码。

于 2009-07-26T12:33:29.697 回答
3

任何计算出的散列包含的信息（位）都比原始数据少，并且永远不可能是唯一的。总是有碰撞。

于 2009-07-26T12:33:12.910 回答
2

如果用户有用户名，那么为什么不使用它呢？它应该是独一无二的（我希望！）并且可能很短且 URL 友好。用户也很容易记住，并且符合 ASP.NET 成员资格方案（因为用户名是成员资格提供程序中的“主键”）。我没有看到任何安全问题，因为（大概）只有经过身份验证的用户才能访问它，无论如何？

于 2009-07-26T13:49:53.873 回答
1

不，它不会那么独特，因为你会从中丢失信息。如果您将 32 个字符的十六进制字符串转换为 8 个字符的十六进制字符串，那么根据定义，您将丢失 75% 的数据。

您可以做的是使用更多字符来表示数据。guid 仅使用 16 个字符（以 16 为基数），因此您可以使用更高的基数（例如以 64 为基数），这样您就可以用更少的字符编码相同数量的信息。

于 2009-07-26T12:34:57.623 回答
1

我认为 HTTP URL 中的普通 GUID 没有任何问题。如果您想要简写形式的 Guid，请使用以下内容。

var gid = Guid.NewGuid().ToString("N");

这将给出一个没有任何连字符或特殊字符的 GUID。

于 2009-07-26T12:40:01.260 回答
1

GUID 是全球唯一的，这意味着您不会遇到冲突，希望永远不会。这些通常基于某种基于时间的计算，并插入了随机性。如果您想使用哈希来缩短某些内容，例如 CRC，那么它的唯一性不是自动的，但只要您自己管理自己的唯一性（检查哈希当前是否未分配给另一个用户，如果是，则重新生成直到你得到一个独特的）然后你可以使用几乎任何东西。

这是很多 url-shorteners 的工作方式。

于 2009-07-26T13:03:38.880 回答
0

如果您使用 UUID/GUID 的 CRC 作为 ID，您还可以首先使用较短的 ID。

UUID/GUID 作为 ID 的想法是 IMO，您可以在断开连接的系统上创建 ID，并且重复 ID 应该没有问题。

无论如何，谁会手动输入个人资料页面的 URL？

此外，我认为 UUID/GUID 的 URL 友好性没有问题 - 没有 http 不允许的字符。

于 2009-07-26T12:33:21.303 回答
0

如何在数据库（或您用来存储数据的任何其他地方）中识别用户？

如果使用此 GUID 识别它们，我会说，你有一个很好的理由，因为这使得搜索特殊 ID 变得非常复杂（即使使用二叉树）；还需要更多空间来存储这些值。

如果它们由唯一的整数值标识，为什么不使用它来调用用户配置文件？

于 2009-07-26T12:41:45.487 回答
0

您可以将 GUID 缩短为 20 个可打印的 ASCII 字符，它仍然是唯一的，并且不会丢失任何信息。

看看 Jeff Atwood 的这篇博文：
装备我们的 ASCII Armor

于 2012-02-19T14:38:42.270 回答