What is this file?

I have a file that has a character then alternates with a null thru the entire file. When I open it in notepad i just see the characters next to each other no null or spaces. I see the nulls as squares in word if i open it that way. When i read the file i have to read it 1 byte at a time so that i can grab the character and skip the null, grap, skip and so on.

So i have 2 questions:

1. What kind of file is this and
2. Is there a better and faster way to read this than 1 byte at a time.

I am using CFile to read it right now.

Any help would be very much appreciated.

Thank you,

It is probably a binary file (as opposed to text files). Yes, you can read as many characters as you want at a time. Function Read() gets a pointer to a buffer and the size of the buffer. It can be any size you want.

when i do this:

CFile myfile;

myfile.open("C:\file.txt");

myfile.Read (pbuf,100);

It still gets the NULLs too and really messes me up when i try to move it to a CString. So what is the best way to read this? I need to remove the NULLs before i put the info into a DB.

Thanks,

Possibly a unicode representation?

Try using CStdioFile::ReadString

It's probably a UTF-16 encoded file.

can anyone give some code on how to read this?

Thanks,

Hi,

You mention CString, so I guess you are using MFC.

Compile your application as unicode and it should work fine, use CFile::Read to read it into the CString.

Alan

where is the setting to compile as unicode?

Hi,
Try this:
http://www.mihai-nita.net/article.php?artID=20060723a

or if that's not enough, this: :-)
http://lmgtfy.com/?q=define+unicode+Visual+studio



Best regards,
Alan

Thank you,

Well when i did that i got 51 errors on a program that was working? Any ideas?

Can you post the file? Or where can I find it? Maybe once I can look at it I might be able to help.

Quote:

---

Originally Posted by strych9

I have a file that has a character then alternates with a null thru the entire file.

---

This sounds like a Unicode version of a file that used to be in a single-byte character set,

For example, a non-Unicode English text file that has been "Unicode-ized" will have the property you're describing.

Regards,

Paul McKenzie

what is the best way to read it?

Quote:

---

Originally Posted by strych9

what is the best way to read it?

---

You read the file in the same way you read other files. If this is a Unicode text file, it is perfectly valid.

The question is this: what is the purpose of your application? Why can't it handle Unicode files read in as-is, without messing around removing NULL characters? If the reason is that "I didn't think about Unicode", then maybe you should add in the ability (either by user option or some other means), to read in and process files based on 16-bit characters in a "natural" way, where you are not removing NULL characters..

Otherwise, just read the file in as-is, and if it is a 16-bit character file, then just inform the user "sorry my app handles only files based on single byte character set". Then take it from there as to what to do next in terms of supporting 16-bit character based files.

Also, you want to do this without removing the NULL characters, since I can produce a file that has 16 bit characters where you should not remove NULL bytes (i.e. an Asian language). What are you going to do when the file contains Chinese or Japanese 16-bit characters? Either you support 16-bit characters, or you don't. If you start removing NULL characters from a "true" 16-bit character set, you are not only changing the characters, you are turning the resulting text into nonsense, and then storing it in your database.

Regards,

Paul McKenzie

Hi,

I still recommend compiling as Unicode, sorry for not pointing out you would need to make some changes to your code as well, since you will now be using Unicode versions of any Windows functions.

Basically, you'll need to wrap (almost) all your text strings in a macro so that the compiler treats them as Unicode, e.g. change "My string" to
_T("My String")

Doing that will fix most of the errors. You may also have to fix up a few memory issues, since the size of a character will now be twice what it was before.

Alan