Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Раздел полезных советов: Работа с русскими именами файлов в ..."	+3 +/–
Сообщение от auto_tips (?), 30-Ноя-10, 23:16
Одна из неожиданных проблем, возникающих при обмене файлами с пользователями Windows - странное поведение ZIP-архивов. Казалось бы, достаточно правильно настроить кодировки... Не тут-то было! Для текстовых файлов достаточно найти редактор с выбором кодировки, для дисков можно указать кодировку при монтировании, более "продвинутые" форматы архивов (RAR, 7zip) тоже как-то решают эту проблему; и только ZIP, самый распространённый и "самый совместимый" архиватор, почему-то неожиданно оказывается несовместимым в принципе, стоит именам файлов выйти за пределы ASCII. Есть мнение, что в архивы ZIP имена файлов пишутся в кодировке файловой системы, и дескать, отсюда и проблемы - в Windows одна кодировка, а в Linux другая. И виноват в том устаревший архивный формат и сделать с этим ничего нельзя, а если очень хочется - переименовывать распакованные файлы скриптами и прочими костылями. Что ж, попробуем. Однако попытка увидеть имена файлов путём перекодировки вида    ls -N | iconv -f cp866 заканчивается провалом. Ладно, не подошла 866, перебираем все известные русские кодировки и все виды юникода - имена файлов остаются нечитаемыми. Что же это за кодировка такая в зипе?! Поиски в сети дают результат - оказывается, надо так:    ls -N | iconv -f cp1252 -t cp850 | iconv -f cp866 Перекодировать распакованные файлы в utf-8 можно следующей командой:    find . -type f -exec sh -c 'np=`echo {}|iconv -f cp1252 -t cp850| iconv -f cp866`; mv "{}" "$np"' \; Битые имена файлов уходят, остаётся вопрос - неужели в зипе правда такая странная кодировка? Что-то сомнительно. Ищем дальше и натыкаемся на разгадку. http://www.linuxfromscratch.org/blfs/view/cvs/general/unzip.... "[]The UnZip package assumes that filenames stored in the ZIP archives created on non-Unix systems are encoded in CP850, and that they should be converted to ISO-8859-1 when writing files onto the filesystem. Such assumptions are not always valid. In fact, inside the ZIP archive, filenames are encoded in the DOS codepage that is in use in the relevant country, and the filenames on disk should be in the locale encoding. In MS Windows, the OemToChar() C function (from User32.DLL) does the correct conversion (which is indeed the conversion from CP850 to a superset of ISO-8859-1 if MS Windows is set up to use the US English language), but there is no equivalent in Linux. When using unzip to unpack a ZIP archive containing non-ASCII filenames, the filenames are damaged because unzip uses improper conversion when any of its encoding assumptions are incorrect. For example, in the ru_RU.KOI8-R locale, conversion of filenames from CP866 to KOI8-R is required, but conversion from CP850 to ISO-8859-1 is done, which produces filenames consisting of undecipherable characters instead of words (the closest equivalent understandable example for English-only users is rot13).[]" Другими словами, имена файлов в ZIP-архиве хранятся в кодировке DOS, соответствующей языку локали. В Windows эта кодировка может быть получена соответствующей функцией, а для прочих систем авторы Info-ZIP решили не возиться и схалтурили - сделали безальтернативное преобразование cp850=>cp1252. Вот, где зарыта собака! Нет никакой "уникальной кодировки ZIP", там обычная 866 (для русской локали). Во всём прочем виноват не устаревший формат, а версия unzip от Info-ZIP для *nix, которая неправильно работает со всеми локалями, отличными от западноевропейских. Что делать? Патчить. Можно, конечно, обойтись разовым переименованием, но только в разовых случаях. Если такие архивы встречаются часто, или их надо создавать, выбора не остаётся, нужен нормальный инструмент, а не костыли. В сети есть разные патчи для zip и unzip от разных авторов и для различных версий, однако многие из них устарели, а некоторые небеспроблемны. Я остановился на патчах от АльтЛинукса. Проблему определения кодировки DOS они решили путём использования своей библиотеки [[http://www.freesource.info/wiki/Lokalizacija/NATSPECDescription libnatspec]], которую перед этим придётся установить, брать можно тут: http://sourceforge.net/projects/natspec/ После её установки актуальные кодировки локали можно проверить командой    natspec -i Патч для unzip-6.0 подошел почти гладко, осталось исправить только две мелких детали. Патчи для zip оказались для предыдущей версии, поэтому пришлось повозиться немного больше, однако оно того стоило - теперь я могу спокойно распаковывать созданные в Windows zip-архивы просто командой unzip, и точно так же упаковывать командой zip, не опасаясь битой кодировки на том конце. Итак, качаем исходник последней стабильной версии unzip [[ftp://ftp.info-zip.org/pub/infozip/src/unzip60.tgz unzip60.tgz]] и исправленную версию патча [[http://www.opennet.dev/soft/zip_rus/unzip60-natspec-mod.diff.gz unzip60-natspec-mod.diff.gz]], распаковываем исходник, переходим в его директорию, патчим, собираем и устанавливаем:    zcat ../unzip60-natspec-mod.diff.gz | patch -p1    make -f unix/Makefile generic_gcc и от рута    make -f unix/Makefile install После этого unzip должен правильно распаковывать zip-архивы с русскими именами файлов, и правильно же выводить их в консоли. Теперь то же самое с zip - берём последнюю версию [[ftp://ftp.info-zip.org/pub/infozip/src/zip30.tgz zip30.tgz]], и к нему мой патч [[http://www.opennet.dev/soft/zip_rus/zip30-natspec-asdos-mod.d... natspec-asdos-mod.diff.gz]]. Распаковываем исходник, и в его директории:    zcat ../zip30-natspec-asdos-mod.diff.gz | patch -p1    make -f unix/Makefile generic_gcc и от рута    make -f unix/Makefile install Теперь мы можем упаковывать zip-архивы в виде, полностью совместимом с проводником Windows и даже с TotalCommander. С последним оказалось, как ни странно, даже больше проблем - он требовал архив не просто в кодировке DOS, а непременно с именами в формате DOS, часть патча "asdos" именно для этого. Что особенно забавно, в TotalCommander использован код всё того же проекта Info-ZIP. Возможно, некоторые спросят - зачем столько возни с этим морально устаревшим зипом, когда полно приличных архиваторов на любой вкус? Ответ - для совместимости, больше ни для чего ZIP и не нужен. А раз так, то пускай он делает своё дело как надо, а не как всегда :) URL: Обсуждается: http://www.opennet.dev/tips/info/2494.shtml
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по ответам | RSS]

