Hi,
Zitat von
Zacherl:
Sau gut dass du das
DEC weiterentwickelst
Danke
Zitat von
Zacherl:
Ich denke mal in dieser Version kann man das vergessen aber für auf lange Zeit gesehen wären eigene Implementierungen von SSL, SRP, etc. ziemlich interessant.
Ja, das würde für dieses Release den Rahmen sprengen. Ich habe jetzt schon dutzende Stunden dafür investiert. Aber sobald die neuen Grundlagen stehen, kann ich für zukünftige Releases ein Augenmerk auf neue Verfahren setzen.
Zitat von
Zacherl:
Zum
Unicode Problem:
Da würde ich zweigleisig mit DecodeWideString und DecodeAnsiString bzw. mit DecodeStringW und DecodeStringA, ganz nach
API Vorbild arbeiten. Ist wohl am wenigsten verwirrend. Zusätzlich kann man eine Funktion DecodeString implementieren die je nach Delphi Version (prüfen mit {$IFDEF
UNICODE}) die W oder A Variante aufruft.
Jein, es wird aber so ähnlich sein. Hintergrund ist, ich möchte die Referenzzählung für UnicodeStrings nicht verlieren. Würde ich hier auf WideString setzen wäre das der Fall, da die Compiler Magic dann hier zuschlägt. Ich könnte natürlich den UnicodeString als Typ für ältere Delphis einführen, aber dadurch gewinne ich nicht viel...
Ich habe nun EncodeString() und DecodeString() überladen für
Unicode/
Ansi/Wide-String und zusätzlich Encode/DecodeAnsiString und -WideString eingeführt. Das erlaubt auch das explizite aufrufen einer gewünschten Funktion, ohne vorher einen Typcast machen zu müssen - das übernimmt dann die Compiler Magic für uns.
Die Idee mit UTF8 war toll, danke nochmal an Sebastian
In jetzigen Tests läuft alles problemlos mit TFormat_Copy / TFormat_HEX - in allen 3 Stringvarianten unter D2010 bzw. 2 Varianten unter D7. Jetzt bin ich gerade an der Re-Implementierung von Base64, PGP, XX, UU und Escaped Encoding. Da hier jetzt nicht mehr auf PAnsiChar sondern PByte gearbeitet wird, ist es halt etwas Arbeit...
@Hagen: Falls Du mitliest, was ist denn Dein MIME32 für ein Format? Die Ergebnisse aus der
DEC 5.1 (und 5.2) stimmen z.B. mit Base32 überhaupt nicht überein. Du hattest es kommentiert mit "MIME ähnliches Base32". Also ein eigener Formatansatz. Ich würde lieber Base32 wie in RFC4648 umsetzen. Hatte es seinerzeit einen besonderen Grund ein eigenes MIME-ähnliches Format für Base32 einzuführen?
Gruß,
Assertor
