StrLen / SizeOf mag Chr(0) nicht?

[xSkaschY]

Morgen,

versuche gerade die Länge eines Strings, welcher auch ein paar "Chr(0);" enthält ,zu ermitteln.

Egal welche kt. ich benutze StrLen / SizeOf beides gibt in meinem Fall nur 8* an

Delphi-Quellcode:

sOutput := 'armapath' + Chr(0) + sValue + Chr(0) + 'port' + Chr(0) + IntToStr(iPort) + Chr(0) + Chr(0);

// Dies ist nur ein Beispielstring der Aufbau des Orginals ist jedoch der gleiche (keyword-chr(0)-value-chr(0)-usw.-Chr(0)-Chr(0) (double chr(0) = EOL))

Also "er zählt" nur das erste Wort vor dem Chr(0).

Gibt es eine möglichkeit diese mit zu zählen?


LG Toby

//

Eine möglichkeit wäre, alle vorhandenen Wörter zu zählen und einfach die Chr(0) mit +1 zu addieren, halte dies aber für "unsauber" und nicht redunant, anything else?

//

Chr(0); ist nur ein Trenner, da ich diese Daten durch nen Socket schiebe und ich die auf der Gegenstelle weiter verarbeite habe ich mir diesen Trenner so angewöhnt.

[mkinzler]

Ist aber auch gleichzeitig ein Kenner für Stringende

[xSkaschY]

Naja, dessen bin ich mir bewusst.

Beantwortet aber trotzdem nicht meine Antwort, trotzdem Danke.

LG Toby

[mkinzler]

Nimm doch einfach einen anderen Trenner

[xSkaschY]

Welcher wäre "frei"?

//

: ; . - usw. gehen nicht, da alle Sonderzeichen möglich wären. Deshalb ja 0x00 weil man des nunmal nicht "eingeben" kann :)

[mkinzler]

Ein Zeichen, welches nicht in deinen Daten enthalten ist.

[xaromz]

Hallo,

warum eigentlich nicht Length()? Das greift auf die Größe des Speicherbereichs zu und lässt sich von Nullzeichen nicht aufhalten.

Gruß
xaromz

[Hawkeye219]

Hallo,

mit dem 0-Zeichen ist das so eine Sache. Eigentlich sollten Pascal-Strings alle Zeichen enthalten können, da sie ja eine Längeninformationen mit sich führen. Deshalb sollte auch die von xaromz angesprochene Funktion Length() in diesem Fall das richtige Ergebnis liefern. Allerdings würde ich mich nicht darauf verlassen, dass alle RTL-/VCL-Routinen die 0 richtig interpretieren:

Delphi-Quellcode:

var
  s : string;
  n : Integer;
  v : Double;
begin  
  s := '123,456'#0'Hallo Welt';

  n := Length(s);      // liefert den Wert 18
  v := StrToFloat(s);  // sollte einen Fehler auslösen, tut das aber nicht...
end;

Um allen Schwierigkeiten bei möglichen Konvertierungen aus dem Weg zu gehen, würde ich also auch zu einem anderen Trenner raten. In der Wikipedia findet man mögliche Kandidaten, zum Beispiel die Zeichen 28-31.

Gruß Hawkeye

[rollstuhlfahrer]

Warum nimmst du nicht als Trenner #1 oder #7 (Beep)?? Einen Beep hab ich bis jetzt noch nicht geschafft irgendwo einzugeben, gleiches ist mir auch mit Chr(1) wiederfahren. Dabei fällt das Problem mit der 0 weg, die als Ende fungiert. Eigentlich ist das etwas komisch, dass das nicht auf anhieb funkioniert. Nach einem ähnlichen Prinzip versteht sich auch der Open- und SaveDialog von Windows, wenn man ihn nonVCL aufruft. Dort signalisiert ein einfaches #0 ein Ende und ein doppeltes #0 ein Zeilenende.

