I have tried to reproduce the bug in Ubuntu LTS without success.
After comparing the ZIPs created under Debian testing and Ubuntu LTS, I
have found that bit 11 (Language encoding flag EFS) in general purpose bit
flag field is not set (incorrectly) under Debian:
$ hexdump test_debian.zip
0000000 4b50 0403 000a 0000 0000 69fd 4e28 0000
$ hexdump test_ubuntu.zip
0000000 4b50 0403 000a 0800 0000 61fd 4e28 0000
In main function of "zip.c" file, I have found that "zip" tries to set
"en_US.UTF-8" locale before enabling bit 11 (using_utf8 global variable):
#ifdef UNICODE_SUPPORT
# ifdef UNIX
/* For Unix, set the locale to UTF-8. Any UTF-8 locale is
OK and they should all be the same. This allows seeing,
writing, and displaying (if the fonts are loaded) all
characters in UTF-8. */
{
char *loc;
/*
loc = setlocale(LC_CTYPE, NULL);
printf(" Initial language locale = '%s'\n", loc);
*/
loc = setlocale(LC_CTYPE, "en_US.UTF-8");
/*
printf("langinfo %s\n", nl_langinfo(CODESET));
*/
if (loc != NULL) {
/* using UTF-8 character set so can set UTF-8 GPBF bit 11 */
using_utf8 = 1;
/*
printf(" Locale set to %s\n", loc);
*/
} else {
/*
printf(" Could not set Unicode UTF-8 locale\n");
*/
}
}
# endif
#endif
So this is the problem, as my Debian installation doesn't provide
"en_US.UTF-8" locale then "zip" refuses to enable bit 11 silently (printf
messages are commented):
$ locale -a
C
C.UTF-8
es_ES.utf8
POSIX
Of course, generating "en_US.UTF-8" locale solves the problem:
$ sudo dpkg-reconfigure locales
$ locale -a
C
C.UTF-8
en_US.utf8
es_ES.utf8
POSIX
Now everything works as expected:
$ touch Adiós
$ zip test.zip Adiós
adding: Adiós/ (stored 0%)
$ 7z l test.zip
7-Zip [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21
p7zip Version 16.02 (locale=es_ES.UTF-8,Utf16=on,HugeFiles=on,64 bits,1 CPU
Intel(R) Core(TM) i3-8100 CPU @ 3.60GHz (906EB),ASM,AES-NI)
Scanning the drive for archives:
1 file, 164 bytes (1 KiB)
Listing archive: test.zip
--
Path = test.zip
Type = zip
Physical Size = 164
Date Time Attr Size Compressed Name
------------------- ----- ------------ ------------
------------------------
2019-01-10 10:14:12 D.... 0 0 Adiós
------------------- ----- ------------ ------------
------------------------
2019-01-10 10:14:12 0 0 0 files, 1 folders
$ hexdump test.zip
0000000 4b50 0403 000a 0800 0000 51c6 4e2a 0000
In conclusion, this is not a "p7zip-full" package bug it's a zip package
locale issue.
Best regards.
El mar., 8 ene. 2019 a las 11:54, Antonio Cebrián (<[email protected]>)
escribió:
> I can reproduce this bug in Debian testing therefore is not a MacOSX files
> only related problem:
>
> devel@debian:~$ touch Adiós.txt
>
> devel@debian:~$ zip test.zip Adiós.txt
> adding: Adiós.txt (stored 0%)
>
> devel@debian:~$ unzip -l test.zip
> Archive: test.zip
> Length Date Time Name
> --------- ---------- ----- ----
> 0 2019-01-08 11:42 Adiós.txt
> --------- -------
> 0 1 file
>
> devel@debian:~$ 7za l test.zip
>
> 7-Zip (a) [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21
> p7zip Version 16.02 (locale=es_ES.UTF-8,Utf16=on,HugeFiles=on,64 bits,1
> CPU Intel(R) Core(TM) i3-8100 CPU @ 3.60GHz (906EB),ASM,AES-NI)
>
> Scanning the drive for archives:
> 1 file, 170 bytes (1 KiB)
>
> Listing archive: test.zip
>
> --
> Path = test.zip
> Type = zip
> Physical Size = 170
>
> Date Time Attr Size Compressed Name
> ------------------- ----- ------------ ------------
> ------------------------
> 2019-01-08 11:42:56 ..... 0 0 Adiós.txt
> ------------------- ----- ------------ ------------
> ------------------------
> 2019-01-08 11:42:56 0 0 1 files
>
> devel@debian:~$ 7z l test.zip
>
> 7-Zip [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21
> p7zip Version 16.02 (locale=es_ES.UTF-8,Utf16=on,HugeFiles=on,64 bits,1
> CPU Intel(R) Core(TM) i3-8100 CPU @ 3.60GHz (906EB),ASM,AES-NI)
>
> Scanning the drive for archives:
> 1 file, 170 bytes (1 KiB)
>
> Listing archive: test.zip
>
> --
> Path = test.zip
> Type = zip
> Physical Size = 170
>
> Date Time Attr Size Compressed Name
> ------------------- ----- ------------ ------------
> ------------------------
> 2019-01-08 11:42:56 ..... 0 0 Adiós.txt
> ------------------- ----- ------------ ------------
> ------------------------
> 2019-01-08 11:42:56 0 0 1 files
>
>
> On Thu, 12 Jul 2012 09:12:15 +0200 Josselin Mouette <[email protected]>
> wrote:
> > reassign 680932 p7zip-full
> > thanks
> >
> > Le lundi 09 juillet 2012 à 12:57 +0200, Mahendra TALLUR a écrit :
> > > this bug occurs when decompressing zip files made under MacOSX (latest
> > > version), which contain some UTF-8 characters. For instance, it occurs
> > > with a ZIP file containing japanese characters made under a French OSX
> > > installation, which is in turn extracted under my system (French
> > > locale, up to date Wheezy).
> > >
> > > What is important, is that, encoding is detected properly when using
> > > 7za from the commandline or when using unzip, but not when using 7z,
> > > which is summoned by file-roller by default as of today.
> >
> > I discussed with the maintainer of p7zip, and he agrees this is the root
> > of the problem.
> >
> > I’m reassigning for now, since the correct behavior should still be to
> > use 7z, not 7za.
> >
> > Cheers,
> > --
> > .''`. Josselin Mouette
> > : :' :
> > `. `'
> > `-
> >
> >
> >
> >
>
>
