"Add File to Zip" doesn't support cyrillic folder (file) names?!

[Rashid]

Hello!

I'm working on WinXP with Russia localization and wanted to zip folders & files with cyrillic (russia) names. I failed to do it: when using standard VI "Add File to Zip" I get abracadabra in my archive instead of the folder & file names.

So, I have to work around by using external zip-utility and calling it with System Exec.vi.

My wishes to NI:
1) to solve the problem with other locale names support in Zip VIs;
2) to add "Extract file(s) from Zip" to palette.

To my pity, the openG tool "lvzip 2.2.1" also fails with
cyrillic names.

Thanks!
Rashid.

Using LV 8.0 Pro on WinXP (Russia)

[rolfk]

---

@Rashid wrote:
Hello!

I'm working on WinXP with Russia localization and wanted to zip folders & files with cyrillic (russia) names. I failed to do it: when using standard VI "Add File to Zip" I get abracadabra in my archive instead of the folder & file names.

So, I have to work around by using external zip-utility and calling it with System Exec.vi.

My wishes to NI:
1) to solve the problem with other locale names support in Zip VIs;
2) to add "Extract file(s) from Zip" to palette.

To my pity, the openG tool "lvzip 2.2.1" also fails with
cyrillic names.

Thanks!
Rashid.

Using LV 8.0 Pro on WinXP (Russia)

---

This is logical. The underlying zlib library uses ANSI strings and does not support multibyte or Unicode strings. If you pass a multibyte string to those functions it will probably interprete it as all kind of garbage. Since NI bases its ZIP files functionality on the same zlib library I used for the OpenG ZIP file functions they will probably have quite some problems to get them to support multibyte strings. Basically you can't without:

1) More or less rewriting huge parts of the zlib library.
2) Redefine the ZIP file format to support multibyte characters which would create serious compatibility problems.

So the fix is to make sure that when converting your paths to strings to pass to the ZIP functions, you are passing valid ASCII strings to those functions. You could do that by converting your multibyte strings to Unicode and from there back to ANSI with MultiByteToWideChar and WideCharToMultiByte Windows API functions.

If you have a better idea that does not involve rewriting the ZLIB library and a good understanding of multibyte character encoding then I would welcome any recommendations to add to the OpenG library to support this too. But it can not involve backwards incompatibilities nor file format changes of the ZIP file format.

Rolf Kalbermatter

Message Edited by rolfk on 04-19-2006 05:29 PM

[Rashid]

Thanks a lot, Rolf for your explanations.

I get the point.

By the way, I'm using now external zip-utility "7za.exe"
that I downloaded from SourceForge and it has no problems with adding cyrillic folder (file) names. I use it for making ordinary zip-files (I'm not using other formats like 7-zip and so on).

It turns out that they use Unicode format in their code.
And their code is *open*,
so isn't it possible to use it instead of obsolete ANSI-zlib?

Thank you, once again.
Rashid.

[rolfk]

---

@Rashid wrote:
Thanks a lot, Rolf for your explanations.

I get the point.

By the way, I'm using now external zip-utility "7za.exe"
that I downloaded from SourceForge and it has no problems with adding cyrillic folder (file) names. I use it for making ordinary zip-files (I'm not using other formats like 7-zip and so on).

It turns out that they use Unicode format in their code.
And their code is *open*,
so isn't it possible to use it instead of obsolete ANSI-zlib?

Thank you, once again.
Rashid.

---

I have good and bad news about this:
The good one: I checked the page and the license is LGPL so it would be compatible with OpenG!

BUT: Do you have any idea how many hours I put into the OpenG ZLIB library using ZLIB? I think you don't really want to know but i is several 100. Using 7-zip would be a least as much work for several reasons:

1) It is mostly an application so turning it into a library that can be used from LabVIEW is quite some work.
2) The original developer does not seem to be concerned very much about multi-platform releases. There are independant Linux/Mac OS command line tools but it seems to be partly modified source code.
3) I'm not sure how much of the necessary ZIP support the LZMA SDK has or if there is also code from the 7-ZIP application needed for that.
4) Last but not least I have really 0 hours to spend on such a project for the moment. So someone else would have to take that burdon if they want a solution that works before .. let's say at least the end of this year.

I'm not exactly sure what the issue is and I'm using not a system where this would be an issue so I have virtually no way to debug nor investigate the issue. The information stored in the ZIP file can't really be unicode or multibyte as that was not foreseen back in the DOS days when ZIP was invented. So the most likely thing I think 7-ZIP might be doing is translating incoming path names from Unicode to ANSI before storing them in the file. I couldn't imagine a mechanisme using the ZIP file format that would completely and without any loss of information store Unicode path names in there to be restored on extraction.

Rolf Kalbermatter