URLの//は何のためですか?[閉まっている]


39

通常、私が見たとき//、それは通常、http:またはのようなプロトコルプレフィックスに従っていますftp:。私はそれが他の場所に置かれたことを見たことがない。例えば、

http://www.google.com/

は典型的なURLです。

ただし、同じサイトの異なるバージョンを生成する次の2つの構文が見つかりました。

http://www.weather.com/

http://www.weather.com//

//プロトコル仕様以外は無効になると思っていたでしょう。驚いたことに、私は間違っていました。 同じサイトの異なるバージョンを放棄するエンディングについてはどう//ですか?

編集:

両方のリンクが同じページにリンクされるようになったため、そのサイトの誰かが他のサイトの風をつかんだはずです。


9
私が推測しなければならなかった場合、あなたがしているのは同じサイトを2回見ているだけですが、最後に余分な/が付いているものはCSSや最近の子供たちがウェブサイトをフォーマットするために使用するものを壊しています。:)
マークアレン

webmasters.stackexchange.comがこの質問に適している可能性があります。
Mehper C. Palavuzlar

1
@ MehperC.Palavuzlar振り返ってみると、はい。しかし、質問の時点で、私は範囲がそれが何であるかよりいくらか広いと思いました。
チャドハリソン

@MarkAllenまあ使用していることをノートにその面白い///////とURLの末尾には、同じサイトになった/ところは// なかった別の何かで結果を。
チャドハリソン

一方、二重バックスラッシュ(\\)は、Windowsの統一命名規則でよく見られます。たとえば、\\HostName[@Port]\SharedFolder\Resource
William C

回答:


67

先頭//はURL構文の一部です。ワールドワイドウェブの発明者はその間違い謝りました

本当に考えてみれば、二重スラッシュは必要ありません。ダブルスラッシュを持たないように設計することもできました。-World Wide Webの発明者であるTim Berners-Lee ir


末尾については//、実際には二重スラッシュではありません。最初のスラッシュは、ホスト名とパスを区切ります。最後のスラッシュパスです。Webサーバーは、必要に応じて/、空のパスとは異なるパスを処理できますが、明らかにweather.comのパスは処理します。これが偶然によるものなのか意図的なものなのかについては、それらについて尋ねる必要があります。


これは、Webルート以外のインデックスを検索するようにWebサーバーを構成できるためです。私の帽子はあなたに良いオフです。
チャドハリソン

http://example.comは違う扱いができると言っていますhttp://example.com/か?私はそれが最初のスラッシュの場合だとは思わなかった。
-DisgruntledGoat

1
@DisgruntledGoat いくつかのルールを使用して、はい、でき.htaccessます。しかし、おそらくそうすべきではありません。
マシュー

1
両方とも空のパスを持っているため、Webサーバーhttp://example.comと異なるものhttp://example.com/を扱うことはできません。ブラウザでは異なる方法で扱うことができます。
デビッドシュワルツ

3
ホストヘッダーを意識せずに、ゼロまたは1つのスラッシュは同じhttpリクエストに変換されます。GET / HTTP/1.1tools.ietf.org/html/rfc2616.html#section-3.2.3
SingleNegationElimination

19

最近では、ダブルスラッシュ役割を果たしていると主張することができます。Googleは(たとえば、安全なページから安全でないコンテンツを誤って呼び出すことを避けるために)このように、埋め込みリソース(スタイルシート、jsなど)からプロトコルを省略することを推奨します

<script src="//www.google.com/js/gweb/analytics/autotrack.js"></script>

そのため、このようなプロトコルなしのURLは完全なURLであり、相対URL(単一のスラッシュで始まる)ではないことが明らかになりました。


1
このスタイルは、「プロトコル相対」URL / URIと呼ばれます。SOにも同様の質問があります。
ヒッピートレール

1
これ以上お勧めしません。paulirish.com/2010/the-protocol-relative-url
lorond

13

