Chinese garbled code problem

[jackletter]

When I unzip the file, I don't know the encoding it uses, but I can detect it (maybe detect fail);

Different files may have different encoding methods, but sharpzip only provides a global setting;

Can provide the original byte of entry.name so that I can decode it myself？
like this:

using (var stream = new ZipInputStream(File.OpenRead(path)))
{
                ZipEntry entry;
                while ((entry = stream.GetNextEntry()) != null)
                {
                       var name=  entry.Name;
                       //expect
                      byte[] bs=entry.NameBytes;
                }
}

[piksel]

No, not right now. It's easier to do in the next release, since you can just set the Encoding manually for each entry. The only way to get the bytes right now afaik is to manually use ZipStrings.ConvertToArray(entry.Name) which should revert the encoding. Any invalid characters would be omitted though, so it's not ideal.

[jackletter]

Use ZipStrings.ConvertToArray(entry.Name) ，Bytes cannot be 100% restored；
There should be only one character encoding in a compressed package，therefore, I don't think it is necessary to set the encoding for each entry；
So I suggest：

1. Specify an encoding rule when reading a compressed package；
2. Provide the original bytes of each entry's name；

[piksel]

Yeah, the intent is for ZipInputStream, ZipOutputStream and ZipFile to have a StringCodec property that you can use to change how the strings are en/decoded. It seems like I forgot to add the property to ZipInputStream though.
In any case, getting the original name bytes is not that simple due to how the implementation works. One way of doing it could be to implement a custom System.Text.Encoding that contains your logic for figuring out the correct encoding...

[jackletter]

When will the edition be released，I'm looking forward to this feature.

[piksel]

No release date as it depends on how much free time I get to spend on this, and currently there hasn't been much. Sorry.