Có an toàn để chuyển đổi đường dẫn tệp Windows sang đường dẫn tệp Unix bằng một thay thế đơn giản không?

Vì vậy, ví dụ nói rằng tôi đã có nó để tất cả các tệp của tôi sẽ được chuyển từ máy windows sang máy unix như vậy: C:\test\myFile.txtto {somewhere}/test/myFile.txt(ký tự ổ đĩa không liên quan tại thời điểm này).

Hiện tại, thư viện tiện ích của chúng tôi do chúng tôi tự viết cung cấp một phương pháp thay thế đơn giản tất cả các dấu gạch chéo ngược bằng dấu gạch chéo về phía trước:

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

Dấu gạch chéo được dành riêng và không thể là một phần của tên tệp, do đó cấu trúc thư mục cần được giữ nguyên. Tuy nhiên, tôi không chắc chắn nếu có các biến chứng khác giữa các cửa sổ và đường dẫn unix mà tôi có thể cần phải lo lắng (ví dụ: tên không phải ascii, v.v.)

Có, nếu bạn chỉ thực hiện thay thế trên Windows, và tắt nó khi chạy trên các hệ thống khác.

Thực hiện thay thế trên các hệ thống giống Unix là sai vì \là ký tự hợp lệ trong tên tệp hoặc thư mục trên các nền tảng giống Unix. Trên các nền tảng này, chỉ NULvà/ bị cấm trong tên tệp và thư mục.

Ngoài ra, một số hàm API của Windows (hầu hết là các hàm cấp thấp hơn) không cho phép sử dụng dấu gạch chéo về phía trước - phải sử dụng dấu gạch chéo ngược .

Vâng, nhưng toàn bộ điều này là một điểm moot. Java chuyển đổi liền mạch các dấu gạch chéo về phía trước thành dấu gạch chéo ngược trên Windows. Bạn chỉ có thể sử dụng dấu gạch chéo về phía trước cho tất cả các đường dẫn được mã hóa cứng hoặc được lưu trữ trong cấu hình và nó sẽ hoạt động cho cả hai nền tảng.

Cá nhân, tôi luôn sử dụng dấu gạch chéo ngay cả trên Windows bởi vì nó là không phải là ký tự thoát. Cho dù đường dẫn thô nằm trong mã hoặc được đặt ngoài trong tệp thuộc tính, tôi mã hóa nó theo cùng một cách.

Thử nó! Điều này sẽ hoạt động trong Windows. Rõ ràng, thay đổi đường dẫn thực tế đến một cái gì đó tồn tại và người dùng của bạn có quyền đọc.

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

Phần thưởng: bạn thậm chí có thể trộn các dấu gạch chéo trong cùng một đường dẫn!

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

Một sự phức tạp khác trên Windows là nó cũng hỗ trợ ký hiệu UNC cũng như các ký tự ổ đĩa truyền thống.

Một tập tin trên một máy chủ tập tin từ xa có thể được truy cập như \\server\sharename\path\filename.

Không. Có nhiều thứ để suy nghĩ hơn là chỉ phân cách đường dẫn (điều "\ vs /"). Như Rob Y đề cập, có cách xử lý không gian và tần suất sử dụng Windows cao. Có hai nhân vật bất hợp pháp khác nhau trong hai môi trường. Có sự sẵn sàng của Unix để cho phép hầu hết mọi thứ khi thoát khỏi "\" hàng đầu. Có Windows sử dụng '"' để xử lý các không gian nhúng. Có sử dụng UCS-16 và Unix sử dụng ASCII hoặc UTF-8 của Windows.

vv , vv , vv

Nhưng , đối với nhiều ứng dụng có thể đặt các ràng buộc vào tên đường dẫn mà chúng cần thao tác, bạn thực sự có thể làm điều đó theo cách bạn đề xuất. Và nó sẽ hoạt động trong ít nhất một số lượng lớn các trường hợp, chỉ là không phải tất cả trong số họ.

Mọi hệ điều hành của Microsoft, bắt đầu với MS-DOS, đều hiểu, ở cấp độ kernel, cả dấu gạch chéo và dấu gạch chéo ngược .

Do đó, trên Windows, bạn có thể chuyển đổi giữa chúng một cách tự do; cả hai đều có trạng thái như nhau là dải phân cách dành riêng. Trong bất kỳ đường dẫn hợp lệ nào, bạn có thể thay thế dấu gạch chéo ngược bằng dấu gạch chéo và ngược lại, mà không thay đổi ý nghĩa của nó, theo như liên quan đến kernel.

Trong các phiên bản đầu của DOS, Microsoft command.com thông dịch đã biến nó thành một ưu tiên có thể định cấu hình, dấu gạch chéo được sử dụng để hiển thị và phân tích các đường dẫn. Điều đó cuối cùng đã được gỡ bỏ.

Một số chương trình không gian người dùng trong Windows như, ồ, Windows shell ( explorer.exe) không thích dấu gạch chéo về phía trước. Đó chỉ là lập trình kém chất lượng trong các chương trình đó.