TStringList verhält sich in D11 anders mit enthaltenen #0

[himitsu]

Grundsätzlicher Bug?

Warum wird SL.LineBreak beim Einlesen überhaupt "so" verwendet?

Wenn LineBreak irgendwass mit #13 und/oder #10 ist, dann gehören ALLE Arten von Linebreaks richtig behandelt, also egal ob #10, #13#10 oder #13.
Nur wenn LineBreak irgendwas ANDERES ist, dann explizit das zum Tennen suchen.

Ja, man könnte auch auch "Q" oder "," als LineBreak verwenden, aber eigentlich gehört sowas gefälligst ins DelimitedText.




Ob man nun auch #0 als Linebreak interpretiert oder zum kompletten Leseabbruch benutzt, daüber lässt sich streiten.
IMHO hat per se #0 in einem Delphi-Strings keine Bedeutung und sollte somit auch als normaler "Char" behandelt werden.

[Uwe Raabe]

Zitat von himitsu:

IMHO hat per se #0 in einem Delphi-Strings keine Bedeutung und sollte somit auch als normaler "Char" behandelt werden.

Genau das passiert ja nun auch in der TString.SetTextStr . Im Gegensatz zu vorher, wo die #0-Zeichen einfach entfernt wurden. Das alte Verhalten war also streng genommen nicht Delphi-konform, die Änderung also nachvollziehbar.

[himitsu]

Achso ... andersrum verstanden.

Joar, aber ging vorher oft auch nicht anders, da an zuvielen Stellen intern mit PChar gearbeitet wird, was bei #0 aufhört.

(wobei das PChar per se kein Problem ist, aber falsche PChar-Funktionen zu verwenden schon, wo es andere PChar-Funktionen gäbe, welche dennoch mit einem Length-Parameter arbeiten)






Gaaaaanz früher gab es auch mal ein Datei-Ende-Zeichen (85 oder so ... weiß nicht mehr ob Hex oder Dez),
bei welchem TP/Delphi auch gern aufhörte die StringList einzulesen.

[Rolf Frei]

Ich habe halt gestern den ganzen Arbeitstag gebraucht herauszufinden was da auf eineam in D11 falsch läuft und ein HTML-Template nun auf einmal nicht mehr richtig verarbeitet wird. Irgendwann habe ich per Zufall entdeckt, dass da an der Stelle wo es aufhört eine #0 drin ist.

Ich bin ja auch eher der Meinung, dass es bisher falsch war und #0 eigentlich nicht entfernt werden sollten. Von daher kann ich mit der Änderung leben. Was mir halt nicht so recht gefällt ist, das ich nun einen Check für #0 machen muss und das eigentlich unnötig Zeit kostet, für einen äusserst seltenen Spezialfall. Der eingentliche Fehler liegt ja hier nicht in Delphi sondern im HTML-Template. Vermutlich lasse ich das auch weg und das Tempalte muss dann halt korrigiert werden.

[Uwe Raabe]

Zitat von Rolf Frei:

Der eingentliche Fehler liegt ja hier nicht in Delphi sondern im HTML-Template. Vermutlich lasse ich das auch weg und das Tempalte muss dann halt korrigiert werden.

Es ist in der Regel auch besser die Ursache eines Problems zu beseitigen als nur seine Symptome.

[Dennis07]

Was ich mich auch frage ist, wieso man auf die Idee kommt, in den Code einer HTML-Seite Null-Chars einzubauen. Ich wüsste nicht mal jetzt auf Anhieb, ob alle Browser das überhaupt vernünftig darstellen würden/könnten und was dafür die W3-konforme Darstellung wäre. Gerade bei einem Browser, der nun einmal nicht in Pascal, C# oder Java geschrieben wurde.

[Rolf Frei]

Das macht ja auch keiner mit Absicht, dennoch hat sich hier in einem HTML Template ein NUL Char eingenistet. Woher und wieso wissen wir leider nicht, nur soviel, dass der Code von irgendwoher vom Kunden per Copy/Paste eingefügt wurde. Das Zeichen hat den Browser bisher garnie erreicht, weil das schon vorher durch die Stringlist eliminiert wurde. Neu würde es ankommen, aber auch hier gibt es noch weiterren Code im Webbroker Framework, das dann eben abbricht und den Rest danach nicht mehr liefert. Die Möglichkeit ein NUL mit dem Webbroker FW an den Browser zu senden, war/ist also garnicht möglich.