Diferencia entre barra diagonal (/) y barra diagonal inversa (\) en la ruta del archivo


153

Me preguntaba sobre la diferencia entre \y /en las rutas de archivo. Me he dado cuenta de que a veces un camino contiene /y otras veces está con \.

Sería genial si alguien puede explicar cuándo usar \y /.


44
¿Diferencia en qué contexto? ¿Un contexto webby? ¿Escapando en cadenas de C #? Está etiquetado con ASP.NET.
Peter Mortensen


66
@Peter Cerraría el anterior como un engaño de esto, ya que esto tiene mejores respuestas.
nicael

66
¿Cómo se relacionan c # y asp.net con la pregunta?
Oriol

2
@zzzzBov ¿por qué este no se redirigió simplemente al anterior y se colocaron las mejores respuestas allí? No me gusta un sistema donde una pregunta que hago podría cerrarse en el futuro como un "duplicado" de algo que sucedió más tarde. Al menos llámalo algo más descriptivo, como "reemplazado" en lugar de duplicado. El "uno" original no puede ser un duplicado de nada, es el único.

Respuestas:


248

/es el separador de ruta en Unix y sistemas similares a Unix. Windows moderno generalmente puede usar ambos \e /indistintamente para rutas de archivos, pero Microsoft ha abogado por el uso \como separador de rutas durante décadas.

Esto se hace por razones históricas que se remontan a la década de 1970, anteriores a Windows en más de una década. Al principio, MS-DOS (la base de principios de Windows) no admitía directorios. Unix tenía soporte de directorio usando el /personaje desde el principio. Sin embargo, cuando se agregaron directorios en MS-DOS 2.0, Microsoft e IBM ya estaban usando el /carácter para los interruptores de comando , y debido al analizador liviano de DOS (descendiente de QDOS , diseñado para ejecutarse en hardware de gama baja), no pudieron encontrar un forma factible de usar el /personaje sin romper la compatibilidad con sus aplicaciones existentes.

Por lo tanto, para evitar errores sobre "falta un interruptor" o "interruptor no válido" al pasar rutas de archivos como argumentos a comandos como estos:

cd/                        <---- no switch specified
dir folder1/folder2        <---- /folder2 is not a switch for dir

se decidió que el \personaje se usaría en su lugar, por lo que podría escribir esos comandos como este

cd\
dir folder1\folder2

sin error.

Más tarde, Microsoft e IBM colaboraron en un sistema operativo no relacionado con DOS llamado OS / 2 . OS / 2 tenía la capacidad de usar ambos separadores, probablemente para atraer a más desarrolladores de Unix. Cuando Microsoft e IBM se separaron en 1990 , Microsoft tomó el código que tenían y creó Windows NT , en el que se basan todas las versiones modernas de Windows, llevando este agnosticismo separador.


Como la compatibilidad con versiones anteriores ha sido el nombre del juego para Microsoft de todas las principales transiciones del sistema operativo que han realizado (DOS a Win16 / DOS, a Win16 / Win32, a Win32 / WinNT), esta peculiaridad se mantuvo, y probablemente existir por un tiempo todavía.

Es por esta razón que existe esta discrepancia. Realmente no debería tener ningún efecto en lo que está haciendo porque, como dije, el WinAPI generalmente puede usarlos indistintamente. Sin embargo, las aplicaciones de terceros probablemente se romperán si pasa un /cuando esperan un nombre \entre directorios. Si está utilizando Windows, quédese con \. Si está utilizando Unix o URI (que tienen su base en las rutas de Unix, pero esa es otra historia completamente), entonces úselo /.


En el contexto de C #: debe tenerse en cuenta, ya que esta es técnicamente una pregunta de C #, que si desea escribir más código C # "portátil" que funcione tanto en Unix como en Windows (incluso si C # es predominantemente un lenguaje de Windows), es posible que desee usar el Path.DirectorySeparatorCharcampo para que su código use el separador preferido en ese sistema y use Path.Combine()para agregar rutas correctamente.


57
Y siempre combina caminos usando Path.Combine.
Cheng Chen

1
Interesante. Por lo tanto, bajo DOS o Windows, foo.exe /barpodría interpretarse como un interruptor de línea de comandos, mientras que foo.exe \barpodría interpretarse como una referencia a un archivo / carpeta llamado barque se encuentra en el directorio raíz \de la "unidad" actual, como C:\por ejemplo.
Jeppe Stig Nielsen

44
Cabe señalar que esta normalización de /a \ se realiza en la capa de compatibilidad de Win32, lo que significa que si lo evita, habrá una diferencia. El ejemplo más conocido de esto son las rutas de longitud extendida: \\?\C:\ funcionará como se espera en NTFS pero \\?\C:/no lo hará.
Voo

