Mehrfach Null-terminierten String auslesen

  • Ich bin auf das Problem gestoßen, einen String, der mehrere Null-Terminierungen enthält, zu Lesen.

    Die Funktion "GetPrivateProfileString" liefert solch einen String, deshalb habe ich hiermit ein Bsp. erstellt.

    Der folgende Aufruf liefert die Sektionsnamen einer INI-Datei in der Form:

    Sektion_1 Chr(0) Sektion_2 Chr(0) ... Sektion_n Chr(0) Chr(0)

    In der dritten Variante gehe ich den Umweg über ein Byte-Array. Da kann ich die Null-Bytes sauber auslesen, ohne das danach abgebrochen wird.

    Aber ist das tatsächlich der einzige Weg - oder sehe ich gerade den Wald vor lauter Bäumen nicht? :/

  • Bei dem schönen Stringkomprimierungswettbewerb letztes Jahr musste ich mich auch damit beschäftigen und hab mir 2 Funktionen hierzu geschrieben:

    Ich hab die Trennung über StringSplit()gelöst und ja das geht!

    Du hast sicherlich auch kurz daran gedacht aber gar nicht erst probiert da es abwegig klang - stimmts?...

    StringReplace() würde aber auch gehen, wenn du kein Array zurückhaben willst.

    Nun der Vorteil meiner Methode im Vergleich zu deiner bisherigen (abgesehen von der Performance) ist, dass meine Variante auch mit UTF-16 kodierten Strings klar käme, wo ja auch NULL-Bytes innerhalb regulärer Zeichen vorkommen können.

    Einmal editiert, zuletzt von AspirinJunkie (12. Januar 2023 um 06:36)

  • BugFix 12. Januar 2023 um 18:25

    Hat das Label von [ offen ] auf [ gelöst ] geändert.
  • Du hast sicherlich auch kurz daran gedacht aber gar nicht erst probiert da es abwegig klang - stimmts?...

    Du kannst Gedanken lesen.... :rofl:

    War wirklich mein erster Gedanke. Dann habe ich aber die Stringlänge im Puffer mit StringLen() geprüft und festgestellt, dass dort bei der ersten Null-Terminierung Schluss ist. Also habe ich verallgemeinert, dass alle nativen Stringfunktionen so vorgehen - erscheint ja irgendwie logisch. :whistling:

    Nun der Vorteil meiner Methode im Vergleich zu deiner bisherigen (abgesehen von der Performance) ist, dass meine Variante auch mit UTF-16 kodierten Strings klar käme,

    Das ist super, feine Lösung. Danke. :thumbup: