Activity for unxed
-
unxed posted a comment on ticket #1173
Screenshot showing sample.mp3 in qmmp's playlist.
-
ID3v1 tags with non-latin chars are displayed incorrectly
-
В taglib у себя это чинить не хотят. Делайте, пишут, кастомный класс StringHandler
-
Вот тут патчик к taglib чисто для демонстрации, как это исправить можно: https://github.com/taglib/taglib/issues/129#issuecomment-2408567868
-
Снова такая проблема. Русские символы в id3v1 пишутся как знаки вопроса. По поводу выбора однобайтной кодировки (в v1 же однобайтная): для её корректного выбора надо использовать системную локаль, таблицу соответствия можно взять из моего патча к 7zip в Debian: https://salsa.debian.org/debian/7zip/-/commit/c9e7cf319db67ee58d27b90dba81832f6fb598a1
-
So, I've done some investigation, and here's what I found out. The tar.exe that comes with Git for Windows is bsdtar, which uses libarchive. And libarchive, when creating archives, always sets the value of "the operating system on which the archive was created" to UNIX, even if the library is built and running on Windows. Consequently, on Windows systems we end up with an archive where the encoding is 866 (standard for Windows console), but the operating system value is UNIX. Therefore, many archivers...
-
Upstream issue: https://github.com/Pr-Mex/vanessa-automation/issues/2128
-
Here is zip.exe that produces such files: https://github.com/tisaconundrum2/zip 1DD3 CENTRAL HEADER #1 02014B50 1DD7 Created Zip Spec 17 '2.3' 1DD8 Created OS 0B 'MVS or NTFS' ... 1E01 Filename 'Дикий помещик.htm' (in 1251 charset)
-
Similar fix suggested for Ubuntu's unzip: https://code.launchpad.net/~mitya57/ubuntu/+source/unzip/+git/unzip/+merge/466860
-
https://github.com/ip7z/7zip/pull/36
-
https://github.com/ip7z/7zip/pull/36
-
The patch itself
-
7zz -mcp=866 l ./zip.zip 7zz -mcp=1251 l ./zip.zip etc
-
7zz -mcp=866 l ./zip.zip 7zz -mcp=1251 l ./zip.zip 7zz -mcp=65001 l ./zip.zip CP866 CP1251 UTF-8
-
Fixed in this patch https://sourceforge.net/p/sevenzip/bugs/2473/?page=1#46c7
-
Bring back fix for https://sourceforge.net/p/sevenzip/bugs/1060/
-
You can use 7zip with this patch: https://sourceforge.net/p/sevenzip/bugs/2473/?page=1#96ae to extract such archive: 7zz -mcp=866 x ./vanessa-automation.1.2.041.15.zip
-
You can use 7zip with this patch: https://sourceforge.net/p/sevenzip/bugs/2473/?page=1#96ae to extract such archive: 7zz -mcp=1 x ./vanessa-automation.1.2.041.15.zip
-
Added -mcp option support
-
Removed code branch that was actually unused. All ANSI archives that I have either also have UnicodeName field or have OEM codepage in Central header what is used by 7-zip and ANSI only in Local header.
-
Fixed some warnings as required by Debian (outdated patch removed)
-
Fixed some minor errors: 1) Avoid possible problems with table size calculation 2) Assume CP437 if charset detection fails
-
Fixed some minor errors: 1) Avoid possible problems with table size calculation 2) Assume CP437 if charset detection fails
-
Debian's 7zip just merged a fix for the same problem: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=779207#51
-
The built-in .zip archiver in older versions of Windows used DOS (OEM) or Windows (ANSI) code page corresponding to current regional settings for new archives. Lots of such archives still exist. The correct behavior is to determine the relevant OEM or ANSI code page based on the system locale and use it. You can look at this PR for reference implementation: https://github.com/p7zip-project/p7zip/pull/232 Sample archive showing this bug attached.
-
The built-in .zip archiver in older versions of Windows used DOS (OEM) or Windows (ANSI) code page corresponding to current regional settings for new archives. Lots of such archives still exist. The correct behavior is to determine the relevant OEM or ANSI code page based on the system locale and use it. You can look at this PR for reference implementation: https://github.com/p7zip-project/p7zip/pull/232
-
The built-in .zip archiver in older versions of Windows used DOS (OEM) or Windows (ANSI) code page corresponding to current regional settings for new archives. Lots of such archives still exist. The correct behavior is to determine the relevant OEM or ANSI code page based on the system locale and use it. You can look at this PR for reference implementation: https://github.com/p7zip-project/p7zip/pull/232
-
https://github.com/p7zip-project/p7zip/pull/232 "locale -> code page" translation table used in this PR is generated from Wine sources, dlls/kernel32/nls, using this tool.
-
The built-in .zip archiver in older versions of Windows (like XP) always used DOS code page corresponding to current regional settings for new archives. Lots of such archives still exist. The correct behavior is to determine the relevant DOS code page based on the system locale and use it. You can look at this PR for reference implementation: https://github.com/p7zip-project/p7zip/pull/232
-
Fixed some warnings as required by Debian
-
Thanks a lot for suggestion and testing!
-
Thank you! The fix looks reasonable. Applied. Check again please.
-
Managed to reproduce bug on my Mint 21.3. Followed this instruction: https://github.com/p7zip-project/p7zip/issues/112#issuecomment-850490605 Bug do not reproduces in far2l terminal, but reproduces in GNOME Terminal. As for ComicInfo.zip, bug reproduces or not depending on current folder name, and only if binary was built on Alpine Linux (it was built by spvkgn in alpine:latest container, probably it's the current stable alpine version). For example, it reproduces if archive and archiver are inside...
-
Managed to reproduce bug on my Mint 21.3. Followed this instruction: https://github.com/p7zip-project/p7zip/issues/112#issuecomment-850490605 Bug do not reproduces in far2l terminal, but reproduces in GNOME Terminal. As for ComicInfo.zip, bug reproduces or not depending on current folder name, and only if binary was build on Alpine Linux (it was built by spvkgn in alpine:latest container, probably it's the current stable alpine version). For example, it reproduces if archive and archiver are inside...
-
Managed to reproduce bug on my Mint 21.3. Followed this instruction: https://github.com/p7zip-project/p7zip/issues/112#issuecomment-850490605 Bug do not reproduces in far2l terminal, but reproduces in GNOME Terminal. As for ComicInfo.zip, bug reproduces or not depending on folder name, and only if binary was build on Alpine Linux (it was built by spvkgn in alpine:latest container, probably it's the current stable alpine version). For example, it reproduces if archive and archiver are inside ~/Проверка...
-
Managed to reproduce bug on my Mint 21.3. Followed this instruction: https://github.com/p7zip-project/p7zip/issues/112#issuecomment-850490605 Bug do not reproduces in far2l terminal, but reproduces in GNOME Terminal. As for ComicInfo.zip, bug reproduces or not depending on folder name, and only if binary was build on Alpine Linux (it was built by spvkgn in alpine:latest container, probably it's the current stable alpine version). For example, it reproduces if archive and archiver are inside ~/Проверка...
-
Managed to reproduce bug on my Mint 21.3. Followed this instruction: https://github.com/p7zip-project/p7zip/issues/112#issuecomment-850490605 Bug do not reproduces in far2l terminal, but reproduces in GNOME Terminal. As for ComicInfo.zip, bug reproduces or not depending on folder name, and only if binary was build on Alpine Linux (it was built by spvkgn, so I do not know exact distro version). For example, it reproduces if archive and archiver are inside ~/Проверка or ~/test test folders. Not reproduces...
-
Managed to reproduce bug on my Mint 21.3. Followed this instruction: https://github.com/p7zip-project/p7zip/issues/112#issuecomment-850490605 Bug do not reproduces in far2l terminal, but reproduces in GNOME Terminal. As for ComicInfo.zip, bug reproduces or not depending on folder name, and only if binary was build on Alpine Linux (it was built by some guy in chat, so I do not know exact distro version). For example, it reproduces if archive and archiver are inside ~/Проверка or ~/test test folders....
-
Managed to reproduce bug on my Mint 21.3. Followed this instruction: https://github.com/p7zip-project/p7zip/issues/112#issuecomment-850490605 Bug do not reproduces in far2l terminal, but reproduces in GNOME Terminal. As for ComicInfo.zip, bug reproduces or not depending on folder name. For example, it reproduces if archive and archiver are inside ~/Проверка or ~/test test folders. Not reproduces with ZipItem_v3.patch
-
Managed to reproduce bug on my local system. Followed this instruction: https://github.com/p7zip-project/p7zip/issues/112#issuecomment-850490605 Also bug do not reproduces in far2l terminal, but reproduces in GNOME Terminal. Not reproduces with ZipItem_v3.patch
-
Asked several friends to test on several systems including Arch.
-
-
Fixed some errors. At least two persons confirmed this version is unzipping ComicInfo.zip as expected. Please retest if possible. Thanks!
-
Asked several friends to test on several systems including Arch.
-
Not reproduces for me. xml file is extracted just ok. 24.05 with patch above, Mint 21.3. I also have no resources to check in any environment possible. Are you sure this issue is somehow related with my patch? https://github.com/p7zip-project/p7zip/issues/112 has several issues described, issue with my patch was 'sometimes 7z creates a file named "IBM437.so"', I am not sure issue with ComicInfo.zip is somehow related to it.
-
Made a new improved PR, code same as in ZipItem_v2.patch https://github.com/p7zip-project/p7zip/pull/232
-
Is that the same what these p7zip commits are? Partially
-
Please try this one
-
Have no Arch to check
-
This patch, applied against 24.05, solves the problem.
-
Important addition: if PackOS field of zip header is 11 and PackVer field is 20 or greater, corresponding ANSI code page should be used instead of OEM code page. Example of how to determine both OEM and ANSI code page for current locale can be found in far2l file manager sources, file WinPort/src/APIStringCodepages.cpp, function DeduceCodepages(). Conversion table itself is also generated from Wine sources. See also: https://sourceforge.net/p/sevenzip/bugs/1060/#ed99/fa7d
-
FYI: far2l file manager handles such archives just fine. It has some logic to choose if ansi or oem charset should be used. See zip.cpp. CP_ACP means Ansi Code Page, like 1251 etc. Relevant discussion. // if (ZipHeader.PackOS==11 && ZipHeader.PackVer>20 && ZipHeader.PackVer<25) if (LITEND(ZipHeader.Flags) & 0x800) { // Bit 11 - language encoding flag (EFS) - means filename&comment fields are UTF8 ; } else if (ZipHeader.PackOS == 11 && ZipHeader.PackVer >= 20) { // && ZipHeader.PackVer<25 CPToUTF8(CP_ACP,...
-
FYI: far2l file manager handles such archives just fine. It has some advanced logic to choose is ansi or oem charset should be used. See zip.cpp. CP_ACP means Ansi Code Page, like 1251 etc. Relevant discussion. // if (ZipHeader.PackOS==11 && ZipHeader.PackVer>20 && ZipHeader.PackVer<25) if (LITEND(ZipHeader.Flags) & 0x800) { // Bit 11 - language encoding flag (EFS) - means filename&comment fields are UTF8 ; } else if (ZipHeader.PackOS == 11 && ZipHeader.PackVer >= 20) { // && ZipHeader.PackVer<25...
-
https://github.com/p7zip-project/p7zip/pull/64 "locale -> code page" translation table used in this PR is generated from Wine sources, dlls/kernel32/nls, using this tool.
-
Try to extract that archive with both programs. unzip extracts correctly. 7zz extracts with incorrect names (which are not valid utf8 sequences).
-
The built-in .zip archiver in older versions of Windows (like XP) always used DOS code page corresponding to current regional settings for new archives. Lots of such archives still exist. The correct behavior is to determine the relevant DOS code page based on the system locale and use it. You can look at this PR for reference implementation: https://github.com/p7zip-project/p7zip/pull/64
-
The built-in .zip archiver in older versions of Windows (like XP) always used DOS code page corresponding to current regional settings. Lots of such archives still exist. The correct behavior is to determine the relevant DOS code page based on the system locale and use it. You can look at this PR for reference implementation: https://github.com/p7zip-project/p7zip/pull/64
-
~/test_folder$ unzip -l ./Desktop.zip Archive: ./Desktop.zip Length Date Time Name --------- ---------- ----- ---- 0 2016-09-28 18:41 Новая папка/ 4 2016-09-28 18:40 Новый текстовый документ.txt --------- ------- 4 2 files
-
Still encoding problems in some cases: https://sourceforge.net/p/sevenzip/bugs/2473/
-
Problematic archive sample
-
Filenames are disturbed while trying to list or decompress archive
-
original link is broken, sample can be found here: https://github.com/elfmz/far2l/issues/114#issuecomment-250554208
-
FYI: most recent putty4far2l version is currently available here: https://github.com/ivanshatsky/putty4far2l
-
libnatspec can be used as alternative solution. https://github.com/Etersoft/libnatspec
-
Please adopt those commits: https://github.com/unxed/putty4far2l/commit/88ef2e7ac47bdfcf5a9c5a71020fdf7963c79f6b https://github.com/unxed/putty4far2l/commit/eae4345eb56484c43fddfd511cb5620440aa431b https://github.com/unxed/putty4far2l/commit/ae0c6b90353a9560d705aa051cdc89ccff5f8bff Thanks!
-
Need to adopt three simple patches for compatibility with recent far2l versions: https://github.com/unxed/putty4far2l/commit/23cad487b9b154293579f8752db971ba8b88e7e0 https://github.com/unxed/putty4far2l/commit/24991b08a05162133b49d2ebbf837853b013f28e https://github.com/unxed/putty4far2l/commit/506b2c2e41cd6c7915e2af74e146921b20fda031
-
Thanks for adopting far2l extensions, that's great! In newer versions of far2l clipboard access protocol is slightly changed. Please update. Here is a patch against vanilla putty 0.73 Changed part is between // clipboard interaction and free(d_out);
-
Archives created on windows are extracted using incorrect code page. Windows use system locale setting for that, current 7zip port not. I've wrote a patch for p7zip fixing that issue, maybe native 7zip port can adopt it? https://github.com/unxed/oemcp/blob/master/p7zip_oemcp_ZipItem.cpp.patch
-
Correct processing of filename charsets in zips explained: https://github.com/mate-desktop/engrampa/issues/5#issuecomment-706412738 There is also p7zip patch implementing this logic: https://github.com/unxed/oemcp/blob/master/p7zip_oemcp_ZipItem.cpp.patch It has already been accepted to the only alive p7zip fork: https://github.com/szcnick/p7zip/commit/e56ea97d89eb0cd59603402496a8208238b3fda2
-
Do not override command line settings during oem code page auto detection
-
Updated version with OEMCP environment varialbe support to manually override OEM CP if needed. Further development will be done here: https://github.com/unxed/oemcp/blob/master/unzip_oemcpauto_unix.c.patch
-
Updated version with OEMCP environment varialbe support to manually override OEM CP if needed.
-
Updated patch file with actual version. Now supports archives created on Mac OS X. Further development will be done here: https://github.com/unxed/oemcp/blob/master/p7zip_oemcp_ZipItem.cpp.patch
-
@ipavlov here is a patch for CPP/7zip/Archive/Zip/ZipItem.cpp that fixes that bug. System locale setting is used to select corresponding OEM code page to use. File/folder names coversion is done via iconv.
-
Updated patch with new version, two bugs was fixed: 1) Forgot to zero-terminate converted utf-8 string 2) Now using LC_CTYPE instead of LC_ALL to fix locale detection in some cases
-
@ipavlov here is a patch for CPP/7zip/Archive/Zip/ZipItem.cpp that fixes that bug. System locale setting is used to select corresponding OEM code page to use. File/folder names coversion is done via iconv.
-
-
Original patch had a bug with string zero termination, here is a fixed one
-
Code page table is from Wine, parsed by my script from here: https://github.com/unxed/oemcp
-
Patch for code pages support is here: https://sourceforge.net/p/p7zip/bugs/187/
-
OEM code page table is made from wine sources, script is here https://github.com/unxed/oemcp
-
Patch should be applied to unix/unix.c
-
@ipavlov here is a patch for CPP/7zip/Archive/Zip/ZipItem.cpp that fixes that bug. System locale setting is used to select corresponding OEM code page to use. File/folder names coversion is done via iconv.
-
[patch] proper OEM code page auto detection
-
Here is a table of OEM charsets with corresponding posix locales (based on Wine sources). https://github.com/unxed/oemcp/blob/master/oemcp.txt So we just need to get system locale, find corresponding OEM charset and use iconv to get correct local file names as windows does.
-
Uploading sample of problem as https://2g0.ru/case2.zip is not working any more.
-
zero-fill free space on partition during (or after?) defragmentation
-
workaround is to run git as root: sudo tsocks git ...
-
google chrome fails to work under tsocks
-
git fails to checkout repository under tsocks
-
Command line switch for specifying charset used to decode OEM-encoded filenames if...
-
As for WIN (ANSI) encoding, according to the sources of Far Manager for Linux, it...
-
As for WIN (ANSI) encoding, according to the sources of Far Manager for Linux, it...
-
As for WIN (ANSI) encoding, according to the sources of Far Manager for Linux, it...
-
as for WIN (ANSI) encoding, according to the sources of Far file manager, it is only...
-
btw, 7z.exe 16.03 processes that archive ok under wine, why p7zip can not behave...
-
tested in 9.20 bundled with my distro. see it fixed in 16.02, thanks
-
incorrectly decoded unicode file names
-
will it ever be supported? most of windows-created .zips goes with OEM encoded f...
-
here is sample output from unzip -l case2.zip and 7za l case2.zip for the same sample...
1 >