Чому URL-адреси файлів починаються з 3-х нахилів?

HTTP починається з двох нахилів. Напр http://example.com.

Те саме стосується і FTP. Напр ftp://example.com.

Однак файл "URL-адреси" починається з трьох нахилів. Наприклад, читаючи pdf-файл за допомогою хрому, URL-адреса була б file:///D:/Desktop/Book.pdf.

Чому URL-адреси файлів використовують три косої риски?

Як уже згадували інші, схема файлу складається у формі "файл: // <host> / <path>". Хоча більшість браузерів не матиме проблеми лише з двома нахилами, і це правильно.

За рівних умов, потрійне нахилене срібло та ключове слово "localhost" існують лише для того, щоб забезпечити відповідність дійсному синтаксису URI / URL. У контексті файлової схеми хост є безглуздим, оскільки він завантажується безпосередньо з файлової системи без явного протоколу передачі або шляху документа до сервера. Оскільки це не HTTP, він не може завантажуватися зі стандартного веб-сервера, де теоретично у вас може бути встановлено кілька локальних віртуальних хостів. І він не може завантажуватись із стандартного мережевого тома, який технічно є іншим "хостом", оскільки браузер просто використовує назву тома типу "файл: /// volumes / foo". Нарешті, спробувати такі речі, як "файл: //example.com/some/file", не працює. Напевно, є якась причина для підтримки зовнішнього хоста, але я не можу придумати жодної.

В даний час IETF розробляє зміни для усунення вимоги з потрійною косою рисою, хоча проект також додає декілька варіантів дивної кулі, як file:c|/pathі навіть file://///host.example.com/path.

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

"3. Ця специфікація не визначає і не забороняє механізм доступу до нелокальних файлів."

Повний синтаксис є file://host/path.

Якщо хост є localhost, його можна опустити, в результаті чого file:///path.

Див. RFC 1738 - Уніфіковані локатори ресурсів (URL) :

URL-адреса файлу має форму:

file://<host>/<path>

[…]

Як окремий випадок, <host>може бути рядок "localhost" або порожній рядок; це трактується як "машина, з якої інтерпретується URL".

Денніс пояснив третій ривок, необхідний для відділення hostвід path, але інші два набагато цікавіші ...

Виявляється, вони були марним і дещо довільним доповненням до синтаксису URL. Тім Бернерс-Лі, винахідник всесвітньої павутини і автор багатьох її стандартів (включаючи RFC, до якого Денніс посилався), скаржився на використання "подвійної косої риски" в інтерв'ю ще в 2009 році.

Пан Бернерс-Лі пояснив, що подвійний косої риски, хоч і конвенція про програмування на той час, не дуже потрібна. Подивіться на всі папери та дерева, - сказав він, - це могло б бути врятовано, якби людям не довелося писати чи виписувати ці штрихи на папері протягом багатьох років - не кажучи вже про людську працю та час, витрачений на введення цих двох натискань клавіш незліченних мільйонів разів у адресних полях браузера.

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

Отже, за винятком незначного (і нехарактерного) пробігу в передбаченні близько 18 років тому, URL-адреса вашого файлу могла бути просто легко file:/D:/Desktop/Book.pdf, а не file:///D:/Desktop/Book.pdf.

Щоб відповісти на ваше запитання, немає вагомих причин, чому URL-адреси мають 3 косої риски.

Оновлення: Як в коментарях зазначає @ComFreek, станом на 2017 рік, file:/D:/...приклад, наведений вище, тепер дійсний! Це завдяки RFC 8089 , який конкретно викликує це виправлення з попереднього стандарту ...

Згідно з визначенням у [RFC1738], URL-адреса файлу завжди починалася з маркера "file: //", після чого слід (необов'язково порожнє) ім'я хоста та "/". Синтаксис, наведений у Розділі 2, робить весь компонент повноважень, включаючи подвійну косу рису "//", необов'язковою.

Який час бути живим.