44
@PC Luddite: que WinAPI puede manejar ambos /y ` is not entirely true. For network path you have to use `(por ejemplo, \\ <servername> bot not // <servername>)
raznagul

2
@raznagul Cierto. Realmente no mencioné las rutas de red en mi respuesta. Me quedé principalmente con el tipo de ruta de archivo común. Agregaré eso.
PC Luddite

20

MS-DOS 1.0 retuvo la opción de línea de comando (o modificador) convención de caracteres '/' de CP / M. En ese momento no había estructura de directorios en el sistema de archivos y no había conflicto.

Cuando Microsoft desarrolló el entorno más similar a Unix con MS-DOS (y PC-DOS) 2.0, necesitaban representar el separador de ruta utilizando algo que no entrara en conflicto con las opciones de línea de comando existentes. Internamente, el sistema funciona igualmente bien con '/' o '\'. El procesador de comandos (y muchas aplicaciones) continuaron usando '/' como un carácter de cambio.

Se podría usar una CONFIG.SYSentrada SWITCHAR=-para anular el /valor predeterminado para mejorar la compatibilidad con Unix. Esto hace que los comandos integrados y las utilidades estándar utilicen el carácter alternativo. El separador de ruta de Unix podría utilizarse sin ambigüedad para los nombres de archivo y directorio. Esta entrada se eliminó en versiones posteriores, pero se documentó una llamada de DOS para establecer el valor después del arranque.

Esto se usó poco y la mayoría de las herramientas de terceros permanecieron sin cambios. La confusión persiste. Muchos puertos de herramientas Unix conservan el carácter de conmutador '-' mientras que algunos admiten ambas convenciones.

El siguiente procesador de comandos de PowerShell implementa escapes rigurosos y cambia parámetros y evita en gran medida la confusión, excepto donde se utilizan herramientas heredadas.

Ni la pregunta ni la respuesta se relacionan con C #.


2
Como nota histórica, el uso de /un introductor de opciones en varios sistemas operativos PDP-11 como RSTS (1970) y RSX (1972) precede a CP / M (1973).
PJTraill

9

En los sistemas basados ​​en Unix, \un carácter de escape, es decir, \le dice al analizador que este es un espacio y no el final de la declaración. En sistemas Unix /es el separador de directorio.

En Windows \es el separador de directorio, pero /no se puede usar en nombres de archivo o directorio.


1
\ y /(al igual que varios otros símbolos) no se pueden usar en nombres de archivo porque DOS no tenía el mismo analizador complejo al que los usuarios de Unix están acostumbrados. La falta de un buen analizador fue el resultado de que MS-DOS descendiera de QDOS ("Sistema operativo rápido y sucio"). Estaba destinado a hacer que las cosas funcionen rápidamente y en hardware limitado. Todo esto, por supuesto, todavía existe en la actualidad para la compatibilidad con versiones anteriores.
PC Luddite

2
bueno, vale la pena mencionar que en versiones posteriores de Windows /se agregó como "Alternate_Directory_Separator"
Tomer W

@PCLuddite, ¿tal vez deberíamos pensar en la compatibilidad con versiones anteriores?

1
@nocomprende ¿Qué pasa con las rutas de archivos son incompatibles? ¿Incomparable con qué? Y como dije antes, salvar "algunas aplicaciones de DOS" (que en realidad eran más como miles) se rompió fue muy importante para los consumidores en ese momento. Es lo que hizo que Microsoft tenga éxito hoy y Unix (y todos los demás realmente) comienzan a disminuir (incluso si ha habido un resurgimiento en la última década). No veo cómo eso no lo mira con sentido común.
PC Luddite

1
@nocomprende Y su argumento sobre las rutas de archivos no estandarizadas es completamente nulo. Están estandarizados en Windows, y están estandarizados en Unix. Si habla de un estándar multiplataforma, no es realmente tan útil o fácil de implementar. ¿Quién puede decir que un estándar es realmente "mejor" que otro?
PC Luddite

8
  • Una URL, estandarizada en RFC 1738, siempre utiliza barras diagonales, independientemente de la plataforma.
  • Una ruta de archivo y un URI son diferentes. \es correcto en una ruta de archivo de Windows y /es correcto en un URI.
  • Varios navegadores (a saber, Firefox y Opera) fallan catastróficamente al encontrar URI con barras invertidas.
  • System.IO.Path.DirectorySeparatorChar para obtener el separador de ruta actual

Este puede ser un recurso relevante.


10
¿Fallar catastróficamente? Firefox se traduce \​​en /forma automática. En mi libro esto se llama "funciona a la perfección".
Kroltan

22
mi casa se incendió la última vez que usé \ en Firefox
user3163495

1
@CarstenS, Firefox no convierte la barra invertida en barra diagonal en URL automáticamente y no abre el enlace. Este complemento corrige la URL con barra invertida y página abierta. addons.mozilla.org/en-US/seamonkey/addon/…
Sami

¿Qué quiere decir exactamente con "fallar catastróficamente"? ¿Lo que pasa? ¿El navegador se bloquea y sale?
Peter Mortensen

7

Además de las respuestas dadas, vale la pena mencionar que \se usa ampliamente para caracteres especiales (como \n \t) en lenguajes de programación, editores de texto y sistemas generales que aplican análisis léxico.

Si está programando, por ejemplo, a veces es inconveniente incluso necesitar escapar de la barra invertida con otro ( \\) para usarlo correctamente, o necesita usar cadenas de escape, como C # @"\test".

Por supuesto, como se mencionó anteriormente, los URI web usan barra diagonal por estándar pero ambas barras funcionan en las últimas y más comunes herramientas de línea de comandos.

ACTUALIZACIÓN: Después de buscar un poco, parece que la historia completa se remonta /y \se remonta al "historial de la computadora", en la época de DOS y los sistemas basados ​​en Unix en ese momento. HowToGeek tiene un interesante artículo sobre esta historia.

En términos cortos, DOS 1.0 fue lanzado inicialmente por IBM sin soporte de directorio, y /se usó para otra funcionalidad de comando ("cambio"). Cuando los directorios se introdujeron en la versión 2.0, /ya estaba en uso, por lo que IBM eligió el símbolo visualmente más cercano, que era \. Por otro lado, Unix se usa de manera estándar /para directorios.

Cuando los usuarios comenzaron a usar muchos sistemas diferentes, comenzaron a confundirse, lo que hizo que los desarrolladores del sistema operativo intentaran hacer que los sistemas funcionen en ambos casos; esto incluso se aplica en la parte de las URL, ya que algunos navegadores admiten la prueba http: \\ www.test. com \ go formato. Sin embargo, esto tenía inconvenientes en general, pero todo se mantiene en pie hoy por causas de compartimiento hacia atrás, con un intento de soporte de ambas barras en Windows, a pesar de que ya no se basan en DOS.


"ambas barras oblicuas funcionan en las rutas del sistema de archivos". es incorrecto, porque Unix está bastante enojado cuando usas ` as well as many make` shells ... tienes razón en que Windows reciente ha definido la variable de entorno ALTERNATE_PATH_SEPARATOR que, por defecto /, Windows probablemente pueda aceptar ambos.
Tomer W

1
@TomerW Windows NT siempre ha sido compatible con POSIX (aunque POSIX anterior era un desastre de todos modos, y algunos de ellos se quedaron en Windows por compatibilidad con versiones anteriores). Eso incluía /rutas de soporte en todas partes del sistema; por supuesto, las aplicaciones podrían malinterpretar esas rutas en su tiempo libre, por lo que no se usó demasiado. Las aplicaciones que no son de CLI que no intentaron hacer su propia validación (interrumpida) de rutas funcionaron bien desde el principio.
Luaan

@Luaan Windows tenía la capacidad de admitir muchas funciones POSIX, pero difícilmente diría que era "compatible con POSIX". Claro, había algunos subsistemas POSIX que uno podía usar a lo largo de los años, pero estaban lejos de ser ideales. Windows 10 admitirá Ubuntu bash aunque a finales de este verano junto con soporte nativo para las herramientas de Linux que vienen con Ubuntu, por lo que puede argumentar eso en el futuro, pero ciertamente no puede decir "siempre".
PC Luddite

@Luaan A menos que por "compatible" se refiera a "cygwin funciona".
PC Luddite

@PCLuddite No, era 100% compatible con POSIX.1c. Eso no significa que todas las aplicaciones de Unix funcionen en él: la mayoría de las aplicaciones de Unix no son compatibles con POSIX :)
Luaan

