Bytestream

From: StackExchange

Byte streams contain, well, bytes. Broken down into what it is actually, it is 8 bits composed of 1s and 0s. If it were representing a number, it would be any number from 0 to 255 (which, I may add, is no coincidence why the 4 numbers in an IP address always range from 0 to 255). Byte streams are usually sophisticated interfaces meant to hide the underlying basic byte array used to hold a circular buffer (you fill up the buffer and wait for someone to empty it, at which time it simply fills up the buffer again).

What the heck does that represent? Well, it could represent a text file, or an image, or a live video stream. What it is is entirely dependent upon the context of who is reading it. Hex representation is another way of saying the same thing, though it is sometimes more convenient to manage bytes in terms of their hex representation rather than numbers however it is the same thing.

When you're referring to raw data, you are usually referring to byte data. The data comes without a tag saying "I am an image file!" Usually you only deal with raw data when you don't really care what the data represents overall. For example, if I wanted to convert an image to its black and white version, I might say to read an image's raw data and for every 3 bytes read (which would actually be representation of red color, representation of green color, and representation of blue color), add its number value and divide by 3, then write that value 3 times. Essentially what I'd be doing is averaging a pixel's red, green, and blue values and making its gray equivalent pixel from that. However, when you talk about performing operations to data at the level of "byte by byte", you don't really care about the big picture, so to speak.

Or, perhaps you wish to save a file in a database, but it asks you to insert its "raw data" in a blob data type. This simply means to convert the data of a file into a large byte array that the database can understand and manage. You'll find that when you retrieve that value from the database, it will be simply one large byte array as you initially provided to the database to begin with. If that data was a file, then you, the programmer, must reinterpret that byte data as if you were reading a file one byte at a time.

If someone asked you to "reverse the 4 byte data", I would assume it refers to big-endian vs little-endian interpretation of numbers, which writes numbers starting with the most or least significant byte. It does not matter if a number is represented as big-endian or little-endian, just that all systems reading the number interpret it consistently.

This isn't to say that the actual number representation (or hex representation for that matter) is changed, simply that the order in which these 4 bytes make a number should be reversed. So say you have 0x01, 0x02, 0x03, and 0x04. To reverse these, you'd have 0x04, 0x03, 0x02, 0x01 instead. The system would presumably read these 4 bytes in the reverse order and since you've already reversed it, the value is interpreted to be the very same as what was intended in the raw data.