我有一个使用如下 URL 的 Web 应用程序：
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
...看看它是否仍然存在。感谢大家。
I have a web application which uses URLs that look like this:
http://library.example.com/Register.aspx?query=academic&key=586c70bb-5683-419c-aae9-e596af9ab66a
(The GUID is used instead of a plain int to discourage guessing, which is all we need for now.)
The problem: that long URL frequently breaks when sent via email. It's humans sending the emails, so I can't control the formatting. Sometimes it's the sending email program at fault, sometimes the receiving, but regardless I'm spending too much time on talking people through fixing problems.
Everything has to be from this domain, so I can't use a third-party shortener. I could host my own, but that seems like a kludge.
Any suggestions?
Edits
@Sunny: Thanks for elaborating, but my situation differs from what you assume. A corporate customer (of mine) passes this URL to its employees, and they use it to get to a branded Registration page. They need to give a working email as part of registration, and that gets forwarded to the corporate supervisor.
Registration gets them access to a database, but what they see is not specific to the corporate customer. So the occasional interloper is not a big deal; when they get weeded out by the corporate supervisor, we invite them to subscribe.
@Everybody: the email breakage is not on the punctuation (?&=), but at some predetermined line-length. Surprised me, too. Note that the domain name is long, as is the path to the virtual directory, which is a part of the problem.
After reading the responses, I'm going to use base64 as a pseudo-shortener, something like:
http://a.MyLongDomainName.com/?q=a&key=base64_encoded_GUID
...and see if that survives. Thanks to all.
发布评论
评论（7）
你至少可以缩短一点。现在，您将发送一个 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”。解决方案是剪掉该字符，因为它只是填充。
归功于原始海报，看起来最好的选择是以下几种方式的组合：
You can at least shorten it a bit. Right now, you're send a GUID, which is a 128-bit number, in a format that is essentially hexadecimal with extra dashes. If you view the GUID as a byte array and convert it to Base64, you can cut things down a bit. Likewise, "query=academic" could be "q=a".
The GUID is currently taking up 36 characters. Converting to Base-64 cuts this down to 22, saving 14 chars. Replacing "query=academic&key=" with "q=a&k=" shaves off another 13. Cutting a total of 27 characters may well keep your URL short enough not to wrap, despite the presence of ampersands and equal signs.
One more detail: the Base-64 text is going to end with an "=", which will then be hex-encoded into "%3D". The solution is to cut that character off, because it's just padding.
With credit to the original posters, it looks like the best bet is a combination of things:
如果您无法使用第三方 URL 缩短程序，那么您唯一的选择（除了更改 URL 结构，如 Sunny 建议的那样）就是用尖括号将您的 URL 括起来，如下所示：
任何遵循以下指南的电子邮件客户端统一资源标识符 (URI)：通用语法文档应显示可点击的链接。然而，这并不是一个万无一失的解决方案，您可能最终会求助于 URL 缩短服务或重组您的 URL。
If you can't use a third-party URL shortener, then your only option (besides changing the URL structure, as Sunny suggested) is to surround your URL with angle brackets, like this:
Any email client that follows the guidelines found in the Uniform Resource Identifiers (URI): Generic Syntax document should display a clickable link. This is not a fool-proof solution, however, and you'll likely end up resorting to a URL shortening service or restructuring your URLs.
安装您自己的缩短服务（在我看来这将是理想的解决方案）的唯一替代方案可能是对整个 URL 进行 Base64 编码（并使用较短的密钥）。但这会使字符串长度增加 33%（也很可能在电子邮件客户端中损坏），而且看起来很丑。
我会构建一个 URL 缩短服务，根据需要将 URL 缩短为如下所示：
The only alternative to installing your own shortener service (which would be the ideal solution IMO), may be
base64encoding of the whole URL (and using a shorter key). But that would increase string length by 33% (very likely to break in E-Mail clients as well), and look ugly.I would go with building a URL shortener service that shortens URLs on demand to something like this:
您可以自行托管一些预先打包的 URL 缩短程序。这是一个 codeplex 搜索
http://www.codeplex.com/site/search?query=url% 20缩短剂
这将使您能够将短网址保留在内部
或者您可以了解如何实现 RESTFul URL，这将更难搞砸
http://library.example.com/Register/Academic/ 586c70bb-5683-419c-aae9-e596af9ab66a
该解决方案应该比查询字符串更好，因为电子邮件客户端中通常会中断的是
?、=和&I个人认为 RESTFul 解决方案是最好的，因为它创建的最干净的 url 仍然具有“某些”意义。
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.
用 YouTube 风格的键替换 GUIDS 怎么样
？
http://library.example.com/Register.aspx?q=academic&k=jkGlkNu8通过使用 Base-64 字符串（而不是 Base-16 的 Guid）并删除那些讨厌的破折号，您可以将大量独特的键打包到少量的字符中。
How about replacing the GUIDS with YouTube style keys
e.g.
http://library.example.com/Register.aspx?q=academic&k=jkGlkNu8By using base-64 strings (instead of Guids which are base-16) and dropping those pesky dashes, you can pack a decent range of unique keys into a small amount of characters.
结合使用此处描述的方法怎么样？
将较短的 URL 与密钥的 Base64 编码相结合将变成
http://library.example.com/Register.aspx?query=academic&key=586c70bb-5683-419c-aae9-e596af9ab66a
进入
http://l.example.com/register/ac/WGxwu1aDQZyq6eWWr5q2ag
更具可读性，IMO。缺少像这样的字符？和&降低剪切和粘贴错误的风险。
What about a combination of the methods described here?
Combining shorter URLs with Base64 encoding of the key would turn
http://library.example.com/Register.aspx?query=academic&key=586c70bb-5683-419c-aae9-e596af9ab66a
into
http://l.example.com/register/ac/WGxwu1aDQZyq6eWWr5q2ag
Much more readable, IMO. And lack of chars like ? and & reduces the risk of cut'n'paste errors.
REST 式网址，例如：
http://www.yourdomainhere.com/register/academic/{userName_here}
在我看来可能有帮助。
如果用户未注册，这将完成&返回消息确认事实
如果用户已经注册，则不会有任何操作和信息。也许可以显示用户已注册的通知。
URL 的路由和/或验证请求等可以是实现细节，最好留给查看请求管道的模块......
HTH。
编辑：
正如@Steven 下面所指出的，此解决方案还涉及一个附加步骤：
当用户单击 REST URL 时，启动确认/登录屏幕，并预先填写用户名。用户可以登录该帐户并这是对用户有效的确认。在他第一次登录之前，帐户的状态可以是“未确认”和“未确认”。在他第一次登录时，可以“确认”，而不必担心点击/请求是否来自发送的电子邮件和/或通过网络浏览器中的请求。
这也将确保它适用于真实的电子邮件帐户，因为在用户实际进行有效登录之前，该帐户不会处于“已确认”状态......
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...