Somehow myExportString became myExportText.
Besides that, what happens if you replace the text before you write it
Another thing you can try is to cast it as a String like so:
Also, maybe try changing the encoding to "UTF-8".
Thank you Harbs
The code is actually in functions, thats why there's name changes.
Changing the encoding to UTF-8 did it :-)
Well sorta ... atleast it will export now. We added UTF-8 to the encoding and now the file is saved with content. But the encoding is wrong - our special danish characters are not displayed right. æ is shown as √¶ - å is shown as √• - ø is shown as √∏ etc. etc...
We've tried changing the encoding to others too, but no luck...
Here's a list of the valid encodings:
US-ASCII, ASCII,ISO646-US,I SO-646.IRV:1991, ISO-IR-6,
Find the right one...
I'd try UTF16 next.
Perhaps the program you are checking it with doesn't support UTF8
I'm in on this case too, working with Thomas.
We open it in TextEditor on the mac, which shows the wrong characters.
When we open in BBEdit they are fine, It says that the format/encoding is: Unicode (UTF-8, no BOM)
When I then in BBEdit change it to Unicode (UTF-8), save the file and open it in TextEditor the file looks as intended!
But, we are talking 400+ files to open and change and save again... No go... :-)
1 person found this helpful
You just answered your own question; write the BOM!
Initialize the string with myExportText = "\uFEFF";
then use += to your heart's content...
Perhaps TextEditor (= TextEdit?) can't handle files without the BOM-marker -- which is, by the way, the Byte Order Mark. The first two characters ought to be 0xFF 0xFE in hexadecimal, so a text processor doesn't have to check each and every single high ASCII code to see if it may be UTF-8.
(http://unicode.org/faq/utf_bom.html has more on this.)
... change it to Unicode (UTF-8) ...
BBEdit is apparently smart enough to check, and then see that all higher ASCII codes are consistent with UTF-8 encoding, so it does recognize the special characters. Only thing that changes when you save the file is the BOM marker gets added to the file.
I think the problem is that, although JS can write UTF-8 encoded files, it's also possible for the user to switch encoding right in the middle of writing a file. So it cannot output the BOM marker first -- you might want to write plain ASCII first, then switch to UTF-8, write some more, switch to Unicode ...
Perhaps you can fool JS just a tiny bit. Open your file for writing, then change the mode to BINARY. Write out the two characters 0xFF and 0xFE (Read Note Below...). Then switch to UTF-8 and do your stuff.
Note Below: ah ... now what was the correct byte order again, for Mac compatible files? It's either 0xFF then 0xFE or first 0xFE then 0xFF. It might not really be important, since these two bytes determine in which byte order 16-bit and 32-bit Unicode files are written ... but you are not using that, UTF-8 is by design byte order independent.
Harbs -- wouldn't using UTF-8 right from the start imply that every Unicode character (> 0x7F) gets output in UTF-8 format, i.e., splitting your "it's just any character like any other one" into four or five separate UTF-8 chunks?
I gotta say, it's possible the .write programmer anticipated this usage.
Seems to be the right direction!
Thomas just went to sleep, and he's "the Brain" so we won't be back on it before sometime tomorrow, or the day after depending on workloads... :-)
So far, thanks a lot!
Normally I would have been stuck without Thomas, but I just got a little stubborn... I managed to get it working!
myFile.write("\uFEFF" + myExportText);
Now everything is as it should be :-D
I've never looked into the use of the BOM enough to know why write() does not insert it automatically.