Allow overriding encoding for zip ectraction

[EvilBeaver]

I certify that I own, and have sufficient rights to contribute, all source code and related material intended to be compiled or integrated with the source code for the SharpZipLib open source product (the "Contribution"). My Contribution is licensed under the MIT License.

Issues #274 and #278 are fixed, but there's an another issue with Unicode test samples.

It seems, that Greek and Arabic samples are incorrect. I've added a workaround in EvilBeaver@887e10d

Probably, old-code tests weren't failing, because ZipStrings.SystemDefaultCodePage was set to 65001, which is seems to be returned by default from Encoding.GetEncoding(0) on net.core

[piksel]

This solution is more or less what I had intended too. The only problem with this approach is that you cannot force UTF-8 encoding by setting the Charset.

The SystemDefaultCodePage (GetEncoding(0)) differs on different frameworks and environments. I will take a look at the tests and see what is going on this weekend.

[EvilBeaver]

The only problem with this approach is that you cannot force UTF-8 encoding by setting the Charset.

No, forcing UTF-8 is still possible. If UTF-8 flag is set in archive - then UTF-8 will be used regardless of codepage property. Please, can you clear the problem you've mentioned? What utf-8 forcing do you want?

[piksel]

With this solution you would not be able to unzip an archive that uses UTF-8 as it's encoding, whilst the unicode bit is not set. It would work if your systems default encoding is UTF-8, but not otherwise.
If we're adding support for setting the decompression encoding it would probably be better if we supported this scenario too.

Perhaps having Codepage default to -1 which would indicate "Auto" (SystemDefaultCodePage or UTF8 depending on Unicode bit), but if set to anything else it would use that codepage instead?

[EvilBeaver]

With this solution you would not be able to unzip an archive that uses UTF-8 as it's encoding, whilst the unicode bit is not set

Why? If client sets CodePage to 65001 then UTF-8 will be used and archive will be read correctly. Am I wrong?

[piksel]

If CodePage is set to 65001 then

CodePage == Encoding.UTF8.CodePage? SystemDefaultCodePage : CodePage

will result in SystemDefaultCodePage being used, no? And that is not UTF-8 in some environments.

[EvilBeaver]

Yes, this is wrong. I'll fix it to -1 as you proposed before

[EvilBeaver]

@piksel please review this.

[EvilBeaver]

@piksel thanks a lot! When the new NuGet version is planned? I want to use this fix in my project as soon as possible.

[piksel]

I'll try to get it done this weekend.