Tại sao tên tệp của tôi trông 'bình thường' trong Linux nhưng không phải từ xa trên Windows?


11

Trong khi làm việc với một đồng nghiệp, tôi đã tìm thấy một vấn đề kỳ lạ có vẻ liên quan đến tiền mã hóa. Chúng tôi đang làm việc với một số hình ảnh mà có đủ tên tập tin đơn giản như city.gifhoặc wine.gif, nhưng như người ta có thể mong đợi nhận được những điều phức tạp hơn khi sử dụng ký tự đặc biệt như é, ë, à. Chúng tôi cũng đang làm việc với dữ liệu Hà Lan có các ký tự này, ví dụ: café( quán rượu ). (Chúng tôi không có quyền kiểm soát nguồn gốc của các tệp.) Đây là nơi các vấn đề bắt đầu phát sinh. Các tên tập tin sau đây chỉ là một ví dụ. Vấn đề cũng xảy ra đối với các nhân vật khác có dấu phụ.

café-2.png
cafetaria.png
café.png

Mục đầu tiên và cuối cùng nên có một dấu e ở đó (dấu aigu, é). Đó là cách nó được hiển thị trong Linux (CentOS 6 & 7) trong một thiết bị đầu cuối khi chạy ls. Nhưng đây là Windows! (Sử dụng Windows 10, 64 bit.) Khi được kết nối trên Windows thông qua SSL với máy chủ của chúng tôi và sau đó gọi ls, danh sách trên trông như thế này:

café-2.png
cafetaria.png
caf▒.png

Như bạn có thể hy vọng, dòng đầu tiên vẫn có dấu e é , nhưng dòng thứ ba thì không. Thay vào đó, tôi thấy ký tự này - medium shadeở dạng unicode (9618 thập phân). Điều này là lạ trong chính nó. Tuy nhiên, khi tôi kết nối qua SFTP với Filezilla (vẫn trên Windows), tôi nhận thấy điều này:

café-2.png
cafetaria.png
café.png

Vì vậy, bây giờ mọi thứ đã quay lại: trong phần đầu tiên, éđã thay đổi thành trình tự và trong phần thứ ba, mọi thứ đều ổn. Tôi thấy ở đây rằng điều này rất có thể là do chuyển đổi Latin-1 <-> UTF-8 đã sai, nếu tôi hiểu đúng. Nhưng đó không phải là tất cả những gì đang diễn ra, phải không?

Linux hiển thị mọi thứ như chúng ta mong đợi, Windows hiển thị hành vi dường như không nhất quán tùy thuộc vào cách chúng ta xem tên tệp (SSH (putty) hoặc SFTP (filezilla)). Có cách nào để 'bình thường hóa' các tên tệp này - tức là chỉnh sửa chúng - và đảm bảo rằng tất cả chúng đều giống nhau trên mọi HĐH; hoặc ít nhất là nhất quán, và nếu vậy, làm thế nào? UTF-8là mã hóa của sự lựa chọn của chúng tôi.

Mặc dù điều này có thể chỉ đơn thuần là một vấn đề thẩm mỹ, nhưng nó không phải là. Khi cố tải xuống mọi thứ thông qua SFTP trong Windows từ máy chủ Linux của chúng tôi, tôi không thể tải xuống các tệp có vấn đề được đề cập ở trên. Filezilla sẽ đưa ra một lỗi như Can't download file café-2.png: café-2.png does not exist on the server. Dường như với tôi rằng Filezilla đọc thư mục và tên tệp, diễn giải nó trong một số mã hóa, gửi yêu cầu GET đến máy chủ với cách giải thích của nó, nhưng cách giải thích đó khác với tên tệp Linux do đó không tìm thấy tệp.

Cuối cùng, thật tuyệt nếu có một giải pháp khả dụng, mặc dù tôi cũng quan tâm đến lý do tại sao điều này xảy ra. Có xảy ra do các tệp hình ảnh có thể được tạo trên các Hệ điều hành khác nhau không? Có xảy ra do máy chủ Linux giải thích chúng sai hay Windows bị rối không? Hy vọng có một giải pháp mà chúng ta có thể chỉ cần liên hệ với sysadmin của mình và yêu cầu họ bật công tắc trong cấu hình máy chủ, nhưng tôi sợ nó không dễ như vậy.


1
Đó là vấn đề của máy khách (PuTTY, v.v.) và cấu hình của chúng và không liên quan đến Windows. Đối với PuTTY, điều đó được thực hiện trong phần dịch thuật .
Thomas Dickey

2
Trông giống như é trong "café-2.png" được mã hóa UTF-8, nhưng é trong "café.png" được mã hóa ISO-8859-1. Bạn có thể chạy python -c "import sys; print(repr(sys.argv[1]))" café-2.pngpython -c "import sys; print(repr(sys.argv[1]))" café.png?
Oskar Skog

@OskarSkog Tôi sẽ thử nó vào buổi sáng. Nhưng tôi luôn nghĩ rằng tên tệp không 'có' mã hóa, nói cách khác: đó là hệ điều hành muốn. Vì vậy, điều đó có nghĩa là các tệp khác nhau đã được tạo trên các hệ điều hành khác nhau? (Chúng tôi không kiểm soát nguồn gốc của các tệp.)
Bram Vanroy

Trên unix như các hệ điều hành, tên tệp chỉ là một chuỗi byte. Khái niệm nhân vật đến ở cấp độ cao hơn.
Oskar Skog

