Writting file with RFile and reading with TFileText (unicode

As tote said, it doesn't matter.

However, to be _really_ unicode, you should write the correct Byte Order Marker (BOM) to the start of the file.

Otherwise, some text editors will think it's ASCII and you'll end up with

H E L L O

Noooo, not RFileWriteStream.

That writes a TDesC out in external format.

That is with codes that say "hay, im a stream" and the length of the descriptor and all that.

Just use plain old RFile.

OK, some explination.

RFileWriteStream isn't for writting to a file so you can read it with another app.  It's for writting to a file so you can read it back as a stream, from your symbian application.  It writes special magic codes along with the actual data that identify the stream type, and the data types as you write them.

Yes, RFile::Write expects TDesC8.  Thats because every file, even Unicode text files, ultimatly boil down to 8-bit data.

You have two choices.  Either you convert the unicode text to ascii (8-bit) and write that, or you really write the unicode data to the file.  Here is how you do both.

Firstly, the conversion:


This copies the 16-bit data into a 8 bit descriptor (and disregards any non-ASCII characters as it does so) then writes the text to the file.

If the 16 bit descriptor contains "HELLO" - the contents of the file is:

HELLO.

Now, actually writting the unicode data to the file:



What this does is basically casts (doesn't convert, just casts) the 16 bit descriptor to a 8-bit one so you can pass it to the file API.

Again, lets say the 16 bit descriptor contains "HELLO" -  the contents of the file now is:

H E L L O

That is, Unicode data.

Many text editors will read that file as is.  Some however, will require you also write the Unicode BOM at the start of the file to indicate the format of the file (endiness, code page etc).

If what I have showed you there doesn't work for you, ill show you how to write the BOM also.

Eh?  You sure...

20 Unicode characters is 20 ASCII characters.  The only difference is Unicode ones take up twice as much space per character - but thats ok, since each "slot" in a TBuf16 is twice that of each slot in a TBuf8.

If TBuf16 and TBuf8 were normal C arrays, the difference is sizeof(TBuf16) is twice sizeof(TBuf8).

So, in windows speak,

WCHAR szUniBuffer[20];

and

CHAR szAsciiBuffer[20];

Can store the same amount of characters, but not the same amount of bytes - i.e. sizeof(szAsciiBuffer) = 20, sizeof(szUniBuffer) = 40.  

Descriptors hide all that rubbish from you, and the tempate parameter is the size in characters - i.e. the same in both cases.

[/b]

Depends what's in the 16 bit descriptor.

If everything is representable in ASCII, it should work fine.

If you have characters in there which don't exist within the ASCII codepage (i.e. Unicode characters) of course it won't work - not really supprising!!  That's why someone invented Unicode.

There are posts on here about "better" ways to convert - that is ones that don't just chuck away non-ascii compatable Unicode characters.  But if your string does contain Unicode characters, the only way to really get whats in the buffer into the file is to write it in Unicode.

I made the assumption we were talking about characters here because Unicode is a concept which is only applicable to textual data.  16 bit discriptors are usually always used for character data.

Sure, descriptors (8-bit) are also used to work with raw binary data - one of the good (some people say) things about them.

Characters may be the wrong word - elements is better maybe.

Anyway, I never said .Copy would accuratly copy the string - only that it would never overflow the destination descriptor - i.e. this statment is not true:

"Note that your 8-bit buffer must be twice bigger then the Unicode. You know, 20 Unicode characters takes up 40 ASCII character slots. That is, aMyFileDataAs8Bit must be TBuf8<40>."

I can see what you're saying (I think).  I think you're saying that .Copy actually does a memory copy of one descriptor to the other....  It doesn't...  If it did, yes that statment is correct.  i.e. if you done:


XXX would need to be 40.

Copy actually works by talking a TUint8 pointer to the unicode string.  One byte is copied into the destination discriptor, and the next is then skipped.  Since every other byte is skipped - it clearly shows the destination buffer does not need to be twice the size of the source.

As I said in my last post and you said - .Copy will only actually accuratly copy the string (or what ever) if every "character" in the string is < decimal 256 - otherwise, as you say, it will just write a 1.