SharpDevelop Community

Hi,

I have a directory that contains files and I would like to create a zip archive.

Some files have names in french (with accents), and the zip file changes these accents (é becomes Ú).
How can I prevent that ?

Here is the code I use (C# ASP.NET 2.0) :

private void CreateZip(string zipDirectory, string fileDirectory) {
   string _oZipFile = zipDirectory + @"Archive.zip";
   DirectoryInfo di = new DirectoryInfo(fileDirectory);
   if (di.Exists) {
      FileInfo[] fis = di.GetFiles();
      FileStream fZip = File.Create(_oZipFile);
      ZipOutputStream zipOStream = new ZipOutputStream(fZip);
      zipOStream.SetLevel(9);
      foreach (FileInfo fi in fis) {
         FileStream fs = File.OpenRead(di.FullName + fi.Name);
         byte[] tampon = new byte[fs.Length];
         fs.Read(tampon, 0, tampon.Length);
         ZipEntry entry = new ZipEntry((fi.Name));
         zipOStream.PutNextEntry(entry);
         zipOStream.Write(tampon, 0, tampon.Length);
         fs.Close();
      }
      zipOStream.Finish();
      zipOStream.Close();
      fZip.Close();
   }
}

Thank you very much for your help,

David

The usual anwer that I see around here would be to first set the DefaultCodePage, e.g.

    ZipConstants.DefaultCodePage = 850;

That should work for you.
However, I have an alternative that I hope people reading this will give their opinion on:

    ZipConstants.VERSION_MADE_BY = 0x0B14;

This sets the OS to Windows NTFS (at least, according to the specs from www.info-zip.org, which differ from the pkware specs). I got this wisdom from looking at files created by WinZip:
- a filename with only OEM chars in it is written with 'version = 0x0014' and is OEM encoded
- a filename with chars that are in Windows-1252 but not in OEM, is written with
   'version = 0x0B14' and is Windows-1252 encoded
- a filename with Unicode chars that are not in Windows-1252 is not accepted

In other words: tools like WinZip will assume the file names are OEM encoded, unless you set the HostSystem to 0x0B, then it assumes the encoding is default, that is, DefaultCodePage 0.
(On the down side, Window XP zip support does not seem to understand the HostSystem byte.)

Anyway, this seems like a good idea if you do not know in advance what filenames you will get.
Right?

Casper

I encountered exactly the same. Interestingly the Windows zip shell uses the right "version made by" field in the headers (0x0B14):

50 4B 03 04 0A 00 00 00 00 00 40 AE F4 34 00 00 00 00 00 00 00 00 00 00 00 00 04 00 00 00 84 94 81 E1 50 4B 01 02 14 0B 0A 00 00 00 00 00 40 AE F4 34 00 00 00 00 00 00 00 00 00 00 00 00 04 00 00 00 00 00 00 00 00 00 20 00 00 00 00 00 00 00 84 94 81 E1 50 4B 05 06 00 00 00 00 01 00 01 00 32 00 00 00 22 00 00 00 00 00

But instead of writing Windows-1252 encoded file name strings, they use the old 850 code page (other zip programs assume that the strings are encoded using the 1252 code page, so file names may be displayed incorrectly). So the underlined bytes represent the string "äöüß" (special german characters).

For maximum compatibility I suggest using the ZipSharpLib default "version made by" field and just changing the default code page to 850.

Interesting,

I have tweaked #Zip to use the current threads OEM code page rather than the windows one but this may be a line one one way to going further to solve this.

I have had thoughts of allowing unicode perhaps as utf8 but while possible it wouldnt work 100% for everyone.  If it was optional in some way in the library it would be great for some people, it would hinder sharing such files with others though.  Compatability is the big issue.

There are other ways to get around this.  Supporting 7z would allow for full unicode!

In the end for plain old zip files there is no 100% solution probably but trying to be cunning about what data you see in the strings would be better thatn what we have.

Thanks for the info,

-jr-