相关：禁止LMGTFY链接|我们要垃圾邮件标志lmgtfy-links吗？ | URL Shorteners清理
禁止在问题/答案中使用URL短路服务。我有以下三个主要理由要求这样做：
隐藏LMGTFY-Links被滥用（有趣的是，此行为范围从20位代表新来者到50K用户）
用于内联链接，这会对可用性造成负面影响（我看不到链接将我带到何处）
它是用来代替正确格式的
根据ChrisF的要求，一些滥用示例（全部删除到现在为止）：
我需要将Mysql数据库转换为SQL Server 2005数据库
使DLL与所有数据库兼容是一个好主意
如何从Excel VBA宏生成XML？
对大整数计算库的建议。
从gmail导入电子邮件
13年8月19日更新：鉴于最近在多个SE网站上进行垃圾邮件攻击，我想建议对此重新考虑。
这些垃圾邮件攻击主要是由于垃圾邮件发送者可以隐藏在缩短的URL后面的事实（本文中的goo.gl案例），将其列入黑名单原始网址不可能。至少禁止最知名的服务将迫使垃圾邮件发送者使用其原始URL（或从整体上阻止攻击），从而更轻松地直接将其作为目标。
#1 楼
对我来说，这与尝试禁止骂人的话是一样的-这是一个从根本上来说是坏的坏主意。 -bad-idea-or-incredible-intercoursing-bad-idea.html对于我们检测到的每个请求（即使我们对每个未知URL都进行了非常昂贵的HTTP请求，这都是完全完全的
更好，更明智，更具可持续性的政策制定并使用标记来实施。顺便说一句，这与我们在网站上处理实际诅咒词的方式相同！
因此，就自动实施网址缩短器而言，我拒绝这样做。这是站不住脚的。但是，当然，我们鼓励人们标记隐藏的lmgtfy链接，我们将对其进行跟踪-政策是lmgtfy不允许，并且不会改变。
评论
短链接用于Twitter，而不是SO。
–艾米尔
2010-09-27 18:30
我实际上想改变我的看法，我喜欢使用短网址，因为这使我可以查看实际单击了链接的人数。
–艾米尔
10-10-23在12:47
@Emil似乎没什么用，因为大多数人都会单击，查看链接的位置并立即关闭。我至少会。虽然，通常我什至不去点击。
– Nikita Rybak
2011-02-20 23:23
/ may /是个不错的主意，当您拥有编辑权限时，请查看一个短链接，自己手动将其展开并更新编辑以反映链接目标。
–肯特·弗雷德里克（Kent Fredric）
2011-02-24 14:56
缩短的链接很短。如果链接较长，则跳过对较短的黑名单的匹配是非常好的启发。
–努比亚水手
13年13月13日在15:37
什么？ 99％的缩短链接来自10个服务，这是从反乌托邦的未来而写的，就本文而言，缩短链接的公司和框架疯狂地运转着。维护并不昂贵。
–djechlin
2013年12月14日15:15
还是使用鞭打来强制执行？不过，有些链接很长。如果只允许您在点击之前查看实际值的起酥油怎么办？例如，preview.tinyurl.com / _____
– WGroleau
2014-09-23 13:58
#2 楼
URL缩短器有变成断开链接的风险。我想说，我们应该制定一项政策，以阻止使用URL缩短器，并考虑禁止使用主要的URL缩短器。而是在提交帖子时实施代码以最终URL替换它们。这还将消除以下问题：有人将缩短的URL设置为有效来源，然后将其切换为垃圾邮件或更糟问题已经从首页上删除了。
评论
您不认为利比亚是一个好的顶级域名吗？ ;-)
– Arjan
2011年2月21日在10:15
@Arjan如果您忽略那里的当前动荡就很好了... centernetworks.com/libya-shuts-down-the-internet-domains
– Pollyanna
2011年2月21日在14:21
甚至在当前事件发生之前，.ly都撤销了域名。但是然后：也许更有可能服务会自行停止。我们中许多人还记得Tr.im。
– Arjan
2011-2-21在17:16
@Arjan Yep，当我刚开始引用当前的顶级问题时，现实情况是确实不能保证提供此类服务。如果您开始怀疑他们如何为服务器付费，那么您可能会开始更加认真地考虑其使用寿命。由于它们通常用于短暂的通信（聊天，推特等），因此它们可能不会将寿命放在高优先级，而且我什至已经看到有些服务开始重新分配url以保持总长度短，过期他们在90天左右之后。我认为它们不适合Stack Overflow打算使用的存储库。
– Pollyanna
2011年2月21日在18:00
（在写我的第一条评论和上面的笑脸时，我还没有听到今天利比亚的局势有多么令人难以置信的糟糕。非常非常悲伤。）
– Arjan
2011-2-21在22:55
@Arjan是的。与他们正在处理的服务相比，如果微不足道的互联网服务出现故障，可能会让我感到不便。
– Pollyanna
2011-2-22在0:47
“提交帖子后，用代码代替最终的URL来替换代码可能是值得的。” @Pollyanna您的500 Rep Bounty是否暗示您要有人为此类工作创建代码？
–未处理的异常
2011-2-23在13:14
@不，我的赏金是要再次提出这个问题，并要求杰夫重新考虑他的立场。
– Pollyanna
11年2月23日在14:17
@Pollyanna是的，发表评论后，我仔细检查了一些有关Mate Bounties的问题，以了解在此类问题上发布赏金背后的逻辑。
–未处理的异常
2011-02-23 14:42
@哦，我也将赏金用于许多其他事情...
– Pollyanna
2011-02-23 17:05
我也很高兴地注意到其他人也是如此:-)
–未处理的异常
2011-02-23 17:37
#3 楼
尽管我一时冲动拒绝投票，但我必须说我确实同意。当您以不可复制的方式共享短网址时，短网址当然具有优势。通过短信或电话，但由于这里不是这种情况，我全力以赴。特别是wrt3。评论
严重的是，如果一个人不知道[linktext]（http：//ur.l“ alt text”）语法来生成一个不错的链接，那么单击该超链接按钮有什么困难呢？
– Tobias Kienzler
2010-09-14 14:48
目前，评论只能发布600个字符。链接通常很长，例如当前页面的链接超过90个字符。 （实际上，许多链接的长度超过100个字符。）按可用性的观点，系统不应将url字符限制在600个字符的限制内。简短的URL是解决此问题的一个不错的选择。它还可以很好地解决url方案问题。
–起搏器
2014-09-24 11:58
@Pacerier实际上，对不计算URL字符的请求是一项很好的功能。 OTOH 600字符很多，并且在非元站点上的注释不应详尽无遗。在？之后可以去除许多URL的引荐和元内容。和＆s
– Tobias Kienzler
2014-09-24 12:01
确实，它已经被要求了，但是我不能打赌它将吸引很多人。如果不计算网址字符，则600个字符的限制可能是正确的。但是，如果我们包含URL字符，则其中包含多个链接的注释可能会超过600个字符，即使它们可能并不详尽。而且在很多情况下，元数据会在后面吗？和＆在链接中是必需的........................................... ...........................
–起搏器
2014-09-24 15:20
........例如。当我们想要链接到某个youtube视频的第45秒时，或者当我们想要链接到Google地图中的某个方向时。同样，在这些元内容是可选的情况下，没有多少人知道如何手动编辑网址以安全地将其删除，例如将此链接（401个字符）更改为其较短版本的364个字符。人们只需复制网址栏中的所有链接并将其粘贴。如果短网址被禁止，由于未链接的链接中总共有765个字符，因此此评论还需要完成一些帖子。
–起搏器
2014-09-24 15:21
#4 楼
自动阻止或重写可能永远不会发生。正如Jeff所指出的那样，这相当昂贵。但是，限制某些流行的特殊起酥油具有一定的教育价值。我们已经在Stack Overflow上进行了几个月的尝试，结果总体上是积极的。网站）：
bit.ly
goo.gl
adf.ly
这些内容仅在帖子主体中被屏蔽（与SO在任何地方都被屏蔽的情况不同）；我不想处理很多关于此的投诉，因为在300多个站点上更新规则可能会容易出错。希望这里的教育价值足够。
评论
如果有人尝试编辑包含在此更改之前添加的缩短URL的帖子，是否会提示他们删除该帖子，然后才能提交编辑？
–好奇号刺猬索尼克
18年7月22日在8:23
是的，系统会提示他们（我刚刚尝试过）。另外，似乎缩短的URL不仅在文本和超链接中被禁止，而且在代码块中也被禁止！为什么在代码中禁止使用它们？
–雷米·勒博（Remy Lebeau）
19年6月5日在19:36
我现在才能够绕过使用HTML实体的禁令，因此黑名单实际上是无用的。
–雷米·勒博（Remy Lebeau）
19年5月5日在19:44
#5 楼
虽然我同意这种观点（我讨厌长度不相关的使用url缩短服务），但我认为禁止它们不会有任何好处。此类服务有数十种，并且保持禁令列表的最新状态总是很麻烦。相反，我只建议我们鼓励所有具有编辑特权的人删除缩短的URL并替换掉带有完整链接。
评论
由于短网址始终会重定向，因此在发布该链接时可以通过简单的http请求检测到它们。这些东西的编辑监控确实有点麻烦...
– Tobias Kienzler
2010-09-14 14:50
关于禁令的好观点，但是托比亚斯的评论令人信服。
– Pops
2010-09-14在16:19
@Tobias：HTTP重定向有许多与缩短无关的和完全有效的用法，可能由发布到SO的链接触发，特别是如果有人从内存中键入内容（例如，许多站点将domainname.tld重定向到www .domainname.tld，反之亦然）。尝试自动检测它们需要AI。可悲的是，我的口袋里没有一个。 :(
–尼古拉斯·奈特
2010-09-14的16:51
@Tobias Kienzler：等一下，您是否只是因为我正在编辑搜索结果而将我称为猴子？ ;）
–时空旅行鲍比
2010-09-14 17:15
@Tobias：有趣的想法。服务器可以提交http请求，如果发生重定向，只需将URL直接替换为重定向结果。 @Nicholas：我认为有效使用重定向并不重要。服务器将自动替换URL，即使将dn.tld解析为www.dn.tld，也可以。当然，需要查看http请求的费用。可以在直接路径之外异步完成此操作，但仍会增加服务器负载。这可能取决于发布的URL数量。
–西蒙·史蒂文斯（Simon P Stevens）
2010-09-15在7:47
@鲍比：什么？哦，不！
– Tobias Kienzler
2010-09-15在8:12
@ Simon，@ Nicholas，这可能会变成一个不同的功能请求：“将重定向链接自动替换为其最终目的地（不包括SOFU的短固定链接）”。当然应该具有无限循环检测功能，并且如果发生超过5个重定向跳转，则拒绝发布
– Tobias Kienzler
2010-09-15 8:16
@Tobias Kienzler：@Jeff Atwood指出（作为对似乎消失的答案的评论），这将花费昂贵的HTTP-Roundtrip，他不愿意（我理解）。
–时空旅行鲍比
2010-09-15在8:34
#6 楼
正如ArchiveTeam所说，URL缩短器是WWW中的滴答作响。链接URL缩短器的答案或问题的价值要比包含完整URL的价值低得多。随时都有失去意义的风险，并且与不鼓励仅链接的答案的做法一致，因为链接目标可能会有所不同，因此不应鼓励此类URL。
类似地，Wikimedia项目已经阻止了URL缩短器在眼前。当然，有些工作了一段时间，但最终它们被阻止了。 SE已经禁止在示例中强制使用“ example.org”和朋友，因此为什么不对URL缩短器使用相同的功能？
此外，如果您关心此问题，请记住以帮助301Works.org和URLTeam（例如，通过在Wiki页面上添加更多缩短器并通过运行ArchiveTeam Warrior）。最后，现在不再是2010年，并且每个链接的HTTP请求都非常昂贵可以由Internet Archive的Archive-It服务执行，并从StackExchange的预算中提供少量资金，以确保长期保留每个链接（或至少保留从第一道防线中幸免一两天的链接）。 Internet档案馆每周保留十亿个网页。 :)
#7 楼
URL缩短器可用于链接到不同于http://或ftp://的架构； irc://，mumble://，steam://，mms://链接就是一个例子。由于我不希望将这些资源的链接以纯文本形式提供，所以我不希望URL缩短器被禁止。
某些URL缩短服务实际上阻止了缩小到非http：//模式的链接； TinyURL没有。
评论
解决这个问题的办法不是允许不同的（安全的）URL方案吗？而且我不确定用HTTP缩短器屏蔽非HTTP URL是否超出了上述滥用范围：人们期望他们将进入网页，而不是希望打开IRC客户端FTP浏览器或其他任何工具。
–user149432
2010-09-14 18:49
很好的一点。甚至还有专用的常见URL，例如tinyurl.com/aboutconfig，但是由于某些原因，我的Firefox不再支持该重定向...
– Arjan
2010-09-14在19:00
@Mark：发布上下文可以很好地改变您的期望；例如，“ SO有聊天室，[单击此处加入] [irc：//irc.freenode.org/stackoverflow/）”；祝您好运，将所有“良好”模式列入白名单。
– Badp
2010-09-14在19:25
@Markmeta.stackexchange.com/questions/71108/…
– Badp
2010-11-29 9:12
因此，应该允许使用URL缩短程序作为站点策略的变通办法？这些协议都是不需要的，因此这是禁止URL缩短的另一个原因。或需要他们，因此应将其列入白名单。协议白名单存在，并不难。
– Nemo
2015年5月4日，7：05
@nemo我们无法控制此站点上的协议白名单。
– Badp
2015年5月4日在7:11
@badp，是的，SE不是免费软件。但是，我不认为允许策略漏洞是制定灵活策略的好方法。我喜欢有道理的政策。 :)
– Nemo
2015年5月4日7:34
#8 楼
我同意维持URL缩短服务的规范黑名单是不可能的。用户可以根据需要找到解决方法。但是...我怀疑只有5-10％的使用短URL的用户会以恶意方式这样做。大多数人只是认为它们优于普通链接（无论出于何种原因），甚至可能会惊讶地发现我们在Stack Exchange上不喜欢它们。将30个顶级URL缩短网站列入黑名单。我们的目标是吸引那些无辜使用
http://goo.gl/...链接并需要提醒我们的用户，我们对此不满意。其余的人可能只是无辜地使用了晦涩的起酥油服务，与标记和什么不。实际的持续逃避者可能会面临主持人的公正审判。
不要仅仅因为无法实现100％而放弃该计划。争取达到90％，并对此感到满意！
评论
问题是，如果goo.gl被禁止，那么将有大量人使用它。这样做不好，因为尽管goo.gl链接可能具有将近99％的未来确定性，但替代链接的（将来）确定性会低得多，从而使我们的链接断开了。
–起搏器
2014-09-24 15:16
#9 楼
您对此有些迟，特别是在过去几个月左右的时间内，tinyurl.com / so-hints已经使用了很多次。这里的问题不是URL短服务，而是使用它们的人。禁止滥用帖子，禁止用户再次犯罪。不要禁用该工具。评论
-1，这里对这些工具的每次使用都是滥用。我们不在推特上；字符数限制为30,000。因此，使用起酥油没有任何好处。但是有缺点。除了混淆LMGTFY，还可以混淆某个站点，该站点运行的恶意脚本的链接显示为“请参阅此处的文档”。
– Pops
2010-09-14的16:08
我全都禁止使用工具。用户即工具。
– Peter Ajtai
2010-09-14 16:23
@Pops，缩短器有好处，如meta.stackexchange.com/questions/64450/…和meta.stackexchange.com/questions/64450/…所示
–起搏器
2014-09-24 15:24
#10 楼
多年后，状态已完成。至少在SO上。没有其他网站禁止该禁令，甚至没有本地化的SO网站（日语，俄语，葡萄牙语，西班牙语）。该解决方案没有追溯力，因此仍然有很多帖子使用这些链接缩短器（但除非您将其删除，否则将拒绝您的修改。）
我已开始按照删除帖子中的链接缩短器中的说明进行删除！阻止这些链接是一个好主意。他们中的许多人导致了不可逆的链接腐烂，有时甚至破坏了问题/答案。
我希望在其他站点上看到类似的内容，以防止出现类似的问题。
#11 楼
当无法使用常规链接时，我经常使用URL缩短。[示例] [1]：http://en.wikipedia.org/wiki/Closure_(computer_science）
当涉及到注释时，尤其是这样，我们必须使用[link]（url）语法。
示例：http://en.wikipedia.org/wiki/Closure_ （computer_science）
（注意括号）
评论
@Peter参见示例
– NullUserExceptionอ_อ
2010-09-14 15:16
当您用转义序列％29替换URL中的最后一个括号时，效果很好[en.wikipedia.org/wiki/Closure_(computer_science%29）。
– Pops
2010-09-14在16:17
@NullUserException-我删除了我的注释，因为我发现了URL缩短在注释中有用的原因<==我不能包括该URL而没有缩短。
– Peter Ajtai
2010-09-14 16:20
@Popular所以我应该开始记住html实体代码？
– NullUserExceptionอ_อ
2010-09-14在16:44
我知道这对评论很有用，这就是为什么我在请求中主要包含答案/问题的原因。但是，wiki链接的问题应报告为错误，恕我直言。
–时空旅行鲍比
2010-09-14在16:48
@null不，只需使用其他五种不同方式中的一种（裸剪切和粘贴除外）来包含URL，这些URL在parens中可以正常工作。参见meta.stackoverflow.com/editing-help
–杰夫·阿特伍德
2010-09-14在16:48
而且，今天可能有效的链接，过去可能无效。同样，我们如何确定没有错误会阻止任何人发布有效链接？在极少数情况下，我确实使用了URL缩短器，这总是由于某些Markdown渲染问题。
– Arjan
2010-09-14在18:00
顺便说一句：有关添加包含括号的URL的不同方法的概述，以及预览中当前已断开的URL的哪些方法，请参阅指向包含括号的URL的链接
– Arjan
2010-09-14在19:07
@空，不，我不建议这样做。我自己甚至都没有记住它，即使我之前看过多次记录该技巧，而且我喜欢这种链接语法。我花了五次努力才把它弄对，这样我才能写评论。除了您使用“不可能”一词而不是“非常烦人”之外，我不会提到它。从技术上讲，这并非不可能，我认为人们应该知道。
– Pops
2010-09-14 21:51
@Pops技术上％29与HTML无关，它是URL转义序列。从Firefox位置栏中粘贴粘贴地址时，括号已进行URL编码。除了手动键入URL以外，是否还会弹出文字括号？
– Palec
13年12月14日在18:40
@Palec关于术语的要点，我已修复。不知道第二个问题是怎么回事；也许三年前的情况有所不同？
– Pops
2013年12月14日22:35
@小伙子，我不这么认为。 IIRC这些天，浏览器仅用于在位置栏中显示转义序列。现在，它们显示已解码（在内部仍在使用编码版本）。但是我必须承认，除了Firefox以外，其他浏览器都具有一点经验。
– Palec
13年12月15日在1:56
#12 楼
我经常在评论中发布链接，这些链接指向特定文档的特定文档中的特定片段。这样的URL可能会很长，这严重限制了我可以在评论中添加的有用文本的数量。如果您禁止使用这些内容，那么也请找到一种使链接中的URL不计入评论长度限制。
下面的注释是一个构造而实际的示例（摘自我的这篇文章），该注释太长了10个字符，除非有人使用URL缩短服务：
如果要对SAX事件流进行
SaxSource，则可以使用从InputSource构造的transform。评论
这意味着[]（）语法中的链接地址不应计入注释长度。因为那是这里的重点。
–吗？
13年3月25日在10:22
@tohecz，是的，请参见meta.stackexchange.com/questions/64450/…
–起搏器
2014-09-24 15:25
@yo'是正确的。但是，该禁令可能仅限于答案和问题，没有长度限制，应长期使用。
– Nemo
2015年5月3日，10：57
我希望我可以投票赞成5次。
–詹姆斯·谢威（James Shewey）
17年1月12日在4:16
#13 楼
请取消禁止goo.gl缩短器。它仅对Google服务有效，因此它真的不能被滥用，并且它是获取可共享的Google Maps链接的唯一方法，这在Travel.SE上非常有用，特别是在提供方向或共享确切位置方面。评论
goo.gl似乎已关闭，因此取消禁止它毫无意义。仍然有大量的“坏”链接。
–影子向导正在接种疫苗
18-10-17在10:22
@ShadowWizard暂不对随机用户开放，但Google服务（例如Google地图）在共享时仍会生成goo.gl链接。这是现在生成的地图中的一个：goo.gl/maps/2GdZmA9tPrR2
–lambshaanxy
18-10-17在10:29
因此，也许将其作为每个站点的事情，例如无需在Travel以外的网站上进行此操作。
–影子向导正在接种疫苗
18-10-17在10:31
@jpatokal不过，您仍然可以获得并使用长链接。
–时空旅行鲍比
18-10-17在16:39
评论
您对第1点有何证据？@ChrisF我以前也看过。
@乔治：华夫饼的评论。是的，它是元数据，但这也是概念验证。
相关文章：[我们将垃圾邮件标记为lmgtfy-links吗？ ]（meta.stackexchange.com/questions/64453/…）
出于好奇，哪个50K主持人使用URL缩短器来隐藏LMGTFY链接？我是我所知道的那个范围内的唯一Mod，并且我有把握确定我从未在SO上发布过LMGTFY链接（但是我喝酒了，所以我想我有可能发布了一个忘了）。 >
@比尔蜥蜴：大概是5万，49或48。我想知道自己仍然对它进行了标记，并且现在找不到了。哦，对不起，我不是在这里谈论钻石，只是具有如此高声誉的普通用户。
@鲍比：哇！我对LMGTFY直言不讳，所以我为自己感到有些尴尬。 :)
好的，是什么阻止了我在数十个域之一中设置网址缩短器？还是我们如何跟上出现的新服务？
顺便说一句，非常感谢那些被标记的帖子。
@ M.NightDemonbobby您已在“鉴于最近的垃圾邮件攻击”中链接回此问题-这是有意的，还是您打算链接至其他帖子？
什么是“ LMGTFY”？您使用某种缩短句子的服务吗？ ;-)
@Spudley：等一下，让我用一个简单的链接来回答这个问题……；）现在您知道我们为什么讨厌它了……我希望。
@ M.NightDemonbobby-实际上我确实知道答案。使用首字母缩略词来描述由缩短URL引起的问题的讽刺意味，使我感到很有趣。因此，我的评论结尾很笑。 （也就是说，您发布链接很好，因为没有人会知道）
长网址不适合注释tinyurl.com/zaz9lha
@TonyStewart注释永远不应包含重要信息，仅用于澄清。并且，如果这样做，则应编辑问题/答案以包含该信息。