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 回答