1
Thậm chí không gần với một câu trả lời, hoặc một giải pháp, chỉ đơn thuần là một suy nghĩ về con đường để theo đuổi. Từ OP, dường như các tệp có thể có nguồn gốc, không kiểm soát được tên do nguồn tạo ra và đã quá muộn để áp dụng các bộ lọc để sửa snafus tên tệp đến. Giải pháp có thể liên quan đến việc chạy tập lệnh trên máy chủ có thể phát hiện và sửa lỗi tên tệp, thậm chí có thể tiêu chuẩn hóa bộ ký tự / trang mã được sử dụng cho tên. Sau đó, OP có thể sử dụng cùng một trang mã trong Filezilla hoặc ứng dụng khách khác và mọi thứ sẽ hoạt động. Ngoài kỹ năng của tôi, nhưng có thể dẫn theo, có thể.
dùng207673

Câu trả lời:


11

Nhưng đây là Windows!

Windows không có gì để làm với điều này. Bạn có thể sao chép hành vi này chính xác cùng với một trường hợp địa phương (nói) GNOME Terminal, với mã hóa thiết bị đầu cuối được lựa chọn một cách thích hợp và miền địa phương được cấu hình một cách thích hợp cho ls, mà không cần bất kỳ Windows là trong hình ở tất cả .

Điều duy nhất mà Windows làm là hiển thị rõ ràng những gì đang diễn ra ở đây. Chương trình FTP Windows của bạn đang lấy các byte trong tên tệp và hiển thị chúng dưới dạng các điểm mã có liên quan trong trang mã 1252. Đây là mã hóa một byte với hầu hết mọi thứ trên 0x1F một glyph có thể in được, cho chúng ta biết chính xác các byte trong tên tệp của bạn là gì .

Tên tệp thứ hai của bạn chủ yếu là không thông tin, nhưng thứ nhất và thứ ba đang nói.

  • Tên tệp đầu tiên là chuỗi byte 63 61 66 c3 a9 2d 32 2e 70 6e 67- Trong trang mã 1252, đây là café-2.png. Nó cũng là mã hóa UTF-8 của café-2.png.
  • Tên tệp thứ ba là chuỗi byte 63 61 66 e9 2e 70 6e 67- Trong trang mã 1252, đây là café.png. Tuy nhiên, đây không phải là mã hóa UTF-8 hợp lệ. e9bắt đầu một chuỗi mã hóa ký tự không đầy đủ.

Vì vậy, điều đang xảy ra là những thứ không sử dụng mã trang 1252 mà đang sử dụng UTF-8, cụ thể là phiên SSH và trình giả lập thiết bị đầu cuối cục bộ của bạn, đang xử lý UTF-8 hợp lệ giống như cách khác nhưng đang xử lý các hợp lệ UTF-8 theo hai cách khác nhau:

  • Người đang hiển thị đồ họa khối rất có thể chỉ đơn giản là sử dụng đồ họa khối đó làm ký tự đầu ra thay thế chung cho các chuỗi UTF-8 không hợp lệ.
  • Chữ cái đang hiển thị chữ cái érơi trở lại Mã 1252 khi nó gặp mã hóa không hợp lệ.

Vấn đề tiềm ẩn của bạn là một hệ thống bằng cách nào đó tạo ra một số tên tệp được mã hóa dưới dạng UTF-8 và các tên tệp khác được mã hóa trong Mã Trang 1252.


Tôi không đồng ý rằng Windows không có gì để làm với điều này. Nó có thể sẽ không xảy ra trên Linux khác. Vấn đề là mã hóa mặc định và afaik Windows đã (hoặc ít nhất là đã có) sử dụng CP của họ chứ không phải UTF, dẫn đến sự cố này xảy ra ngay cả trên cùng một hệ điều hành trên khắp các quốc gia. Bạn có thể tái tạo điều này trên Linux, nhưng Linux nhất quán hơn trong việc chọn Unicode
MatthewRock

Chào bạn Cảm ơn câu trả lời công phu. Bạn tập trung vào những gì đang xảy ra, điều này thật tuyệt: tôi luôn muốn hiểu những gì đang xảy ra. Nhưng có lẽ bạn có thể làm sáng tỏ lý do tại sao điều này xảy ra, và làm thế nào chúng ta có thể chống lại các vấn đề xảy ra sau sự không nhất quán này? Tôi đã thêm hai đoạn để làm rõ những gì tôi muốn nói.
Bram Vanroy

Tôi tự hỏi tại sao cả hai "quán cà phê" được hiển thị giống nhau khi họ không. Ls (1) của GNU có xử lý lỗi mã hóa lố bịch không?
Oskar Skog

@MatthewRock Trong trường hợp này tôi nghĩ Windows thực sự không liên quan gì đến nó. Tôi không hài lòng với hầu hết những gì M $ làm, và sẵn sàng thừa nhận nhiều tệ nạn của nó, nhưng tôi không thể thấy sự đổ lỗi được đưa ra khi không có gì đến hạn. Khi câu trả lời rõ ràng, vấn đề là ở chính các giá trị byte của tên. Trong trường hợp này, Windows đã để lộ triệu chứng này, nhưng không phải là vấn đề. Không quá nhiệt kế là vấn đề khi nó cho thấy cơn sốt của bạn là 104 °. Vấn đề bắt nguồn từ bất kỳ quy trình nào đã tạo ra các tên trên máy chủ có các tệp mà OP đang cố truy cập.
dùng207673

Bạn có thể cung cấp thêm thông tin và giải pháp có thể? Nếu không, tôi đã dành tiền thưởng của tôi cho không có gì.
Bram Vanroy
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.