Почему мои имена файлов выглядят «нормально» в Linux, а не удаленно в Windows?

Во время работы с коллегой я обнаружил странную проблему, которая, похоже, связана с кодированием. Мы работаем с некоторыми изображениями , которые имеют достаточно простые имена файлов , таких как city.gifили wine.gif, но как можно было бы ожидать , все становится более сложным при использовании специальных символов , таких как é, ë, à. Мы также работаем с голландскими данными, в которых есть эти символы, например café( паб ). (У нас нет контроля над происхождением файлов.) Здесь начинаются проблемы. Следующие имена файлов являются лишь примером. Эта проблема также возникает для других персонажей с диакритическими знаками.

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

На первом и последнем элементе должен быть акцентирован знак e (акцент aigu, é). Вот как это показано в Linux (CentOS 6 и 7) в терминале при запуске ls. Но здесь идет Windows! (Использование Windows 10, 64-разрядная версия.) При подключении к Windows через SSL с нашим сервером и последующем вызове lsприведенный выше список выглядит следующим образом:

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

Как вы можете видеть , надеюсь, первая линия до сих пор имеет ударение е é , но третий один не делает. Вместо этого я вижу ▒этот символ - который medium shadeв Unicode (9618 десятичных). Это странно само по себе. Однако, когда я соединяюсь через SFTP с Filezilla (все еще в Windows), я вижу это:

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

Так что теперь все éизменилось : в первом все изменилось в последовательности, а в третьем все хорошо. Я обнаружил здесь, что это наиболее вероятно из-за преобразования Latin-1 <-> UTF-8, которое пошло не так, если я понял это правильно. Но это не может быть все, что происходит, верно?

Linux показывает все так, как мы ожидаем, Windows демонстрирует внешне противоречивое поведение в зависимости от того, как мы видим имя файла (SSH (putty) или SFTP (filezilla)). Есть ли способ «нормализовать» эти имена файлов - т.е. отредактировать их - и убедиться, что они все одинаковы в каждой ОС; или хотя бы непротиворечиво, и если да, то как? UTF-8наша кодировка выбора.

Хотя это может быть просто эстетической проблемой, это не так. При попытке загрузить вещи через SFTP в Windows с нашего сервера Linux, я не могу загрузить файлы, имеющие проблему, упомянутую выше. Filezilla выдаст ошибку, такую ​​как Can't download file café-2.png: café-2.png does not exist on the server. Мне кажется, что Filezilla читает каталог и имя файла, интерпретирует его в некоторой кодировке, отправляет запрос GET на сервер с его интерпретацией, но эта интерпретация отличается от имени файла Linux, поэтому файл не найден.

В конечном итоге было бы неплохо, если бы было доступно решение, хотя меня также интересует, почему это происходит. Это происходит потому, что файлы изображений были созданы в разных операционных системах? Это происходит из-за того, что сервер Linux неправильно их интерпретирует, или из-за ошибки в Windows? Надеемся, что есть решение, в котором мы можем просто связаться с нашим системным администратором и попросить его включить переключатель в конфигурации сервера, но, боюсь, это не так просто.

Но здесь идет Windows!

Windows не имеет ничего общего с этим. Вы можете воспроизвести это же точное поведение с локальным экземпляром (скажет) GNOME Terminal, с соответствующим выбранным терминалом кодированием и соответствующим образом настроенными локал для ls, без какого - либо Windows , будучи в картине вообще .

Единственное, что делает Windows, это четко показывает, что здесь происходит. Ваша FTP-программа для Windows берет байты в именах файлов и отображает их как соответствующие кодовые точки в кодовой странице 1252. Это однобайтовая кодировка с почти всем, что больше 0x1F для печатаемого глифа, точно говорит нам, какие байты в ваших именах файлов ,

Ваше второе имя файла в значительной степени неинформативно, но первое и третье говорят.

• Первое имя файла - это последовательность байтов 63 61 66 c3 a9 2d 32 2e 70 6e 67- в кодовой странице 1252 это так café-2.png. Это также кодировка UTF-8 café-2.png.
• Третье имя файла - это последовательность байтов 63 61 66 e9 2e 70 6e 67- в кодовой странице 1252 это так café.png. Это, однако, не является действительной кодировкой UTF-8. e9начинается неполная последовательность кодирования символов.

Таким образом, все происходит не с использованием кодовой страницы 1252, а с использованием UTF-8, а именно сеанс SSH и эмулятор локального терминала, обрабатывают действительный UTF-8 так же, как друг друга, но обрабатывают недопустимый UTF-8 двумя различными способами:

• Тот, который отображает графику блока, очень просто использует эту графику блока в качестве основного выходного символа замены для недопустимых последовательностей UTF-8.
• Тот, который отображает букву, éвозвращается к кодовой странице 1252, когда обнаруживает недопустимую кодировку.

Ваша основная проблема - это система, которая каким-то образом генерирует некоторые имена файлов, закодированные как UTF-8, и другие имена файлов, закодированные в кодовой странице 1252.