The problem: Text file created on Mac is not decoded correctly on Windows. It appears to be due to some physical file difference(s), but I may be all wet.
Data is stored in a file as strings: several header strings (one per line) and string data, one point per line.
When imported into Windows, something goes wrong. I dumped the Mac file which looks as though the file has about a 1k header mostly filled with nils, but with an Apple string that can be seen within the dumped nil header. I don’t know how to view a file dump in Windows. I suspect that some or all of the Apple header is being kept as data.
Having had no formal computer training I am stumped and appealing here for assistance.
Are you creating the file in Xojo?
Show us the code if possible. Upload a file. A decoding problem usually shows up with normal characters mixed up with odd combinations. So try a file with ASCII characters first.
If you are seeing a “1k header mostly filled with nil”, than I postulate that you are NOT working with a “text” file… but perhaps a file created by some word processor maybe? A plain text file will be just that… plain text… with perhaps some “visual gibberish” if it has special characters and/or encoding…
Sounds to me like, there are several things at play here.
#1 Text Encoding, make sure that you’re using the same encoding for reading and writing text.
#2 Line Endings, OS X & Windows typically use different line endings. I would suggest rather than using the TextStreams, use a binary stream and load the data into memory (or create it in memory) this way you can control which line ending is used Check the EndOfLine object. You can use the split function to then separate all the data into lines.
#3 If you’re creating your own file format, use a JSONItem to serialize a dictionary, or if you want XML (it’s a bit more work). Also make sure that you include a format version identifier, this when a future version of your application changes the file format, the older version of the application can alert the user rather than crashing or erroring.
TextInputStream gracefully handles line endings. BinaryStream is overkill.