AnsiString speichern und laden

[himitsu]

Inzwischen gibt es ja nun die Inline-Variablen.

Delphi-Quellcode:

var F := TMyForm.Create(nil);
try

finally
  F.Free;
end;

[Willie1]

Zitat:

Zitat von himitsu (Beitrag 1484845)

Also hast du keinen AnsiString (CP_ACP) sondern einen RawByteString, oder besser noch ein TBytes.

Und vorallem mit Letzterem bereitet das TFile.WriteAllBytes keine Probleme.

Du hast rect, ich brauche kein AnsiString. Memo.Text liefert jedoch WideString, bei dem jedes zweite Byte 0 ist. (war hier schon mal Thema) Gibt es einen Cast WideString to TByte? Ich bin nicht allein mit diesem Problem:https://support.industry.siemens.com.../219715?page=0 Inline-Variablen: ich muss immer noch dazulernen!

KodeZwerge, damit muss ich mich beschäftigen.

Willie.

[Rolf Frei]

Du kannst da eifnach eine Typecast auf AnsiString machen:

Delphi-Quellcode:

var 
  MeinAnsiStr: AnsiString;
  MeineBytes: TBytes;
begin
  MeinAnsiStr := AnsiString(Memo1.Lines.Text); // Kann zu Zeichenverlust führen, wenn ein Zeichen nicht im ANSI untersützt wird!
  MeineBytes := BytesOf(MeinAnsiStr);
  ...
end;

Du musst da aber aufpassen, denn wenn dein Memo Unicodezeichen enthält, die es im ANSI nicht gibt, wirst du da an der Stelle ein "?" haben. Da musst dir gründlich überlegen, ob du das da nicht anderst machen willst, damit keine Konvertierung Unicode/ANSI stattfinden muss.

Du könntest ja auch einfach alles als Unicode nutzen und verschlüsseln.

Delphi-Quellcode:

MeineBytes := BytesOf(Memo1.Lines.Text);

In diesem Fall hast du ein ByteArray aus Unicodezeichen, also in der Regel sowas wie 40 00 45 00... Das könnte ja deine Routine auch auf Bytebene (wie bisher AnsiChar) vershlüsseln. StringOf(MeineBytes) macht dann übrigens das Gegenteil, also aus TBytes wieder ein String.

[himitsu]

Zitat:

Du musst da aber aufpassen, denn wenn dein Memo Unicodezeichen enthält

Jetzt rate mal, warum ich z.B. RawByteString genannt hatte.

Beim AnsiString (CP_ACP) ist vorallem besonders spaßig, dass bei unterschiedlichen Sprachen auch andere Zeichen codiert sind.
z.B. AnsiString-zu-String liefert ein anderes Ergebnis in Deutschland, Russland, China usw.



Ja, String/Char ist seit Delphi-2009 Unicode, genauer UnicodeString/WideChar mit 2 Byte pro Char.
Der WideString ist bissl was Anderes, hat aber die gleichen Chars drin.


TEncoding

Delphi macht es ähnlich, beim Cast mit Unicode von/zu ANSI.
Ein AnsiString und seine Nachfahren haben seit 2009 eine CodePage.

AnsiString = CP_ACP / 0
UTF8String = CP_UTF8 / 65001
RawByteString = $FFFF

Auch UnicodeString hat quasi eine CodePage 1200
https://stackoverflow.com/questions/...01-12000-12001




https://www.delphipraxis.net/206950-...ml#post1482784

[Willie1]

Da habe ich einiges zu lesen (bzw. vorlesen zu lassen) !
In europäischen Sprachen wird doch das zweite Byte nicht gebraucht, richtig?
Willie.

[himitsu]

ä ö ü ß

oder z.B. bei den Franzosen und Dergleichen auch é ê ë ì í î ï ñ ò ó ô õ ö ... , was nicht alles in die 255 rein passt.

[Rolf Frei]

Doch da gibt es auch solche Zeichen. Z.B. das Euro Zeichen hat den Wert $20AC.

Hier gibt es ein White Paper von Emba zu Unicode mit Delphi und was man da für die Migration beachten muss:
White Paper: Delphi and Unicode

Oder das hier:
Delphi Unicode Migration for Mere Mortals

Lies dir diese PDF's mal durch und dann wird schon vieles viel einfacher verständlich sein.

Es gibt übrigens bei Embarcadero einen eigenen Bereich für die Migration, wo auch auf das Thema Unicode Migration eingegangen wird. Hier findest du die Seite und weitere Links zum Thema:
https://www.embarcadero.com/rad-in-a...upgrade-center

[KodeZwerg]

Willie möchte aber nicht aus Ansicode Unicode machen, er hat lediglich den falschen Datentyp für sein Experiment genutzt.
TBytes nennt es sich heute, damals halt

Delphi-Quellcode:

array of byte

.

Ich kenne die Problematik, da auch ich mich mal fürs falsche Entschieden hatte.
Eine sofort Korrektur mit minimal Aufwand wäre halt per Base64 möglich. Encode(AnsiString) / Decode(Base64String) o.ä..
Jedenfalls hatte ich mich damals dafür Entschieden und würde es wahrscheinlich wieder machen ;-]

Ebenfalls möglich ohne viel Aufwand auf einen TStream umzusatteln.

Das ganze total Oldskool als Record laden/speichern ginge auch. Da muss halt im Record der Typ stimmen.

Also es gibt viele Möglichkeiten so das Dein En-/Kodierverfahren weiterhin genutzt werden kann, nur außen rum brauchst Du halt was anderes.

[Willie1]

Viele gute Antworten. Danke.
Aber ich schaffe es nicht, die Nibbles so zu verknüpfen, wie ich mir das vorgestellt habe. Ich erkenne nicht, ob der Fehler am Codieren oder Decodieren liegt. Ich habe die Bereichsprüfung eingeschaltet, um einen Überlauf zu erkennen. Ist aber nicht.

Willie.

[himitsu]

Es gibt verschiedene Einstellungen für TEncoding bzw. WideCharToMultiByte und standardmäßig gibt es keine Fehlermeldung, wenn es nicht passt.
https://www.delphipraxis.net/207225-...evexpress.html

Und die Bereichsprüfung kann hier nicht greifen, dass die Chars nicht einzeln im Delphi-Code von WideChar ins AnsiChar zugewiesen werden.

Bestes Beispiel: UTF8Decode und seine Freunde geben einfach still und heimlich einen Leerstring zurück, wenn man man dort "ungültiges" UTF-8 reingibt.
Und standardmäßig werden eben ungültige unpassende WideChars in ein '?' übersetzt, wenn es nicht passt. (bei den AutoCatst still und heimlich, da Rückgaben nicht geprüft werden)

Außerdem kann es sein, dass Combining-Chars zusammengefasst werden, aber zurück dann nicht wieder getrennt. Oder A mit Akzent wird in ein pures A übersetzt und zurück geht dann nicht mehr.
Aber hier kann man mit den passenden Optionen und Auswertung des Rückgabewertes entgegengewirkt werden.