Strange characters returned from "Read from Text File"

[PaulOfElora]

OK, this is weird.  I have a csv file I'm reading using "Read from Text File Function".  I get 3 bogus characters at the beginning that I know aren't actually in the file, they are (hex) EF BB BF.  I saw this once before a couple weeks ago, couldn't figure it out so just made a workaround.  But now it's bugging me and I'm worried about production code getting tripped up.  I "know" they're not there because they don't show up in either Excel or Notepad++, both of which I'm using to edit the file.  Any of you ever see this before? Thanks, paul

[Bob_Schor]

Hard to say anything constructive until you (a) attach the .csv file and (b) attach the VI that reads the extra characters.  Sorry, I need to "see it to believe it", and then maybe (??) I can "explain" it.

Bob Schor

[RavensFan · Accepted solution]

I'm sure those characters are in the file, otherwise LabVIEW wouldn't be reading them.

Sounds like a UTF-8 byte order mark.

https://en.wikipedia.org/wiki/Byte_order_mark

What program created this file?  If Excel or Notepad++ aren't showing them, it doesn't mean they aren't there.  It just means that those programs are reading them, knowing what they mean, and then showing the rest of the file according to the UTF-8 standard.

[rolfk · Accepted solution]

Yep, definitely byte order mark and Notepad and Notepad++ will just overread them by default and treat the reminder as UTF-8. LabVIEW File IO functions will treat the file simply as binary content and not do any encoding translation whatsoever. The only encoding related thing happening in LabVIEW is when you display the binary data in a string control where LabVIEW will use the standard Windows ANSI codepage configured for your local to display the bytes as text.

In Noetpad++ you can go into the Encoding menu and select ANSI instead. Then safe the file and those byte order marks in the beginning are gone. But don't expect the file to represent characters outside of the 7-bit ANSI coding across systems with different local settings and 8-bit encoding only will be right if used under the same local encoding on both the writer and reader.

[PaulOfElora]

Right you are, Ravensfan and Rolfk - I fired up Frhed and there they are - thanks for teaching me something new! paul