html <base>タグの推奨事項は何ですか？

<base>HTMLタグが 実際にどこでも実際に使用されるのを見たことがありません。その使用に落とし穴がありますか？それは私がそれを避けるべきであることを意味しますか？

最近のプロダクションサイト（または他のサイト）で使用されていることに気づかなかったという事実は、私のサイトのリンクを簡略化するための便利なアプリケーションのように見えるかもしれませんが、私はそれを恐れています。

編集する

数週間ベースタグを使用した後、ベースタグを使用することで、最初に登場したときよりもずっと望ましくないいくつかの主要な問題を見つけました。基本的に、への変更href='#topic'およびhref=''ベースタグの下では、非常に自分のデフォルトの動作と互換性、およびデフォルトの動作から、この変更は簡単に外にあなたのコントロールのサードパーティのライブラリを作ることができる非常に信頼性がありません 論理的にデフォルトの動作に依存するため、予期しない方法で。多くの場合、変更は微妙であり、大規模なコードベースを処理するときに、すぐには明らかにならない問題につながります。それ以来、以下で経験した問題を詳しく説明する回答を作成しました。したがって、の広範な展開を行う前に、リンクの結果を自分でテストしてください。これ<base>が私の新しいアドバイスです。

<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>タグを閉じると、WinXP SP3上のIE6 の狂気も即座に修正<script>さsrcれ、無限ループ内で相対URIを使用してリソースをリクエストします。

あなたが相対URIを使用するときに別の潜在的なIEの問題が明らかになり<base>、タグのような、<base href="https://stackoverflow.com//example.com/somefolder/">または<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に関連する相対リンクはもうありません（タグなしでは発生します）。これはまず第一に混乱を招くかもしれません。これらのアンカーを正しく構築するには、基本的にURIを含める必要があります。<base>

<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>。他のJSFページにリンク/ナビゲートするために使用するURLも参照してください。

ベースタグの効果の内訳：

ベースタグには直感的でない効果があるようです。結果に気づき、自分でテストしてから<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の修正：DOM階層、すなわちを台無しに避けるために、IE6の条件付きコメントを必要<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.htmlとdir/other.htmlで開始するDOCUMENT_ROOT与えられた例で、/other-subdirectory（正しく）ファイルとして扱われ、従って省略されます。

したがって、相対リンクの場合BASE、移動されたページで正常に動作?queriesします。ただし、アンカーであり、ファイル名を明示的に指定する必要があります（BASE末尾のスラッシュ、または最後の要素が、使用されているファイルの名前に対応していません）。

これは、ファイル自体（およびファイルが存在するディレクトリではない）へ<BASE>の完全なURLを置き換えるものと考えれば、問題はありません。この例で使用されているファイルが（新しい場所に移動された後）であるとすると、正しい指定は次のようになります。other-subdirectory/test.html

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

-ら出来上がり、すべてが期待通りに動作します：#anchor、?query、other.html、very/other.html、/completely/other.html。

まあ、ちょっと待って。ベースタグはこの悪い評判に値するとは思いません。

ベースタグのいいところは、複雑なURLの書き換えを手間をかけずに行えることです。

ここに例があります。http://example.com/product/category/thisproductをhttp://example.com/product/thisproductに移動することにしました。.htaccessファイルを変更して、最初のURLを2番目のURLに書き換えます。

ベースタグを配置したら、.htaccessの書き換えを行います。問題ない。しかし、baseタグがないと、すべての相対リンクが壊れます。

URLの書き換えは、サイトのアーキテクチャと検索エンジンの可視性を向上させるために必要になることがよくあります。確かに、人々が言及した「＃」と「」の問題の回避策が必要です。ただし、ベースタグはツールキット内の場所に値します。

それを使用する必要があるかどうかを判断するには、それが何をするか、そしてそれが必要かどうかを認識する必要があります。これはすでにこの回答で部分的に概説されており、私も寄稿しました。しかし、理解と理解を容易にするために、ここで2番目の説明を行います。最初に理解する必要があります：

リンク<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>、ユーザーから最初に呼び出されたサーバーと異なる場合）
• ここでは相対URLが重要になるため、設定方法には特別な注意が必要です<BASE>。
  • ディレクトリに設定しないようにしてください。そうすることで、「タイプ3」のリンクは引き続き機能する可能性がありますが、「タイプ4」のリンクは確実に破られます（「ケースB」を除く）。
  • 設定し、完全修飾ファイル名、ほとんどの場合、所望の結果を生成します。

