LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Unicode characters in file names

Hello NI (if you are reading) and other users!

I'm facing a problem: chinese LabView users are able to a) use chinese characters in VI file names and paths (including linked sub VIs) and b) to use chinese text on front panels. I saw screenshots proving it.

Now I got a package of files to check the code for and being on a german Windows with german LabView I cannot open (window open for a split second and closes again) any VI that has unicode characters in the file name. If I rename any VI to have only latin characters, it would open but won't be able to find sub VIs. The search pop-up shows all chinese characters in file names and paths as "?" only.

 

I read LabView is not officially supporting unicode, but Windows 7 does and so it should be possible to at least open the VI. The new entry "UseUnicode=true" in the labview.ini did not help, at least not about the file name/path problem.

 

Any chance to get this working, but most of all - how do the chinese programmers do it? For them it seems to be no problem at all.

0 Kudos
Message 1 of 15
(6,118 Views)

I have been told that there is a chinese version of LabView. Doh! Really? And the other versions around the world are not compatible to each other when using file names with unicode characters?Smiley Surprised

0 Kudos
Message 2 of 15
(6,112 Views)

@MaSta wrote:

I have been told that there is a chinese version of LabView. Doh! Really? And the other versions around the world are not compatible to each other when using file names with unicode characters?Smiley Surprised


No they are not, since LabVIEW is a MBCS application, not a Unicode application. This means it interpretes the strings as Multi Byte Character String Sequences, which basically means that the number of bytes in a string is NOT equal to the number of characters in that string. The interpretation of this in non Unicode environments is code page determined.

 

However your Windows system needs support for the according code page installed and you need to switch your locale to use that particular code page in order for the string to be properly understood. And this is not even LabVIEW's problem but an issue of the underlaying system which needs to be configured correctly for the string local you want to interprete.

 

The localized versions of LabVIEW do not implement different ways of dealing with strings, but simply contain different string resources for the menus, error messages, etc. etc. And in order to display those menus and messages correctly the underlaying system needs to be configured for that specific locale. LabVIEW itself is always the same in all of these localized versions.

 

I know you will say it's a LabVIEW problem anyhow as it should support Unicode, but the problem with that is that implementing Unicode support in LabVIEW is basically a change that requires quite a few totally backwards incompatible changes to how LabVIEW code from earlier versions would interact with this new Unicode enabled version in just about anything from binary encoded strings inside VIs to string based protocols such as VISA, TCP/IP and everything, which makes use of flattened data. So while there has been put quite a bit of work in this in the past it was always stopped at concerns about backwards compatibility.

 

The new LabVIEW NXG platform which got revealed at NI Week will be incompatible enough to classic LabVIEW to finally make that switch. Smiley Tongue

<sarcasme>Another "advantage" of LabVIEW NXG is that it only supports Windows (hopefully only initially but heavy reliance on .Net makes me not so hopeful) so no need to figure out intricacies of other Unicode implementations on other platforms like Linux and Mac.</sarcasme>

Rolf Kalbermatter
My Blog
Message 3 of 15
(6,099 Views)

Thanks. But as you supposed, I will say it's LabView to blame. Because other softwares I work with, for example MS Office or the Adobe CC tools, don't have such problem at all. I could easily live with a missing support of unicode text in the VI code, but working with files and paths with unicode characters in the name should work in the year 2017. I may be wrong, but I don't think this is even related to backward compatibility.

My suggestion to chinese LabView users: only use latin characters in the files/paths. Makes it easier for the rest of the world. Smiley Wink

NI makes it too easy for them not to do so with the chinese LabView version.

0 Kudos
Message 4 of 15
(6,084 Views)

duplicate

Rolf Kalbermatter
My Blog
0 Kudos
Message 5 of 15
(6,078 Views)

@MaSta wrote:

 

My suggestion to chinese LabView users: only use latin characters in the files/paths. Makes it easier for the rest of the world. Smiley Wink


You misinterpreted this. It was a sinister attempt to copy protect their VI code from non-Chinese users! Smiley Very Happy

 

