Локаль: utf-8, ALT Linux 4.0 Desktop. Кириллические имена файлов в zip-архивах показываются квадратиками, аргумент -O не работает. Раньше всё работало без проблем.
(In reply to comment #0) > Раньше всё работало без проблем. Раньше -- это когда? В Desktop работает? Если нет -- вешайте на Desktop.
Два года назад патч был еще живой, нтересно, когда он отвалился... Буду копать, но код там бредовый... Жутко бредовый...
Раньше - это месяц назад в Сизифе. Сейчас не работает ни в Сизифе, ни в Desktop
(In reply to comment #3) > Раньше - это месяц назад в Сизифе. Сейчас не работает ни в Сизифе, ни в > Desktop Это действительно блокер. Евгений, можно исправить быстро?
Да, при LANG=ru_RU.UTF8 выводит в консоль в CP866. А вот никакого ключа -O я не нашёл у unzip.
[cas@cas ~]$ unzip -v | grep Maint UnZip 5.52 of 28 February 2005, by Info-ZIP. Maintained by C. Spieler. Send [cas@cas ~]$ unzip -h | grep CHARSET -O CHARSET specify a character encoding for DOS, Windows and OS/2 archives -I CHARSET specify a character encoding for UNIX and other archives
Created attachment 2119 [details] Патч, использующий natspec и корректный буфер Проблема старого патча была в следующем: - в нём использовалась таблица из нескольких кодировок, в которой не было UTF8 - в качестве размера буфера использовалась длина исходной строки, что делало невозможным перекодирование из CP866 в UTF-8 (строка не влезала)
Created attachment 2120 [details] Патч к спеку для сборки с новым патчем natspec Если нужно, я могу и залить пакет. Было бы отлично, если кто-то ещё проверит.
(In reply to comment #8) > Created an attachment (id=2120) [edit] > Патч к спеку для сборки с новым патчем natspec > > Если нужно, я могу и залить пакет. Было бы отлично, если кто-то ещё проверит. Твой пакет работает. Из консоли и в file-roller. А вот в Ark имя файла обрезается. Тут уж надо KDE патчить.
А какой длины обрезаемые имена? Возможно в unzip стоит увеличить лимит, если там ошибка в условиях, то там может быть 255 как предел (соотв. 127 символов) P.S. Мне ещё и Ark патчить? Я могу :) Если меня не заставят потом патч пропихивать :)
> Мне ещё и Ark патчить? Я могу :) Если меня не заставят потом патч > пропихивать :) См. https://bugzilla.altlinux.org/show_bug.cgi?id=12418 и пиши Zerg. В исходниках идут жестокие хаки вывода и, похоже, строка неправильно преобразуется.
Проверено на .zip "имени winrar" и "имени winxp" (правда, не совсем понятно, не причастен ли и тут случайно winrar) -- замечательно работает.
не работает на zip имени gmail alt2 работает alt4 нет
Created attachment 2326 [details] пример файла
Проблема с русскими именами в zip принципиально нерешаема! То, что у нас сделано - это грязный хак, а zip имени gmail нарушает даже те размытые стандарты, которые есть на кодирование не-ascii символов. Теоретически можно написать аутоугадав на базе enca или чего-то подобного, но это сложно и я за это не возьмусь. Давайте закончим это тем, что ни в одной операционной системе, ни с одним вариантом архиватора(консольного или графического) нельзя гарантированно получить русские имена из архива. Для данного архива комманда unzip -O utf8 может быть использована
2 eostapets: BTW видел https://bugzilla.altlinux.org/show_bug.cgi?id=4871#c12 ?
Не знаю, не знаю. Дописать проверку, что имя в архиве написано в utf8 - легко. И "архивы имени gmail" будут тоже нормально открываться. Они так сделали, потому что а) у них Linux б) другого варианта на будущее - нет Правда смысла с ничем не совместимом решении нет... А проблема с русскими именами решаема и решена практически.
https://bugzilla.altlinux.org/show_bug.cgi?id=4871#c15
Проблема с кодировкой названий файлов в zip имени gmail (https://bugzilla.altlinux.org/attachment.cgi?id=2326) воспроизводится: > $ unzip 12313-gmail.zip > Archive: 12313-gmail.zip > inflating: ╨║╨╛╨╗╨╗╨╡╨║╤В╨╕╨▓╨б╨б.odt > inflating: ╨╗╨╕╤З╨╜╨╛╤Б╤В╤М╨б╨б.odt > inflating: ╨╜╨░╤Б╨╗╨╡╨┤╤Б╤В╨▓╨╡╨╜╨╜╨╛╤Б╤В╤М╨б╨б.odt > inflating: ╨┐╨░╨╝╤П╤В╤М╨б╨б.odt > inflating: ╨┐╨╡╨┤╨╛╨╗╨╛╨│╨╕╤П╨б╨б.odt > inflating: ╨┐╨╛╨╜╤П╤В╨╕╨╡╨б╨б.odt > inflating: ╤А╨╡╨▒╨╡╨╜╨╛╨║╨б╨б.odt > inflating: ╤А╨╡╨║╨░╨┐╨╕╤В╤Г╨╗╤П╤Ж╨╕╤П╨б╨б.odt > inflating: ╨б╨╛╨╖╨╜╨░╨╜╨╕╨╡╨б╨б.odt > inflating: ╤Б╨╛╤Ж╨╕╨░╨╗╤М╨╜╨░╤П╤Б╨╕╤В╤Г╨░╤Ж╨╕╤П╤А╨░╨╖╨▓╨╕╤В╨╕╤П╨б╨б.odt > inflating: ╤Б╤А╨╡╨┤╨░╨б╨б.odt Как описано в https://bugzilla.altlinux.org/show_bug.cgi?id=12313#c15, `-O utf8` помогает: > $ unzip -O utf8 12313-gmail.zip > Archive: 12313-gmail.zip > inflating: коллективСС.odt > inflating: личностьСС.odt > inflating: наследственностьСС.odt > inflating: памятьСС.odt > inflating: педологияСС.odt > inflating: понятиеСС.odt > inflating: ребенокСС.odt > inflating: рекапитуляцияСС.odt > inflating: СознаниеСС.odt > inflating: социальнаяситуацияразвитияСС.odt > inflating: средаСС.odt Воспроизводится на виртуальных машинах: [p10] unzip-6.0-alt5.x86_64 kworkstation-10.1-x86-64 education-10.1-x86-64 education-10.1-x86-64-kde workstation-10.1-x86-64 server-10.1-x86-64 [sisyphus] unzip-6.0-alt5.x86_64 kworkstation-10.1-x86-64 education-10.1-x86-64 education-10.1-x86-64-kde workstation-10.1-x86-64 server-10.1-x86-64
> $ locale > LANG=ru_RU.UTF-8 > LC_CTYPE="ru_RU.UTF-8" > LC_NUMERIC="ru_RU.UTF-8" > LC_TIME="ru_RU.UTF-8" > LC_COLLATE="ru_RU.UTF-8" > LC_MONETARY="ru_RU.UTF-8" > LC_MESSAGES="ru_RU.UTF-8" > LC_PAPER="ru_RU.UTF-8" > LC_NAME="ru_RU.UTF-8" > LC_ADDRESS="ru_RU.UTF-8" > LC_TELEPHONE="ru_RU.UTF-8" > LC_MEASUREMENT="ru_RU.UTF-8" > LC_IDENTIFICATION="ru_RU.UTF-8" > LC_ALL=
(Ответ для Artem Varaksa на комментарий #19) > Проблема с кодировкой названий файлов в zip имени gmail Кто сформировал такой .zip и как сформировать такой самостоятельно? Если в нём не указало, что имена файлов юникодные, то он должен через natspec определить cp1251 и перекодировать из неё в кодировку локали. Т.е. сперва надо убедиться, что .zip сформирован корректно.
Created attachment 14015 [details] Пример (архив с wormhole) (Ответ для Sergey V Turchin на комментарий #21) > (Ответ для Artem Varaksa на комментарий #19) > > Проблема с кодировкой названий файлов в zip имени gmail > Кто сформировал такой .zip и как сформировать такой самостоятельно? Это zip из вложения в этой ошибке, добавленный в https://bugzilla.altlinux.org/show_bug.cgi?id=12313#c14 (также см. предыдущий комментарий c13). > $ zipinfo 12313-gmail.zip > Archive: 12313-gmail.zip > Zip file size: 378359 bytes, number of entries: 11 > -rw---- 2.0 fat 10940 bl defN 07-Dec-13 01:03 ╨║╨╛╨╗╨╗╨╡╨║╤В╨╕╨▓╨б╨б.odt > [...] > 11 files, 391320 bytes uncompressed, 376693 bytes compressed: 3.7% Другой пример ============= Такая же проблема происходит с zip имени https://wormhole.app (пример zip добавлен вложением): 1. $ touch тест1.txt && touch тест2.txt 2. https://wormhole.app > Select files to send > выбрать 2 файла. 3. Открыть отображаемую ссылку > Download all files. 4. Выполнить команду вида: > $ unzip "Wormhole ABCDE.zip" > Archive: Wormhole ABCDE.zip > extracting: ╤В╨╡╤Б╤В1.txt > extracting: ╤В╨╡╤Б╤В2.txt > $ unzip -O utf8 "Wormhole ABCDE.zip" > Archive: Wormhole ABCDE.zip > extracting: тест1.txt > extracting: тест2.txt > $ zipinfo "Wormhole ABCDE.zip" > Archive: Wormhole ABCDE.zip > Zip file size: 258 bytes, number of entries: 2 > -rw---- 2.0 fat 0 b- stor 23-Aug-08 14:25 ╤В╨╡╤Б╤В1.txt > -rw---- 2.0 fat 0 b- stor 23-Aug-08 14:25 ╤В╨╡╤Б╤В2.txt > 2 files, 0 bytes uncompressed, 0 bytes compressed: 0.0% Дополнительно ============= При создании архива через Engrampa (mate-file-archiver) наблюдается интересное поведение - похоже, корректное, но 'continuing with "central" filename version' не отображается в архивах из https://bugzilla.altlinux.org/43687, https://bugzilla.altlinux.org/21137 - в архивов из тех ошибок сразу используются правильные имена. 1. $ touch тест1.txt && touch тест2.txt 2. Используя графический интерфейс, открыть Стандартные/Прочие/Инструменты > Менеджер архивов Engrampa. 3. Выбрать Архив > Создать > ввести имя test.zip > Создать. 4. Выбрать Правка > Добавить файлы > выбрать тест1.txt, тест2.txt > Добавить. 5. Выполнить: > $ rm -fv тест*; unzip test.zip; ls -l | grep тест > удалён 'тест1.txt' > удалён 'тест2.txt' > Archive: test.zip > тест1.txt: mismatching "local" filename (тест1.txt), > continuing with "central" filename version > extracting: тест1.txt > тест2.txt: mismatching "local" filename (тест2.txt), > continuing with "central" filename version > extracting: тест2.txt > -rw-r--r-- 1 test test 0 янв 1 12:34 тест1.txt > -rw-r--r-- 1 test test 0 янв 1 12:34 тест2.txt
(Ответ для Artem Varaksa на комментарий #22) > Такая же проблема происходит с zip имени https://wormhole.app А как вы определили, что он формирует корректный zip-файл? У меня по главной странице сайта уже есть сомнения.
Для справки, аналогичная проблема воспроизводится с архивом с mail.yandex.ru: https://bugzilla.altlinux.org/43687 (Неверное отображение имён файлов в кирилице из zip архива). Возможно, эти ошибки стоит объединить.
Домклик, например, делает zip-ы, которые нормально отображаются.
(Ответ для Artem Varaksa на комментарий #24) > mail.yandex.ru И у них может быть кривой. > Возможно, эти ошибки стоит объединить. Думаю, да.
*** Bug 43687 has been marked as a duplicate of this bug. ***
7zip с моим патчем: https://salsa.debian.org/debian/7zip/-/merge_requests/8/diffs Нормально открывает Attachments_xxx_2022-09-03_13-44-29.zip (это который с mail.yandex.ru) и архивы с wormhole Гляньте там алгоритм, как кодировка выбирается. Можно также в исходники far2l посмотреть, алгоритм разрабатывался для него, я потом по аналогии в 7zip сделал: https://github.com/elfmz/far2l/blob/master/multiarc/src/formats/zip/zip.cpp В re.zip с gmail, увы, с кодировкой проблема. Там, похоже, utf-8 в полях, где должны быть имена в однобайтной кодировке. Чтоб открыть такое правильно, нужно уметь как-то отличать такие архивы от стандартных. Рискну преположить, что можно использовать для этого бит 8 (в стандарте он unused, а в re.zip — единица) из поля General Purpose Flag. Но. Я только что скачал с gmail архив с файлами с русскими именами, и там уже всё в порядке: имя в utf8 лежит в поле UnicodeName, как и положено. Так что ничего нам делать тут не надо, это был баг в gmail и они его починили. Для самостоятельно изучения: zipdetails ./re.zip Стандарт: https://users.cs.jmu.edu/buchhofp/forensics/formats/pkzip.html Так что надёжный способ извлечь русские имена из зипа всё-таки существует :) Если найдёте экзотику, которую не ест 7zip с моим патчем — пишите, погляжу, можно ли поправить. Если кто-то логику из 7zip с моим патчем перетащит в unzip - буду благодарен! PS: libnatspec сознательно не использую, т.к. в большинстве дистров его нету. Увы, проще вклеить в архиватор таблички "локаль-кодировка" для OEM и ANSI, чем протащить natspec в дистры. Для дальнейшего изучения: https://sourceforge.net/p/sevenzip/bugs/2473/ https://sourceforge.net/p/infozip/bugs/43/
Ой, бит в General Purpose не 8й, а 4й. В общем, это в любом случае уже не особо важно, но если интересно, посмотреть можно, опять-таки, в выводе zipdetails ./re.zip
Архив из https://bugzilla.altlinux.org/21137 7zip с моим патчем тоже нормально показывает
Так, я вам снова наврал, в re.zip стоит не 4й бит General purpose, а третий, потому что считаются они с нуля. А третий бит это флаг Streamed, что к кодировке очевидо отношения не имеет. На использование UTF-8 вместо однобайтных кодировок указывает бит 11, но он тут не установлен, так что это действительно именно в gmail баг был и сейчас исправлен. Ссылку на стандарт оставлю тут на всякий случай тоже https://pkwaredownloads.blob.core.windows.net/pkware-general/Documentation/APPNOTE-6.3.9.TXT
(Ответ для Ivan Sorokin на комментарий #28) ... > PS: libnatspec сознательно не использую, т.к. в большинстве дистров его > нету. Увы, проще вклеить в архиватор таблички "локаль-кодировка" для OEM и > ANSI, чем протащить natspec в дистры. Наоборот, в большинстве дистров он есть, а в чём проблема протащить? Собрал так же, как архиватор.
Написал в русскую Википедию, как работать с кодировками в zip'ах, чтоб нормально русские буквы работали. В основном на основе документации на стандарт, однако использование ANSI кодировки в zip'ах в Windows не особо где документировано (найдёте — делитесь!), поэтому там я экспериментально выяснял, пробуя сделать архив на разных версиях ОС и разными архиваторами. https://ru.wikipedia.org/wiki/.ZIP#%D0%9F%D1%80%D0%BE%D0%B1%D0%BB%D0%B5%D0%BC%D1%8B_%D0%B8%D0%BD%D1%82%D0%B5%D1%80%D0%BD%D0%B0%D1%86%D0%B8%D0%BE%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7%D0%B0%D1%86%D0%B8%D0%B8
В Дебиане libnatspec не находится: https://packages.debian.org/search?keywords=libnatspec&searchon=names&suite=stable§ion=all Там есть только закрытый RFP с последним комментарием «это никому не нужно»: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=545151 В Федоре вот есть пакет, да, вижу. Но Дебиан и его производные это слшиком большая доля дистров, чтоб просто забить на них. А из ppa никто ничего ставить не будет, люди лишком ленивы. Впрочем, написал знакомому мэйнтейнеру, спросил. Может, добавят всё-таки, т.к. есть конкретная логичная причина: из всех поддерживающих .zip архиваторов её дергать можно будет, а не дублировать каждый раз все таблицы.
Добавить libnatspec в Дебиан можно, но нужен доброволец мейнтейнером! Если такой есть, надо написать мне в Телеграм: https://t.me/unxed
(Ответ для Ivan Sorokin на комментарий #35) > Добавить libnatspec в Дебиан можно, но нужен доброволец мейнтейнером! Если > такой есть, надо написать мне в Телеграм: https://t.me/unxed Если никого не найдётся, я хотел бы им стать.
Отлично! Предлагаю подождать недельку, не отзовётся ли кто-нибудь ещё, и, если нет, свяжу вас с человеком, который готов подсказать, как всё это делается.
Держите unzip с нормальной поддержкой кодировок! https://github.com/unxed/unzip/tree/ubuntu Нюансы: 1) Тут всё сделано поверх полного набора патчей из Ubuntu, в истории коммитов это отражено. То есть из этой репы можно сделать новый патч и добавить его в Ubuntu последним, и всё взлетит, по идее. Сделано так потому, что я не хотел забирать чужой код (с поддержкой опций -I и -O) в свой патч, как бы воруя авторство, а хотел дополнить его корректным автоопределением кодировки. 2) Пока нет поддержки архивов с ANSI кодировкой (экзотика, но встречается). Впрочем, её там не было и раньше. Ключевой коммит собственно вот: https://github.com/unxed/unzip/commit/19a05fb096447344aae629d89eea18ed72356070
В этой версии работает всё перечисленное здесь, кроме re.zip (но это бага в gmail уже исправленная) и архивов с wormhole (сейчас разберусь, почему, и попробую поправить тоже; видимо, в unzip где-то часть логики определения utf8 упущена).
Ага, unzip не знает про 11й бит в general purpose flag. Вот и не понимает архив с Wormhole. Это должно быть несложно поправимо.
Починил 11 бит. Теперь всё работает как с моим патчем к 7zip, за исключением ANSI архивов без дублирования имён файлов в UTF-8, которые ещё пойди найди.
(Ответ для Vitaly Lipatov на комментарий #36) > (Ответ для Ivan Sorokin на комментарий #35) > > Добавить libnatspec в Дебиан можно, но нужен доброволец мейнтейнером! Если > > такой есть, надо написать мне в Телеграм: https://t.me/unxed > > Если никого не найдётся, я хотел бы им стать. Напишите Dmitry Shachnev на mitya57@debian.org, пожалуйста! Или приходите в телеграм-чат far2l, мы там обсуждаем это всё https://t.me/far2l_ru
ANSI архивы тоже починил
Версия поверх убунтовой серии патчей: https://github.com/unxed/unzip/tree/ubuntu То же самое для дебиана: https://github.com/unxed/unzip/tree/debian
