[FPC 2.6.2] AnsiString für binäre Daten verwendbar?

[mjustin]

Ist in Free Pascal 2.6 der Type AnsiString zum Speichern von Binärdaten verwendbar?
In Delphi habe ich RawByteString verwendet, das aber erst in FPC 2.7.1 enthalten ist.


Ich verwende RecvBufferStr aus Synapse zum Empfangen von Binärdaten, und habe aufgrund der Dokumentation angenommen, es sei möglich binäre Daten in einen AnsiString zu speichern:

Delphi-Quellcode:

    {Similar to RecvBufferEx, but readed data is stored in binary
     string, not in memory buffer.}
    function RecvBufferStr(Len: Integer; Timeout: Integer): AnsiString; virtual;

Falls AnsiString jedoch von der (Default) Codepage abhängig ist, wird es beim Empfangen von Daten via Synapse in FPC Anwendungen zu korrupten Daten kommen. (Oder habe ich etwas übersehen?)

[cookie22]

Ja, kannst du machen. Ansi ist Ansi, was soll da lokaleabhängig sein?

[Bernhard Geyer]

Eigentlich ist AnsiString für Binärdaten vollkommen ungeeignet. Binärdaten können einen Nullwert ($00) enthalten. Bei vielen Funktionen welche man mit AnsiStrings verwenden kann die ein Betriebssystem-API aufrufen werden die Binärdaten dann am $00 abgeschnitten da dies für C-Funktioen das String-Ende ist.

Das dies im Bereich Netzwerkverkehr oft verwendet werden kann liegt daran das hier (orginale) Binärdaten oft Codiert (Base64 und Co.) werden.

[mjustin]

Zitat von cookie22:

Ja, kannst du machen. Ansi ist Ansi, was soll da lokaleabhängig sein?

Ich nehme an, dass es Probleme gibt wenn die aktuelle Codepage manche Zeichen nicht enthält. Für Delphi 2009 und höher habe ich gerade dieses Beispiel gefunden:

https://forums.embarcadero.com/threa...threadID=70842

Um es unter Free Pascal 2.6 zu testen, könnte ich einem AnsiString einfach der Reihe nach alle Zeichen von $0 bis $ff hinzufügen und dann kontrollieren ob es angekommen ist. Ich teste das mal.

[mjustin]

Nachtrag:

http://synapse.ararat.cz/doku.php/public:howto:d2009

Zitat:

Binary communication buffers are implemented as ansistrings. Data from socket goes to memory what is managed by ansistring and all next processing goes through ansistrings.

Wenn Free Pascal AnsiString wie in non-Unicode Delphi arbeiten, wäre es also nach diesen Angaben technisch kein Problem, Binärdaten in AnsiString zu speichern.

Ich habe eine Fehlermeldung eines Benutzers erhalten, aber noch keinen reproduzierbaren Testfall. Ich melde mich dann hier wieder, sobald es sich aufgeklärt hat.

[cookie22]

Zitat von mjustin:

In Delphi habe ich RawByteString verwendet, das aber erst in FPC 2.7.1 enthalten ist.

Der RawByteSting in den neueren Delphi Versionen, ist auch nur ein AnsiString.

Zitat von mjustin:

Wenn Free Pascal AnsiString wie in non-Unicode Delphi arbeiten...

Wieso sollte in non-Unicode Versionen AnsiString anders arbeiten? Wie schon gesagt, ein AnsiString ist ein AnsiString. Da ändert sich gar nichts.

[mjustin]

Zitat von cookie22:

Ja, kannst du machen. Ansi ist Ansi, was soll da lokaleabhängig sein?

Stimmt. Meinte auch die lokalen (Default) Codepage der Sender / Empfänger Systeme. (Die auch Linux als OS einsetzen könnten.)

[mjustin]

Zitat von cookie22:

Zitat von mjustin:

In Delphi habe ich RawByteString verwendet, das aber erst in FPC 2.7.1 enthalten ist.

Der RawByteSting in den neueren Delphi Versionen, ist auch nur ein AnsiString.

In Delphi 2009 ist

type RawByteString = type AnsiString(65535); In Free Pascal 2.7.1 ist

type RawByteString = type AnsiString($FFFF); Vgl. z.B. Wie funktioniert RawByteString? (ab FPC 3.x)

Der AnsiString in Delphi 2009 und neuer verwendet defaultmäßig die aktive Codepage des Rechners auf dem das Programm ausgeführt wird.

Ab Delphi 2010:

RawByteString:      AnsiString; bzw. in C++

typedef AnsiStringT<65535> RawByteString;

[Namenloser]

Was macht denn die (65535) bzw. ($FFFF)? Die Notation kenne ich noch gar nicht... Ich kenne nur, dass man bei ShortStrings mit eckigen Klammern die maximale Länge (bis zu 255) angeben kann, aber das muss ja was anderes sein...

Übrigens, ich finde es schade, dass man nicht einfach die Bedeutung von "string" etwas aufgebohrt hat, statt 100 spezialisierte Typen einzuführen. Dann könnte es z.B. geben:

Delphi-Quellcode:

var 
  a: string of AnsiChar;
  b: string of WideChar;
  c: string of Byte;

Also genau so deklariert wie ein Array, bloß mit den zusätzlichen Vorteilen eines Strings. Natürlich wäre jeder andere Typ als Arrayinhalt genau so denkbar.

Die Idee ist nicht von mir, ich habe den Vorschlag mal in einem Blog gelesen, aber ich hätte das eine sehr schöne Lösung gefunden.

[himitsu]

Das gibt die CodePage an, welche für den String verwendet wird.

Delphi-Quellcode:

type 
  UTF8String = type AnsiString(CP_UTF8);

In den neuen LongStrings wird (zumindestens in Delphi) neben der String-Länge auch noch die CodePage und die CharSize gespeichert, damit Delphi dementsprechend die Typumwandlung automatisch machen kann, also die CodePage anpassen, wenn man den String von einer Variable in eine Andere kopiert/übergibt/castet.

Nur beim RawByteString wird keine Konvertierung des Textinhaltes vorgenommen.


Das TYPE gibt dabei an, daß ein eigener Typ in der RTTI generiert wird.

Delphi-Quellcode:

type 
  X = Byte;
  Y = type BYTE;

X ist nur ein Alias für Byte, während TypInfo(X) das Byte als Typ liefert.
Y ist aber ein eigener Typ, welcher so groß wie ein Byte ist. Er ist auch kompatibel mit dem normalen Byte. Aber z.B. bei der Typprüfung für Parameter wird der Typ entsprechend ausgewertet.



Ein AnsiString/UnicodeString entspricht nur Teilweise einem array of AnsiChar/WideChar .
Dort ist noch hinten eine implizite doppelte #0 angehängt und dann eben noch die zusätzlichen erwähnten Infos (CharSize und CodePage, welche vor der Length untergebracht wurden)
Außerdem ist bei den LongStrings das CopyOnWrite aktiv, was man bei den normalen Arrays oftmals leider vergessen hat zu aktivieren.