Feature: Use UTF-8 encoding for ZIP creation to ensure cross-language compatibility

[oxygen-dioxide]

Currently, when creating ZIP archives, Files defaults to the system local encoding (e.g., GBK for Chinese, Shift_JIS for Japanese). UTF-8 is used only when there are characters in file name that can't be expressed in system encoding. This causes filenames to become unreadable when the archive is opened on systems with a different language locale. For example, a Chinese user creates a ZIP with filenames in GBK → Japanese users extract it as Shift_JIS → garbled text.

After this PR, Files always creates ZIP archive in UTF-8 encoding, which is consistent with windows explorer's behaviour. The archive created by Files will never become garbled no matter who downloads it.

Resolved / Related Issues

To prevent extra work, all changes to the Files codebase must link to an approved issue marked as Ready to build. Please insert the issue number following the hashtag with the issue number that this Pull Request resolves.

• Bug: File names for Japanese zips aren't shown correctly on Chinese language #14937 is partially solved in this PR.

Steps used to test these changes

Stability is a top priority for Files and all changes are required to go through testing before being merged into the repo. Please include a list of steps that you used to test this PR.

I'm a Chinese developer, so below is how I test it in Simplified Chinese windows. I don't know whether this affects English users and how they'll test this.

1. install python, and pip install zipunicode
2. Create a file with Simplified Chinese filename. for example, 中文.txt
3. In Files, right click on the file, Compress -> Create 中文.zip
4. In command line, zipu 中文.zip

Previous behaviour:

* Detected encoding  :  GB2312 | Language:Chinese | Confidence:86%

New Behaviour:

* All file names are properly in UTF8 encoding

[yaira2]

LGTM

[realwyz]

Seems this didn't built in the Files - Preview versions. If the file names contains symbol characters, then Files or Files - Preview creates a zip archive still has problem, while other tools like the Bandizip doesn't.

For example, there's three text files named:

01_1920×1080.txt
02_2560×1600.txt
03_3200×2000.txt

Use Files and Bandizip separately create them into a zip archive, then use unzip -t to test the data, they have different results:

❯ unzip -t test_bandizip.zip
Archive:  test_bandizip.zip
    testing: 01_1920×1080.txt        OK
    testing: 02_2560×1600.txt        OK
    testing: 03_3200×2000.txt        OK
No errors detected in compressed data of test_bandizip.zip.

❯ unzip -t test_files.zip
Archive:  test_files.zip
03_3200×2000.txt:  mismatching "local" filename (03_3200+□2000.txt),
         continuing with "central" filename version
    testing: 03_3200×2000.txt        OK
01_1920×1080.txt:  mismatching "local" filename (01_1920+□1080.txt),
         continuing with "central" filename version
    testing: 01_1920×1080.txt        OK
02_2560×1600.txt:  mismatching "local" filename (02_2560+□1600.txt),
         continuing with "central" filename version
    testing: 02_2560×1600.txt        OK
At least one warning-error was detected in test_files.zip.