html <base>标签有哪些建议?


462

我从未见过 在任何地方实际使用过<base>HTML标记。使用它有陷阱吗,这意味着我应该避免使用它?

我从来没有注意到它在现代生产站点(或任何站点)上使用过的事实,这使我对此持反对态度,尽管似乎它可能具有用于简化我的站点上的链接的有用应用程序。


编辑

在使用基本标签几周后,我确实发现使用基本标签会引起一些重大麻烦,这使它比最初出现的要难得多。从本质上讲,更改以 意外的方式进行,因为它们在逻辑上将取决于默认行为。通常,这些更改是细微的,在处理大型代码库时会导致不那么明显的问题。此后,我创建了一个答案,详细说明了我在下面遇到的问题。因此,在您承诺广泛部署之前,请先亲自测试链接结果,这是我的新建议!href='#topic'href=''基本标签下是非常有它们的默认行为不兼容,并可以从默认行为,这种变化很容易使第三方库的控制之外非常不可靠<base>


12
它经常用在搜索引擎结果的缓存版本中,以保持链接正常运行。
Gumbo

11
只需注意:base标记还与简单的锚点交互,因此,如果您使用base,以前仅是页面上某个位置的锚点<a href='#anchor1'>Anchor1</a>也将使用base标记,覆盖了将当前页面引用为默认行为基地。因此,这绝对是要提防的事情(尽管可以通过在使用大量锚点的页面中使用另一个基本标签来解决此问题)。
卡扎伊2010年

1
如果您对接受的答案不满意,为什么不拒绝并重新分配它呢?
流行

1
当时还不知道这是一个选择,但是,是的,不想重复(如果它甚至给了我分数),但是我认为归根结底,弊大于利,并想强调一下。
卡扎伊2010年

2
通常,您不会查看所访问的每个主要站点的源代码。我相信正在使用的人<base>比您想象的要多。
Mathias Lykkegaard Lorenzen 2013年

Answers:


259

在决定是否使用该<base>标签之前,您需要了解它的工作原理,它可以用于什么以及其含义是什么,并最终超过了优点/缺点。


<base>标签主要简化了使用模板语言创建相对链接的过程,因为您不必担心每个链接中的当前上下文。

您可以例如

<base href="${host}/${context}/${language}/">
...
<link rel="stylesheet" href="css/style.css" />
<script src="js/script.js"></script>
...
<a href="home">home</a>
<a href="faq">faq</a>
<a href="contact">contact</a>
...
<img src="img/logo.png" />

代替

<link rel="stylesheet" href="/${context}/${language}/css/style.css" />
<script src="/${context}/${language}/js/script.js"></script>
...
<a href="/${context}/${language}/home">home</a>
<a href="/${context}/${language}/faq">faq</a>
<a href="/${context}/${language}/contact">contact</a>
...
<img src="/${context}/${language}/img/logo.png" />

请注意,该<base href>值以斜杠结尾,否则将相对于最后一条路径进行解释。


至于浏览器的兼容性,这仅会导致IE中的问题。该<base>标记在HTML中被指定为没有结束标记</base>,因此仅在<base>没有结束标记的情况下使用是合法的。但是IE6认为不是这样,整个内容<base>标签是放置在这样的情况下孩子的的<base>在HTML DOM树元素。乍一看,这可能会导致Javascript / jQuery / CSS中无法解释的问题,即,元素在特定的选择器(如中)完全不可访问html>body,直到您在HTML DOM检查器中发现两者之间应该有一个base(和head)。

常见的IE6修复程序使用IE条件注释来包含结束标记:

<base href="http://example.com/en/"><!--[if lte IE 6]></base><![endif]-->

如果您不关心W3验证程序,或者已经使用HTML5,则可以自行关闭它,每个Web浏览器都支持它:

<base href="http://example.com/en/" />

关闭 <base>标签也立即修复了疯狂 IE6的在WinXP SP3来请求<script>与相对URI资源src无限循环。

