![]() |
AW: Vermutlich Hex Daten Umwandeln
Natürlich befinden sich in einer Datei, die keine reine Textdatei ist, auch andere Bytes, die nicht direkt sinnvoll als Text interpretierbar sind. Das ist in Datenbank-Dateien sicherlich so, und das ist auch (daher kenne ich das sehr gut) in mp3-Dateien mit dem ID3-Tag so der Fall.
Wenn in einer solchen Mix-Datei an einer Stelle abwechselnd "Nullen" und "Buchstaben" stehen, und diese Buchstaben aneinandergereiht auch noch ein sinnvolles Wort ergeben, dann ist das ein verdammt starker Hinweis darauf, dass an dieser Stelle in der Datei ein UTF16-kodierter String steht. Alles andere wäre sehr, sehr abwegig. Ich würde sogar noch weitergehen und behaupten, dass die 06 00 00 00 davor die Länge dieses Strings angeben, aber das ist ohne weitere Kenntnis des Dateiformates nur ein Schuss ins Blaue. |
AW: Vermutlich Hex Daten Umwandeln
Der TE lässt sich per IBExpert den Inhalt eines BLOB-Felds als HEX anzeigen und bekommt das so präsentiert.
Was hat das jetzt damit zu tun, wie die Datenbank die Daten in einer Datei auf der Platte speichert? |
AW: Vermutlich Hex Daten Umwandeln
Weil ein Textblob eventuell für einen Bytehaufen nicht zwingend die richtige Wahl der Speicherform sein muss?
Man müsste mal prüfen, ob Bytehaufen (= beliebige binäre Daten) auch problemlos in Textblobs abgelegt werden können. |
AW: Vermutlich Hex Daten Umwandeln
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. :wall: |
AW: Vermutlich Hex Daten Umwandeln
@Gausi
Genau das habe ich auch immer hier gesagt. Ich habe dann auf deinen Beitrag reagiert Zitat:
|
AW: Vermutlich Hex Daten Umwandeln
Ah, ok, dann haben wir ein wenig aneinander vorbei geschrieben. :thumb:
Ich meinte die Kodierung tatsächlich auf diesen Ausschnitt des Blobs bezogen. Aufgabe ist es also, das Blob zu parsen (ganz rudimentär reicht ja ggf., weil für die Aufgabe nicht alle Daten wichtig sind), und dann den relevanten Teil in einen (Wide)String zu laden. |
AW: Vermutlich Hex Daten Umwandeln
Zitat:
|
AW: Vermutlich Hex Daten Umwandeln
Hast du denn schon mal die lösung für Dummys ausprobiert:
Delphi-Quellcode:
ist alles andere als sauber, aber könnte funktionieren.
mytext:=query.fieldbyname('myfield').asstring;
Gruß K-H |
AW: Vermutlich Hex Daten Umwandeln
Zitat:
|
AW: Vermutlich Hex Daten Umwandeln
Und wenn du es dir mit AsBytes erstmal als ByteArray holst?
|
Alle Zeitangaben in WEZ +1. Es ist jetzt 02:22 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz