Einzelnen Beitrag anzeigen

Benutzerbild von himitsu
himitsu

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
43.149 Beiträge
 
Delphi 12 Athens
 
#42

AW: Externes Programm Teil 2

  Alt 2. Feb 2018, 19:37
Zip, 7Zip und RAR erlauben es, die Daten auch mit Passwort zu verschlüsseln.

Seit einer Weile ist für ZIP direkt im Delphi eine Klasse enthalten, aber ich weiß nicht ob dort die Funktionalität für das Verschlüsseln mit eingebaut wurde.
7Zip hat gegenüber RAR aber den Vorteil, dass es quelloffen und kostenfrei ist. RAR dagegen ist ein propitäres Format und so weit ich weiß, ist dort nur das "entpacken" mit freien DLLs/Programmversionen legal möglich.

Zum Komprimieren und Verschlüsseln gibt es für Delphi auch Komponenten. ZLib ist seit Jahren in Delphi enthalten. (die hauptsächlich bei ZIP und GZIP verwendete Komprimierungsmethode)
Und Verschlüsselungsfunktionen gibt es mehrere Bibliotheken, also grundsätzlich kannst du dir selber sowas bauen, was ohne externe DLLs auskommt.


Aber das Hauptproblem mußt du dennoch erstmal lösen, also in welchem Format kommen deine Daten in den Stream.
z.B. einfach immer ANSI, Unicode oder z.B. UTF-8. Aber kein String/PChar, welches sich verändert, außer du speicherst in dem Stream auch wie er wieder ausgelesen werden muß und dann eine/mehrere Auslesefunktionen (bei Einer dann mit Fehlermeldung, wenn die Daten "unverständlich" sind)

Delphi-Referenz durchsuchenTReader und Delphi-Referenz durchsuchenTWriter sind auch ganz praktisch, denn deren String-Sunktionen speichern mit ab, wie sie die Strings gespeichert haben. Genauer speichern die das komplette Datenformat zu jedem einzelnen Teil.
PS: Darum können die vielen Property der DFMs im Delphi so schön deserialisiert werden, weil man beim Auslesen schauen kann, was für ein Format die nachfolgenden Daten haben. (original ist die DFM ein Binärformat ... das Textformat ist davon nur die menschenlesbare Version)


Zitat:
oder wird es nach dem nächsten Windows Update wieder crashen
Delphiprogramme haben per se recht wenige externe Abhängigkeiten, nicht so wie .NET oder JAVA.
Hier liegt das Problem in unterschiedlichen Compilern.
Ein "String" wird z.B. im Delphi 7 als AnsiString und in aktuellen Delphis als UnicodeString behandelt. "String" ist ein Alias, der je nach Compiler/Zielsystem auf unterschiedliche Typen zeigt.
Also mit einem Delphi 7-Programm speichert mit dem Code aus Kommentar #32 den Text als ANSI, aber versuchst du später das mit einem Delphi XE-Programm auszulesen, dann will das Unicode haben und liest somit nur Kauderwelsch aus, der ein bisschen an Chinesisch erinnern wird. (es gibt im Unicode sehr viele asiatische Zeichen, drum werden sie sehr wahrscheinlich getroffen)
Garbage Collector ... Delphianer erzeugen keinen Müll, also brauchen sie auch keinen Müllsucher.
my Delphi wish list : BugReports/FeatureRequests

Geändert von himitsu ( 2. Feb 2018 um 19:45 Uhr)
  Mit Zitat antworten Zitat