1. Сообщение от Natrio (?), 30-Ноя-10, 23:16	+/–
Чуть не забыл – ссылки оригинальные патчи от AltLinux и их обсуждения: http://sisyphus.ru/ru/srpm/Sisyphus/unzip/patches http://sisyphus.ru/ru/srpm/Sisyphus/zip/patches https://bugzilla.altlinux.org/show_bug.cgi?id=4871 https://bugzilla.altlinux.org/show_bug.cgi?id=12562
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #5, #9, #11, #33

2. Сообщение от Аноним (-), 30-Ноя-10, 23:35	+/–
Можно просто распаковать в корень уже собранные пакеты unzip от альта с того же сизифа.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #6

3. Сообщение от Anonym (?), 01-Дек-10, 00:04	+/–
Проще отказаться от Zip, чем заниматься пропатчиванием
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #4, #8, #22

4. Сообщение от iZEN (ok), 01-Дек-10, 02:24	+/–
Ношу ZIP-архивы с русскими именами файлов, сделанные под Windows, на работу. Там распаковываю, пакую в 7-Zip и приношу домой. :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3

5. Сообщение от iZEN (ok), 01-Дек-10, 02:25	+/–
> Чуть не забыл – ссылки оригинальные патчи от AltLinux и их обсуждения: > http://sisyphus.ru/ru/srpm/Sisyphus/unzip/patches > http://sisyphus.ru/ru/srpm/Sisyphus/zip/patches > https://bugzilla.altlinux.org/show_bug.cgi?id=4871 > https://bugzilla.altlinux.org/show_bug.cgi?id=12562 А в майнстрим Info-ZIP слабо закинуть?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #7

6. Сообщение от Natrio (?), 01-Дек-10, 08:28	+/–
Я очень благодарен авторам патчей из AltLinux, и я дал ссылки на оригинал. Однако мне пришлось добавить кое-что от себя, чтобы zip и unzip не только правильно обрабатывали файлы, но и правильно выводили имена в консоли. В тексте даны уже мои патчи, сделанные на основе оригинальных.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2

7. Сообщение от Natrio (?), 01-Дек-10, 08:36	+/–
Многие уже пробовали "закинуть" подобные патчи в мэйнстрим Info-ZIP, но их либо отклоняли, либо удаляли в следующей версии. Разработчики Info-ZIP занимаются новой версией формата, рассматривая его как предпочтительный. Авторам же патчей ZIP требуется лишь для совместимости, а для всего остального у них есть другие архиваторы. Взаимопонимания в такой ситуации достичь сложно. Тем более с моим английским ;)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5

8. Сообщение от Natrio (?), 01-Дек-10, 08:49	+/–
Я могу отказаться от ZIP, но не могу заставить отказаться от него тех, кто приносит/присылает/выкладывает такие архивы, а также тех, у кого никакие другие просто не откроются. ZIP нужен именно для этого.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3

