Guten Morgen,
ich habe nun seit mehreren Tagen schon ein ärgerliches Problem.
Ich muss in einem Projekt verschlüsselte Daten speichern und habe dafür die Crypto-API benutzt.
Ich speichere also diesen Salt-Wert zwischen und lade ihn später wieder.
Das funktioniert auch tadellos. Es gibt aber leider auch Ausnahmen.
Und zwar, wenn der zufällig erstellte SALT-Wert irgendwelche Zeichen enthält, die nicht vernünftigt aus der Datei ausgelesen werden können.
Natürlich kann es an der Art liegen, wie ich den Wert speichere.
Ich hoffe, mir kann hier wer helfen.
Speichern des Wertes: Open (App.Path + „\salt.dat“) For Append As 1
Print #1, strsalt
Close #intdateinr
Auslesen des Wertes: Open (App.Path + „\salt.dat“) For Input As 1
Line Input #1, strsalt
Close #intdateinr
Muss ich den Wert anders Speichern oder Einlesen??
input ist für den Zweck ungeeignet, weil es Steuerzeichen berücksichtigt, verarbeitet aber nicht mit liest.
Für binäre Daten ist Get besser.
Dim ff As Integer
Dim Daten As String
Dim Fl As Long
Dim Na As String
Na = "C:\Test.dat"
ff = FreeFile
Fl = FileLen(Na)
Daten = Space(Fl)
Open Na For Binary As #ff
Get #ff, , Daten
Close #ff
Open Na For Binary As #ff
Put #ff, , Daten
Close #ff
Nun tut sich ein Problem auf, welches ich bis jetzt noch nicht lösen konnte.
Ich speichere die Daten mit einem eigenen Type.
Type Account
email as string
name as string
end type
Speichern würde ich in etwa so:
put #1,position, new_account
Wie bekomm ich das mit der Position nun richtig hin?
Beim Speichern sowie Auslese habe ich einen Integerwert,
welchen Wert ich habe.
Ich setze den Integer einen hoch und will unter der Position speichern.
Beim Auslesen habe ich die entsprechende Position.
Wie setze ich das um?
Wenn ich einfach den Integerwert reinsetze, klappts natürlich nicht,
was mich auch nicht wundert.
Aber wie es richtig geht, weiß ich nicht.
da hast Du mich auf dem falschen Fuß erwischt, mit wahlfreiem Zugriff habe ich noch gar nichts geschrieben.
Ich habe aber etwas zusammenbekommen, das funktioniert, eventuell hilft Dir das ja.
Option Explicit
Private Type Account
email As String \* 10
name As String \* 10
End Type
Private Sub Command1\_Click()
'Daten erzeugen und schreiben
Dim AC(9) As Account
Dim Na As String
Dim ff As Integer
Dim i As Integer
ff = FreeFile
Na = "C:\Test.txt"
For i = 0 To 9
AC(i).email = "Adresse" + CStr(i)
AC(i).name = "Name" + CStr(i)
Next
Open Na For Binary As #ff
Put #ff, , AC
Close #ff
End Sub
Private Sub Command2\_Click()
'Daten komplett lesen
Dim AC(9) As Account
Dim Na As String
Dim ff As Integer
Dim i As Integer
ff = FreeFile
Na = "C:\Test.txt"
Open Na For Binary As #ff
Get #ff, , AC
Close #ff
For i = LBound(AC) To UBound(AC)
List1.AddItem AC(i).email + " " + AC(i).name
Next
End Sub
Private Sub Command3\_Click()
'Einen Satz lesen
Dim AC As Account
Dim Na As String
Dim ff As Integer
Dim i As Integer
ff = FreeFile
Na = "C:\Test.txt"
Open Na For Random As #ff Len = Len(AC)
Get #ff, 5, AC
Close #ff
List1.AddItem AC.email + " " + AC.name
End Sub
Noch eine Verständnisfrage hinterher,
wenn ich im Type, die Stringlänge festlege mit
string * 10
oder ähnlichem
Und ich dann den String wieder auslese…
muss ich dann irgendwelche Leerzeichen abtrennen
oder bekomme ich nur den Anfangsstring zurück
auch wenn der meinetwegen nur 3 Zeichen lang war?
Dann könnte ichs mir sparen die Länge zu speichern.
Noch eine Verständnisfrage hinterher,
wenn ich im Type, die Stringlänge festlege mit
string * 10
oder ähnlichem
Und ich dann den String wieder auslese…
muss ich dann irgendwelche Leerzeichen abtrennen
ja: Neu = RTrim(Alt)
oder bekomme ich nur den Anfangsstring zurück
auch wenn der meinetwegen nur 3 Zeichen lang war?
Nur wenn Du Trim oder RTRim verwendest.
Dann könnte ichs mir sparen die Länge zu speichern.
Die Längenangabe? Dann läuft das Programm wieder nicht mehr.
Für den wahlfreien Zugriff müssen die Datensätze gleich lang sein.
Funktioniert nun alles wunderbar.
Ich speichere die Länge als Integer auch in dem Type.
Könnte das später zu Problemen führen?
Ich bin davon ausgegangen, das Integer immer
den gleichen Speicherbedarf haben
das freut mich. Danke für die Frage, nun weiß ich auch wie es geht, wenn ich das mal brauche. Das hat gut gepasst, ich habe alles auf Anhieb gefunden und jetzt habe ich es auch verstanden.
Ich speichere die Länge als Integer auch in dem Type.
Könnte das später zu Problemen führen?
Das habe ich jetzt nicht versucht, das geht? Das ist zumindest überflüssig, weil …
Ich bin davon ausgegangen, das Integer immer
den gleichen Speicherbedarf haben
… Du das genau richtig siehst. Ein Integer ist immer zwei Bytes lang. Nur für Strings sollst Du die Länge angeben, alles andere hat feste Längen.
Ich mache das mit dem Integer, weil ich mir unsicher war.
Denn, dieser Salt-Wert wird ja mit zufälligen Zeichen gefüllt
und ich hatte die Befürchtung, das Trim mir da eventuell auch
mal das ein oder andere Zeichen rausnehmen kann.
Ich bin mir ja nicht sicher, mit welchem Zeichensatz der Saltwert erstellt wird.
Ich mache das mit dem Integer, weil ich mir unsicher war.
nicht nötig, Integer hat immer zwei Bytes.
Denn, dieser Salt-Wert wird ja mit zufälligen Zeichen gefüllt
und ich hatte die Befürchtung, das Trim mir da eventuell auch
mal das ein oder andere Zeichen rausnehmen kann.
Da musst Du Dir keine Sorgen machen, Trim entfernt nur Leerzeichen, sonst nichts.
Ich bin mir ja nicht sicher, mit welchem Zeichensatz der
Saltwert erstellt wird.
Das spiel keine Rolle, VB liest ja den ASCII und kümmert sich nicht um den Zeichensatz. Trim() macht einfach nur Replace(String, " ", „“).
Ich meine ja nur, dass ja eventuell im Salt-Wert absichtlich
Leerzeichen drinstehen könnten, die dann gelöscht würden.
die Leerzeichen die drin stehen werden von Trim() nicht gelöscht, nur die davor und dahinter. Mit LTrim() nur die davor und mit RTrim() nur die dahinter. Die Leerzecien im String kann man mit Trim nicht entfernen, das würde dann nur mit Replace gehen.
unterscheiden sich da VB und VBa f. Excel?
In Excel kommt da kein Fehler:
Sub tt()
MsgBox Trim("A b ") ’ ergibt „A b“
End Sub
nein, die unterscheiden sich nicht. Mit Fehler war auch keine Fehlermeldung gemeint, sondern die Frage war so gestellt, daß das Leerzeichen hinter ‚A b‘ mit zum Code gehört. Daß es entfernt wird ist in dem Fall der ‚Fehler‘.