6

No deberías usar ninguno en C #. Siempre debes usar la Pathclase . Contiene un método llamado Path.Combineque puede usarse para crear rutas sin especificar el separador usted mismo.

Ejemplo de uso:

string fullPath = System.IO.Path.Combine("C:", "Folder1", "Folder2", "file.txt");

5

\ se usa para rutas de archivos locales de Windows y rutas de red como en:

C:\Windows\Temp\ o \\NetworkSharedDisk\Documents\Archive\

/ es lo que requieren los URI estándar como en:

http://www.stackoverflow.com/


2
@NikhilVartak, agregué ejemplos, aunque pensé que mi respuesta inicial abordaba todas las preguntas del OP.
Ash

3
Windows también reconoce /en las rutas (al menos 7 lo hace).
Kenneth K.

Esta respuesta está lejos de ser completa.
reinierpost

¿Estaba destinado a vincular algunos recursos, además de la página principal de Stack Overflow?
Tas

@reinierpost, mi respuesta se basa en la pregunta del OP y las etiquetas asociadas. Como algunas de las otras respuestas aquí, podría copiar algo de stackoverflow.com/questions/1589930/... y pegarlo aquí, pero me pareció excesivo. @tas, tenía la intención de vincular a la página de stackoverflow o cualquier hipervínculo del sitio web para ilustrar el uso de /URI estándar como lo he indicado en la respuesta.
Ash
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.