9. Сообщение от john (??), 01-Дек-10, 11:17	+/–
При распаковке имена на русском zipinfo - дает абракадабру или набор '?????'
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #10

10. Сообщение от Natrio (?), 01-Дек-10, 11:27	+/–
Оригинальные unzip и zipinfo, будучи собранными с опциями по умолчанию, при выводе в консоль заменяю вопросительными знаками всё, что выходит на пределы ASCII. Есть опция NO_SETLOCALE, которая снимает блокировку, и в моём патче эта опция включена. Оригинальный zip при упаковке файлов выводит их имена в консоль в кодировке архива, то есть неправильно. В моём патче это исправлено, и имена выводятся в консоль без изменений.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9 Ответы: #12

11. Сообщение от Natrio (?), 01-Дек-10, 11:39	+/–
А это мои патчи (ссфлки есть в тексте статьи): http://www.opennet.dev/soft/zip_rus/unzip60-natspec-mod.diff.gz http://www.opennet.dev/soft/zip_rus/zip30-natspec-asdos-mod.d...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

12. Сообщение от john (??), 01-Дек-10, 13:08	+/–
> Оригинальные unzip и zipinfo, будучи собранными с опциями по умолчанию, при выводе > в консоль заменяю вопросительными знаками всё, что выходит на пределы ASCII. > Есть опция NO_SETLOCALE, которая снимает блокировку, и в моём патче эта > опция включена. > Оригинальный zip при упаковке файлов выводит их имена в консоль в кодировке > архива, то есть неправильно. В моём патче это исправлено, и имена > выводятся в консоль без изменений. Да, это работает - большое спасибо!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10

13. Сообщение от Andrey Mitrofanov (?), 01-Дек-10, 14:08	+/–
>| iconv -f cp1252 -t cp850 | iconv -f cp866 Вариант: |recode lat1..850,866..   , может быть, |recode -f lat1..850,866..   , если будет на чём спотыкаться. unzip -l $file |recode -f 8859-1..850,866.. -работает, теперь ждём Совета, какой recode нужен для 7z l $file | .... :)
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #14, #15

14. Сообщение от Natrio (?), 01-Дек-10, 14:45	+/–
Нет, у 7z со своими и раровскими архивами всё нормально. А вот зип он распаковывает своеобразно – имена в кодировке cp866, но с лишним левым байтом перед каждым символом. Но это всё костыли. Я перед тем, как занялся патчами, сам соорудил два работающих скрипта – один для переименования после распаковки, другой с распаковкой через трубу и сохранение в файле с перекодированным именем. Первый вариант требует заранее подготовить пустой каталог (а в норме unzip распаковывает файлы в любой), второй вариант сопровождается потерей всех даты и времени всех файлов, что тоже не всегда хорошо. И оба совершенно негибкие.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #16

15. Сообщение от Natrio (?), 01-Дек-10, 15:48	+/–
По уточнённым данным, 7z (p7zip) под Linux начинает распаковывать zip–архивы в неискаженной кодировке cp866, если указать ему ключ -no-utf16 или установить переменную LC_CTYPE в любое значение, отличное от пустой строки.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #25

16. Сообщение от x0r (??), 01-Дек-10, 15:55	+/–
отправте пожалуйста багрепорт
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14

17. Сообщение от Аноним (-), 02-Дек-10, 06:37	+/–
А AltLinux-у отправили свои улучшенные патчи?
Ответить | Правка | Наверх | Cообщить модератору

18. Сообщение от мше (?), 02-Дек-10, 08:53	+/–
> более "продвинутые" форматы архивов (RAR, 7zip) тоже как-то решают эту проблему; нифига они не решают. вон у меня щас лежит rar, который даже не распаковывается
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #19

19. Сообщение от Natrio (?), 02-Дек-10, 09:18	+/–
Чем именно не распаковывается? Последнее время появилась новая модификация архивов .rar, и для их распаковки нужна новая версия unrar. Если вы пользуетесь p7zip, то в него она включена, кажется, с 9й версии. Не спрашивайте меня, зачем разработчики winrar это сделали – вопрос к ним :) Но к кодировкам всё это отношения не имеет. Не буду говорить за всех, но с 9й версией p7zip у меня не возникает проблем с распаковкой созданных в Windows .rar и .7z архивов, а созданные им под Linux архивы .7z нормально открываются 7zip под Windows.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #23

20. Сообщение от fank (?), 02-Дек-10, 13:10	+/–
о, сколько лисапетов сразу rusxmms.sf.net удивитесь, как грамотные люди давным давно решили все эти проблемы
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #21

21. Сообщение от Natrio (?), 02-Дек-10, 16:58	+/–
ЗдОрово! А патчи для unzip-6.0 и zip-3.0 уже есть?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20 Ответы: #24

