[Bug]: The password is emoji compress is error.

[psvajaz]

bit7z version

4.0.x RC

Compilation options

BIT7Z_AUTO_FORMAT, BIT7Z_USE_NATIVE_STRING

7-zip version

v22.01

7-zip shared library used

7z.dll / 7z.so

Compilers

MSVC

Compiler versions

MSVC2017

Architecture

x86_64, x86

Operating system

Windows

Operating system versions

Windows 11, Windows 10

Bug description

set password is ok, but compress is error

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! What archive format are you using?

7-zip doesn't support emojis in passwords when creating Zip archives. You can also check this in the 7-zip GUI I'll improve the error message of bit7z in such a case.

I did some tests with the 7z format and had no issues with emojis in passwords.

[psvajaz]

7-Zip 22.01 GUI set emojis in passwords is ok. compress and uncompress is ok

[rikyoz]

So you're compressing to 7z both in the GUI and with bit7z, right?

Uhm, it should work fine, provided that you correctly encode the password string:

BitFileCompressor compressor( lib, BitFormat::SevenZip );
compressor.setPassword( L"\U0001f600" ); // 😀
compressor.compressFile( inPath, outPath );

What's the error message?

Also, I noticed that the path to the archive is a bit long, so the problem might actually be that you're exceeding the default max path length of Windows.

If this is the case, one way to overcome this is to prepend the string \\?\ (\\\\?\\ escaped) to every path string you pass to the library (https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation?tabs=registry).

Alternatively, you can enable the option BIT7Z_AUTO_PREFIX_LONG_PATHS in CMake, which will make bit7z automatically prepend the long path prefix when needed.

[rikyoz]

I did some further testing and also

compressor.setPassword( L"😀" );

should work fine.

[Luosiyuan]

Hello author, after further optimization, can the framework support zip format and set emoji emoji emoji as the password for the compressed package. Currently, the latest version of 7z is not supported.

[rikyoz]

Hi!

after further optimization, can the framework support zip format and set emoji emoji emoji as the password for the compressed package.

Unfortunately, this is a limitation of 7-zip, there isn't much that bit7z can do.

Currently, the latest version of 7z is not supported.

The stable version of bit7z v4 will support the latest version of 7-zip (v23.01). Unfortunately, also this version of 7-zip doesn't support non-ASCII passwords for the zip format.

The only way to add support to emoji passwords for zip files would be to patch the 7-zip source code.

[Luosiyuan]

Hello, author After reading the 7z source code, it was found that as long as the zip format is compressed, the input password will be judged whether it is AsciiString. After commenting out the code, Chinese and emoji characters can be set as the zip format compression package password. And a simple test was conducted, and both decompression and compression were normal. You can give it a try and see if there are any problems.

[Luosiyuan]

After in-depth research on 7-zip encryption and decryption source code, it was found that if the above restrictions are commented out, there will be two problems: 1 The encrypted string and the decrypted string must be encoded in the same region. 2. For some non CP UTF8 or CP UTF7 encoded strings as passwords will not be unique. If you can accept the above two defects, simply commenting out the password filtering logic in the source code can enable zip compression to support special character encryption. Another way is to modify the character encoding format of encryption and decryption to Unicode encoding format. But this way

[rikyoz]

Hi @Luosiyuan,

After reading the 7z source code, it was found that as long as the zip format is compressed, the input password will be judged whether it is AsciiString. After commenting out the code, Chinese and emoji characters can be set as the zip format compression package password. And a simple test was conducted, and both decompression and compression were normal. You can give it a try and see if there are any problems.

After in-depth research on 7-zip encryption and decryption source code, it was found that if the above restrictions are commented out, there will be two problems: 1 The encrypted string and the decrypted string must be encoded in the same region. 2. For some non CP UTF8 or CP UTF7 encoded strings as passwords will not be unique. If you can accept the above two defects, simply commenting out the password filtering logic in the source code can enable zip compression to support special character encryption. Another way is to modify the character encoding format of encryption and decryption to Unicode encoding format.

Yeah, that is the code that handles the ASCII password check, and it can be patched to make 7-zip work with non-ASCII passwords, as you researched.

However, there may have been a misunderstanding with my previous message: I'm not the author of 7-zip; I'm only the author of this project, bit7z, a library for using 7-zip's shared libraries. The change you propose concerns the code of 7-zip, not of bit7z.

In any case, I recently added the same ASCII password check also in bit7z, mainly to improve the error message that bit7z provides to the user. Since someone like you might want to use a patched version of 7-zip that doesn't limit Zip passwords to only ASCII characters, I made the check inside bit7z optional so that it can be disabled if needed. The change is on the develop branch, and it will be available in the next v4.

[Luosiyuan]

Okay, thank you