Tại sao URL tệp bắt đầu bằng 3 dấu gạch chéo?

HTTP bắt đầu bằng hai dấu gạch chéo. Ví dụ http://example.com.

FTP cũng vậy. Ví dụ ftp://example.com.

Tuy nhiên, tệp "URL" bắt đầu bằng ba dấu gạch chéo. Ví dụ: Đọc tệp pdf bằng chrome, URL sẽ là file:///D:/Desktop/Book.pdf.

Tại sao URL tệp sử dụng ba dấu gạch chéo?

Như những người khác đã đề cập, lược đồ tệp có dạng "file: // <host> / <path>". Mặc dù hầu hết các trình duyệt sẽ không gặp vấn đề với chỉ hai dấu gạch chéo và đúng như vậy.

Tất cả mọi thứ đều bằng nhau, từ khóa ba dấu gạch chéo và "localhost" chỉ tồn tại để đảm bảo tuân thủ cú pháp URI / URL hợp lệ. Trong ngữ cảnh của lược đồ tệp, máy chủ lưu trữ là vô nghĩa vì nó tải trực tiếp từ hệ thống tệp mà không có bất kỳ giao thức chuyển giao rõ ràng hoặc đường dẫn tài liệu máy chủ. Vì không phải là HTTP, nên nó không thể tải từ một máy chủ web tiêu chuẩn, theo lý thuyết bạn có thể có nhiều máy chủ ảo cục bộ được thiết lập. Và nó không thể tải từ một ổ đĩa mạng tiêu chuẩn về mặt kỹ thuật là một "máy chủ" khác, vì trình duyệt chỉ sử dụng tên âm lượng như "file: /// volume / foo". Cuối cùng, thử những thứ như "file: //example.com/some/file" không hoạt động. Có lẽ có một số lý do để hỗ trợ một máy chủ bên ngoài, nhưng tôi không thể nghĩ ra.

IETF hiện đang soạn thảo các thay đổi để loại bỏ yêu cầu ba gạch chéo, mặc dù dự thảo cũng bổ sung một vài khả năng kỳ quặc như file:c|/pathvà thậm chí file://///host.example.com/path.

https://tools.ietf.org/html/draft-ietf-appsawg-file-scheme-03

"3. Thông số kỹ thuật này không định nghĩa cũng không cấm cơ chế truy cập các tệp không cục bộ."

Cú pháp đầy đủ là file://host/path.

Nếu máy chủ lưu trữ localhost, nó có thể được bỏ qua, dẫn đến file:///path.

Xem RFC 1738 - Bộ định vị tài nguyên thống nhất (URL) :

Một URL tệp có dạng:

file://<host>/<path>

[Càng]

Trong trường hợp đặc biệt, <host>có thể là chuỗi "localhost" hoặc chuỗi trống; điều này được hiểu là "cỗ máy mà URL đang được giải thích".

Dennis đã giải thích dấu gạch chéo thứ 3, cần thiết để tách hostkhỏi path, nhưng hai cái còn lại thú vị hơn nhiều ...

Hóa ra họ là một bổ sung vô dụng và hơi tùy tiện cho cú pháp URL. Tim Berners-Lee, nhà phát minh của World Wide Web và là tác giả của nhiều tiêu chuẩn của nó (bao gồm cả RFC mà Dennis liên kết), đã than thở về việc sử dụng 'cú chém kép' trong một cuộc phỏng vấn vào năm 2009.

Dấu gạch chéo kép, mặc dù là một quy ước lập trình vào thời điểm đó, hóa ra không thực sự cần thiết, ông Berners-Lee giải thích. Nhìn vào tất cả giấy và cây, ông nói, điều đó có thể đã được cứu nếu mọi người không phải viết hoặc gõ những dấu gạch chéo đó trên giấy trong nhiều năm - chưa kể đến sức lao động của con người và thời gian gõ hai phím gõ đó vô số hàng triệu lần trong hộp địa chỉ trình duyệt.

http://bits.bloss.nytimes.com/2009/10/12/the-webs-inventor-regrets-one-small-thing/

Vì vậy, hãy tiết kiệm cho một sai sót nhỏ (và không phổ biến) trong tầm nhìn xa khoảng 18 năm trước, URL tệp của bạn có thể dễ dàng được file:/D:/Desktop/Book.pdf, hơn là file:///D:/Desktop/Book.pdf.

Có, để trả lời câu hỏi của bạn, không có lý do chính đáng tại sao URL có 3 dấu gạch chéo.

Cập nhật: Như @ComFalet chỉ ra trong các bình luận, tính đến năm 2017, file:/D:/...ví dụ trên hiện đã có hiệu lực! Điều này là nhờ RFC 8089 , đặc biệt gọi bản sửa lỗi này từ tiêu chuẩn trước đó ...

Theo định nghĩa trong [RFC1738], URL tệp luôn bắt đầu bằng mã thông báo "tệp: //", theo sau là tên máy chủ (tùy chọn trống) và "/". Cú pháp được đưa ra trong Phần 2 làm cho toàn bộ thành phần thẩm quyền, bao gồm cả dấu gạch chéo kép "//", tùy chọn.

Thật là một thời gian để sống.