By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,573 Members | 3,017 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,573 IT Pros & Developers. It's quick & easy.

Problem Using TextReader and Binaray Reader on Same File

P: n/a
I am rewriting a C++ application in C#. This file has a combination of Text
and Binary data.

I used CFile before to read the text. If I hit a certain string that
denotes the following data is binary, I used the current position in the
file and another stream to read to the binary data.

All text data is ended with a carriage return / line feed while the binary
is actually an image file listed byte by byte. Preceding the binary data is
a text value ended by a cr/lf listing the actual number of bytes of binary
data.

The problem is that the position given by textreader.basestream seems to be
actually twice the actual position in bytes. Therefore positioning a Binary
Reader based on the position in a Text Reader is incorrect.

This worked with CFile.

Any ideas?

Thank You,
Jeff
Nov 22 '05 #1
Share this Question
Share on Google+
4 Replies


P: n/a
It sounds like you are using a 16-bit encoding with the TextReader. I
wonder if specifying an 8-bit encoding (System.Text.Encoding.ASCII)
would solve your problem. It's worth a try.
Otherwise, if you can consistently see that the TextReader position is
always twice the binary position... well, divide by 2 (right shift 1)!
je**********@bellsouth.net wrote:
I am rewriting a C++ application in C#. This file has a combination of Text
and Binary data.

I used CFile before to read the text. If I hit a certain string that
denotes the following data is binary, I used the current position in the
file and another stream to read to the binary data.

All text data is ended with a carriage return / line feed while the binary
is actually an image file listed byte by byte. Preceding the binary data is
a text value ended by a cr/lf listing the actual number of bytes of binary
data.

The problem is that the position given by textreader.basestream seems to be
actually twice the actual position in bytes. Therefore positioning a Binary
Reader based on the position in a Text Reader is incorrect.

This worked with CFile.

Any ideas?

Thank You,
Jeff

Nov 22 '05 #2

P: n/a
Joshua,

I am considering that except I did not want to do anything that would
potentially fail in converting to a 64 bit OS.

I did try the ASCII encoding, etc and the same problem occurred. I think I
am just going to use the binary reader and create my own readline
functionality.

I also just read the entire file into memory and it did not bog down the
machine too much. I am not sure about the deployment machine yet. The
FileStream / Binary Reader classes may provide some behind the scenes
buffering to help this.

This does give me the capability to scan the contents quickly and create
some file offset arrays to quickly process the data I need.

Thanks for the input,
Jeff

"Joshua Flanagan" <jo**@msnews.com> wrote in message
news:uy**************@TK2MSFTNGP09.phx.gbl...
It sounds like you are using a 16-bit encoding with the TextReader. I
wonder if specifying an 8-bit encoding (System.Text.Encoding.ASCII) would
solve your problem. It's worth a try.
Otherwise, if you can consistently see that the TextReader position is
always twice the binary position... well, divide by 2 (right shift 1)!
je**********@bellsouth.net wrote:
I am rewriting a C++ application in C#. This file has a combination of
Text and Binary data.

I used CFile before to read the text. If I hit a certain string that
denotes the following data is binary, I used the current position in the
file and another stream to read to the binary data.

All text data is ended with a carriage return / line feed while the
binary is actually an image file listed byte by byte. Preceding the
binary data is a text value ended by a cr/lf listing the actual number of
bytes of binary data.

The problem is that the position given by textreader.basestream seems to
be actually twice the actual position in bytes. Therefore positioning a
Binary Reader based on the position in a Text Reader is incorrect.

This worked with CFile.

Any ideas?

Thank You,
Jeff

Nov 22 '05 #3

P: n/a
<je**********@bellsouth.net> wrote:
I am rewriting a C++ application in C#. This file has a combination of Text
and Binary data.

I used CFile before to read the text. If I hit a certain string that
denotes the following data is binary, I used the current position in the
file and another stream to read to the binary data.

All text data is ended with a carriage return / line feed while the binary
is actually an image file listed byte by byte. Preceding the binary data is
a text value ended by a cr/lf listing the actual number of bytes of binary
data.

The problem is that the position given by textreader.basestream seems to be
actually twice the actual position in bytes. Therefore positioning a Binary
Reader based on the position in a Text Reader is incorrect.


This is an unfortunate problem with TextReader. You *may* find that
creating a StreamReader with a buffer size of 1 sorts the problem, but
it'll be very inefficient.

If your file is in ASCII, you could spot the CRLF while reading it as
binary data, and then convert the binary data to text when you find the
CRLF, all the while knowing where you are.

If you're in control of the file format, however, I'd suggest that you
prefix any text section with the number of bytes in that text section.
You can then read that amount of data and convert it to text
separately, without overrunning.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 22 '05 #4

P: n/a
Joshua Flanagan <jo**@msnews.com> wrote:
It sounds like you are using a 16-bit encoding with the TextReader. I
wonder if specifying an 8-bit encoding (System.Text.Encoding.ASCII)
would solve your problem. It's worth a try.
Otherwise, if you can consistently see that the TextReader position is
always twice the binary position... well, divide by 2 (right shift 1)!


No, the problem is that StreamReader will read more than it's returned
so far into an internal buffer. The stream's position is then
"inaccurate" in terms of how much appears to have been read.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 22 '05 #5

This discussion thread is closed

Replies have been disabled for this discussion.