22. Сообщение от vovans (ok), 02-Дек-10, 21:51	+/–
конечно, можно ля-лякать, если с реальными людьми не общаешься... Но задолбёшься каждому объяснять... Не стоит на пустом месте раздражаться и раздражать других. Если есть возможность в течении нескольких минут исправить ситуацию раз и надолго, то нечего мозги компостировать себе и людям.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3

23. Сообщение от мше (?), 03-Дек-10, 11:45	+/–
хм... действительно
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19

24. Сообщение от fank (?), 03-Дек-10, 18:48	+/–
> ЗдОрово! А патчи для unzip-6.0 и zip-3.0 уже есть? сарказм? (С) Sheldon Cooper видимо, перцу, что это написал, надоело упрашивать дубоватых иностранцев и каждому объяснять, что за зоопарк местные девелоперы изобрели - патчи там скорее всего устарели, но все они описаны и не думаю, что сильно сложно допинать их для новых версий заявляется, что патчится все в несколько строк кода
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21

25. Сообщение от h31 (ok), 03-Дек-10, 21:29	+/–
Бесполезно. Помогли только патчи от RusXMMS.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15 Ответы: #38

26. Сообщение от StrangeAttractor (ok), 07-Дек-10, 23:51	+/–
Спасибо. А как тут статью плюсануть?
Ответить | Правка | Наверх | Cообщить модератору

27. Сообщение от ананим (?), 08-Дек-10, 23:54	+/–
предпочитаю использовать fuse-zip - man fuse-zip fuse-zip - a FUSE filesystem for zip archives with write support ....        If you want to specify character set conversion for file names in archive, use the following fusermount options:          -omodules=iconv,from_code=$charset1,to_code=$charset2 .... DESCRIPTION        fuse-zip  is  a  fuse  filesystem,  that enables any program to work with a ZIP archive as though it is a plain directory.  Unlike KIO or Gnome VFS, it can be used in any application without modifications.        Unlike other FUSE filesystems, only fuse-zip provides write support to ZIP archives.  Also, fuse-zip is faster that all known implementations on large archives with many files.
Ответить | Правка | Наверх | Cообщить модератору

28. Сообщение от autopilot (?), 10-Дек-10, 11:47	+/–
Debian 4 Etch + unzip-5.52-9etch1 на хостинге при распаковке кодировка битая, однако это фиксится в php, кроме одной вредной буквы 'Ш'-большая, которая, как выяснилось, просто проглатывается в процессе распаковки. В листинге же эта буква остается. Случайно выяснилось, когда залили архив с файликом городка "Шахунья.jpg". Рекомендую для проверки патчей и локалей обратить на это внимание.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #29

29. Сообщение от Natrio (?), 10-Дек-10, 11:51	+/–
Проверил – у моих патченых zip и unzip такой ошибки нет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28

30. Сообщение от prof_alex (?), 11-Дек-10, 01:57	+/–
Что-то не пойму. Собрал unzip из calculate emerge -vp unzip These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild   R   ] app-arch/unzip-6.0-r9  USE="bzip2 natspec unicode" 0 kB [1] Total: 1 package (1 reinstall), Size of downloads: 0 kB Portage tree and overlays: [0] /usr/portage [1] /var/lib/layman/calculate Всё вроде есть: natspec -i libnatspec 0.2.6, compiled Aug  3 2010 === Overall information === Current locale: ru_RU.UTF-8 System locale: ru_RU.UTF-8 Filename encoding in iconv/nls form: utf8 Country ID (for DOS): -1 Codepage of DOS: 866 Charset of 'UNIX' system: UTF8 Charset of 'WIN' system: CP1251 Charset of 'DOS' system: IBM866 Charset of 'MAC' system: MACCYRILLIC After setlocale:     nl_langinfo(CODESET): UTF-8     natspec_get_charset: UTF8 Current locale is in UTF8 encoding unzip -l UnZip 6.00 of 20 April 2009, by ALT Linux Team.  Original by Info-ZIP. Usage: unzip [-Z] [-opts[modifiers]] file[.zip] [list] [-x xlist] [-d exdir]   Default action is to extract files in list, except those in xlist, to exdir;   file[.zip] may be a wildcard.  -Z => ZipInfo mode ("unzip -Z" for usage).   -p  extract files to pipe, no messages     -l  list files (short format)   -f  freshen existing files, create none    -t  test compressed archive data   -u  update files, create if necessary      -z  display archive comment only   -v  list verbosely/show version info       -T  timestamp archive to latest   -x  exclude files that follow (in xlist)   -d  extract files into exdir modifiers:   -n  never overwrite existing files         -q  quiet mode (-qq => quieter)   -o  overwrite files WITHOUT prompting      -a  auto-convert any text files   -j  junk paths (do not make directories)   -aa treat ALL files as text   -U  use escapes for all non-ASCII Unicode  -UU ignore any Unicode fields   -C  match filenames case-insensitively     -L  make (some) names lowercase   -X  restore UID/GID info                   -V  retain VMS version numbers   -K  keep setuid/setgid/tacky permissions   -M  pipe through "more" pager   -O CHARSET  specify a character encoding for DOS, Windows and OS/2 archives   -I CHARSET  specify a character encoding for UNIX and other archives See "unzip -hh" or unzip.txt for more help.  Examples:   unzip data1 -x joe   => extract all files except joe from zipfile data1.zip   unzip -p foo | more  => send contents of foo.zip via pipe into program more   unzip -fo foo ReadMe => quietly replace existing ReadMe if archive file newer А листинг с вопросами: unzip -lO IBM866 SP\ 41\ 108.zip Archive:  SP 41 108.zip   Length      Date    Time    Name ---------  ---------- -----   ----    448972  10-10-2008 09:46   ???? 41-108-2004 ???????????????????????? ????????????????????????????.pdf ---------                     -------    448972                     1 file Написал своё, без natspec на python: ./pyunzip.py -l SP\ 41\ 108.zip Archive:  SP 41 108.zip   Length      Date    Time    Name ---------  ---------- -----   ----    448972  2008-10-10 09:46   СП 41-108-2004 ПОКВАРТИРНОЕ ТЕПЛОСНАБЖЕНИЕ.pdf ---------                     -------    448972                     1 files Можно привести примеры использования?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #31

