Trong một URL, // để làm gì? [đóng cửa]

39

Thông thường, khi tôi thấy //, nó thường theo một số tiền tố giao thức như http:hoặc ftp:. Tôi chưa bao giờ thấy nó được đặt ở bất cứ nơi nào khác. Ví dụ,

http://www.google.com/

là một URL điển hình.

Tuy nhiên, tôi đã tìm thấy hai cú pháp sau để mang lại các phiên bản khác nhau của cùng một trang,

http://www.weather.com/

http://www.weather.com//

Tôi đã nghĩ rằng //bất cứ nơi nào khác ngoài đặc tả giao thức sẽ không hợp lệ. Thật ngạc nhiên, tôi đã sai. Điều gì về cái kết //mà các bạn có một phiên bản khác nhau của cùng một trang web?

CHỈNH SỬA:

Ai đó ở trang đó chắc chắn đã bắt được gió của người kia vì cả hai liên kết giờ đều nằm trên cùng một trang.

url syntax uri

— Chad Harrison
nguồn

9

Nếu tôi phải đoán, tất cả những gì bạn đang làm là nhìn thấy cùng một trang web hai lần, nhưng trang web có thêm / cuối cùng đang phá vỡ CSS hoặc bất cứ thứ gì trẻ em ngày nay sử dụng để định dạng trang web của chúng. :)

— Mark Allen

webmasters.stackexchange.com có thể phù hợp hơn cho câu hỏi này.

— Mehper C. Palavuzlar

1

@ MehperC.Palavuzlar Nhìn lại, vâng. Nhưng tại thời điểm của câu hỏi, tôi nghĩ phạm vi có phần rộng hơn so với những gì nó là.

— Chad Harrison

@MarkAllen Vâng thú vị của nó để lưu ý rằng việc sử dụng ///hoặc ////vào cuối URL dẫn các trang web giống như /nơi // đã dẫn đến một cái gì đó khác nhau.

— Chad Harrison

Trong khi đó, dấu gạch chéo kép (\\) thường thấy trong Công ước đặt tên thống nhất của Windows, ví dụ:\\HostName[@Port]\SharedFolder\Resource

— William C

67

Hàng đầu //là một phần của cú pháp URL. Các nhà phát minh của web trên toàn thế giới đã xin lỗi vì sai lầm đó .

Thực sự, nếu bạn nghĩ về nó, nó không cần dấu gạch chéo kép. Tôi có thể đã thiết kế nó để không có dấu gạch chéo kép. - Ngài Tim Berners-Lee, nhà phát minh web trên toàn thế giới

Đối với dấu vết //, nó thực sự không phải là một dấu gạch chéo kép. Dấu gạch chéo đầu tiên tách tên máy chủ khỏi đường dẫn. Dấu gạch chéo cuối cùng là đường dẫn. Nếu một máy chủ web có thể, nếu nó muốn, xử lý một đường dẫn /khác với một đường dẫn trống và rõ ràng là Weather.com. Về việc đây là do vô tình hay cố ý, bạn phải hỏi họ về điều đó.

— David Schwartz
nguồn

Điều đó làm cho hoàn thành kể từ khi, bởi vì bạn có thể định cấu hình máy chủ web để tìm kiếm một chỉ mục khác ngoài web root! Mũ của tôi là cho bạn tốt thưa ông.

— Chad Harrison

Bạn đang nói http://example.comcó thể được đối xử khác nhau từ http://example.com/? Tôi đã không nghĩ rằng đó là trường hợp với dấu gạch chéo đầu tiên.

— DisgruntledGoat

1

@DisgruntledGoat Bạn có thể , vâng, sử dụng một số .htaccessquy tắc. Nhưng có lẽ bạn không nên.

— Matthew

1

Bạn không thể đối xử http://example.comkhác với http://example.com/trong một máy chủ web, vì cả hai đều có một đường dẫn trống. Bạn có thể đối xử với họ khác nhau trong một trình duyệt.

— David Schwartz

3

neverminding tiêu đề sở tại, không hoặc một dấu gạch chéo dịch để yêu cầu http cùng: GET / HTTP/1.1: tools.ietf.org/html/rfc2616.html#section-3.2.3

— SingleNegationElimination

19

Gần đây hơn, nó có thể lập luận rằng các dấu gạch chéo kép không có một vai trò. Google khuyến nghị (ví dụ: để tránh vô tình gọi nội dung không an toàn từ một trang bảo mật), bỏ qua giao thức từ các tài nguyên được nhúng (bảng định kiểu, js, v.v.), như thế này

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

Vì vậy, rõ ràng là một URL không có giao thức như vậy là một URL đủ điều kiện và không phải là một URL tương đối (sẽ bắt đầu bằng một dấu gạch chéo).

— DaveP
nguồn

1

Kiểu này được gọi là URL / URI "giao thức". Có những câu hỏi tương tự về SO.

— hà mã

1

Không giới thiệu thêm. Xem thêm paulirish.com/2010/the-protatio-relative-url

— lorond

13

Để thực sự trả lời câu hỏi, thông số kỹ thuật ban đầu cho các giao thức http:(hoặc có thể ftp:, gopher:, mailto:, news:, telnet:, wais:, file:hoặc prospero:) sau đó một // để cho biết rằng các Resource Locator (URL) cú pháp Uniform đã được sử dụng, sau đó các máy chủ (tùy chọn bắt đầu bằng user:password@) sau đó địa chỉ thích hợp bắt đầu với người khác /. Điều này đã được đề xuất trong RFC 1738 .

