System.IO.Compression results in garbled Chinese directory names when extracting.

[JHeLiu]

When I use the System.IO.Compression library to unzip a ZIP file that contains Chinese directories and files compressed by another compression software, the Chinese characters appear garbled. However, when I use the SharpCompress library, it works correctly. How can the official System.IO.Compression library address this issue?

  using (ZipArchive archive = ZipFile.Open(zipPath, ZipArchiveMode.Read))
  {
      foreach (ZipArchiveEntry entry in archive.Entries)
      {
          // If there are Chinese characters, they will appear garbled.
          string entryName = entry.FullName;

          Console.WriteLine($"Extracted: {entryName }");
      }
  }

Please note, I compressed the files using another compression software, and when I use the program to extract them, the Chinese characters appear garbled

https://www.bandisoft.com/bandizip/

https://yasuo.360.cn/

Neither of the two compression software programs above work.

Then, we compress a file using any compression software, like this.

@elgonzo @colejohnson66

[huoyaoyuan]

What's the filename encoding used in the zip file? You can inspect it with some software that can change that, for example BandiZip I'm using.

[JHeLiu]

哥 我补充下内容 看到了吧

[elgonzo]

See if you need to explicitly configure this compression software to use UTF-8 file names. If this isn't possible or doesn't solve the issue, could you perhaps attach a small ZIP file example to this thread that is demonstrating the issue with System.IO.Compression?

For CJK and other characters not representable by the IBM 437 code page, the only suitable text encoding for file names defined by the ZIP format specification (and thus more or less universally supported) is UTF-8.

I tend to suspect the compression software you used doesn't produce ZIP file entries conforming to the ZIP format spec when confronted with non-ASCII file names. If that's the case, it will always be hit-or-miss if these non-standard ZIP archives will be processed correctly by some software, entirely depending on which support or workarounds the used software provides for non-standard ZIP files. (Heck, i even remember like 15 years or so ago the then still popular WinZIP software and/or Windows' built-in ZIP archiver didn't manage with its default settings to correctly encode file names containing non-ASCII characters, even those in IBM 437, and used the system code page instead of IBM 437 or UTF-8 if i remember correctly.)

[JHeLiu]

My information has been updated, please take a look at it."

[colejohnson66]

What program did you compress them with and what are the original file names?

[JHeLiu]

My information has been updated, please take a look at it."

[elgonzo]

Do NOT trust the console output. It might very well just be the console not being able to show CJK characters.

Instead, set a break point on the Console.WriteLine(...) line, run your program in the debugger and inspect the value of the entryName string when the breakpoint is being hit. What is the entryName value as displayed by the debugger?

[elgonzo]

Okay, if you could please share the ZIP archive here, we can take a look at how exactly the file names are encoded in it.

[JHeLiu]

新建文本文档.zip

Thanks. It's this compressed package.

[elgonzo]

As suspected, this is a non-standard ZIP file (it is not using UTF-8 for the file entry names, hence why you get the garbled output).

I strongly suggest to create the ZIP files with UTF-8 file entry names, because the ZIP format specification defines UTF-8 as one of the text encodings that must be supported for file entry names. Pretty much almost every ZIP utility or ZIP library made within the last 15 years or so will support UTF-8.

BandiZip is using UTF-8 automatically for names that can't be encoded in IBM 437, as per its default settings. So, using BandiZip would be a no-brainer. However, i can't tell how you would configure the yasuo.360 software to make it use UTF-8, as i unfortunately don't understand Chinese.

If you however have no choice but to deal with ZIP files using a non-standard file entry name encoding, you have to pass a System.Text.Encoding instance to the ZipFile.Open method that matches the text encoding used in the ZIP file. This however requires you to know the correct encoding. And if you need to deal with different ZIP files that each use different encodings for the file name entries, you would have to figure out the correct text encoding that's used in a particular ZIP file. Therefore, to avoid this hassle, i strongly recommend to create only standard-conforming ZIP files using UTF-8 encoding.

For the ZIP file you posted here, the correct encoding to pass to the ZipFile.Open method would be Encoding.GetEncoding("gb2312"). Depending on your target framework and/or runtime environment, you might need to use the System.Text.Encoding.CodePages package for being able to create a gb2312 Encoding instance. But again, no such hassle if you were to create ZIP files with UTF-8 file name entries to begin with.

[huoyaoyuan]

ZIP file has a bit in its header indicating whether UTF-8 is used for filename.
System.IO.Compression always uses UTF-8 by default.

[elgonzo]

System.IO.Compression always uses UTF-8 by default.

Ugh... that's true. And bad. The ZIP support in System.IO.Compression is painfully lacking.

The ZIP format specification permits either IBM 437 or UTF-8 as text encodings for any file entry individually. Many ZIP tools and libraries are trying to use IBM 437 by default for any names that can be encoded by this code page and for any other name use UTF-8 (like for example BandiZip). It's a well-trodden road. I mean, how is one supposed to deal with ZIP files containing a mix of IBM 437-encoded entry names and UTF-8-encoded entry names using System.IO.Compression?

Frankly, probably the best response to anyone thinking about using System.IO.Compression for dealing with ZIP files they have no control over how they are created is to avoid System.IO.Compression like the plague and use a 3rd party ZIP library instead. Aye yai yai... :-(