31. Сообщение от Natrio (?), 11-Дек-10, 09:52	+/–
Чуть выше я уже писал, что unzip/zipinfo, собранный без опции NO_SETLOCALE, при выводе в консоль заменяет все не-ASCII символы вопросительными знаками. Мой патч к unzip http://pda.opennet.ru/soft/zip_rus/unzip60-natspec-mod.diff.gz как раз и отличается от альтовского патча включением этой опции. Другой способ её включить – задать для сборки unzip переменную окружения    LOCAL_UNZIP="-DNO_SETLOCALE" Опции -I и -O нужны ТОЛЬКО для случаев, когда вам требуется задать кодировки отличные от тех, что выдаёт natspec. Если кодировка архива совпадает с определённой natspec DOS-кодировкой, то никаких дополнительных ключей не требуется:    $ unzip -l ../test.zip    Archive:  ../test.zip      Length      Date    Time    Name    ---------  ---------- -----   ----            0  12-03-2010 21:23   тест/            7  12-03-2010 21:23   тест/эюя            7  12-03-2010 21:23   тест/абв           17  12-10-2010 11:49   Шах и мат.txt    ---------                     -------           31                     4 files
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30

32. Сообщение от Forth (??), 12-Дек-10, 14:55	+/–
Использую ваш патч, в unzip появились опции -I и -O и все равно вопросики в консоли. :( Система - Fedora 14. Где копать?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #34, #35

33. Сообщение от sanek (??), 12-Дек-10, 15:04	+/–
Zip & русские имена, поможем решить этот баг? Нужна ваша помощь!      Ребята, многие из вас любят голосовать и так далее, я предлагаю вам сделать полезную для всего сообщества вещь. Необходимо будет потратить всего лишь пару минут на регистрацию и зарегистрироваться на оф. ресурсе https://launchpad.net/ И проголосовать вот за решение этого бага: Проголосовать можно здесь: https://bugs.launchpad.net/ubuntu/+source/unzip/+bug/580961 Учитывая что там в баге в комментах идёт мощный срач, просьба НИЧЕГО там не писать, просто нажать ссылку Does this bug affect you? И выбрать в выпадающем меню Yes, it affects me Я уже проголосовал. Ссылка на форум откуда взято- http://forum.ubuntu.ru/index.php?topic=124286.0
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

34. Сообщение от Natrio (?), 13-Дек-10, 09:14	+/–
Нет у меня федоры, проверить не могу. Могу подсказать следующее: 1) Мой патч http://www.opennet.dev/soft/zip_rus/unzip60-natspec-mod.diff.gz должен накладываться на оригинальный unzip-6.0 : ftp://ftp.info-zip.org/pub/infozip/src/unzip60.tgz 2) В моём патче включена опция NO_SETLOCALE. Если это так, она должна присутствовать в выводе команды сборки. То есть, после    make -f unix/Makefile generic_gcc в выводе должно часто присутствовать -DNO_SETLOCALE Если нет – значит сборка идёт как-то неправильно, или наложенный патч – не мой. 3) После сборки с моим патчем unzip устанавливается в /usr/bin/ Возможно, у вас уже установлена другая версия в /usr/local/bin/ , которая обычно имеет более высокий приоритет в переменной $PATH. Если это так, то одна из версий явно лишняя.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32

