Vermutlich Hex Daten Umwandeln

[Gausi]

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.

[Schokohase]

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?

[Delphi.Narium]

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.

[Gausi]

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:

[Schokohase]

@Gausi

Genau das habe ich auch immer hier gesagt. Ich habe dann auf deinen Beitrag reagiert

Zitat:

Zitat von Gausi (Beitrag 1429393)

ISO8859-1 ist der 1-Byte-Zeichensatz, den wir hier in Westeuropa üblicherweise nutzen. In dem Bild sieht man aber deutlich, dass "Privat" mit einem 2-Byte-Zeichensatz gespeichert wurde. Und wie schon gesagt, ist das UTF16. Da in dem Beispiel nur Zeichen verwendet werden, die auch mit ihrer Unicode-Nummer in 1 Byte passen, ist hier jedes zweite Byte 0.

Warum das nicht mit der Spezifikation der DB übereinstimmt - keine Ahnung.

aus dem ich entnommen habe, dass du denkst in dem gesamten BLOB-Feld steht Text. Das habe ich nur versucht richtig zu stellen.

[Gausi]

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.

[Dumpfbacke]

Zitat:

Zitat von Delphi.Narium (Beitrag 1429375)

Code:

50 00 72 00 69 00 76 00 61 00 74
P   .   r   .   i   .   v   .   a   .   t

IBExpert interpretiert die Zahlen hexadezimal und zeigt das passenden ASCII-Zeichen an. Nicht anzeigbare Werte werden als . dargestellt.

Irgendwie sieht mir das so aus, als wären hier Texte im Textblob, die nicht kompatibel mit dem Zeichensatz ISO8859_1 der Tabelle / Datenbank sind.

Also Aufgabe

• Prüfen, was für Daten das sind.
• Welcher Zeichensatz steht hinter diesen Daten im Original?
• Testdatenbank mit dem entsprechenden Zeichensatz anlegen.
• Ein paar Testdaten einlesen.
• Daten anzeigen / ausgeben.

Hoffentlich hilft das ein bisserl weiter und bringt Dich Deinem Ziel näher.

Also als Darten wird hier "nur" text in eine Memo Feld gespeichert. In der Datenbak liegen einige Datensätze. Das mit dem Anzeigen ist nicht so einfach möglich das ist ja genau mein Problem. Es würde mir ja schon reichen wenn ich die Hexwerte bekommen würde wie im ersten Bild. Irgendwie funktioniert es nicht. Die ersten Zeichen werden anscheinend richtig ins Hexformat umgewandelt am dann später geht es nicht mehr. Leider bin ich da noch nicht an der Stelle wo ich die Daten benötige.

[p80286]

Hast du denn schon mal die lösung für Dummys ausprobiert:

Delphi-Quellcode:

mytext:=query.fieldbyname('myfield').asstring;

ist alles andere als sauber, aber könnte funktionieren.

Gruß
K-H

[Dumpfbacke]

Zitat:

Zitat von p80286 (Beitrag 1429465)

Hast du denn schon mal die lösung für Dummys ausprobiert:

Delphi-Quellcode:

mytext:=query.fieldbyname('myfield').asstring;

ist alles andere als sauber, aber könnte funktionieren.

Gruß
K-H

Ja habe ich funktioniert leider nicht. Es kommen am Anfang einige Rechtecke raus und dann nichts mehr.

[Ydobon]

Und wenn du es dir mit AsBytes erstmal als ByteArray holst?