Ob mein Datensalat eine Bytefolge in einer Datei ist, oder in einem Blob-Feld (Binary Large Object), ist doch relativ irrelevant. Da werden Daten gespeichert, die nicht in die gängigen Datentypen Int, String, wasweißich passen. Halt irgendwelche Daten. Innerhalb dieser Daten ist jedoch ein String versteckt, den der TE haben möchte. Und dieser ist hier offensichtlich UTF16 kodiert. Oder meinetwegen UCS-2LE, was aber in fast allen Fällen egal sein dürfte.
Wie man innerhalb des Blob-Feldes den Anfang (und das Ende) des Strings erkennt, ist natürlich auch noch eine wichtige Frage. Das könnte in der Dokumentation stehen. Oder man versucht, das irgendwie auszutüfteln, in dem man die entsprechenden Felder anderer Datensätze untersucht. Recht wahrscheinlich ist ein konstanter Offset davor mit einigen Flags und/oder Metainformationen zu dem String, wie z.B. die Länge.
Natürlich ist es möglich, dass hier eine andere Kodierung verwendet wurde. Aber das ist äußerst unwahrscheinlich. Das bekloppteste, was mir bei Kodierungen mal untergekommen ist, war ein String, der zeichenweise als nullterminierter String als UTF16 mit Byte-Order-Mark abgespeichert wurde. Also 6 Byte pro Zeichen - 2 Byte BOM, 2 Byte für das eigentliche Zeichen, 2 Null-Byte für den Terminator.
The angels have the phone box.