35. Сообщение от Natrio (?), 13-Дек-10, 09:17	+/–
4) Вопросики только в консоли? Имена распакованных файлов правильные?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32

36. Сообщение от Yo (??), 13-Дек-10, 13:56	+/–
# можно и так: zipinfo -1 my.zip | while read z do u=$(echo "$z"|iconv -f cp866) unzip my.zip "$z" && mv -i "$z" "$u" done
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #37

37. Сообщение от Natrio (?), 14-Дек-10, 08:43	+/–
Не получится. 1) Непатченный unzip/zipinfo выводит имена с перекодировкой cp850 => cp1252. Поэтому в вашем примере надо сначала обратить её, а потом уже переводить из cp866 :    iconv -f cp1252 -t cp850 | iconv -f cp866 подробности в статье выше. 2) Во многих дистрибутивах unzip/zipinfo собран БЕЗ опции NO_SETLOCALE, и потому будет выводить в консоль все имена в виде "?????". Перекодировка после этого, естественно, уже невозможна.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36

38. Сообщение от sergey (??), 16-Дек-10, 13:45	+1 +/–
7z l -no-utf16 <fname>.zip | iconv -f cp866 толькочо проверил
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25

39. Сообщение от pva0xd (ok), 23-Дек-10, 17:38	+/–
Natrio, а не могли бы вы пояснить в каких случаях нужена опция -K? И вообще зачем изменёно умолчание для dosify?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #41

40. Сообщение от RUR (?), 24-Дек-10, 12:51	+/–
По мотивам Yo, создаём бат файл: echo 'zipinfo -1 $1 | while read z; do u=$(echo "$z"|iconv -f cp1252 -t cp850|iconv -f cp866); unzip $1 "$z" && mv -i "$z" "$u"; done' > brusunzip chmod +x brusunzip brusunzip my.zip
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #42

41. Сообщение от Natrio (?), 24-Дек-10, 12:55	+/–
Опция -K обратна опции -k, то есть отключает "dosify". Умолчание изменено для совместимости с win-програмами. В частности, TotalCоmmander не видит русских имён файлов, если архив упакован БЕЗ опции dosify.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39

42. Сообщение от Natrio (?), 24-Дек-10, 13:01	+/–
Я начинал именно с таких скриптов, только получаются они очень неуклюжими. Кроме того, zipinfo, будучи собранным без дополнительных опций (у меня так и было), НЕ ВЫВОДИТ русские имена в консоль, заменяя их на ?????, то есть эти скрипты на половине систем не будут работать без пересборки пакета unzip. А если уж пересобирать, то я решил лучше пропатчить и больше не мучаться со скриптами.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40

43. Сообщение от lucentcode (ok), 07-Апр-11, 01:49	–1 +/–
C unzip 6.0.1 вы можете использовать опцию -O cp866 когда надо распаковать файл, пожатый в windows.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #44

44. Сообщение от aleks (??), 03-Мрт-12, 23:10	+/–
> C unzip 6.0.1 вы можете использовать опцию -O cp866 когда надо распаковать > файл, пожатый в windows. В ман не нашел такой опции
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #43

45. Сообщение от aleks (??), 03-Мрт-12, 23:13	+/–
Ну и в догонку под bsd 7.3 отлично работает такой способ например: 7z e -no-utf16 jtv.zip convmv -f cp866 -t koi8-r * --notest
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #46

46. Сообщение от Natrio (?), 03-Мрт-12, 23:37	+/–
Возможно, но статья не об этом, а о том, как НОРМАЛЬНО работать в *nix с ОБЫЧНЫМИ, то есть DOS/Win zip-архивами.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #45 Ответы: #47

47. Сообщение от aleks (??), 04-Мрт-12, 02:10	+/–
Ок, поясню. В приведенном мною примере jtv.zip архив тот самый виндовый архив, при распаковке unzipом оного можно увидеть кривую кодировку названий файлов. Приведенный мною пример как раз показывает как можно НОРМАЛЬНО работать с такими архивами.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46 Ответы: #48

48. Сообщение от Natrio (?), 04-Мрт-12, 08:51	+/–
В статье выше тоже приводятся примеры таких костылей, только это не называется "нормально работать". Это называется "перекодировать кривую кодировку имён файлов после распаковки", это ДАВНО ИЗВЕСТНО, и статья совсем не об этом. В статье предлагается пропатчить zip и unzip, чтобы имена файлов всегда правильно упаковывались и распаковывались.    zip -r фрхив.zip файлы и каталоги    unzip архив.zip Также после этого можно использовать GUI-шные оболочки, которые используют zip и unzip для упаковки и распаковки. Мне известны пакеты с этими патчами для ubuntu/debian https://launchpad.net/~frol/+archive/zip-i18n и для ArchLinux: http://aur.archlinux.org/packages.php?ID=47921 https://aur.archlinux.org/packages.php?ID=47920
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #47 Ответы: #49

