Чому імена моїх файлів виглядають "нормально" в Linux, але не віддалено в Windows?

Працюючи з колегою, я виявив дивну проблему, яка, здається, пов'язана з кодуванням. Ми працюємо з деякими зображеннями , які мають досить прості імена файлів , таких як city.gifабо wine.gif, але як можна було б очікувати , все стає більш складним при використанні спеціальних символів , таких як é, ë, à. Ми також працюємо з голландськими даними, які містять ці символи, наприклад café( pub ). (У нас немає контролю над походженням файлів.) Ось де починають виникати проблеми. Наступні назви файлів - лише приклад. Проблема виникає і для інших персонажів з діакритикою.

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

Як можна сподіватися, перший рядок все ще має наголос e é , а третій - ні. Натомість я бачу ▒цей символ - який знаходиться medium shadeв унікоді (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 плутається? Сподіваємось, існує рішення, де ми можемо просто зв’язатися з нашим sysadmin та попросити їх увімкнути комутатор у конфігурації сервера, але я боюся, що це не так просто.

windows filenames character-encoding

— Брам Ванрой
джерело

Це питання клієнта (PuTTY тощо) та їх конфігурації, а не стосується Windows. Для PuTTY це робиться в розділі перекладу .

— Томас Дікі

Це виглядає так, що в "café-2.png" é зашифровано UTF-8, але é в "café.png" зашифровано ISO-8859-1. Можна бігти python -c "import sys; print(repr(sys.argv[1]))" café-2.pngі python -c "import sys; print(repr(sys.argv[1]))" café.png?

— Оскар скаго

@OskarSkog Я спробую це вранці. Але я завжди думав, що назви файлів не мають кодування, іншими словами: це так, як хоче цього ОС. Так це означатиме, що різні файли створювалися в різних ОС? (У нас немає контролю над походженням файлів.)

— Брам Ванрой

У unix, як операційні системи, ім'я файлу - це лише рядок байтів. Поняття персонажів виходить на більш високий рівень.

— Оскар скаго

Навіть не близька до відповіді чи рішення, просто думка про проспект, який слід шукати. З ОП виходить, що файли можуть мати різне походження, без контролю над іменем, згенерованим джерелом, і занадто пізно застосовувати фільтри для виправлення вхідного імені файлу snafus. Рішення, ймовірно, передбачає запуск сценарію на сервері, який може виявляти та виправляти помилки імен файлів, можливо навіть стандартизуючи набір символів / кодову сторінку, що використовується для імен. Тоді ОП може використовувати ту саму кодову сторінку у Filezilla чи іншому клієнті, і все буде працювати. Окрім моїх навичок, але, можливо, слід вести за собою

— користувач207673

Але ось приходить Windows!

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

Єдине, що робить Windows - це чітко показати, що тут відбувається. Ваша програма Windows FTP приймає байти у назви файлів і відображає їх як відповідні кодові пункти на кодовій сторінці 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
Той, що відображає лист é, повертається до коду сторінки, коли він стикається з невірним кодуванням.

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

— JdeBP
джерело

Я не згоден, що Windows не має до цього нічого спільного. Це, швидше за все, не станеться в інших Linux. Проблема полягає в кодуванні за замовчуванням, і afaik Windows використовував (або, принаймні, використовував) свою CP, а не UTF, внаслідок чого ця проблема виникає навіть в одній і тій же ОС у всіх країнах. Ви можете відтворити це в Linux, але Linux більш послідовний у виборі Unicode

— MatthewRock

Привіт там! Дякую за детальну відповідь. Ви орієнтуєтесь на те, що відбувається, що приємно: мені завжди подобається розуміти, що відбувається. Але чи не могли б ви пролити світло на те, чому це відбувається, і як ми можемо протистояти проблемам, які випливають із цієї невідповідності? Я додав два абзаци, щоб уточнити, що я маю на увазі.

— Брам Ванрой

Цікаво, чому обидва "кафе" показані однаковими, коли їх немає. Чи має ls (1) GNU смішне керування помилками кодування?

— Оскар скаго

@MatthewRock У цьому випадку я думаю, що Windows дійсно не має нічого спільного з цим. Я не задоволений більшою частиною того, що робить M $, і охоче визнаю багато своїх зл, але я не можу бачити провини в тому, де ніхто не належить. Оскільки відповідь зрозуміла, проблема полягає у значеннях байтів самих імен. У цьому випадку Windows виявила цей симптом, але це не проблема. Не більше, ніж термометр - це проблема, коли він показує, що ваша температура - 104 °. Проблема виникає з будь-якими процесами, створеними іменами на сервері, який містить файли, до яких намагається отримати доступ.

— користувач207673

Чи могли б ви надати більше інформації та можливих рішень? Інакше я витратив свій дар задарма.

— Брам Ванрой