例はそれを最もよく説明します

いくつかのURLを使用して「かわいらしく」したいとしますmod_rewrite：

• 実際のファイル： <DOCUMENT_ROOT>/some/dir/file.php?lang=en
• 実際のURL： http://www.example.com/some/dir/file.php?lang=en
• ユーザーフレンドリーなURL： http://www.example.com/en/file

ユーザーフレンドリーなURLを実際のURL mod_rewriteに透過的に書き換えるために使用されていると仮定しましょう（外部リダイレクトがないため、「ユーザーフレンドリー」なURLはブラウザーのアドレスバーに残り、実際のURLはロードされます）。今何をする？

• <BASE>指定なし：すべての相対リンクを解除します（現在のリンクと同じですhttp://www.example.com/en/file）。
• <BASE HREF='http://www.example.com/some/dir>：間違いです。指定されたURLのファイル部分dirと見なされるため、すべての相対リンクは壊れています。
• <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=
• …

Drupalは最初は<base>タグに依存していましたが、後でHTTPクローラーとキャッシュの問題のために使用しないことを決定しました。

私は一般的にリンクを投稿したくない。しかし、これは<base>タグを使用した実際のエクスペリエンスの詳細を探している人に役立つ可能性があるため、共有する価値があります。

http://drupal.org/node/13148

オフラインでの閲覧が簡単になります。完全修飾URLをベースタグに入れると、リモートリソースが適切に読み込まれます。

ハッシュ「＃」は現在、base要素と組み合わせてジャンプリンクで機能しますが、IE9ではなく、Google ChromeとFirefoxの最新バージョンでのみ機能します。

IE9は、どこにもジャンプせずにページをリロードさせるようです。iframeの外側でジャンプリンクを使用していて、フレーム内の別のページにジャンプリンクを読み込むようにフレームに指示している場合は、代わりに、フレーム内に読み込まれたジャンプリンクページの2番目のコピーを取得します。

それはよく知られていないので、おそらくあまり人気がありません。すべての主要なブラウザーがサポートしているので、私はそれを恐れることはありません。

サイトでAJAXを使用している場合は、すべてのページでAJAXが正しく設定されていることを確認する必要があります。そうしないと、解決できないリンクが表示される可能性があります。

targetHTML 4.01 Strictページでは属性を使用しないでください。

ページにインライン化されたSVG画像の場合、baseタグが使用されたときに発生する別の重要な問題があります。

baseタグが付いているので（上記のように）、次のような相対ハッシュURLを使用する機能を事実上失う

<a href="#foo">

現在のドキュメントの場所ではなくベースURLに対して解決されるため、相対的ではなくなります。したがって、次のようなリンクに現在のドキュメントのパスを追加する必要があります

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

したがって、baseタグの見かけ上は肯定的な側面の1つ（長いURLプレフィックスをアンカータグから遠ざけ、より良い短いアンカーを取得すること）は、ローカルハッシュURLに対して完全に逆効果をもたらします。

これはあなたのページにSVGをインライン化する際にので、それは静的なSVGまたは動的に生成されたSVGも特に迷惑であるSVGが、そのような言及をたくさんすることができ、彼らはできるだけ早くすべて解除されますbaseほとんどで、タグが使用されている、すべてではなく、ユーザーエージェントの実装（Chromeは、執筆時点で少なくともこれらのシナリオで引き続き機能します）。

テンプレートシステムや、ページを処理/生成する別のツールチェーンを使用している場合、私は常にbaseタグを削除しようとします。

また、非標準ポートでWebサーバーを実行する場合は、base hrefにもポート番号を含める必要があることを覚えておいてください。

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

私は実際にそれを使用するポイントを見たことがありません。利点はほとんどなく、物事を使いにくくすることさえあります。

あなたがたまたま数百または数千のリンクを持たない限り、すべて同じサブディレクトリへのリンクです。その後、数バイトの帯域幅を節約できます。

後から考えると、IE6のタグに問題があることを思い出しているようです。それらを本文の任意の場所に配置して、サイトのさまざまな部分をさまざまな場所にリダイレクトできます。これは多くのサイトを壊したIE7で修正されました。