実際に質問に答えるために、元の仕様は、プロトコルを与えたhttp:(またはおそらくftp:gopher:mailto:news:telnet:wais:file:またはprospero:)、その後// のURL(Uniform Resource Locator)構文が使用されていたことを示すために、その後、(必要に応じてで始まるホストuser:password@)、アドレス別の適切な開始/。これはRFC 1738で提案されました

インターネットが進化するにつれて、http:支配的なプロトコルになったため、ブラウザはプレフィックスhttp://がない場合はプレフィックスを追加する必要があると仮定しています。


3
あなたの答えは、URL以外の何かがプロトコルで一度に使用された可能性があることを示しているように思われ、//それが使用中であったことを示すため以外の何かを使用していました...そうですか?
イズカタ

3
@Izkata 80年代後半と90年代後半、インターネットが始まった頃、さまざまなアイテムにいくつかの異なる形式が提案されていました。URLはURNのサブセット(RFC 3305を参照)であり、これらはさまざまな形式、たとえばを持つことができますisbn:1-23-456789-12-3。実践ではhttp:、残りはURLであることを定義します。RFCは単なる提案であり、多くの場合、実現しない拡張を許可します。ある時点で、Tim Berners-Leeは、これ//は「サブネット」(例:)向けだと述べましたhttp:/govnet/whitehouse.gov。このアイデアは決して使用されませんでしたが、「//」は、多くのコードがそれを期待し、チェックするので、残ります。
StarNamer

1
@Izkata:通信プロトコルでURL以外のURNが使用されることはおそらくないでしょう。それが//の目的です。これは、リソースが検出される(場合によってはリモートの)ネットワークロケーションにアクセスするためにプロトコルが使用されていることを示します。他のデータ部分を持ち、//を使用しないURN たくさんあります(たとえば、ブラウザはおそらく「mailto:」を認識します)。参照:en.wikipedia.org/wiki/URI_scheme
KutuluMike

@MichaelEdenfieldまあ、それが今私が思っていることです。同じプロトコルを介して通信できる異なる何か-異なる使用が意図されたポイントがありました。粗製の例として、意図可能性が一度はためになっているhttp://www.google.com/http:%/74.125.225.97/有効であることの両方に、と//のような何か他の一方で、ホスト名を示す%/IPアドレスを示していますか?
イズカタ

1
そうは思いません。少なくとも、URLの代替階層スキームを持つドラフトドキュメント/例/などを見たことはありません。私の印象では、TBLはURLが実際のリソース(任意のデータではなく)を指していることを明らかにするために何かを望み、//を使用することでファイルのように見えるようになりました。私が見た他のスタイルのURNには、データ部分に特別な接頭辞がありません。一部のプロトコルはそれを許可します(たとえば、telnetやgopher と思います)が、http(s)のようなものを見たことはありません。
KutuluMike

1

Davidの受け入れられた答えに追加したいと思います。

ウェブの発明者の謝罪にもかかわらず、私は二重スラッシュ構文が重要な目的を果たしたと思います:視覚的に際立つことです。ダブルスラッシュを使用すると、ハイパーリンクなしでテキスト内のURLを視覚的に簡単に区別できます。ダブルスラッシュを見たとき、すぐにブラウザウィンドウに入力できると思った。@電子メールの送信に使用できます。その時代のプロトコル(ftp、telnet、gopher)がサーバーアドレスまたはリソースパス(ほとんど両方)を表す独自の奇妙な概念を持っていたWebへの移行段階では特に重要でした。ダブルスラッシュはURLの最も暗号化されていない部分であるため、ダブルスラッシュに関連するほとんどの問題は依然として存在します。ポート番号、パーセントエンコーディング、大文字と小文字の区別を考慮してください。しかし、http:something.comのようなURLを持つことは、私の例:something.comと簡単に混同される可能性があります。一方、http://を見ると、ダイヤモンドのように輝いています。ダブルスラッシュはWebシンボリズムの重要な部分であり、意図的ではないものの採用率も加速したと考えています。

また、AmigaOSがファイルパス構文を使用しているため、AmigaOSの仕事でファイル名とURLを区別しやすくなった可能性もありますvolume:path/to/destination。:)

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.