But honestly, unfortunately LabVIEW is a programming language and making it deal with Unicode filenames requires it to also support those filenames in the programming functions, with all the problems that come with this. Office is quite a different story and so is typical Adobe software.

Rolf Kalbermatter
My Blog
0 Kudos
Message 6 of 15
(6,076 Views)

I'm not a software architect, but I guess when implementing the support for unicode - which should cover all languages and characters on this earth - and making "one for all" version it will most likely be less expensive than making a locale version for CJK and other exotic character languages.

0 Kudos
Message 7 of 15
(6,071 Views)

You are wrong! The only difference in the various localized versions of LabVIEW are the actual resources such as menus, error messages, maybe some images and such but you need to translate them anyways (Unicode or not) to have an application work for a specific local. The complete programming logic in LabVIEW is unaffected by for what locale a package is build. If it works for MBCS language X it will work for all others too.

And to support multiple languages at the same time with the same build you don't really need Unicode but you need a resource system (menu, images, messages, dialogs, etc) which can dynamically switch between different languages. LabVIEW at its core has that, but at some point the support to dynamically switch between languages was considered to much trouble (and believe me it really is) so they build different language packages instead.

 

Microsoft does the same: you can't install a Windows version and switch it to display a different language, as the resources that contain text and other information are packed into the distribution when building for a specific language.

 

And technically there are not Unicode characters in a file name. There are however characters in the file name that can't be represented in the typical Windows 1252 codepage that most people in the western hemisphere use. The underlaying file system may or may not store the filenames as Unicode (the typical NTFS file system used in most modern Windows installations does use UTF-16, but under Linux it is nowadays common to store names as UTF-8 instead, FAT and older Linux distributions used whatever codepage was configured for the current session and created an additional problem when mounting such a filesystem on a differently configured system). Non NTFS filesystems such as what is commonly used for USB sticks or the good old CDFS fo CDs still don't use normally Unicode for instance.

The problem occurs when LabVIEW as MBCS application interfaces to Windows. Windows has to translate the names coming from the filesystem first from whatever representation the filesystem uses to Unicode 16 bit. This is basically a lossless conversion since just about any possible character can be represented by Unicode UTF-16, provided Windows knows about in what encoding the filename originally was. Then it translates it to whatever codepage is configured for the actual Windows session to pass to LabVIEW. Here the conversion can be lossy since not every character can be represented in most codepage systems. So Windows replaces the invalid characters with a question mark. Then LabVIEW passes this back to Windows to open a file but now Windows can't match this name containing question marks to any name in the filesystem and causes an error. Configuring your Windows session to use the correct codepage is all that is necessary, though Western Windows distributions usually don't support most Asian code pages unless the user explicitly installs additional codepage support.

Rolf Kalbermatter
My Blog
Message 8 of 15
(6,067 Views)

I understand. Very good explanation. So this is not about unicode in the file names, but just characters from a different code page.

However, support for this is built in even my german Windows and Windows itself and actually most softwares I use (if not older than 10 years) so far have no problem with opening files named as such. At least they open. LabView does not.

Well, thanks anyway.

0 Kudos
Message 9 of 15
(6,023 Views)

Hello Rolfk,

I have some questions about your explaination, maybe you have already written it but I don't understand.

I am writing an application which have to be translated in russian (so it have to use cyrillic characters).

I have implemented varius function in order to convert varius part of controls with the cyrillic char set and it seems to properly work.

Now I am facing with file reading and writing, I already know the way in order to read and write Unicode text file (the only unknow is on binary file, I have to test it but I think that binary files are treated as bit sequences).

My question are:

- In a computer which Windows languages is english (at least I hope so) and the language for the non-unicode software is set to russian, the directory paths is always in latin char set?

- What happens if OS is installed in russian and LabVIEW is a latin version?

- What happens if in a path control of the LabVIEW latin version the user writes a path whit the keyboard set to russian and the OS is hopefully latin?

Many thanks

0 Kudos
Message 10 of 15
(5,827 Views)