当您在<base>标记中使用相对URI (例如<base href="https://stackoverflow.com//example.com/somefolder/">或)时,还会出现另一个潜在的IE问题<base href="https://stackoverflow.com/somefolder/">。这将在IE6 / 7/8中失败。但是,这并非完全是浏览器的错。在<base>标签中使用相对URI 本身就是错误的。所述HTML4说明书指出,它应为绝对URI,从而开始与所述http://https://方案。这已在HTML5规范中删除。因此,如果仅使用HTML5和目标HTML5兼容的浏览器,则可以通过在<base>标记中使用相对URI来解决问题。


至于使用命名/哈希片段锚点()<a href="#anchor">,查询字符串锚点(例如)<a href="?foo=bar">和路径片段锚点(例如)<a href=";foo=bar">,使用该<base>标签,您基本上是在声明与之相关的所有相对链接,包括那些锚点。相对链接都不再与当前请求URI相关(就像没有该<base>标记一样)。首先,这可能会使初学者感到困惑。要以正确的方式构建这些锚点,您基本上需要包括URI,

<a href="${uri}#anchor">hash fragment</a>
<a href="${uri}?foo=bar">query string</a>
<a href="${uri};foo=bar">path fragment</a>

其中${uri}基本上转化为$_SERVER['REQUEST_URI']在PHP,${pageContext.request.requestURI}JSP中,并#{request.requestURI}在JSF。应该注意的是,像JSF这样的MVC框架具有标记,可以减少所有这些样板并消除对的需求<base>。另请参见使用什么URL链接/导航到其他JSF页面


BalusC,大约与我在此处写答案的同时,stackoverflow.com / a / 46539210/632951在此主题下,由多位作者发表了长达8年以上的10条以上的有用评论,详细介绍了有关<base>的信息。知道评论的链接已移至哪个主意吗?
Pacerier's

162

基本标签的效果明细:

基本标记似乎具有一些非直觉的影响,我建议您在了解结果之前,先对结果进行测试并亲自进行测试<base>!自从我发现它们之后尝试使用base标签处理具有不同url的本地站点并且仅在发现令人烦恼的影响之后,令我沮丧的是,我感到不得不为他人创建这些潜在陷阱的摘要。

<base href="http://www.example.com/other-subdirectory/">在以下情况下,我将使用一个基本标记:作为示例,并假装代码所在的页面为http://localsite.com/original-subdirectory

重大的:

除非明确指出,否则任何链接,命名的锚点或空白href都不会指向原始子目录:基本标记使所有链接都不同,包括指向基本标记url的同一页锚点链接,例如:

  • <a href='#top-of-page' title='Some title'>A link to the top of the page via a named anchor</a>
    变成
    <a href='http://www.example.com/other-subdirectory/#top-of-page' title='Some title'>A link to an #named-anchor on the completely different base page</a>

  • <a href='?update=1' title='Some title'>A link to this page</a>
    变成
    <a href='http://www.example.com/other-subdirectory/?update=1' title='Some title'>A link to the base tag's page instead</a>

通过一些工作,您可以通过明确指定这些链接链接到它们所在的页面来解决您可以控制的链接上的这些问题,但是当您将第三方库添加到依赖于标准行为的组合中时,它很容易造成大混乱。

次要:

要求有条件的意见IE6补丁:需要有条件的评论对IE6避免搞砸了DOM的层次结构,即<base href="http://www.example.com/"><!--[if lte IE 6]></base><![endif]-->BalusC在他的回答中提到以上。

因此,总的来说,除非您对每个链接都拥有完全的编辑控制权,否则主要问题就变得棘手了,而且正如我最初担心的那样,这使麻烦变得比其价值更大。现在,我必须开始重写它的所有用法!:p

使用“片段” /哈希时测试问题的相关链接:

http://www.w3.org/People/mimasa/test/base/

http://www.w3.org/People/mimasa/test/base/results


Izzy编辑:对于你们所有人,我都对我的评论感到困惑:

