如果链接包含多个点，composer 在第二个点之后就不知道如何处理了。像这个：
是 bug 还是 feature？
https://www.sell.fi/sites/default/files/elainlaakarilehti/tieteelliset_artikkelit/kahkonen_t._et_al.canine_pancreatitis-_review.pdf
我认为您使用了强调效果，将 canine_pancreatitis 写成了 像这样的文本。
1 个赞
第二个句点后的下划线导致了斜体。如果您将链接包装在 < 和 > 中，我认为它会正确显示：
<https://www.sell.fi/sites/default/files/elainlaakarilehti/tieteelliset_artikkelit/kahkonen_t._et_al._canine_pancreatitis_-_review.pdf>
4 个赞
每天都有新东西。我不知道下划线也能斜体。
所以……这是功能，不是 bug 
1 个赞
自动链接因 PDF 链接中的多个句点而感到困惑，并开始将后面的下划线读取为 markdown，这可能不理想？
但转义 <\\> 包装是一个很好的解决方法，如果你需要的话。
2 个赞
这是 @Vitaly 正在跟踪的一件事，这在很大程度上取决于这些问题的普遍程度。如果每百万个链接中只有 1 个出现问题，那么改进链接器就不值得；如果每 10 个链接中就有 1 个出现问题，那肯定值得。
4 个赞
这取决于。如果需要分享科学链接和pdf，就像在我的论坛上一样，几乎所有的链接都会被覆盖。否则，不那么频繁，但多于一个点也不是罕见的。
在我看来——有没有理由认为以 http:// 或 https:// 开头并以空格结尾不够，再加上允许的文件格式呢？
规则很复杂并且在不断变化。
链接器在没有 https:// 前缀的情况下也能工作，这增加了额外的复杂性。
我怀疑我们可以做些什么来放宽链接器对 https:// 前缀情况的行为，但这要由 Vitaly 来定夺。
1 个赞
这在某种程度上是我的观点 
好吧，我正在尝试教用户使用 < 和 >。这里最大的类似用户体验的问题是 Discourse 在很多情况下表现得与用户期望的差异太大。但这比仅仅尝试记住链接何时有效、何时无效要深奥得多。
这对我来说很有意义。我认为只链接裸主机名，并要求带有路径的 URL 包含 http 是可以的。
我已录制测试用例，但与之前基于强调的相同问题的可能性很高。
通常，所有带有 http(s):// 协议的链接都可以修复，我将很快开始处理（真的）。
模糊链接没有实际的解决方案（并且会为 ReDoS 打开大门）。但是，正如我多次说过的，此模式的附加值并不明显，并且由于许多副作用，默认情况下它是禁用的。我这样做只是因为其他软件包也提供了它。
1 个赞
我认为解决 http(s):// 的大小写问题将带来巨大的便利。
绝大多数人只是从浏览器的地址栏复制 URL，其中肯定包含协议。
1 个赞
确实如此。我不知道在没有协议的情况下链接有什么用例。
2 个赞
IMO 强制用户为这类链接键入 https:// 比处理模糊模式的副作用更简单。