Dear Maintainer,

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.

The bad encoding both affects the file listing in file-roller itself, and the resulting files after extracting the archive. I exchanged a couple of emails with the p7zip maintainer who indicated that the behaviour is expected from 7z.

Would it be possible to depend on 7za instead of 7a ? Would there be some unforeseen consequences ? I think it's quite important for a stable release, as there are quite a few people using OSX likely to make .zip files with UTF-8 characters.

Best regards and thanks a lot for reading and all your work !

reassign 680932 p7zip-full
thanks

Le lundi 09 juillet 2012 à 12:57 +0200, Mahendra TALLUR a écrit :

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,

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

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