É seguro converter caminhos de arquivos do Windows em caminhos de arquivos Unix com uma simples substituição?

Por exemplo, digamos que eu o possua para que todos os meus arquivos sejam transferidos de uma máquina Windows para uma máquina Unix como tal: C:\test\myFile.txtto {somewhere}/test/myFile.txt(letra da unidade é irrelevante neste momento).

Atualmente, nossa biblioteca de utilitários que escrevemos para nós mesmos fornece um método que substitui todas as barras invertidas por barras invertidas:

public String normalizePath(String path) {
   return path.replaceAll("\\", "/");
}

As barras são reservadas e não podem fazer parte de um nome de arquivo; portanto, a estrutura de diretórios deve ser preservada. No entanto, não tenho certeza se existem outras complicações entre os caminhos do Windows e do Unix que possam me preocupar (por exemplo: nomes não-ascii, etc.)

Sim, se você fizer a substituição apenas no Windows e desligá-lo ao executar em outros sistemas.

A substituição em sistemas do tipo Unix está incorreta porque \é um caractere válido em um nome de arquivo ou diretório em plataformas do tipo Unix. Nessas plataformas, apenas NULe /são proibidos nos nomes de arquivos e diretórios.

Além disso, algumas funções da API do Windows (principalmente as de nível mais baixo) não permitem o uso de barras - as barras invertidas devem ser usadas com elas.

Sim, mas tudo isso é um ponto discutível. Java converte perfeitamente barras para barras no Windows. Você pode simplesmente usar barras para todos os caminhos codificados ou armazenados na configuração e funcionará para as duas plataformas.

Pessoalmente, eu sempre usar a barra mesmo no Windows, porque é não o caractere de escape. Quer o caminho bruto esteja no código ou seja externalizado em um arquivo de propriedades, eu o codifico da mesma maneira.

Tente! Isso funcionará no Windows. Obviamente, altere o caminho real para algo que exista e seu usuário tenha permissão para ler.

File f = new File("c:/some/path/file.txt");
if (!f.canRead()) {
  System.out.println("Uh oh, Snowman was wrong!");
}

Bônus: você pode até misturar barras no mesmo caminho!

File f = new File("c:/some\\path/file.txt");
if (!f.canRead()) {
  System.out.println("Uh oh, Snowman was wrong again!");
}

Outra complicação no Windows é que ele também suporta a notação UNC e as letras de unidade tradicionais.

Um arquivo em um servidor de arquivos remoto pode ser acessado como \\server\sharename\path\filename.

Não . Há muito mais em que pensar do que apenas o separador de caminho (a coisa "\ vs /"). Como Rob Y menciona, há como os espaços são manipulados e sua alta frequência no uso do Windows. Existem diferentes caracteres ilegais nos dois ambientes. Existe a disposição do Unix de permitir quase qualquer coisa quando escapado por um "\" principal. Existe o uso de '"' no Windows para lidar com espaços incorporados. Há o uso de UCS-16 pelo Windows e o uso de ASCII ou UTF-8 pelo Unix.

etc. , etc. , etc.

Mas , para muitos aplicativos que podem restringir os nomes de caminho que eles precisam manipular, você pode fazê-lo da maneira que sugere. E funcionará em pelo menos um grande número de casos, mas não em todos eles.

Todo sistema operacional da Microsoft, começando com o MS-DOS, entendeu, no nível do kernel, barras e barras invertidas .

Portanto, no Windows, você pode converter entre eles livremente; ambos têm status igual como separadores reservados. Em qualquer caminho válido, você pode substituir barras invertidas por barras e vice-versa, sem alterar seu significado, no que diz respeito ao kernel.

Nas versões anteriores do DOS, o command.comintérprete da Microsoft tornava uma preferência configurável qual barra era usada para exibir e analisar caminhos. Isso acabou sendo removido.

Alguns programas de espaço do usuário no Windows, como, oh, o shell do Windows ( explorer.exe), não gostam de barras. Isso é apenas uma programação de má qualidade nesses programas.