base-タグが使用されているサイトもあり、説明されている問題が発生しました。（jqueryをアップグレードした後）、次のようなタブURLを持つことで修正できました：

<li><a href="{$smarty.server.REQUEST_URI}#tab_1"></li>

これはそれらを「ローカル」にします

私が使用した参照：

http://bugs.jqueryui.com/ticket/7822 http://htmlhelp.com/reference/html40/head/base.html http://tjvantoll.com/2013/02/17/using-jquery-ui- tabs-with-the-base-tag /

AngularJSを操作すると、BASEタグが$ cookieStoreを黙って破り、アプリがcookieを書き込めなくなった理由を理解するのにしばらく時間がかかりました。注意してください...

覚えておくべきこと：

iOSのUIWebView内に表示されるWebページを開発する場合は、BASEタグを使用する必要があります。それ以外の場合は機能しません。JavaScript、CSS、画像である-タグBASEが指定されていない限り、UIWebViewの下の相対リンクでは機能しません。

私は気づくまでこれまでに捕まったことがある。

<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>

ページの最後に使用する必要があります

私の推奨は、<base>URLパスの管理にこの要素を使用しないことです。どうして？

ある問題を別の問題と交換するだけです。基本要素がなければ、相対パスやリンクに好きなパスシステムを使用して、壊れる心配はありません。すべてのURLをそのパスで機​​能するように「ロックイン」されているパスにベース要素を設定した分、ベースパスから機能するようにすべてのパスを変更する必要があります。悪いアイデア！

つまり、LONGERパスを記述し、各パスがこのベースからの相対位置を追跡する必要があります。悪いことに..... <base>要素を使用する場合、完全修飾ベースパスを使用して古いブラウザ（ " https://www.example.com/ "）をサポートすることをお勧めします。これで、ドメインをハードコード化してページまたはすべてのリンクを有効なドメインパスに依存させます。

一方、ウェブサイトからもう一度ベースパスを削除すると、完全に修飾された短い相対パスを使用できるようになり、ルートからの絶対パスを使用するか、またはあなたがいるファイルとフォルダー。はるかに柔軟です。そして、「＃hello」のようなすべてのフラグメントの中で最も優れたものは、追加の修正なしで正しく動作します。繰り返しになりますが、人々は存在しない問題を引き起こしています。

また、最近のほとんどのサーバーでは、任意のドメインの新しいアプリケーションルートフォルダーとしてサブフォルダーをすばやく設定できるため、ベースページのURLを使用してWebページのフォルダーを新しいサブフォルダーの場所に移行できるという上記の議論は、今日は重要ではありません。現在、Webアプリケーションの定義または「ルート」は、フォルダーまたはドメインのいずれによっても制約されていません。

この全体の議論はちょっとばかげているようです。だから私はベースURLを省いて、それを使用しない古いネイティブサーバークライアントデフォルトパスシステムをサポートすると言います。

注：問題が新しいAPIシステムによるパスの制御である場合、解決策は簡単です... APIですべてのURLとリンクをパスする方法に一貫性を持たせます。ブラウザAPIのベースやHTML5のサポート、またはJavaScript APIキディのように新しいサーカストリックに依存しないでください。すべてのアンカータグを一貫してパスするだけで、問題が発生することはありません。さらに、使用するパスシステムに関係なく、Webアプリケーションを新しいサーバーに即座に移植できます。

古いものはまた新しいです！基本的な要素は、20年前にはWebワールドに存在しなかった問題の解決策を作成しようとすることです。

ベースhrefの例

リンクのある典型的なページを言う：

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

。およびdiffフォルダーへのリンク：

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

ではベースHREF、我々は避けることができ、繰り返しを基本フォルダをINGの。

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

したがって、それは勝利です.. しかし、ページには、ベースを比較するためのURLが含まれていることがよくあります。現在のWebは、ページごとに1つのベース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>

（Baseターゲットは役に立つかもしれません。）Base hrefは次のように役に立たないです：

• ページは次の理由で同様に濡れています：
  • デフォルトのベース[–親フォルダー]⇌完全（不要/まれな例外𝒞1および𝒞2を除く）。
  • 現在のWeb⇌サポートされていない複数のベースhref。

関連した

• Apache∙rewriteベースとの比較