¿Por qué las URL de archivo comienzan con 3 barras inclinadas?


182

HTTP comienza con dos barras inclinadas. Por ej http://example.com.

Lo mismo vale para FTP. Por ej ftp://example.com.

Sin embargo, las "URL" de archivo comienzan con tres barras inclinadas. Por ejemplo, al leer un archivo pdf usando Chrome, la URL sería file:///D:/Desktop/Book.pdf.

¿Por qué las URL de archivo usan tres barras inclinadas?


55
Opera para Windows lo expande file://localhost/D:/Desktop/automáticamente.

Respuestas:


14

Como otros han mencionado, el esquema del archivo tiene la forma "archivo: // <host> / <path>". Aunque la mayoría de los navegadores no tendrán problemas con solo dos barras, y con razón.

En igualdad de condiciones, la barra diagonal triple y la palabra clave "localhost" solo existen para garantizar la conformidad con la sintaxis URI / URL válida. En el contexto del esquema de archivo, el host no tiene sentido ya que se carga directamente desde un sistema de archivos sin ningún protocolo de transferencia explícito o ruta de documentos del servidor. Como no es HTTP, no se puede cargar desde un servidor web estándar donde, en teoría, podría tener múltiples hosts virtuales locales configurados. Y no se puede cargar desde un volumen de red estándar que técnicamente es otro "host", ya que el navegador solo usa el nombre del volumen como "file: /// volume / foo". Finalmente, probar cosas como "file: //example.com/some/file" no funciona. Probablemente haya alguna razón para admitir un host externo, pero no se me ocurre ninguna.

El IETF actualmente está redactando cambios para eliminar el requisito de triple barra, aunque el borrador también agrega algunas posibilidades extrañas como file:c|/pathe incluso file://///host.example.com/path.

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

"3. Esta especificación no define ni prohíbe un mecanismo para acceder a archivos no locales".


1
El borrador se convirtió en RFC 8089 en 2017, que aún incluye su presupuesto.
ComFreek

252

La sintaxis completa es file://host/path.

Si el host es localhost, se puede omitir, lo que resulta en file:///path.

Ver RFC 1738 - Localizadores uniformes de recursos (URL) :

La URL de un archivo toma la forma:

file://<host>/<path>

[...]

Como caso especial, <host>puede ser la cadena "localhost" o la cadena vacía; esto se interpreta como "la máquina desde la cual se interpreta la URL".


3
¡Genial, no esperaba que la respuesta a esta pregunta fuera un estándar RFC!
Pacerier

33
@Pacerier Casi todo lo que tenga que ver con Internet puede explicarse mediante un RFC (tenga en cuenta que no son necesariamente "estándares" pero pueden adoptarse como tales).
slhck

55
Tenga en cuenta que Tim Berners Lee se disculpó por esas 2 barras que se encuentran en cada URL: news.bbc.co.uk/2/hi/technology/8306631.stm
Peter

77
¿Puedo omitir el localhostde otros protocolos también o solo funciona file://?
Agos

3
Tenga en cuenta que Firefox realmente no sigue este estándar `file: // test / C: \` se comportará igual que `file: /// C: \` y `http: /// test` dará una URL no válida error
Earlz el

27

Dennis ha explicado la 3a barra, necesaria para separar la hostde la path, pero las otras dos son mucho más interesantes ...

Resulta que eran una adición inútil y algo arbitraria a la sintaxis de URL. Tim Berners-Lee, inventor de la World Wide Web y autor de muchos de sus estándares (incluido el RFC al que Dennis se vinculó), lamentó su uso del 'doble corte' en una entrevista en 2009.

El doble corte, aunque era una convención de programación en ese momento, resultó no ser realmente necesario, explicó Berners-Lee. Mire todo el papel y los árboles, dijo, que podrían haberse salvado si la gente no hubiera tenido que escribir o escribir esas barras en papel a lo largo de los años, sin mencionar el trabajo humano y el tiempo dedicado a escribir esas dos pulsaciones de teclas innumerables millones de veces en los cuadros de direcciones del navegador.

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

Entonces, salvo por un lapso menor (y poco característico) en previsión hace unos 18 años, la URL de su archivo podría haber sido fácilmente file:/D:/Desktop/Book.pdf, en lugar de hacerlo file:///D:/Desktop/Book.pdf.

Para responder a su pregunta, no hay una buena razón por la cual las URL tienen 3 barras diagonales.


Actualización: como @ComFreek señala en los comentarios, a partir de 2017, ¡el file:/D:/...ejemplo anterior ahora es válido! Esto es gracias a RFC 8089 , que específicamente llama a esta corrección del estándar anterior ...

Según la definición en [RFC1738], la URL de un archivo siempre comenzó con el token "file: //", seguido de un nombre de host (opcionalmente en blanco) y un "/". La sintaxis dada en la Sección 2 hace que todo el componente de autoridad, incluidas las barras diagonales "//", sea opcional.

Qué tiempo para estar vivo.


2
TimBL también explica esto en su FAQ
Molomby

2
Sin mencionar que se pueden guardar 2 bytes simplemente usando en http:example.comlugar de http://example.comNo puede parecer mucho, pero suman. Google recibe millones de búsquedas por día. ¿Cuántos enlaces hay en una página? Al menos 20. Eso significa que para un millón de búsquedas, si las barras no fueran necesarias, se podrían haber guardado 20 MB de ancho de banda.
Cole Johnson

1
@ColeJohnson: ¿Sabía que también puede omitir la parte del protocolo? Por http://example.comlo tanto, podría vincularse como //example.comen un documento transmitido a través de http. Se llama URL relativa al protocolo , todos los navegadores los admiten.
Molomby

Los conozco bien, pero personalmente solo los uso en CSS. Cuando escribo HTML, también uso el protocolo. No hay razón real realmente. Excepto tal vez porque cuando HTML5 + CSS3 se convirtió en "grande" por primera vez hace unos años, casi todos los sitios que miré eran así.
Cole Johnson

1
Al contrario de lo que su respuesta podría sugerir, file:/D:/Desktop/Book.pdfhay un URI de archivo válido según RFC 8089 (de 2017), que reemplazó a RFC 1738 (1994) en aspectos de URI de archivo.
ComFreek
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.