From 04:00 PM CDT – 08:00 PM CDT (09:00 PM UTC – 01:00 AM UTC) Tuesday, April 16, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
LabVIEW
Zipping files with local characters
Solved!
Hi Community,
I'd like to zip files with LabVIEW but the filenames in the zipfiles get messy whereever I use none english characters such as "á", "é" etc. If I zip outside of labview then the filenames are fine, so I assume its a labview thing. Can you help me out how can I zip these filenames properly? Removing / altering the filenames is not an option.
thanks!
The code I use currently:
@1984 wrote:
I have checked that document briefly before I have sent my post. I have sent the UseUnicode = True, it makes no difference. Anyways I dont think it is really applicable as applicable as the problem lies in the Add file to zipfile.vi which is password protected. The paths coming in into this VI have the filenames with the correct characters.
There is no easy way to solve this. The zlib library and in fact really accompagning miniZIP library that was used for the ZIP implementation in LabVIEW does not do anything about character encoding. ZIP files traditionally use whatever DOS codepage the system used back then. The DOS codepage is however not the same as the ANSI codepage that normal Windows GUI applications are using. So any special character in LabVIEW is passed to the ZIP function and there interpreted as a different character.
The most simple solution would be to convert the filenames to the OEM codepage before passing them to the ZIP function and converting back from OEM to ANSI when receiving filenames from the functions. Newer ZIP formats also support UTF8 encoding but that is not supported by the miniZIP library used for ZIP support in LabVIEW.
I've been battling with these issues in the OpenG ZIP Toolkit Library too and it is a very tricky and involved problem especially if you consider that it should work on more platforms than just Windows. For the moment I have decided to sidestep that problem and concentrate on getting a new release of the library out, without trying to deal to much with those character coding issues.
My recommendation really is to just avoid those special characters altogother for now.
And I'm not sure you would gain much by calling a command line utility. Unlike Windows GUI programs the command line utility works with the OEM codepage too and assumes that its parameters are in that codepage, so you would have to translate special characters anyways before building the command line string.
Why odd? It's not a problem for English locales and that is where LabVIEW is developed in! 
It also makes the code base a lot more complicated. There is a reason that LabVIEW still doesn't officially support Unicode. It's a can of worms with a 7 headed Hydra waiting behind, to be slashed and conquered.
@1984 wrote:
Great explanation. I need those spec characters, so I just decided to use fbzpack which is a 300k command line tool requires no installation and then call this tool with a system exec. Seems to work great. Not ideal as I have to have that tool, but its not too much of a hassle.
I really like 7-zip. It is a free tool (open source) and has a command line interface that is pretty simple. I have not tried the special characters yet, so that might be something to try.
