Dlaczego adresy URL plików zaczynają się od 3 ukośników?

HTTP zaczyna się od dwóch ukośników. Np http://example.com.

To samo dotyczy FTP. Np ftp://example.com.

Jednak pliki „URL” zaczynają się od trzech ukośników. Np. Czytanie pliku pdf za pomocą chrome, URL będzie file:///D:/Desktop/Book.pdf.

Dlaczego adresy URL plików używają trzech ukośników?

Jak wspomnieli inni, schemat pliku ma postać „plik: // <host> / <ścieżka>”. Chociaż większość przeglądarek nie będzie miała problemu tylko z dwoma ukośnikami, i słusznie.

Wszystkie rzeczy są jednakowe, potrójny ukośnik i słowo kluczowe „localhost” istnieją tylko po to, aby zapewnić zgodność z prawidłową składnią URI / URL. W kontekście schematu plików host nie ma znaczenia, ponieważ ładuje się bezpośrednio z systemu plików bez wyraźnego protokołu przesyłania lub ścieżki dokumentu serwera. Ponieważ nie jest to HTTP, nie można go załadować ze standardowego serwera WWW, na którym teoretycznie można skonfigurować wiele lokalnych hostów wirtualnych. I nie można go załadować ze standardowego woluminu sieciowego, który technicznie jest innym „hostem”, ponieważ przeglądarka używa po prostu nazwy woluminu, np. „Plik: /// volume / foo”. Wreszcie, próbowanie czegoś takiego jak „file: //example.com/some/file” nie działa. Prawdopodobnie istnieje jakiś powód, aby wspierać zewnętrznego hosta, ale nie mogę o nim myśleć.

IETF opracowuje obecnie zmiany w celu usunięcia wymogu potrójnego cięcia, chociaż wersja robocza dodaje również kilka dziwnych możliwości, takich jak file:c|/pathi parzyste file://///host.example.com/path.

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

„3. Ta specyfikacja nie definiuje ani nie zabrania mechanizmu dostępu do plików nielokalnych.”

Pełna składnia to file://host/path.

Jeśli host jest localhost, można go pominąć, co powoduje file:///path.

Patrz RFC 1738 - Jednolite lokalizatory zasobów (URL) :

Adres URL pliku ma postać:

file://<host>/<path>

[…]

W szczególnym przypadku <host>może to być ciąg „localhost” lub pusty ciąg; jest to interpretowane jako „maszyna, z której interpretowany jest adres URL”.

Dennis wyjaśnił trzeci slash, potrzebny do oddzielenia go hostod path, ale pozostałe dwa są o wiele bardziej interesujące ...

Okazuje się, że były one bezużytecznym i nieco arbitralnym dodatkiem do składni adresu URL. Tim Berners-Lee, wynalazca World Wide Web i autor wielu jego standardów (w tym RFC, do którego Dennis się odniósł), ubolewał nad użyciem podwójnego ukośnika w wywiadzie z 2009 roku.

Berners-Lee wyjaśnił, że podwójny ukośnik, choć w tym czasie konwencja programowa, nie był tak naprawdę konieczny. Popatrz na cały papier i drzewa, powiedział, że można by je uratować, gdyby ludzie nie musieli pisać ani pisać tych cięć na papierze przez lata - nie wspominając już o ludzkiej pracy i czasie spędzonym na pisaniu tych dwóch naciśnięć klawiszy niezliczonych milionów czasy w polach adresowych przeglądarki.

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

Tak więc, z wyjątkiem drobnego (i nietypowego) upływu czasu w prognozowaniu jakieś 18 lat temu, adres URL pliku mógł być po prostu łatwiejszy file:/D:/Desktop/Book.pdfniż file:///D:/Desktop/Book.pdf.

Aby odpowiedzieć na twoje pytanie, nie ma dobrego powodu, dla którego adresy URL zawierają 3 ukośniki.

Aktualizacja: Jak wskazuje @ComFreek w komentarzach, od 2017 roku file:/D:/...powyższy przykład jest teraz ważny! Dzieje się tak dzięki RFC 8089 , który specjalnie wywołuje tę poprawkę z poprzedniego standardu ...

Zgodnie z definicją w [RFC1738] adres URL pliku zawsze zaczynał się od tokena „file: //”, po którym następowała (opcjonalnie pusta) nazwa hosta i „/”. Składnia podana w rozdziale 2 powoduje, że cały komponent uprawnień, w tym podwójne ukośniki „//”, są opcjonalne.

Co za czas na życie.