TFileStream und #0

[hoika]

Hallo #,

es gibt doch Delphi-Versionen, die Probleme beim Laden binärer Dateien mit #0 haben.
Dabei wurde beim ersten #0-Zeichen abgebrochen.

Es gab sogar mal ein direktes Bsp. zum Testen, ich finde es aber leider nicht mehr.

Kann mir jemand helfen ?

Danke

Heiko

[Sir Rufo]

Das kenne ich nur in dem Zusammenhag, wenn man die Datei direkt in einen String laden will

[hoika]

Hallo,

das kommt als nächstes ;)
Ich will eigentlich eine Binärdatei durchsuchen,
allerdings nicht per Pos, sondern zu Fuss.

Vielleicht verwechsle ich das jetzt auch mit StringReplace ...


Heiko

[Sir Rufo]

Und du willst die Binärdatei nach einem String durchsuchen?

Wie zuverlässig wirst du den den finden wollen?
In der Binärdatei kann der ja in jeder möglichen Codierung enthalten sein (eben auch MultiByte).

Wenn die Codierung des Strings innerhalb der Binärdatei bekannt ist, dann hole dir die Bytefolge des Strings und suche nach dieser Bytefolge in der Binärdatei. Dadurch weißt du allerdins nur, dass diese Bytefolge in der Binärdatei ist und nicht, ob damit auch wirklich der gesuchte String dort repräsentiert wird.

Gesichert weiß man das nur, wenn man den strukturellen Aufbau der binären Datei kennt. Ansonsten können die Bytefolgen dort alles und nichts bedeuten.

[himitsu]

In Strings kann man #0 und Co. immernoch problemlos laden.

Aber TStringList und Co. behandeln die 0#
und viele vergessen, daß ein UnicodeString "neuerdings" 2 Byte hat.
Schon interessant, daß das nach fast 5 Jahren kaum einer weiß.

Zitat:

Zitat von hoika (Beitrag 1245460)

allerdings nicht per Pos, sondern zu Fuss.

Seitdem Pos auf FastCode umgestellt wurde, kann man es nicht mehr verwenden, wenn eine #0 im String vorkommt.

Vorher ging man direkt auf Length, aber seitdem wird das auf PChar gecastet und die schrottige #0 verwendet,
was übrigens wunderbar knallt, wenn die implizieten zwei #0-en am String-Ende zerschossen wurden.

[hoika]

Hallo,

Ich durchsuche Doc-Dateien nach bestimmten Kennern,
z.B. <NachName>.
Word hat aber die Eigenheit, dann auch sowas nach einer wilden Formataktion zu erzeugen:
<Nac#0hName#0> .
Das soll auch gefunden werden.
Der aktuelle Code läuft über direktes Byte-Lesen
und ist gerade bei großen Dateien etwas langsam.
Ich dachte jetzt, dass mit TFileStream zu machen.
Ich müsste dann jedes Byte einzeln ansprechen.
Die interne Suchroutine soll ja so bleiben.

Es geht hier übrigens nur um DOC, bei DOCX und ODT
habe ich dank dem XML-Format weniger Probleme ...

Heiko

[jaenicke]

Zitat:

Zitat von hoika (Beitrag 1245583)

Der aktuelle Code läuft über direktes Byte-Lesen
und ist gerade bei großen Dateien etwas langsam.
Ich dachte jetzt, dass mit TFileStream zu machen.
Ich müsste dann jedes Byte einzeln ansprechen.

Dafür empfehle ich die Verwendung von MMFs:
http://www.delphipraxis.net/151898-s...ei-reader.html
Damit lese ich in meinen Registryeditor .reg Dateien ein. Damit schaffe ich auf einer normalen Desktopfestplatte 70-100 MiB/s beim byteweisen (!) Auslesen, je nach Modell. Sprich es geht Richtung Maximalgeschwindigkeit der Platte. Bei SSDs ist es noch einmal schneller, damit habe ich aber nicht viel getestet.

[hoika]

Hallo,

ich lese dort immer Textdateien (bei dem Link von jaenicke),
ich brauche das ganze aber binär.


Heiko

[jaenicke]

Dort benutze ich PAnsiChar, aber du kannst daraus auch problemlos PByte machen und stattdessen die Bytewerte nehmen (die Unicode-Teile kannst du einfach entfernen). Du sollst den Quelltext ja nicht unbedingt 1:1 benutzen, aber du kannst ihn als Vorlage benutzen um mit einer MMF die Dateien sehr schnell und dennoch rein byteweise auszulesen.
Ob das nun Zeichen oder Bytewerte sind, ändert an der Vorgehensweise nichts.

Ich suche dort die Zeilenenden. Analog kannst du auch nach deinen Werten suchen.

[hoika]

Danke


Heiko