Select to view content in your preferred language

Reading BLOBs-- byte array returns improper bytes

663
2
10-30-2023 01:41 PM
AlfredBaldenweck
MVP Regular Contributor

Hi all, I'm experimenting with reading a BLOB field.

I know the values that should be in it, however, they are wrong.

\x00d\x00\x00\x00\x00  #100
\xe8\x03\x00\x00\x00 #1,000
\x10\'\x00\x00\x00 #10,000
\xa0\x86\x01\x00 #100,000
\x00@B\x0f\x00\x00 #1,000,000
\x80\x96\x98\x00\x00 #10,000,000
\x00\xe1\xf5\x05\x00 #100,000,000

 

The pattern appears to be 5 sets of bytes, the last of which is an empty separator (so 4 sets), then the bytes that are not empty are ignored and everything is read backwards. So, 1000 (\xe8\x03\x00\x00\x00) is read as '03e8'. Easy.

However. 

This does not work for 100, 10,000, or 1,000,000.

100 should be returned as \x64\x00\x00\x00\x00.

10,000 should be \x10\x27\x00\x00\x00

1,000,000 should be \x40\x42\x0f\x00\x00

The issues:

  • The separator between 100,000 and 1,000,000 appears to have been absorbed into the first byte of 1,000,000. Instead, we get this weird \x00@B\, which doesn't seem to mean anything.
  • Ditto for 100 and its preceding number; we instead get \x00d\. 0d is the number 13, so not sure where that came from.
  • 10,000 just gives an apostrophe instead of a real value.

What is going on, and how can I reliably parse this byte array?

0 Kudos
2 Replies
HaydenWelch
Occasional Contributor II

Classic webdev blunder:

\x64 is the unicode hex for small d

\x27 is the unicode hex for apostrophe.

However you're reading the BLOB field data is for some reason parsing the bytes as Unicode characters.

0 Kudos
AlfredBaldenweck
MVP Regular Contributor

That's what I figured out, yeah. Ended up returning as string so I could parse the hex instead of trusting returnasbinary to give me values I can trust.

0 Kudos