[Bug]: Incorrect display and decompression of compressed file name

[psvajaz]

bit7z version

4.0.x

Compilation options

BIT7Z_AUTO_FORMAT, BIT7Z_USE_NATIVE_STRING

7-zip version

v23.01

7-zip shared library used

7z.dll / 7z.so

Compilers

MSVC

Compiler versions

MSVC2017

Architecture

x86_64

Operating system

Windows

Operating system versions

Win11

Bug description

When previewing and decompressing the compressed file generated by Unix, the file names in the compressed file cannot be displayed properly. Through debugging the code, it was found that the BitArchiveItemInfo:: mItemProperties of the text item cannot display properly. Method=L "Deflate", HostOS=L "Unix", Characters=L "UT: MA: 1 Ux". I used the system's built-in tools in MacOS to compress a compressed package file name that can display normally, corresponding to Method=L "Store", HostOS=L "Unix", Characters=L "UT: MAC: 3 ux" Attachment 1: Attachment 2:

Steps to reproduce

No response

Expected behavior

No response

Relevant compilation output

No response

Code of Conduct

• [X] By submitting this issue, I agree to follow bit7z's Code of Conduct

[rikyoz]

Hi! If I understand your problem correctly, you're trying to display non-ASCII file names on the Windows console. If this is the case, it might not be an issue of bit7z but rather that printing Unicode strings in console programs on Windows is more complex than it should be (https://stackoverflow.com/questions/2492077/output-unicode-strings-in-windows-console).

You're using the BIT7Z_USE_NATIVE_STRING, so bit7z uses wide strings. In this case, to correctly print Unicode characters, you must first call _setmode(_fileno(stdout), _O_U16TEXT) to set the stdout encoding to UTF-16. Please be aware that you need also to include the following headers:

#include <fcntl.h> //for _O_U16TEXT
#include <io.h>  //for _setmode

This might be a duplicate of https://github.com/rikyoz/bit7z/issues/65, and, in the same issue, you can find a more complete code example https://github.com/rikyoz/bit7z/issues/65#issuecomment-1013655027.

If this is not the case, can you provide the path strings that cause the issue? Thank you!

[psvajaz]

After our testing, it seems that this is not the issue you mentioned. We tested the replacement 7z version and found that this issue did not occur in versions before 19.00, but occurred after 19.01. We tested tools including 7zFM and nanaZip that use the default 7z.dll, and they can also reproduce this issue. We can provide you with the problematic ZIP file, but this file has some privacy issues and cannot be published on GitHub. Can you provide me with a way to send the ZIP file

[psvajaz]

I presented an issue to the developers of 7z in sourceforge: https://sourceforge.net/p/sevenzip/bugs/2428/

[rikyoz]

I see! Unfortunately, there isn't much that bit7z can do in this case, as it seems to be a problem of 7-Zip itself.