Zip-файлы расширяются с помощью обратной косой черты в Linux, без подкаталогов

Question

Итак, странно, я могу разархивировать файл, созданный другом на Windows. То, что он выдает, странно и неправильно, чего я раньше не видел.

<base directory stuff>
assets\Changes.txt
assets\DefaultConfig,txt

И так далее. Очевидно, это подкаталог, но они выходят в виде файлов с обратной косой чертой в них.

Они сделали это на Windows , (используя Сжать-архив PowerScript команды), я попытался извлечь его на Linux, используя как программу ark из KDE, а также архив-менеджер из GNOME.

Что тут происходит?

Answer 1

Это происходит потому, что некоторые инструменты Windows, очевидно, используют обратную косую черту (\) в качестве разделителя, где они должны использовать прямую косую черту (/). Обратная косая черта в Unix может быть частью имени файла или каталога.

,Спецификация формата файла ZIP (версия: 6.3.5, когда я пишу это, исправлено 20 ноября 2018 года) гласит:

4.4.17.1 Имя файла с необязательным относительным путем. Сохраненный путь НЕ ДОЛЖЕН содержать букву диска или устройства или начальную косую черту. Все косые черты ДОЛЖНЫ быть косыми чертами / в противоположность косым чертам \ для совместимости с файловыми системами Amiga и UNIX и т.д. Если ввод поступил со стандартного ввода, поле имени файла отсутствует.

Этот файл упоминается Microsoft в документе « Смягчение последствий: ZipArchiveEntry.FullName Path Separator:

Начиная с приложений, предназначенных для .NET Framework 4.6.1, разделитель пути используется в ZipArchiveEntry.FullName изменено с обратной косой черты (\), использовавшейся в предыдущих версиях .NET Framework, на прямую косую черту (/). [...]

Влияние

Это изменение приводит реализацию .NET в соответствие с разделом 4.4.17.1 .Формат файла ZIP Спецификация и позволяет.ZIP-архивы для распаковки в системах, отличных от Windows.

Распаковка zip-файла, созданного приложением, которое нацелено на предыдущую версию .NET Framework в операционных системах, отличных от Windows, таких как Macintosh, не может сохранить структуру каталогов. Например, на Macintosh он создает набор файлов, имя файла которых объединяет путь к каталогу, любые символы обратной косой черты (\) и имя файла. В результате структура каталогов распакованных файлов не сохраняется.

Обратите внимание, что проблема может существовать, если архиватор использовал какую-то старую версию .NET Framework или вообще не использовал ее, а реализовал свой собственный (независимый) подход к zip-файлам.

С rar может возникнуть та же проблема: Unrar создает файлы с обратным слешем в именах вместо правильной иерархии каталогов.

Вы можете найти этот вопрос в Unix & Linux SE полезным: Преобразование созданного в Windows ZIP в Linux (проблема с внутренними путями). Мой (несколько экспериментальный) подход заключается в этом ответе.

Answer 2

На самом деле это ошибка в Microsoft.PowerShell.Archive:

https://github.com/PowerShell/Microsoft.PowerShell.Archive/issues/48

... который будет решен в этом PR, запланированном для версии 1.2.3:

https://github.com/PowerShell/Microsoft.PowerShell.Archive/pull/62

А пока это быстрое решение (кредит):

for file in *\\*; do target="${file//\\//}"; mkdir -p "${target%/*}"; mv -v "$file" "$target"; done