Here's an adapted version of one I've used successfully for reading TIFF
files. Note that it requires a "fieldsize" parameter. This is because the
stream is read the same direction regardless of the byte order. It is the
size in bytes of the data that affects the reading of the bytes from the
stream. It returns the bytes in the correct order after reading, as an array
of bytes. It can be used with other methods to get specific types, such as
Int32, Int64, etc. For example, if you know you're reading Int32 data, you
would pass 32 to the fieldSize parameter. Then you use the BitConverter
class to convert the byte array to whatever data type it is. Below the enum
and method definition I have an example for Int32:
public enum ByteOrder : int
{
LittleEndian,
BigEndian
}
public static byte[] ReadBytes(BinaryReader reader, int fieldSize, ByteOrder
byteOrder)
{
byte[] bytes = new byte[fieldSize];
if (byteOrder == ByteOrder.LittleEndian)
return reader.ReadBytes(fieldSize);
else
{
for (int i = fieldSize - 1; i > -1; i--)
bytes[i] = reader.ReadByte();
return bytes;
}
}
public static int ReadInt32(BinaryReader reader, ByteOrder byteOrder)
{
if (byteOrder == ByteOrder.LittleEndian)
{
return (int)reader.ReadInt32();
}
else // Big-Endian
{
return BitConverter.ToInt32(ReadBytes(reader, 32,
ByteOrder.BigEndian));
}
}
--
HTH,
Kevin Spencer
Microsoft MVP
..Net Developer
We got a sick zebra a hat,
you ultimate tuna.
"Mike" <vi********@yahoo.com> wrote in message
news:Of*************@TK2MSFTNGP14.phx.gbl...
"Karl Seguin [MVP]" <karl REMOVE @ REMOVE openmymind REMOVEMETOO . ANDME
net> wrote in message news:ua**************@tk2msftngp13.phx.gbl... The BinaryWriter/Reader's are little-endian only. Was hoping they were
going to be made more flexible in 2.0, but that doesn't appear to be the
case.
Anyone already done all the work of implementing this? :)
I was hoping so as well.
In addition, any word of a .Net binary stream or serialzation library
compat. with a Java serializaion or Java DataInput/Output stream would
great. This on the .Net server side would save me quite a bit of mobile
badwidth and parsing processing power on the J2ME client side vis-a-vis
XML.
Karl
--
http://www.openmymind.net/
