21

または、それを「シャープ」と呼ぶかもしれません-＃記号。

あるインスタンスに出くわしました。＃！および＃単一のURLで同時に使用されます。RFCを含む他の記事を読んでも、それが合法的な組み合わせであるかどうかはわかりません。このようなページに遭遇すると、Mozillaブラウザ（この場合はIceweasel）はURLを2つの＃として表示しますが、Chromeは1つしか表示しませんが、すぐに停止します（ページを含むタブが応答しなくなり、クラッシュしますが、接続されていない可能性があります） 。

さて、私の質問は、両方を1つのURLに含めることは合法ですか、それは合法で冗長であるか（正規化する必要があります）、それともMozillaブラウザの単なるバグですか？それで、私がAJAXリクエストを行っている、またはブラウザの履歴をナビゲートしようとしていると仮定します-この状況に遭遇した場合、どうすればよいですか？

URLのダブルハッシュ

RFC-3986：https ://www.rfc-editor.org/rfc/rfc3986#section-3.4 、これはそれを明確にする必要があります...念のため。

また、https ： //developers.google.com/webmasters/ajax-crawling/docs/specificationGoogleクローラーが物事をどのように見るか。

4

3 に答える 3

19

フラグメントの形式では、スラッシュ、疑問符、およびpcharsのみが許可されます。RFCを調べると、ハッシュマークが有効ではないことがわかりますpchar。

window.location.hashただし、ブラウザは、 （IE、Firefox、およびChromeで）の値を確認することでわかるように、繰り返しハッシュをエスケープされているかのように処理することにより、無効なURLを読み取るために最善を尽くします。

http://www.example.com/hey#foo#bar

これは同じwindow.location.hashです

http://www.example.com/hey#foo%23bar
于 2012-06-01T13:15:52.990 に答える
4

私の答えは、少なくともRFC 3986を参照する場合は、明らかにノーです。しかし、3.4以上のものを見る必要があります

セクション3では、URIの構造を次のように定義しています。

     foo://example.com:8042/over/there?name=ferret#nose
     \_/   \______________/\_________/ \_________/ \__/
      |           |            |            |        |
   scheme     authority       path        query   fragment

（私はURLに関連する上部を取り上げました）

したがって、あなたの質問に答えるには、すべての部分を見る必要があります。

  • スキームにハッシュ記号を含めることはできません（のみALPHA *( ALPHA / DIGIT / "+" / "-" / "."）
  • オートリティにはハッシュが含まれていない可能性があり（ここでは詳しく説明しません）、'次のスラッシュ（ "/"）、疑問符（ "？"）、または番号記号（ "＃"）で終了します。
  • パス'は、スラッシュ（ "/"）文字で区切られた一連のパスセグメントで構成されます。パスセグメントは、pcharのみで構成できます。たとえば、この回答を参照してください。したがって、ここにハッシュはありません！また、'最初の疑問符（ "？"）または番号記号（ "＃"）、またはURIの終わりで終了します。
  • クエリ部分（最初の「？」で示される）は、pchar、「/」、または「？」のみで構成できます。'番号記号（ "＃"）文字またはURIの終わりで終了します。

したがって、少なくとも1つのハッシュを使用したい場合は、URIを終了することを除いて、これまでのところハッシュは許可されていません。

ついに：

  • フラグメントは、'番号記号（ "＃"）'の存在によって示され、pchar、 "/"、または "？"のみで構成されます。'URIの終わりで終了します'。

要約すると、準拠URL（またはURI）でURLフラグメントのマーカーとして許可される「＃」は1つだけです。特に、パス内にあるはずのハッシュ記号（少なくとも見た目からは、後でスラッシュがあるため）は、パス部分を正式に終了するため、問題があります。

これは、ハッシュ後のナビゲーションがサーバーではなくクライアント側で行われるため、これが使用されるシングルページアプリケーションなどで問題を引き起こす可能性があります。この場合、SPAは、受信時に残りのURLを正しく処理することを確認する必要があります。これには、（ブラウザー固有の）URLエンコードされたクエリとフラグメントが含まれる可能性があります。

于 2020-07-16T16:39:03.947 に答える
2

@apsillersが述べたようにそれは合法かもしれません。ただし、URLに関して特定の混乱を引き起こす可能性があるため、必要な場合を除いて、これは避けます。

そのようなURL：

http://www.example.com/hey#foo#bar

私には本当に混乱しているようで、通常のユーザーやおそらく検索エンジンにはさらに混乱するでしょう。

于 2012-06-01T13:26:28.760 に答える