Jump to content
Posted 02 December 2012 - 05:26 PM
Posted 02 December 2012 - 05:57 PM
Posted 02 December 2012 - 06:07 PM
I'm trying to write binary data on Android and read it from Windows (and also the other way around). I tried just using the std::fstream in binary mode alone. The thing is, when I read the data from Windows that I wrote in Android I get lots of corrupted values. I read that ARM is a bi-endian processor so it could be little or big endian depending on the device? How can binary file formats be written to be endian independent?
Posted 02 December 2012 - 06:12 PM
Posted 02 December 2012 - 06:15 PM
Posted 02 December 2012 - 10:44 PM
Posted 03 December 2012 - 04:48 AM
Posted 03 December 2012 - 06:34 AM
Are you talking about the Unicode BOM? I don't think that has anything to do with Microsoft (other than indirectly via their involvement in the working group). Though if you know better, I'd be interested to hear more about it.
If you read the first word and it comes out correctly, just read the rest of your file. If it comes out with wrong byte order, you need to flip all values. If it comes out as something else, it's not a file of the type you expected. Microsoft's infamous byte order mark is nothing else but exactly that.
Posted 03 December 2012 - 09:28 AM
Every TIFF begins with a 2-byte indicator of byte order: "II" for little-endian (aka "intel byte ordering", circa 1980) and "MM" for big-endian (aka "motorola byte ordering", circa 1980) byte ordering. The third byte represents the number 42 which happens to be the ASCII character "*", also represented by hexidecimal 2A, selected because this is the binary pattern 101010 and "for its deep philosophical significance". The 4th byte is represented by a 0, an ASCII "NULL". All words, double words, etc., in the TIFF file are assumed to be in the indicated byte order. The TIFF 6.0 specification says that compliant TIFF readers must support both byte orders (II and MM); writers may use either.
Posted 04 December 2012 - 06:58 AM
Posted 04 December 2012 - 07:31 AM
Yes, the Unicode BOM. I've named Microsoft both because of their involvement in the working group and because most (all?) of their products are well-known to use BOMs even when not appropriate such as in UTF-8 encoded files (though, it's not strictly forbidden, but it is nonsense and causes trouble with some software).
Are you talking about [...]?