我刚刚对自己进行了测试,结果如下:

  • 斜线与否,使得在这里给出的实施例没有差别(#anchor?query将简单地被附加到指定的<BASE>)。
  • 但是,它对相对链接有所不同:省略尾部斜杠,other.htmldir/other.htmlDOCUMENT_ROOT给定示例开始于,/other-subdirectory被(正确地)视为文件并因此被省略。

因此,对于相对链接,BASE可以在移动的页面上正常工作-同时定位并?queries需要明确指定文件名(带有BASE斜杠,或者最后一个元素与所使用文件的名称不对应)。

可以将其视为<BASE>替换文件本身(而不是文件所在目录)的完整URL,这样您就可以正确处理。假设此示例中使用的文件是other-subdirectory/test.html(移至新位置后),则正确的规范应为:

<base href="http://www.example.com/other-subdirectory/test.html“>

-等瞧,一切都按预期工作:#anchor?queryother.htmlvery/other.html/completely/other.html


27

好吧,等一下。我认为基本标签不应该享有这个不良声誉。

基本标记的好处是,它使您可以轻松进行复杂的URL重写。

这是一个例子。您决定将http://example.com/product/category/thisproduct移到http://example.com/product/thisproduct。您更改.htaccess文件以将第一个URL重写为第二个URL。

有了基本标签后,就可以重写.htaccess了。没问题。但是,如果没有基本标记,则所有相对链接都会中断。

URL重写通常是必需的,因为调整它们可以帮助您的网站架构和搜索引擎可见性。没错,您将需要解决人们提到的“#”和“”问题的解决方法。但是基本标记在工具箱中应有位置。


10
在我看来,这个问题是面向未来的。如果在页面上使用基本标记,则与该页面交互的所有其他库都将受到基本标记的影响,包括可能依赖于裸锚标记或哈希的默认行为的第三方库。
Kzqai 2010年

4
@ Kzqai,+ 1分,但是很多网站没有使用有缺陷的库。问题不在于基本href,而是库,需要在此修复。
Pacerier,2014年

2
@Pacerier,我会说问题确实出在基本href上。或更确切地说,问题在于浏览器似乎不够灵巧,以至于根本无法影响以#开头的anchor href。我试图用javascript修复此问题,这导致使用href='#'链接的库(例如引导程序)出现问题。责备这些库就像责怪它们为HTML带来的其他所有错误。简单来说,它是完成现代工作的过时工具。
Deji 2015年

2
“以更少的麻烦来完成复杂的URL重写。” -尽管在这种情况下,base标签可以说是一种解决方法,因为它一开始就没有(正确地)使用相对于根的URL(甚至是绝对URL)。
MrWhite

@Deji,当我写“问题”时,我的意思是“错误”。是的,基本href的存在确实是一个真正的“问题”,但是在上述情况下,我是说该错误与基本href无关。(但是,不要一度认为我支持使用base href,确实,我的立场是当前版本的base href是无用的stackoverflow.com/a/46539210/632951。现在最好的方法是弃用它或启用多个base hrefs,因为它仅在可以使用多个时才有用)
Pacerier's

22

要决定是否应该使用它,您应该知道它的作用以及是否需要它。这个答案已经部分概述了,我也对此做出了贡献。但是为了使其更容易理解和遵循,这里进行第二个解释。首先,我们需要了解:

浏览器如何处理链接而不<BASE>使用它们?

对于某些示例,假设我们具有以下URL:

A)http://www.example.com/index.html
B)http://www.example.com/
C)http://www.example.com/page.html
D)http://www.example.com/subdir/page.html

A + B都导致将相同的文件(index.html)发送到浏览器,C当然发送page.html,而D发送/subdir/page.html

让我们进一步假设,两个页面都包含一组链接:

1)完全限定的绝对链接(http://www...
2)本地绝对链路(/some/dir/page.html
3)相连接,包括文件名(dir/page.html),和
4)用“段”相对链接仅(#anchor?foo=bar)。

浏览器接收页面,并呈现HTML。如果找到某个URL,则需要知道将其指向何处。对于链接1)来说总是很清楚的,它是按原样进行的。所有其他都取决于渲染页面的URL:

URL     | Link | Result
--------+------+--------------------------
A,B,C,D |    2 | http://www.example.com/some/dir/page.html
A,B,C   |    3 | http://www.example.com/dir/page.html
D       |    3 | http://www.example.com/subdir/dir/page.html
A       |    4 | http://www.example.com/index.html#anchor
B       |    4 | http://www.example.com/#anchor
C       |    4 | http://www.example.com/page.html#anchor
D       |    4 | http://www.example.com/subdir/page.html#anchor

现在什么样的变化 <BASE>被使用?