49. Сообщение от aleks (??), 04-Мрт-12, 20:32	+/–
Эта статья как раз из серии "а  мыши кололись, плакали, но продолжали жрать кактус" как ни посмотри. > В статье предлагается пропатчить zip и unzip, чтобы имена файлов всегда правильно > упаковывались и распаковывались. Да вот это и есть костыли. ППЦ сделать костыли для костылей. Зачем? Есть нормальный продукт 7z где уже из "коропки" все распаковывается и тут же можно перевести в нужную кодировку, замечу без всяких патчей и прочей заумной мути. Просто написать одну строчку и вуаля. Куда проще то? Нет, конечно, можно с умным видом ложить патчи какие-то чето там пересобирать и еще держать в уме а как же на других серваках не забыть потом это все проделать или помнить... Бред. Не работает это глюкалово unzip ну и нафиг его есть другие инструменты которые могут это сделать быстро и парой команд.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #48 Ответы: #53

50. Сообщение от Ю.Т. (?), 15-Дек-12, 13:37	+/–
> Одна из неожиданных проблем, возникающих при обмене файлами с пользователями Windows - > странное поведение ZIP-архивов. Казалось бы, достаточно правильно настроить кодировки... > Не тут-то было! ... Да, это полезный совет. Всё верно. Пока существуют винды и WinZip и InfoZip, придётся иметь дело с архивами, из которых файлы на юниксах будут извлекаться с искорёженными названиями. Но! Описанное решение проблемы, по-моему, не лучше самой проблемы, имея в виду его собственную сложность и трудоёмкость поддержки. Я то же самое давно решаю несколько иначе и, мне кажется, удобнее. Правда, я ничего не делал с zip-ом. Что же сделано? Во-первых, исключены все переделки кодировок в процедурах вывода unzip -- в трёх местах (два в fileio.c и одно, кажется, в list.c) три вызова спрятаны под комментарий. Эти места легко отыскиваются во всех версиях unzip от 5-й до 6-й, и вполне просто переделываются. Во-вторых, пересобранный unzip называется, скажем, unzip0, и укладывается хоть бы и в ~/bin. В-третьих, немного дорабатываются скрипты работы с "файловой системой UZIP" из состава midnight commander (т.е., открытие архивов как обычных каталогов). В них: (а) меняются вызовы unzip на unzip0; (б) добавляется перекодировка получаемого списка названий с помощью iconv (этот тул давно присутствует во всех линуксах из коробки, и даже в freebsd без него не обходятся); (в) изменённые скрипты (их можно сделать несколько, для разных кодировок исходного архива) укладываются в ~/.mc/ или ~/.config/mc (зависит от версии mc). После этого можно в коммандере, как обычно, открывать архивы как каталоги, работать с файлами и т.д. Достоинства изложенного здесь решения: 1) делается просто 2) даёт удобный инструмент 3) не требует целовать никаких разработчиков ни в какие места 4) сохраняет работоспособность при сменах дистрибутива и даже, с очевидными мелкими доработками, при сменах системы в пределах юниксов. Наконец, оно оставляет возможность выбора окончательного решения за человеком, как самым лучшим опознавателем кодировок. :) Недостатки изложенного здесь решения: 1) влияет лишь на один инструмент (mc) и не влияет на unzip общесистемной доступности 2) требует кой-каких дополнительных движений в mc (active VFS list->Free VFSs now и что-то вроде cd abc.zip#uzipu), если кодировка в архиве была не предугаданной (не той, с которой работает доработанный mc-ский скрипт для uzip).
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #51

51. Сообщение от Natrio (?), 15-Дек-12, 14:05	+/–
Не так уж всё и сложно :) Что касается "сопровождения", то дистрибутивы, как правило, позволяют собирать не только вручную, но и собирать пакеты, или подключать сторонние репозитории. После установки пакетов их "сопровождение" ничем не отличается от всех прочих, а работа с ними – от работы со оригинальными zip и unzip, независимо от программ, которые их вызывают. Для себя в ArchLinux я собрал пакеты, заменяющие zip и unzip, и положил в AUR: http://aur.archlinux.org/packages/zip-natspec/ http://aur.archlinux.org/packages/unzip-natspec/ Для Убунты (к Дебиану тоже подходят) мои пакеты собрали без меня :) http://launchpad.net/~frol/+archive/zip-i18n Насчёт других дистров не знаю, но в случае чего можно поступить аналогично. А кодировку libnatspec определяет самостоятельно, на основе языка локали. Если запустить с другой локалью, будет выбрана другая кодировка. Юникодные архивы альтернативного формата infozip будут распаковываться как обычно, на это патчи не влияют.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #50 Ответы: #52

