1
votes

I'm having trouble creating files in UTF-8 for appending. The MSDN documentation states that using "a+" for the mode parameter opens files for "reading and appending", which is what I need to do. For some reason, when no file exists and I'm creating a new one on the fly, the BOM or byte order mark that's created in the new file is malformed.

Basically, it is only writing the first 2 of 3 bytes. It's supposed to write the bytes 0xEF, 0xBB, and 0xBF, but it's only writing the first two (0xEF and 0xBB). If you look at it in a text editor, it should look like this: , but looks like this instead: ï». Has anyone seen this? A known fopen bug maybe? This is the code that I'm using to open, and I'm using a simple fwrite to write the file. Everything works fine when I pass in "w" (write) for the mode, but the BOM is malformed for "a" or "a+":

_tfopen(PathToFile,UNICODE_CHAR_MACRO("a+, ccs=UTF-8"));
1
Do you properly close/flush the file? - Cornstalks
Since you refer to "documentation says" that way, I want to clarify something: append mode means, new bytes are always appended to the end of file no matter what, unlike normal write mode. This is probably what you want, saying just in case. - hyde
Yes. I have an extremely simple program that opens the file, prints a Unicode literal string and closes it. - Stubbs
Why are you using _tfopen instead of fopen? - evanmcdonnal
@evanmcdonnal Sorry about that. It's actually using _wfopen under the covers, depending on whether or not we're building in Unicode or ANSI. - Stubbs

1 Answers

0
votes

I finally figured this out. The third party software that we're using was actually stripping off the last byte of the BOM, thinking that it was the ctrl-z MS-DOS end of file character.