LabVIEW Idea Exchange

About LabVIEW Idea Exchange

Have a LabVIEW Idea?

  1. Browse by label or search in the LabVIEW Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
  2. If your idea has not been submitted click Post New Idea to submit a product idea to the LabVIEW Idea Exchange. Be sure to submit a separate post for each idea.
  3. Watch as the community gives your idea kudos and adds their input.
  4. As NI R&D considers the idea, they will change the idea status.
  5. Give kudos to other ideas that you would like to see in a future version of LabVIEW!
Showing results for 
Search instead for 
Did you mean: 

Opening VI's named in Chinese in the English version of LabVIEW

Status: Already Implemented

Available in LabVIEW NXG. See GregR's comments in the idea thread for more information.

I have VI's and projects saved in Chinese characters and they do not open in the English version of LabVIEW. LabVIEW is unable to read special character unless I change my system languages. I feel that LabVIEW should be able to read all different languages and not required to download different versions. 

Proven Zealot

I feel a "implemented in NXG" coming up Smiley Very Happy. And this time, I think it's a proper response.


CG dates back over 20 years ago. Rewriting all string based code will be practically impossible. Much better reason for NXG then the zoom.


It is hard to talk about this with it turning into a thorough discussion of string encoding, but I'll try to give a little more information. The basic issue is that what we sometimes refer to as ASCII is really much more complicated than that. There are many different ways to turn bytes into characters and almost all of them only support a subset of the characters that exist across all languages. Specifically all Latin-derived languages tend to use a single definition of characters. On Windows this is "code page 1252". This code page defines that the byte 0xC8 represents the accented character 'È' but has no way to describe any Chinese characters. When displaying Chinese, Windows uses "code page 936". This defines multi-byte sequences that represent simplified Chinese characters but has no way to represent 'È'. LabVIEW treats all string data as a single one of these code pages so there is no way for it to display 'È' and '俇' at the same time. Teaching LabVIEW a different way to handle strings isn't just about the amount of work but also about maintaining compatibility. Changing the character encoding makes the same byte sequence turn into different characters and can change the behavior of VIs.


Enter LabVIEW NXG. NXG treats all strings as Unicode. Unicode was designed as the ultimate character encoding to support all languages, even if you consider emoji a language. It is the reason that in this reply I was able to include both the accented E and the Chinese character. Most of the web also uses Unicode.


This does mean there can be conversion required when bringing string data and diagrams from LabVIEW to LabVIEW NXG but we thought this was the right time to make the change. Which is a longer way of saying "implemented in NXG".

Proven Zealot

Just as a side note. AFAIK, Unicode isn't an encoding. Well, at least not a computer encoding. Unicode defines the code to character relation, not the encoding.


There are UTF-8, UTF-16, UTF-32, and many, many others, including MBSC to encode them. The U in UTF means unified, and that means it covers the entire Unicode character set. (There are encodings that seem to cover Unicode, but don't have a U.) MBSC can't do that, the code page defines the resulting Unicode character. And there's only one code page per application instance.


Fonts and character sets are a big historically grown mess.


AFAIK, UTF is most often used, UTF-16 in general. It depends on the use case though. IIRC, UTF-32 is fixed width (always 4 bytes per character), while UTF-16 and UTF-8 are not (1-4 bytes per character). UTF-8 is smaller in memory, while UTF-16 is generally faster. Or something like that.

Proven Zealot
Status changed to: Already Implemented

Available in LabVIEW NXG. See GregR's comments in the idea thread for more information.

DNatt, NI