I have a binary file with a custom formatting that I need to parse and extract information from.
When I open the file with a Hex editor, it shows 675 bytes in the file, and the file size in its windows properties windows is also 675 bytes(Size on disk: 4KB).
When I use the C# method File.ReadAllBytes(), I get an array of size 1172 bytes.
I cannot make any sense of the bytes present in the array with respect to the bytes in the Hex editor.
Why does C# read in 1172 bytes when the file contains 675 bytes? How can I parse this?
Related
In C# I want to replace example bytes number 200-5000 by an array/stream of 30000 bytes inside a file, the numbers are just for example, the sizes may vary, I could be replacing a section with either more or less bytes than the size of the section.
I have checked this question:
Replace sequence of bytes in binary file
It only explains how to override a fixed-sized section and will overwrite data after if the byte array length is bigger than original section and will leave old bytes in place if the section to be replaced is bigger than the new bytes.
Higher performance and not having to read the entire file into memory would be preferred, but anything goes.
I would need this to work both on windows and linux.
When I try to understand SFML, I tried to set an icon with RenderWindowInstanse.SetIcon()
the method, that takes 3 parameters, fist two is size, 3 - byte[], then I try to use File.ReadAllBytes()
and same tools in c#, but that don't work, I search and find on-site ImageInstanse.Pixels property that returns byte[] like a parameter, that's works but I don't understand why they are returning different byte arrays
In SFML.NET, Image.Pixels returns an array of bytes that are nicely organized RGBA pixel values that represent the image in memory.
.NET's own File.ReadAllBytes() function returns the bytes that come from the file itself in the system's storage device.
Every file has a format that defines the layout and meaning of the bytes that make up that file. Image files are an extension of that concept as there any many different file formats for images. The pixel data for an image has to be encoded (and/or compressed) according to the format it is being saved as. This means that the bytes in the file no longer matches the raw RGBA pixel data as it was in the computer memory.
Files often contain lots of extra bytes for things like a file header, metadata, compression information, or possibly even an index for blocks of data that are smaller files or images within a file.
When you use File.ReadAllBytes(), you are given all of the bytes that represent this data in an array and you have to know exactly what the meaning of the byte at each index is.
SFML understands how to decode many different image formats, and will read the bytes of the file and process that into an array of pixel data. This is what the constructor for Image that takes a file is doing in the background. Once you have an SFML.Graphics.Image instance, you can use its Pixels property to access that decoded RGBA pixel data.
I'm working on a file reader for a custom file format. Part of the format is like the following:
[HEADER]
...
[EMBEDDED_RESOURCE_1]
[EMBEDDED_RESOURCE_2]
[EMBEDDED_RESOURCE_3]
...
Now what I'm trying to do is to open a new stream that its boundaries are only one resource, for instance EMBEDDED_RESOURCE_1's first byte is at the 100th byte and its length is 200 bytes so its boundaries are 100 - 300. Is there any way to do so without using any buffers?
Thanks!
Alternatively - MemoryStream.
Before reading the necessary number of bytes set the initial position of the position by the property - Position.
But it is necessary to read the entire file into MemoryStream.
I need to store an arbitrary amount of files (with any file type) as a property on a class. This class will get serialized to a JSON file. Later the user can load the JSON file back into the app, and has the ability to recreate the files they originally loaded. Right now I'm storing the files as an array of bytes. The issue is that some of the files are large, and the array of bytes is too large and is causing the serialization/deserializationto take a very long time.
Is there a way I can store the files as a string/array of strings instead of bytes? Or some different way of storing the files? What are some options to deal with this problem?
edit:
I believe a string would be faster because right now when the byte array is being rendered out in JSON in ascii format, so it looks like this:
150,123,43,62...
Encode your byte array as a base 64 string using Convert.ToBase64String(). That should reduce the size of your JSON significantly: http://rextester.com/ILJNV57711
For example, here's a random byte array, serialized as JSON:
[95,103,154,174,23,5,178,179,158,186,181,89,40,229,233,168,217,42,98,65,248]
Here's the same array, converted to a base 64 string, serialized as JSON:
"X2earhcFsrOeurVZKOXpqNkqYkH4"
It's plain to see that a byte array is smaller in JSON when expressed as a base 64 string. It goes from 76 characters to 30.
Certainly don't store the byte array as decimal numbers like that; Base64 encode it at the very least. Base64 encoding will enlarge the data to 133% of the raw file size but that'll be a massive improvement from the 400% enlargement you're currently using.
An OLE Object column contains images but the image type (jpg/gif/tiff) is unknown. These images need to be extracted from the DB and saved to disk. The application is primarily using VB.NET but C# examples are welcome too.
thanks
Rahul
Try using the System.Drawing.Image.FromStream to load the image. You can make a stream from a byte array using System.IO.MemoryStream foo = new System.IO.MemoryStream(MyByteArray);
Once you've loaded the image, you can use whatever GDI stuff you want to save it (e.g. ImageInstance.Save(FileName);)
Create a byte array large enough to hold the OLE object:
Dim bArr(Len(<OLE Object Field>)) as Byte
Read in the first row of your OLE Object column and place it in the Byte array.
For a GIF file, bytes 0 through 2 will have the ASCII value "GIF".
For a JPEG file, bytes 6 through 9 will typically have the value "JFIF".
For a PNG file, bytes 1 through 3 will have the ASCII value "PNG".
TIFF is more difficult since there are so many different TIFF standards.
Once you have determined the file type, you can use Brian's method to save the file