<BASE>应该替换出现在浏览器中的URL 。因此,它呈现所有链接,就好像用户已调出中指定的URL一样<BASE>。这解释了其他一些答案中的一些困惑:

  • 同样,“完全限定的绝对链接”(“类型1”)没有任何变化
  • 对于本地绝对链接,目标服务器可能会更改(如果指定的服务器<BASE>与最初从用户调用的服务器不同)
  • 相对网址在这里变得至关重要,因此您必须特别注意如何设置<BASE>
    • 最好避免将其设置为目录。这样做,“类型3”的链接可能会继续起作用,但是肯定可以中断“类型4”的链接(“情况B”除外)
    • 在大多数情况下,将其设置为标准文件名将产生所需的结果。

一个例子可以很好地说明

假设您要使用mod_rewrite以下网址“美化”某些网址:

  • 真实文件: <DOCUMENT_ROOT>/some/dir/file.php?lang=en
  • 真实网址: http://www.example.com/some/dir/file.php?lang=en
  • 用户友好的网址: http://www.example.com/en/file

假设mod_rewrite用于透明地将用户友好的URL重写为真实的URL(没有外部重定向,因此“用户友好的” URL保留在浏览器的地址栏中,而加载真实的URL)。现在做什么?

  • <BASE>指定:断开所有相对链接(因为它们将基于http://www.example.com/en/file现在)
  • <BASE HREF='http://www.example.com/some/dir>:绝对错误。dir会被视为指定URL 的文件部分,因此,所有相对链接都被破坏了。
  • <BASE HREF='http://www.example.com/some/dir/>:已经更好了。但是“类型4”的相对链接仍然断开(“情况B”除外)。
  • <BASE HREF='http://www.example.com/some/dir/file.php>:是的。一切都应该与此一起工作。

最后一点

请记住,这适用于文档中的所有 URL:

  • <A HREF=
  • <IMG SRC=
  • <SCRIPT SRC=

指的是您的最后一条记录...我很好奇..这是否还会改变jQuery ajax请求的解释方式。这与<SCRIPT SRC=
bkwdesign

@bkwdesign我不使用jQuery,但我认为是。
Izzy

@Izzy,重新“示例” 实际上,如果您将</some/dir/file.php?lang=en>美化为</ en / file>,那么您也想美化</ some / dir / page2?lang = en>和</ some / dir / script>到</ en / page2>和</ en / script>。因此,你的相对路径将工作就像他们应该
Pacerier

如何<BASE HREF='http://www.example.com/some/dir/file.php>使用“类型4”?是不是就像example.com/some/dir/file.php?foo=bar而不是example.com/subdir/page.html?foo=bar
ANewGuyInTown

@ANewGuyInTown是的,这就是应该的–在我的示例中http://www.example.com/some/dir/file.php为“真实位置”(请参见“示例对其进行了最佳说明”),并且仅传递一个片段(#anchor)只能在该位置解析。
Izzy

12

Drupal最初依赖<base>标签,后来由于HTTP搜寻器和缓存的问题决定不使用标签。

我通常不喜欢发布链接。但是,这确实值得分享,因为它可能会有益于那些希望通过<base>标签寻找现实世界体验的细节的人:

http://drupal.org/node/13148


该链接指向此答案的讨论已经进行了八年,所以现在已经差不多十年了。我认为,如果这仍然是一个问题,应该做更多的测试,而不是链接到这种可能不存在的问题的古老描述。
Sami Kuhmonen

没错,但恕我直言它仍然是一个大开眼界,以你需要的问题测试你的<base>基于执行打击,不只是你的锚在浏览器中运行。
Amr Mostafa 2015年

@AmrMostafa,只是不要使用基本href。
佩里耶

10

它使页面更易于离线查看;您可以将完全限定的URL放在base标记中,然后您的远程资源将正确加载。


@Erik,除了脱机查看之外,它还适用于所有需要演示另一个域页面的权宜之计的用例。例如,在jsfiddle上演示页面时,您可以使用base href来代替jsfiddle的域。¶尽管实际上说来,仅为此类权宜之计用例创建标记不是一个好的设计,因此应弃用并删除基本href,即使它对于此类权宜之计用例也很有用。
Pacerier's

5

当前,井号“#”可与基本元素一起用于跳转链接,但仅适用于最新版本的Google Chrome和Firefox,而非IE9。

IE9似乎导致页面被重新加载,而没有跳转到任何地方。如果在iframe的外部使用跳转链接,同时指示框架将跳转链接加载到框架内的单独页面上,则将获得加载到框架内部的跳转链接页面的第二份副本。


5

它可能不是很流行,因为它并不知名。因为所有主要的浏览器都支持它,所以我不会害怕使用它。

如果您的网站使用AJAX,则需要确保所有页面的设置都正确,否则您最终可能会获得无法解析的链接。

只是不要target在HTML 4.01 Strict页面中使用该属性。


实际上basetarget可能有用,但是basehref不是。确实,它没有流行是因为它没有。看到我的肛门。
Pacerier's

现在,所有浏览器都支持base标记。
Vitaly Zdanevich

3

对于页面中内联的SVG图像,base使用标记时会出现另一个重要问题:

由于有了base标记(如上所述),您实际上失去了使用相对哈希网址的能力,例如

<a href="#foo">

因为它们将根据基本URL而不是当前文档的位置进行解析,因此不再是相对的。因此,您必须将当前文档的路径添加到此类链接中,例如

<a href="https://stackoverflow.com/path/to/this/page/name.html#foo">

因此,看似积极的方面之一 base标签(这是将较长的URL前缀从anchor标签上移开,并获得更好的,较短的anchor)完全适得其反。

当在页面中内联SVG时,这是特别烦人的,无论是静态SVG还是动态生成的SVG,因为在SVG中可能有很多这样的引用,并且base在大多数(但不是全部)用户上,只要使用了标记,它们就会全部中断。代理程序的实现(在撰写本文时,Chrome至少仍可在这些情况下使用)。

如果您使用的是处理/生成页面的模板系统或其他工具链,我将始终尝试摆脱该base标记,因为如我所见,它给表带来的问题多于解决的问题。


不论是否使用SVG,基本标签都没有用,并被认为是有害的。详见我的阐述:stackoverflow.com/a/46539210/632951
Pacerier,

3

另外,您应该记住,如果您在非标准端口上运行Web服务器,则还需要在base href上包括端口号:

<base href="//localhost:1234" />  // from base url
<base href="../" />  // for one step above

2

我从来没有真正看到过使用它的意义。提供很少的优势,甚至可能使事情变得更难使用。

除非您碰巧有成百上千的链接,否则所有链接都指向同一个子目录。然后,它可以为您节省一些字节的带宽。

事后想想,我似乎记得IE6中的标记存在一些问题。您可以将它们放置在体内的任何位置,从而将站点的不同部分重定向到不同的位置。该问题已在IE7中修复,该网站破坏了很多站点。


3
好处可能不是节省带宽,而是使网址更简洁。不幸的是,事实证明,对所有链接的行为进行细微的改变确实是不值得的。
Kzqai 2010年

1
base标签是一些问题的解决方案。如果您没有问题,请不要使用base标签。示例:1.在不同系统中重用HTML内容。链接在内容中保持相对关系,并base设置了适当的标记(由CMS),因此,链接可以正确解析。2.现有站点始终使用相对URL,但后来决定实施“漂亮” URL,这会更改URL路径深度。甲base标签可以被视为优选的为“固定”的所有的相对URL。
怀特先生'17

@MrWhite,由于HTML 已经支持默认的相对路径,因此CMS无需使用基本标记即可正确解析链接。为当前文件夹的。参见此处的详细说明:stackoverflow.com/a/46539210/632951
Pacerier,

1
@Pacerier这取决于内容的位置(FWIW,我不是指WordPress等)。
怀特先生

@MrWhite通常,CMS首先不会使用静态链接,因此该示例有点奇怪。实际上,如今,很少有网站是使用静态HTML构建的。-我在那里可以看到您的观点,但是这些是现在基本上已经过时的问题的解决方案。(每个人和他们的祖父母都在使用WordPress或类似的工具。)
Atli


2

与AngularJS一起使用时,BASE标记无声地破坏了$ cookieStore,花了我一段时间才弄清楚为什么我的应用程序无法再编写Cookie。被警告...


1

要记住的一件事:

如果要开发要在iOS的UIWebView中显示的网页,则必须使用BASE标签。否则它将根本无法工作。就是JavaScript,CSS,图像-除非指定了标记BASE,否则它们都不能与UIWebView下的相对链接一起使用。

之前我一直被这个困扰,直到发现为止。


1

我找到了一种使用<base>和锚定链接的方法。您可以使用JavaScript保持链接#contact正常工作。我在一些视差页面中使用了它,并且对我有用。

<base href="http://www.mywebsite.com/templates/"><!--[if lte IE 6]></base><![endif]-->

...content...

<script>
var link='',pathname = window.location.href;
$('a').each(function(){
    link = $(this).attr('href');
    if(link[0]=="#"){
        $(this).attr('href', pathname + link);
    }
});
</script>

您应该在页面末尾使用


0

我的建议是不要<base>在管理URL路径中使用该元素。为什么?

它只是将一个问题换成另一个。没有基本元素,您就可以将任何喜欢的路径系统用于相对路径和链接,而不必担心它们会断开。在将基本元素设置为“锁定”路径的那一刻,您将设计所有URL来使用该路径,并且现在必须更改所有路径才能从基本路径开始工作。馊主意!

这意味着您现在必须编写更长的路径,并跟踪每个路径相对于该基准的位置。更糟糕.....当<base>他们使用该元素时,建议您使用完全限定的基本路径来支持旧版浏览器(“ https://www.example.com/ ”),因此现在您已将域硬编码到页面或使所有链接都取决于有效的域路径。

另一方面,从网站上再次删除基本路径的那一刻起,您现在又可以自由地使用较短的相对路径,它可以是完全限定的,可以使用来自根的绝对路径,也可以使用真正相对于路径的路径。文件和文件夹。它更加灵活。并且所有片段中最好的片段如“ #hello”都可以正常工作,而无需任何其他修复。同样,人们正在制造不存在的问题。

同样,上面的论点是使用基本URL来帮助您将网页的文件夹迁移到新的子文件夹位置,今天实际上并不重要,因为大多数现代服务器都允许您将任何子文件夹快速设置为任何域下的新应用程序根文件夹。Web应用程序的定义或“根”现在不受文件夹或域的约束。

整个辩论似乎有些愚蠢。因此,我说省略基本URL,并支持不使用它的较早的本机服务器-客户端默认路径系统。

注意:如果由于某些新的API系统而导致问题在于控制路径,则解决方案很简单...在您的API中对所有url和链接进行路径设置的方式要保持一致。不要依赖浏览器对base或HTML5或更新的马戏团技巧的支持,例如javascript API kiddy。只需对所有锚定标记进行一致的路径设置,就不会有问题。而且,无论使用什么路径系统,您的Web应用程序都可以立即移植到新服务器。

旧的又是新的!基本要素显然是关于尝试创建解决方案,以解决20年前Web世界中从未存在过的问题,而今天要少得多。


-1

基本href示例

用链接说一个典型的页面:

<a href=home>home</a> <a href=faq>faq</a> <a href=etc>etc</a>

.and链接到diff文件夹:

..<a href=../p2/home>Portal2home</a> <a href=../p2/faq>p2faq</a> <a href=../p2/etc>p2etc</a>..

使用base href,我们可以避免重复基本文件夹:

<base href=../p2/>
<a href=home>Portal2-Home</a> <a href=faq>P2FAQ</a> <a href=contact>P2Contact</a>

所以这是一个胜利。. 但是页面也经常包含差异基址的 URL,并且当前的网页每页仅支持一个基址href,因此,由于不正确的基址·被重复的基址重复出现,因此胜利很快就失去了,例如:

<a href=../p1/home>home</a> <a href=../p1/faq>faq</a> <a href=../p1/etc>etc</a>
<!--.. <../p1/> basepath is repeated -->

<base href=../p2>
<a href=home>Portal2-Home</a> <a href=faq>P2FAQ</a> <a href=contact>P2Contact</a>


结论

基本目标可能有用。)基本href无效,因为:

  • 页面同样是WET因为:
    • 默认库[–parent文件夹]⇌完美(除非不必要/罕见例外𝒞1𝒞2)。
    • 当前Web⇌不支持多个基本href

有关


可以肯定的是@downvoters不能解释basehref的用处,尤其是当整个行业广泛建议不要使用它时。
佩里耶
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.