以 // 开头的 URL 是否有效？

Question

我们可以看到许多HTML页面使用 src="//example.com/myjavascript.js" 来引入一个.js文件并让浏览器使用http:// / https://code>根据当前页面URL的方案。

这是一个有效的URI吗？

- toutpt

---

请参见https://dev59.com/v3I-5IYBdhLWcg3wF0Qc。 - koppor

可能是重复的问题：以两个斜杠开头的URI的行为是什么？ - Enigmativity

Answer 1

是的，它绝对有效。 这是一个“协议相对” URI。从一开始就在规范中。对于处理 http/https 问题非常有帮助。

阅读更好的描述和注意事项： 是否可以在 <script src="http://..."> 中用 // 替换 http://？

需要注意以下几点：

• 在 IE 7 和 8 上会出现一些小问题，会导致文件双重下载
• 如果您从文件查看 HTML 页面，则浏览器将使用 file:// 替换方案，并且不会像使用以 http:// 或 https:// 开头的完整 URL 时那样从服务器加载 JS 文件。

针对现代 Web 开发实践进行编辑：

虽然这个 URL 仍然有效，但现在建议使用 https 来获取第三方资源（并从安全页面提供这些资源）。由于更新的协议和浏览器，以前的性能或兼容性问题已基本解决。

- Adam B

---

感谢 @Adam 的澄清，我已经从问题中删除了我的评论 - 如果你不小心的话，每天都会学到新东西。 - freefaller

Answer 2

作为警告...我们发现在HTML BASE标签中使用此方法时，Internet Explorer不支持（已确认IE8和9，修补问题前没有测试其他版本）。

在网站上新实施SSL后，我们最初更新了整个应用程序中的BASE标签，只是简单地引用“//www.mydomain.com”：但页面模板（仅在IE中）破裂了，所有脚本都没有位于站点根目录下。这很有道理，因为BASE标签没有捕捉到样式表或其他相对链接资源，这些资源假定它们是从根目录而不是嵌套位置引用的。

由于BASE URI是我们自己的域名，我们通过将BASE标签的值设置为“https://www.mydomain.com”来解决了这个问题。无论客户端是在SSL模式还是不在SSL模式下浏览网站，至少现在可以跨浏览器工作，并且始终可以找到其内容-通过强制始终使用https，我们确保在使用https浏览页面时不会收到任何内容不匹配的警告。

- Dave McHale

Answer 3

确实是有效的，我刚刚通过艰难的方式学到了这一点！！我们破坏了一个定制功能，因此您应该始终像这样验证URL（在.NET中）： 请注意：

• White spaces (Trim)

• "scheme relative" URI (UriKind.RelativeOrAbsolute)

  public bool IsValidUrl(string resourceUrl)
  {
      Uri uri;
      if (Uri.TryCreate(resourceUrl.Trim(), UriKind.RelativeOrAbsolute, out uri))
      {
          return uri.IsWellFormedOriginalString();
      }
  
      return false;
  }
  

- Major