2

我有一个 Web 应用程序，它使用如下所示的 URL：

http://library.example.com/Register.aspx?query=academic&key=586c70bb-5683-419c-aae9-e596af9ab66a

（使用 GUID 而不是普通的 int 来阻止猜测，这是我们现在所需要的。）

问题：通过电子邮件发送时，长 URL 经常中断。是人发送电子邮件，所以我无法控制格式。有时是发送电子邮件程序有问题，有时是接收程序有问题，但不管我花太多时间与人们讨论解决问题。

一切都必须来自这个域，所以我不能使用第三方缩短器。我可以主持自己的，但这似乎是一个杂项。

有什么建议么？

编辑

@Sunny：感谢您的详细说明，但我的情况与您的假设不同。公司客户（我的）将此 URL 传递给其员工，他们使用它来访问品牌注册页面。作为注册的一部分，他们需要提供工作电子邮件，然后将其转发给公司主管。

注册使他们能够访问数据库，但他们所看到的并不是企业客户特有的。所以偶尔的闯入者没什么大不了的；当他们被公司主管淘汰时，我们邀请他们订阅。

@Everybody：电子邮件破损不在标点符号 ( ?&=) 上，而是在某个预定的行长处。也让我吃惊。请注意，域名很长，虚拟目录的路径也很长，这是问题的一部分。

阅读回复后，我将使用 base64 作为伪缩短器，例如：

http://a.MyLongDomainName.com/?q=a&key=base64_encoded_GUID

……看看能不能活下来。谢谢大家。

4

7 回答 7

4

你至少可以缩短一点。现在，您将发送一个 GUID，它是一个 128 位的数字，其格式基本上是带有额外破折号的十六进制。如果您将 GUID 视为一个字节数组并将其转换为 Base64，您可以减少一点。同样，“query=academic”可以是“q=a”。

GUID 当前占用 36 个字符。转换为 Base-64 将其减少到 22 个，节省了 14 个字符。将“query=academic&key=”替换为“q=a&k=”会减少另外 13 个字符。尽管存在 & 和等号，但总共减少 27 个字符可能会使您的 URL 足够短而不会换行。

更多细节：Base-64 文本将以“=”结尾，然后将被十六进制编码为“%3D”。解决方案是切断该字符，因为它只是填充。

归功于原始海报，看起来最好的选择是以下几点：

  1. 带有 base-64 的紧凑 GUID。
  2. 缩短键名，如果可能，缩短值。
  3. 用尖括号包裹 URL 以鼓励客户端正确解析它。
  4. 如果可能，将键名替换为 URL 重写，使其看起来像一条路径。
于 2010-07-19T20:50:15.003 回答
2

如果您不能使用第三方 URL 缩短器，那么您唯一的选择（除了更改 URL 结构，正如 Sunny 建议的那样）是用尖括号括住您的 URL，如下所示：

<http://library.YourDomainNameHere.com/Register.aspx?query=academic&key=586c70bb-5683-419c-aae9-e596af9ab66a>

任何遵循统一资源标识符 (URI)：通用语法文档中的指南的电子邮件客户端都应该显示一个可点击的链接。但是，这不是一个万无一失的解决方案，您最终可能会求助于 URL 缩短服务或重组您的 URL。

于 2010-07-19T20:51:33.580 回答
1

安装您自己的缩短服务（这将是 IMO 的理想解决方案）的唯一替代方法可能是base64对整个 URL 进行编码（并使用更短的密钥）。但这会使字符串长度增加 33%（也很可能在电子邮件客户端中中断），并且看起来很丑。

我会构建一个 URL 缩短器服务，将 URL 按需缩短为如下所示：

http://library.example.com/go/586c70bb-5683-419c-aae9-e596af9ab66a
于 2010-07-19T20:48:20.430 回答
0

用 YouTube 风格的键替换 GUIDS 怎么样

例如http://library.example.com/Register.aspx?q=academic&k=jkGlkNu8

通过使用 base-64 字符串（而不是 base-16 的 Guid）并删除那些讨厌的破折号，您可以将相当多的唯一键打包到少量字符中。

于 2010-07-19T21:12:13.193 回答
0

那么这里描述的方法的组合呢？

将较短的 URL 与密钥的 Base64 编码结合起来会变成

http://library.example.com/Register.aspx?query=academic&key=586c70bb-5683-419c-aae9-e596af9ab66a

进入

http://l.example.com/register/ac/WGxwu1aDQZyq6eWWr5q2ag

更具可读性，IMO。并且缺少像 ? 和 & 降低了剪切粘贴错误的风险。

于 2010-07-19T21:12:44.270 回答
0

REST-ful url like:

http://www.yourdomainhere.com/register/academic/{userName_here}

might help IMO.

If the user is not registered, this will do it & return a message confirming the fact

If the user has already been registered, there will be no action & perhaps a notification that the user has been registered can be shown.

The routing of the URL and/or validating the request etc. can be implementation detail best left to a module looking at the request pipeline...

HTH.

EDIT:

As pointed out by @Steven below, there is an addition step involved in this solution:

When the user clicks on the REST URL, launch the confirmation/login screen with the user name pre-filled. The user can login to the account & this is confirmation that the user is valid. Till he does the first login, the status of the account can be "not confirmed" & at his first login, it can be "confirmed" without bothering if the click/request has come from the email sent and/or via a request in a web browser.

This will also ensure that it will work for authentic email account since till the user actually does a valid login, the account will not be in "confirmed" status...

于 2010-07-19T20:45:39.120 回答
0

There are some prepackaged URL Shorteners that you could host on your own. Here's a codeplex search
http://www.codeplex.com/site/search?query=url%20shortener
This will give you the ability to keep your short url's in house

Alternatively you could some how implement a RESTFul URL that would be a lot harder to screw up
http://library.example.com/Register/Academic/586c70bb-5683-419c-aae9-e596af9ab66a
This solution should work better than the querystring simply because what usually breaks in the email clients is the ?, the =, and the &

I personally think a RESTFul solution is best as it creates the cleanest urls that still make "some" sense.

于 2010-07-19T20:47:08.417 回答