Yet another binary file loading question

I am currently trying to port an existing application to Unity, and when it comes to resources loading, problems arise…
I fumbled for a while until I found about the “.bytes” extension required to load binary files and … it still didn’t work.
My files begin with a magic number and a version number like follows :

0x504D425200000200  (in hexa)
which can be read in ASCII as : PMBR....  (the last 4 characters are not writable)

when I load a file, I obtains only the first 4 bytes.

A few experiments later, I tried on a hunch to change the first byte to a hex value > 128 and it finally worked !

But this solution feel dirty, I have to modify the content of my resources (in addition to changing the extension) and what guaranty do I have that it will work with all my files ?

Does anyone know of a true solution to this problem ?

Edit :

To clarify my question, here is what I think happens :

  • If a file starts with ASCII characters (< 0x80), Resources.load(“myFile”, typeof(TextAsset)) loads the file into a string and TextAsset.bytes returns the bytes of the string.
    So if a file contains 0x0000 (or just 0x00 ?) the file is cut when loaded to a string and so, TextAsset.bytes returns only the bytes available in the string (0x504D4252 in my case).

  • If on the contrary the file starts with a non-ASCII character (> 0x80), it is handled as a binary file and there is no problem when loading it

Hava you already encountered such behavior ? how did you handle it ?

Depending on what system you work it’s a difference between little-endian and big-endian format.

If you read the first 4 bytes as an int32 on a “normal” x86+ architecture you will have the little-endian format. So the first 4 values(0-3) as one int32 will look like this:

0x52424D50

The next 4 bytes (4-7) look like this (if that’s the true hex representation):

0x00020000

Another thing:
When this “PMBR0020” is the ascii representation the last 4 bytes will be

0x30323030

0x30 == 48(dec) == “0”