Diferença entre barra (/) e barra invertida (\) no caminho do arquivo

Eu estava pensando sobre a diferença entre \e /nos caminhos dos arquivos. Percebi que, às vezes, um caminho contém /e às vezes é com ele \.

Seria ótimo se alguém pudesse explicar quando usar \e /.

/é o separador de caminho nos sistemas Unix e Unix-like. Windows moderno geralmente pode usar tanto \e /de forma intercambiável para filepaths, mas a Microsoft tem defendido o uso de \como separador de caminho ao longo de décadas.

Isso é feito por razões históricas que datam da década de 1970, anteriores ao Windows por mais de uma década. No começo, o MS-DOS (a base do Windows inicial) não suportava diretórios. O Unix tinha suporte de diretório usando o/ personagem desde o início. No entanto, quando os diretórios foram adicionados no MS-DOS 2.0, a Microsoft e a IBM já estavam usando o /caractere para opções de comando e, devido ao analisador leve do DOS (descendente do QDOS , projetado para executar em hardware de ponta), eles não conseguiram encontrar um maneira viável de usar o /personagem sem quebrar a compatibilidade com os aplicativos existentes.

Portanto, para evitar erros sobre "falta de uma opção" ou "opção inválida" ao passar caminhos de arquivo como argumentos para comandos como estes:

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

foi decidido que o \personagem seria usado em vez disso, para que você pudesse escrever esses comandos como este

cd\
dir folder1\folder2

sem erro.

Posteriormente, Microsoft e IBM colaboraram em um sistema operacional não relacionado ao DOS chamado OS / 2 . O OS / 2 tinha a capacidade de usar os dois separadores, provavelmente para atrair mais desenvolvedores do Unix. Quando a Microsoft e a IBM se separaram em 1990 , a Microsoft pegou o código que eles tinham e criou Windows NT , no qual todas as versões modernas do Windows se baseiam, levando consigo esse agnosticismo separador.

Como compatibilidade com versões anteriores tem sido o nome do jogo para a Microsoft de todas as principais transições de SO que eles realizaram (DOS para Win16 / DOS, Win16 / Win32, Win32 / WinNT), essa peculiaridade ficou emperrada e provavelmente existe por um tempo ainda.

É por esse motivo que essa discrepância existe. Realmente não deve ter efeito no que você está fazendo, porque, como eu disse, o WinAPI geralmente pode usá-los de forma intercambiável. No entanto, aplicativos de terceiros provavelmente serão interrompidos se você passar um /quando eles esperam um \entre nomes de diretório. Se você estiver usando o Windows, fique com \. Se você estiver usando Unix ou URI (que têm como base os caminhos do Unix, mas isso é outra história), use /.

No contexto do C #: Observe que, como essa é tecnicamente uma questão do C #, se você quiser escrever um código C # mais "portátil" que funcione no Unix e no Windows (mesmo que o C # seja predominantemente um idioma do Windows), você convém usar o Path.DirectorySeparatorCharcampo para que seu código use o separador preferido nesse sistema e use Path.Combine()para anexar os caminhos corretamente.

MS-DOS 1.0 manteve a convenção de caracteres da opção de linha de comando (ou opção) de '/' do CP / M. Naquela época, não havia estrutura de diretórios no sistema de arquivos nem conflito.

Quando a Microsoft desenvolveu o ambiente mais semelhante ao Unix com o MS-DOS (e PC-DOS) 2.0, precisou representar o separador de caminho usando algo que não conflitasse com as opções de linha de comando existentes. Internamente, o sistema funciona igualmente bem com '/' ou '\'. O processador de comando (e muitos aplicativos) continuou usando o '/' como caractere de opção.

Uma CONFIG.SYSentrada SWITCHAR=-pode ser usada para substituir o /padrão para melhorar a compatibilidade do Unix. Isso faz com que comandos internos e utilitários padrão usem o caractere alternativo. O separador de caminho do Unix pode então ser usado sem ambiguidade para nomes de arquivos e diretórios. Essa entrada foi removida em versões posteriores, mas uma chamada do DOS foi documentada para definir o valor após a inicialização.

Isso foi pouco usado e a maioria das ferramentas de terceiros permaneceu inalterada. A confusão persiste. Muitas portas das ferramentas Unix mantêm o caractere de switch '-' enquanto algumas suportam ambas as convenções.

O processador de comando subsequente do PowerShell implementa rigorosos parâmetros de escape e comutação e evita amplamente a confusão, exceto onde as ferramentas herdadas são usadas.

Nem a pergunta nem a resposta estão relacionadas ao C #.

Em sistemas baseados em Unix, \há um caractere de escape, isto é, \informa ao analisador que este é um espaço e não o fim da instrução. Em sistemas Unix/ é o separador de diretório.

No Windows \está o separador de diretório, mas /não pode ser usado nos nomes de arquivo ou diretório.

• Uma URL, padronizada na RFC 1738, sempre usa barras, independentemente da plataforma.
• Um caminho de arquivo e um URI são diferentes. \está correto no caminho do arquivo do Windows e/ correto no URI.
• Vários navegadores (a saber, Firefox e Opera) falham catastroficamente ao encontrar URIs com barras invertidas.
• System.IO.Path.DirectorySeparatorChar para obter o separador de caminho atual

Este pode ser um recurso relevante.

Além das respostas dadas, vale ressaltar que \é amplamente utilizado para caracteres especiais (como\n \t ) em linguagens de programação, editores de texto e sistemas gerais que aplicam análise lexical.

Se você estiver programando, por exemplo, às vezes é inconveniente precisar escapar da barra invertida com outra ( \\) para usá-la corretamente - ou usar seqüências de escape, como C #@"\test" .

Obviamente, como mencionado anteriormente, os URIs da Web usam barra padrão por padrão mas as duas barras funcionam nas ferramentas de linha de comando mais recentes e mais comuns.

ATUALIZAÇÃO: Depois de pesquisar um pouco, parece toda a história entre /e \remonta à "história do computador", na era do DOS e dos sistemas baseados em Unix da época. O HowToGeek tem um artigo interessante sobre essa história.

Em resumo, o DOS 1.0 foi lançado inicialmente pela IBM sem suporte a diretório e /foi usado para outra funcionalidade de comando ("comutação"). Quando os diretórios foram introduzidos na versão 2.0, /já estavam em uso, a IBM escolheu o símbolo visualmente mais próximo, que era \. Por outro lado, o Unix é usado normalmente /para diretórios.

Quando os usuários começaram a usar muitos sistemas diferentes, começaram a ficar confusos, fazendo com que os desenvolvedores do sistema operacional tentassem fazer com que os sistemas funcionassem nos dois casos - isso até se aplica à parte dos URLs, pois alguns navegadores suportam o http: \\ www.test. formato com \ go . Isso teve desvantagens, em geral, mas hoje a coisa toda ainda permanece por causas de compartimento atrasado, com uma tentativa de suporte de ambas as barras no Windows, mesmo que elas não sejam mais baseadas no DOS.

Você não deveria estar usando C #. Você sempre deve usar a Pathclasse . Ele contém um método chamado Path.Combineque pode ser usado para criar caminhos sem especificar você mesmo o separador.

Exemplo de uso:

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

\ é usado para caminhos de arquivos locais do Windows e caminhos de rede, como em:

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

/ é o que é exigido pelos URIs padrão, como em:

http://www.stackoverflow.com/