Filenames are not correct encoded on expanding old archives build with version 0.86 (i.e.)

[freica]

Steps to reproduce

1. build an zip-archive using version 0.86 with filenames conaining special chars i.e äöüÄÖÜß...
2. expand this zip-archive using current version (1.3.3)
3. filenames with special chars are not correct encoded
4. archives built with the current version are well expaned

Comments:

• 7zip i.e. can expand archives build with version 0.86 as well as archives built with version 1.3.3
• On the compress side we used only default encoding and nothing else, assuming UTF will be used and all is done well.

Questions:

1. What's to do to get always well encoded filenames on expanding an archive undependent of the used zip-version.?

[piksel]

UTF-8 is used if the Unicode bit is set for the entries, so set it using:

zipEntry.IsUnicodeText = true;

Otherwise the encoding is set to the "system default" encoding, which may mean different things depending on OS, language settings, framework and sharpziplib version.

[piksel]

It looks like 0.86 used Thread.CurrentThread.CurrentCulture.TextInfo.OEMCodePage instead as the default, which is probably why you were seeing cp850 (Western European (DOS)).

[freica]

Ok, seems possible...

[freica]

So there is only one thing from this morning not solved. Using V1.3.3 and default settings for example 7zip does show a bad encoding of the filename.
A further test with
ZipStrings.UseUnicode = true;
results in a good encoding in 7zip.

On the other hand the implemented encoding is realy a mess, I had a look at the code.
And here one thing in my mind could be a bug.

static ZipStrings()
		{
			try
			{
				var platformCodepage = Encoding.GetEncoding(0).CodePage;
				SystemDefaultCodePage = (platformCodepage == 1 || platformCodepage == 2 || platformCodepage == 3 || platformCodepage == 42) ? FallbackCodePage : platformCodepage;
			}
			catch
			{
				SystemDefaultCodePage = FallbackCodePage;
			}
		}

private static int codePage = AutomaticCodePage;

private const int AutomaticCodePage = -1;

public static int CodePage
		{
			get
			{
				return codePage == AutomaticCodePage? Encoding.UTF8.CodePage:codePage;
			}
			set
			{
				if ((value < 0) || (value > 65535) ||
					(value == 1) || (value == 2) || (value == 3) || (value == 42))
				{
					throw new ArgumentOutOfRangeException(nameof(value));
				}

				codePage = value;
			}
		}

If no settings are made from outside, codePage and CodePage is not the same!
codePage results in -1 and CodePage in Encoding.UTF8.CodePage (=65001)!
A further result of this is that UseUnicode in this case results in false!

(By the way, I don't no how you can compile return codePage == AutomaticCodePage? Encoding.UTF8.CodePage:codePage
Here my Compiler runs in an error, because AutomaticCodePage is not a bool)

Please have a look on it ;-)

[piksel]

codePage == AutomaticCodePage is a bool.

return codePage == AutomaticCodePage ? Encoding.UTF8.CodePage : codePage;

// is the same as:

if (codePage == AutomaticCodePage) {
	return Encoding.UTF8.CodePage;
} else {
	return codePage;
}

The CodePage getter and setter does not map 1:1, this is because the same static settings are used for both creating and reading zip files, so there is no easy way to answer "what is the encoding/codepage being used", as the encoding depends on the entry headers.
The internal codePage is either a forced codepage specified by the consumer, or it's AutomaticCodePage.

UseUnicode forces the use of UTF-8 regardless of what the entry headers indicate, hence why it returns false if you have not specifically set it.

[freica]

Ok, I understand
return codePage == AutomaticCodePage ? Encoding.UTF8.CodePage : codePage; Here I was to fast with my eyes,

But if I set UseUnicode=true, it seems that I get an other encoding (UTF-8) which 7zip shows correct.
So should this say that 7zip could identify on my system archives encoded with codepage 65001(UTF-8) and 850 and perhaps other ones, but not 1252?

If the difference between codePage and CodePage is not a bug, so at least it's a questionable implementation that encourages this mess.

Have a nice evening!