Bug: `unzip -t` report errors when the archived filenames contain symbol characters.

[realwyz]

Description

As the picture shows, the same files separately compressed by Files - Preview - 4.0 and Bandizip into .zip archives. Then using unzip -t command to test data, Files compressed one detected error whereas Bandizip didn't.

This can be quite panic and inconvenient on managing a large number of archive files. Because when you suspect that some files may be corrupted due to hardware failure or improper transfer, then you using unzip -t to check all the nested folders' archives, this warning-error messages are very annoying, turning out not the data corrupted but the filenames contain symbol characters like ×. This makes it harder to identify which files are actually corrupted.

By the way, this has been happening since I started using Files, from version 3.9.1 to the latest 4.0. It didn't appear only after using UTF-8 compressing in version 4.0.

Steps To Reproduce

1. Create text files named as 1920×1080, 2560×1600, 3200×2000.
2. Select all of them, right click then choose compress > create xxx.zip, rename it to files.zip; the same files right-click choosing Bandizip to compress them into a .zip file, rename it to bandizip.zip.
3. Open Git Bash in Windows Terminal, execute unzip -t bandizip.zip and unzip -t files.zip.

Files Version

4.0.0.0

Windows Version

10.0.26100.1742

User ID

81723aa7-ab09-4d2c-86c2-baa4b7c7d83d

Log File

debug.log

[Josh65-2201]

Thanks for the report, Are you using the Unicode symbol https://graphemica.com/%C3%97

[realwyz]

Yes, the multiplication sign ×.