52. Сообщение от Ю.Т. (?), 15-Дек-12, 14:33	+/–
> Не так уж всё и сложно :) > Что касается "сопровождения", то дистрибутивы, как правило, позволяют собирать не только > вручную, но и собирать пакеты, или подключать сторонние репозитории. > После установки пакетов их "сопровождение" ничем не отличается от всех прочих, а > работа с ними – от работы со оригинальными zip и unzip, > независимо от программ, которые их вызывают. ... Ну-с, что кому кажется сложным или простым, тема вечная. По-моему, основывать решение на доп. библиотеке, которая угадывает (!) кодировку, это уже ошибка. А не угадает, тогда как? Или вот тут предлагали: то шелл-скрипты, то в два действия архив раскрывать. Да вообще работа со сложно-уложенной информацией в консоли это скорее упражнение в йоге, но не работа. :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #51

53. Сообщение от Хрен с горы (?), 15-Сен-13, 16:26	+/–
Люто, бешено плюсую. 7z спасёт отцов русской демократии.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #49

54. Сообщение от uropb (??), 21-Янв-15, 15:45	+/–
Для меня лично наиболее удобным оказался вариант с mc. Миднайт командер, оказывается, нормально заходит в архивы с русскими именами. При копировании из архива в нужную директорию русские имена сохраняются. И никаких патчей.
Ответить | Правка | Наверх | Cообщить модератору

55. Сообщение от x230 (ok), 21-Июн-20, 16:47	+/–
В Manjaro KDE (в dolphin) такая проблема решилась после того, как я сделал следующее: # Удалил: zip unzip # Установил: zip-natspec unzip-natspec libnatspec
Ответить | Правка | Наверх | Cообщить модератору

56. Сообщение от Аноним (56), 23-Июн-20, 17:01	+/–
Я тут патчики написал к unzip и p7zip, которые раз и навсегда решают проблему с кодировками windows-архивов. Вот тут всё лежит: https://github.com/unxed/oemcp
Ответить | Правка | Наверх | Cообщить модератору

57. Сообщение от Лев (?), 05-Сен-20, 18:30	+/–
Привет из будущего! Столкнулся с этой столетней проблемой, когда запускал unzip по SSH через PHP из-под WSL Win10 😳 Оказалось, что локаль консоли удаленного хоста зависит от локали локального хоста (и от настроек SSH), поэтому у меня при подключении из-под Windows была локаль C.UTF-8, а из-под соседних linux'ов en_US.UTF-8, и соответственно из-под linux все было нормально, имена файлов после unzip отображались корректно, а из-под windows - знаки вопроса. Так что достаточно просто поменять локаль на en_US.UTF-8 или ru_RU.UTF-8. Надеюсь кому-то поможет. php -r "print_r(shell_exec(\"ssh user@host 'LANG=ru_RU.utf8 && unzip filename.zip'\"));"
Ответить | Правка | Наверх | Cообщить модератору

58. Сообщение от Аноним (56), 12-Окт-20, 14:48	+/–
Удивительно, насколько ни один из архиваторов (в ключая unzip) на linux не в состоянии правильно определять кодировку зипов без подсказок. Правильный алгоритм: 1. Есть ли в заголовке поле «Unicode Path» (0x7075)? Используем его, оно в UTF-8. 2. Установлен ли флаг Unicode (0x800) в поле «Flags»? Предполагаем, что поле «Имя файла» в UTF-8. 3. Имеет ли поле «HostOS» значения 0 (FAT) или 11 (NTFS)? Предполагаем, что поле «Filename» в кодировке OEM, соответствующей языку системы (соответствие кодировок языкам можно глянуть, например, в исходниках Wine). 4. Предполагаем, что поле «Имя файла» находится в UTF-8. far2l (линуксовый порт far manager) делает это именно так, и в нём корректно открываются все протестированные зипы из моего зоопарка (там есть с винды, с макоси, с линукса, сделанные кучей упаковщиков разных версий). На сладкое держите perl скрипт, определяющий правильную кодировку имени для каждого файла в zip архиве (да, они ещё и отличаться могут!): https://github.com/unxed/oemcp/blob/master/ziplist А, да, ещё есть версия p7zip с этим алгоритмом в комплекте, вот прям сразу .deb для amd64, работающий на всём, что не старше убунты 20.04 https://github.com/unxed/oemcp/blob/master/p7zip-oemcp.deb установка этой штуки чинит зипы в engrampa в mint, например
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #59

59. Сообщение от Аноним (56), 12-Окт-20, 15:15	+/–
На самом деле, алгоритм там чуууточку сложнее, ведь ещё и в ANSI зипы встречются (но чтоб без дублирования в UTF8 - исключительно редко). В скрипте ziplist это учитывается, совсем идеальный алгоритм можно подсмотреть там.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #58

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема