[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:

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;

[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.)