Khi internet phát triển, http:trở thành giao thức thống trị, vì vậy các trình duyệt hiện cho rằng http://nên thêm tiền tố vào nếu không có.

— StarNamer
nguồn

3

Câu trả lời của bạn dường như chỉ ra rằng một cái gì đó không phải là URL có thể đã được sử dụng với giao thức tại một thời điểm và sẽ sử dụng một cái gì đó khác hơn là //chỉ ra nó đang được sử dụng ... Có phải vậy không?

— Izkata

3

@Izkata Vào cuối những năm 80 và 90, khi internet bắt đầu, có một số định dạng khác nhau được đề xuất cho các mặt hàng khác nhau. URL là / là một tập hợp con của Đỉnh (xem RFC 3305) và chúng có thể có các định dạng khác nhau, ví dụ isbn:1-23-456789-12-3. Trong thực tế, http:định nghĩa rằng phần còn lại sẽ là một URL. RFC chỉ là đề xuất và thường cho phép các phần mở rộng không bao giờ thành hiện thực. Tại một thời điểm, Tim Berners-Lee nói rằng đó //là vì một 'mạng con' (ví dụ. http:/govnet/whitehouse.gov). Ý tưởng này không bao giờ được sử dụng, nhưng '//' vẫn còn rất nhiều mã hiện đang mong đợi và kiểm tra nó.

— StarNamer

1

@Izkata: bạn có thể sẽ không thấy URN không URL được sử dụng với giao thức truyền thông; đó là những gì // dành cho. Nó chỉ ra rằng giao thức đang được sử dụng để truy cập vị trí mạng (có thể là từ xa) nơi tìm thấy tài nguyên. Có rất nhiều của URN khác có phần dữ liệu khác và không sử dụng // (trình duyệt của bạn có thể nhận "mailto:", ví dụ). Xem: vi.wikipedia.org/wiki/URI_scheme

— KutuluMike

@MichaelEdenfield Chà, đó là điều tôi đang thắc mắc. Đã bao giờ có một điểm mà nó được dự định sẽ được sử dụng khác nhau - một cái gì đó khác nhau có thể giao tiếp thông qua cùng một giao thức. Như một ví dụ thô thiển, ý định tại một thời điểm có thể có http://www.google.com/và http:%/74.125.225.97/cả hai đều hợp lệ và //chỉ ra một tên máy chủ trong khi một cái gì đó khác như %/chỉ ra một địa chỉ IP?

— Izkata

1

Tôi không nghĩ vậy. Ít nhất tôi chưa bao giờ thấy bất kỳ tài liệu dự thảo / ví dụ / vv nào có sơ đồ gia truyền thay thế cho các URL. Ấn tượng của tôi luôn là TBL chỉ muốn một cái gì đó rõ ràng rằng một URL trỏ đến một tài nguyên thực tế (chứ không phải dữ liệu tùy ý) và sử dụng // làm cho mọi thứ trông giống như tệp. Mọi kiểu dáng khác của URN mà tôi từng thấy không có tiền tố đặc biệt trong phần dữ liệu của nó. Một số giao thức cho phép điều đó (tôi nghĩ telnet và gopher, ví dụ) nhưng tôi chưa bao giờ thấy bất cứ điều gì như thế cho http (s).

— KutuluMike

1

Tôi muốn thêm vào câu trả lời được chấp nhận của David:

Bất chấp lời xin lỗi của nhà phát minh web, tôi nghĩ rằng cú pháp gạch chéo kép phục vụ một mục đích quan trọng: nổi bật về mặt trực quan. Dấu gạch chéo kép cho phép phân biệt trực quan dễ dàng các URL trong văn bản mà không cần siêu liên kết. Khi bạn nhìn thấy dấu gạch chéo kép, bạn nghĩ ngay rằng nó có thể được nhập vào cửa sổ trình duyệt, tương tự như cách bạn nghĩ một văn bản có chứa@có thể được sử dụng để gửi email. Điều đặc biệt quan trọng trong giai đoạn chuyển đổi sang web nơi các giao thức của thời đại đó (ftp, telnet, gopher) có khái niệm kỳ lạ của riêng họ để đại diện cho địa chỉ máy chủ hoặc đường dẫn tài nguyên, hiếm khi cả hai. Hầu hết các vấn đề liên quan đến dấu gạch chéo kép vẫn tồn tại, bởi vì dấu gạch chéo kép là phần khó hiểu nhất của URL, hãy nghĩ về số cổng, mã hóa phần trăm và phân biệt chữ hoa chữ thường. Nhưng có một URL như http: Something.com có thể dễ dàng bị nhầm lẫn với ví dụ của tôi ở đây: Something.com. Nhìn vào http: // mặt khác, làm thế nào nó tỏa sáng như một viên kim cương. Dấu gạch chéo kép là một phần quan trọng của biểu tượng Web và tôi tin rằng nó cũng tăng tốc tỷ lệ chấp nhận nó, ngay cả khi nó không có chủ ý.

Họ cũng có thể đã làm cho công việc của AmigaOS dễ dàng hơn để phân biệt giữa tên tệp và URL do AmigaOS sử dụng cú pháp đường dẫn tệp volume:path/to/destination. :)

— Sedat Kapanoglu
nguồn