https://www.opennet.dev/openforum/vsluhforumID3/72961.html Одна из неожиданных проблем, возникающих при обмене файлами с пользователями Windows - странное поведение ZIP-архивов. Казалось бы, достаточно правильно настроить кодировки... Не тут-то было!<br><br>Для текстовых файлов достаточно найти редактор с выбором кодировки, для дисков можно указать кодировку при монтировании, более "продвинутые" форматы архивов (RAR, 7zip) тоже как-то решают эту проблему; и только ZIP, самый распространённый и "самый совместимый" архиватор, почему-то неожиданно оказывается несовместимым в принципе, стоит именам файлов выйти за пределы ASCII.<br><br>Есть мнение, что в архивы ZIP имена файлов пишутся в кодировке файловой системы, и дескать, отсюда и проблемы - в Windows одна кодировка, а в Linux другая. И виноват в том устаревший архивный формат и сделать с этим ничего нельзя, а если очень хочется - переименовывать распакованные файлы скриптами и прочими костылями. Что ж, попробуем.<br><br>Однако попытка увидеть имена файлов путём перекодировки вида<br><br> ls -N &#124; iconv -f cp866<br><br>заканчивает https://www.opennet.dev/openforum/vsluhforumID3/72961.html#59 Mon, 12 Oct 2020 12:15:28 GMT На самом деле, алгоритм там чуууточку сложнее, ведь ещё и в ANSI зипы встречются (но чтоб без дублирования в UTF8 - исключительно редко). В скрипте ziplist это учитывается, совсем идеальный алгоритм можно подсмотреть там.<br> https://www.opennet.dev/openforum/vsluhforumID3/72961.html#58 Mon, 12 Oct 2020 11:48:00 GMT Удивительно, насколько ни один из архиваторов (в ключая unzip) на linux не в состоянии правильно определять кодировку зипов без подсказок.<br><br>Правильный алгоритм:<br><br>1. Есть ли в заголовке поле &#171;Unicode Path&#187; (0x7075)? Используем его, оно в UTF-8.<br>2. Установлен ли флаг Unicode (0x800) в поле &#171;Flags&#187;? Предполагаем, что поле &#171;Имя файла&#187; в UTF-8.<br>3. Имеет ли поле &#171;HostOS&#187; значения 0 (FAT) или 11 (NTFS)? Предполагаем, что поле &#171;Filename&#187; в кодировке OEM, соответствующей языку системы (соответствие кодировок языкам можно глянуть, например, в исходниках Wine).<br>4. Предполагаем, что поле &#171;Имя файла&#187; находится в UTF-8.<br><br>far2l (линуксовый порт far manager) делает это именно так, и в нём корректно открываются все протестированные зипы из моего зоопарка (там есть с винды, с макоси, с линукса, сделанные кучей упаковщиков разных версий).<br><br>На сладкое держите perl скрипт, определяющий правильную кодировку имени для каждого файла в zip архиве (да, они ещё и от https://www.opennet.dev/openforum/vsluhforumID3/72961.html#57 Sat, 05 Sep 2020 15:30:48 GMT Привет из будущего! Столкнулся с этой столетней проблемой, когда запускал unzip по SSH через PHP из-под WSL Win10 &#128563; Оказалось, что локаль консоли удаленного хоста зависит от локали локального хоста (и от настроек SSH), поэтому у меня при подключении из-под Windows была локаль C.UTF-8, а из-под соседних linux'ов en_US.UTF-8, и соответственно из-под linux все было нормально, имена файлов после unzip отображались корректно, а из-под windows - знаки вопроса.<br>Так что достаточно просто поменять локаль на en_US.UTF-8 или ru_RU.UTF-8. Надеюсь кому-то поможет.<br>php -r "print_r(shell_exec(\"ssh user@host 'LANG=ru_RU.utf8 && unzip filename.zip'\"));"<br> https://www.opennet.dev/openforum/vsluhforumID3/72961.html#56 Tue, 23 Jun 2020 14:01:49 GMT Я тут патчики написал к unzip и p7zip, которые раз и навсегда решают проблему с кодировками windows-архивов.<br><br>Вот тут всё лежит:<br>https://github.com/unxed/oemcp<br> https://www.opennet.dev/openforum/vsluhforumID3/72961.html#55 Sun, 21 Jun 2020 13:47:09 GMT В Manjaro KDE (в dolphin) такая проблема решилась после того, как я сделал следующее:<br><br># Удалил:<br>zip<br>unzip<br><br># Установил:<br>zip-natspec<br>unzip-natspec<br>libnatspec<br> https://www.opennet.dev/openforum/vsluhforumID3/72961.html#54 Wed, 21 Jan 2015 12:45:55 GMT Для меня лично наиболее удобным оказался вариант с mc. Миднайт командер, оказывается, нормально заходит в архивы с русскими именами. При копировании из архива в нужную директорию русские имена сохраняются. И никаких патчей.<br> https://www.opennet.dev/openforum/vsluhforumID3/72961.html#53 Sun, 15 Sep 2013 12:26:37 GMT Люто, бешено плюсую.<br>7z спасёт отцов русской демократии.<br> https://www.opennet.dev/openforum/vsluhforumID3/72961.html#52 Sat, 15 Dec 2012 10:33:52 GMT &gt; Не так уж всё и сложно :) <br>&gt; Что касается "сопровождения", то дистрибутивы, как правило, позволяют собирать не только <br>&gt; вручную, но и собирать пакеты, или подключать сторонние репозитории.<br>&gt; После установки пакетов их "сопровождение" ничем не отличается от всех прочих, а <br>&gt; работа с ними &#8211; от работы со оригинальными zip и unzip, <br>&gt; независимо от программ, которые их вызывают.<br><br>...<br><br>Ну-с, что кому кажется сложным или простым, тема вечная. По-моему, основывать решение на доп. библиотеке, которая угадывает (!) кодировку, это уже ошибка. А не угадает, тогда как? Или вот тут предлагали: то шелл-скрипты, то в два действия архив раскрывать.<br><br>Да вообще работа со сложно-уложенной информацией в консоли это скорее упражнение в йоге, но не работа. :)<br> https://www.opennet.dev/openforum/vsluhforumID3/72961.html#51 Sat, 15 Dec 2012 10:05:34 GMT Не так уж всё и сложно :)<br><br>Что касается "сопровождения", то дистрибутивы, как правило, позволяют собирать не только вручную, но и собирать пакеты, или подключать сторонние репозитории.<br>После установки пакетов их "сопровождение" ничем не отличается от всех прочих, а работа с ними &#8211; от работы со оригинальными zip и unzip, независимо от программ, которые их вызывают.<br><br>Для себя в ArchLinux я собрал пакеты, заменяющие zip и unzip, и положил в AUR:<br>http://aur.archlinux.org/packages/zip-natspec/<br>http://aur.archlinux.org/packages/unzip-natspec/<br>Для Убунты (к Дебиану тоже подходят) мои пакеты собрали без меня :)<br>http://launchpad.net/~frol/+archive/zip-i18n<br>Насчёт других дистров не знаю, но в случае чего можно поступить аналогично.<br><br>А кодировку libnatspec определяет самостоятельно, на основе языка локали. Если запустить с другой локалью, будет выбрана другая кодировка.<br>Юникодные архивы альтернативного формата infozip будут распаковываться как обычно, на это патчи не влияют.<br>