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

[joelletham]

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. 

[wiebe@CARYA]

I feel a "implemented in NXG" coming up . 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.

[GregR]

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".

[wiebe@CARYA]

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.

[Darren]

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