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:
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
Using LV 8.0 Pro on WinXP (Russia)
Message Edited by rolfk on 04-19-2006 05:29 PM
I have good and bad news about this:
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.