The following method should also be valid for reading  a file.

Disclaimer: There may be a better way, but this works.

I am reading and writing serial port data with excel  and use string
variables to hold binary  data.
I use CHR$() to put binary data into the string variable and I use
ASC() to pull bytes out of the string, like this:
BinaryByte = Asc(Mid(data_msg, 6, 1))

Where data_msg is the string variable and this pulls one byte from
location 6 in the string.

Make it Hex(Asc(Mid(data_msg, 6, 1))) and you can see the bytes as hex
data the way you show below.

Where needed, I use a loop to (change the "6" here and) scan through
the bytes in the string

While it may sound strange, the data in a string variable is
actually no different that data in any other variable, namely bytes.
It is the way that data is interpreted by the software that makes it a
string. That is, a string variable is interpreted as a series of
ASCII codes and, therefore, it can be displayed as printable
characters, *IF* you request that they be printed. If I print my
particular strings, I see lots of garbage. My binary data is for
controlling a Ham radio that needs binary control codes and parameters.

I don't fully understand the example data below, nor how you are
actually seeing it. If I interpret correctly, the file data appears
to consist of byte values of &H00, &H20 and &H32 [interpreted as ASCII
NUL, Space and "2"]. Since a byte of 00 is a non printable ASCII
character code, it may very well be in the string (FullTRFText), just
not printing because of the way you are doing it. You should try to
scan through the string (FullTRFText) using MID() and see what the
actual bytes are.
If the nulls are still absent, then Excel is deleting them as mon
printable (as Dave S. says), but it seems to me that they should be there.
That said, one important issue will be the delimiter used in the
file. In my case, I read bytes from the port and have a binary
delimiter (&HFD) that I look for. If the file in question has a CR
(&H0D) delimiter, it can be read as strings and, I believe, all will
be well in the universe. If not, you can read individual bytes (one
at a time rather than by whole lines) and scan for the delimiter as I do.

Lastly, OPENing as Binary may be the cause. Excel tends to assume
that it knows what you want and can, at times, make conversions
between data types behind your back and confuse the heck out of you
(well... me anyway). If I'm reading this correctly, the file should
be opened as string or text rather than binary (I don't remember the
actual OPEN parameter name for a text file read). The half-life of
that knowledge chunk has been exceeded... (;-)