From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
LabVIEW
Unicode - again! 不 is showing up as 上, but only if read from a file!
Solved!
Hi, LabVIEWers:
If you've been following some of my posts here (I have no idea why you would, but just in case), you know that a project I am working on is a translation of things from English to unicode. It's been working fabulous so far, except for one thing.
It seems that 不 is consistently showing up as 上 in any text box, caption, etc, etc, but only if I read it from a text file! It doesn't matter what position it's in, and I tried saving it in notepad (unicode option), notepad ++ (encode in UCS-2 little-endian) and Word (other encoding - Unicode) but it doesn't make a difference. And when I copy the wrong character and paste it, it really IS the wrong character, like it magically got transformed.
If I paste the right character into a any kind of text box, it works fine. Furthermore, I can wire that text box to anything that accepts a string and it shows up correctly there, too.
Here's ther weird thing:
As far as I can tell, that's the only character I am having trouble with!!!
Anyone have any ideas?
Thanks!
Oops, LV 2009 SP1.
The ugly workaround I installed was to do a simple substitution, but obviously that won't work if the text is SUPPOSED to be 上!
The other workaround was to eliminate the 不 from the text file and and insert the 不 where it belongs in the code.
Each way has its pros and cons. Any comments?
I see that 上 sits on bit 10 and 不 at 13 on the same word. Do you think they accidentally both got mapped to 10 by whoever coded the unicode support? You know, cut and paste '10' for mappings '10' - '15' and then forgot to change one of them?
Or do you think it's silly to assume that someone did it by hand?
It was a case of "stupid me." Disabling "Convert EOL" on the read from text file makes it work fine. I got to this point by remembering about disabling termination characters when dealing with binary data. That triggered the thought that the same kind of thing could be happening here.
Dec 10 is linefeed and dec 13 is carriage return. Are you sure you disabled Convert EOL on the read file function? I'm not sure how you read in the Unicode strings but if you use Read Text File there is a right popup option to have LabVIEW do some automatic translation. Does Read File deal with Unicode or are you doing something yourself there? Either it does not and then of course does ASCI replacement or if it does the code for Convert EOL does not correctly treat Unicode characters.
The author of the LabVIEW Unicode Programming Tools should update his code - he didn't catch it, either!
You are absolutely correct. I shoudl've recognized that. Fortunately I had other experiences which led me to the same conclusion after having gone down a different path.
