It looks like the UTF8 bytes are being interpreted as individual characters at some point. For example: ä = C3, A4 in UTF8 Ã = C3 in several codepages ¤ = A4 in several codepages
>> when I encode something here
>> but when one of my beta testers encodes it
What does "encode" actual mean here?
My exe is an MFC dialog based app with unicode enabled.
"Unicode enabled" just means that the WinAPI calls and any parts of the code where you use "T" constructs will default to wide characters interpreted as UTF-16. It has very little to do with writing UTF-8 to a file.
Where is the actual conversion from the in-memory format to UTF-8 performed?
Write throws an exception in response to several conditions, including the disk-full condition.
If Write() throws an exception, you have a memory leak since you didn't deallocate buffer.
This has been brought up in other threads here: There is no need to allocate using new[]/delete[] at all in a C++ program, unless you're writing your own allocator, or doing some really specialized work. Use CString or CArray classes instead, and for the reasons I stated above.
If an exception is thrown, then CString/CArray will automatically clean up itself.
Thanks for your reply. I haven't written this class, I found it in one of the threads in this forum. Whilst I don't think the leak is my issue, I'll certainly look at correcting it.
Your beta tester is probably just using an editor that doesn't assume the file is UTF8 encoded. The bytes that represent "äëïöü ¿? ¡!" in UTF8 are the exact same bytes that represent "äëïöü ¿? ¡!" in codepage 1252.
If you put a UTF8 BOM in the file, then any decent editor will recognize that the file is UTF8 encoded. To do that, you need to call "file.setWriteBOM(TRUE)". Or better yet, change that class's default value for "writeBOM_" to TRUE instead of FALSE. Having a BOM should be preferred over not having one.
Attached is a screen grab from a file compare using KDiff. The two files (one created in Spain, the other in Australia) are created from the same project file with the same executable.
* The Best Reasons to Target Windows 8
Learn some of the best reasons why you should seriously consider bringing your Android mobile development expertise to bear on the Windows 8 platform.