Bernhard

[jbg]

Zitat:

Zitat von rollstuhlfahrer

Eigentlich ist das etwas komisch, dass das nicht auf anhieb funkioniert.

Wenn er StrLen benutzt ist es kein Wunder, dass beim ersten #0 der String endet. Denn StrLen sucht ja gerade nach dem ersten #0. Und SizeOf ist die völlig falsche Funktion. Sie liefert nicht die Länge des Strings zurück.

[rotfc]

Als "Stringtrenner" benutze ich notfalls das auf dem Kopf stehende spanische Fragezeichen, da es noch nicht mal Spanier "aus Versehen" eintippen können :mrgreen:

[himitsu]

Die null ist nunmal der Trenner von den netten WindowsArrays (kennt man z.B. vom OpenDialog (WinAPI), nur das da intern in TOpenialog ein "|" verwendet wird, da die viele Stringoperationen mit der #0 nicht klarkommen)

Delphi-Quellcode:

// Result = string/array-length exclusive terminating #0#0

Function StrLen0Array(P: PChar): Integer;
  Var i: Integer;

  Begin
    Result := 0;
    If P = nil Then Exit;
    Repeat
      i := StrLen(P);
      Inc(Result, i + 1);
      Inc(P, i + 1);
    Until i = 0;
    Dec(Result, 2);
  End;

ach ja, es darf nur ein Array übergeben werden, welches mit #0#0 endet ... sonst kommt es schnell mal zu 'ner Exception (Zugriffsverletzung)

[grenzgaenger]

Zitat:

Zitat von xaromz

Hallo,

warum eigentlich nicht Length()? Das greift auf die Größe des Speicherbereichs zu und lässt sich von Nullzeichen nicht aufhalten.

Gruß
xaromz

kommt auf die stringdefinition an. je nach string art, wird die länge eben anders ermittelt, mal wird einzeln abgezählt bis #0, mal wird über das längenbyte/längenpointer referenziert. das mit #0 ist einfach eine däm* idee.

wenn du das dennoch brauchst, kannst dir ja deine eigene struktur zusammenpasteln ...

[himitsu]

Delphi-Quellcode:

i := StrLen0Array(PChar(sOutput));  // Funktion siehe oben

Zitat:

Zitat von Hawkeye219

v := StrToFloat(s); // sollte einen Fehler auslösen, tut das aber nicht...

nja, diese Funktion nimmt halt die #0 als Kennung für das Stringende,
wonach der Wert natürlich korrekt wäre :zwinker:

Zitat:

Eine möglichkeit wäre, alle vorhandenen Wörter zu zählen und einfach die Chr(0) mit +1 zu addieren, halte dies aber für "unsauber" und nicht redunant, anything else?

eine andere Möglichkeit gibt es aber nicht und für so unsauber halte ich es ebenfalls nicht


Windows nutzt ja selber an vielen Stellen eine derartige Strucktur
z.B. im Open-/Savedialog und in der Registry (REG_MULTI_SZ)

Zitat:

Chr(0); ist nur ein Trenner, da ich diese Daten durch nen Socket schiebe und ich die auf der Gegenstelle weiter verarbeite habe ich mir diesen Trenner so angewöhnt.

nja, wenn das so ist, dann könntest du dich natürlich auch an ein anderes Zichen gewöhnen :gruebel:

es bieten sch für Texte ja einige Zeichen an ...
meistens alles in den Bereichen #1-#7, #11, #12 und #14-#31

[Namenloser]

Muss es denn ein String sein? Du könntest auch mit einem Memorystream arbeiten, da wäre das #0 kein Problem, und du statt ein Trennzeichens zu verwenden auch einfach eine Längenangabe vor jeden Wert schreiben, sodass du dann auch kein Problem hättest, wenn in deinen Daten mal ein #0 vorkommt (was ja bei Binärdaten z.B. nicht ungewöhnlich ist).