Text-Verarbeitung in Rust ist gleichzeitig strenger und ehrlicher als in den meisten anderen Sprachen. Strenger, weil die Sprache zwei String-Typen unterscheidet — &str und String — und weil Index-Zugriffe auf Zeichen-Ebene unmöglich sind. Ehrlicher, weil sie UTF-8 als Default und Pflicht durchzieht: kein versteckter Code-Page-Wechsel, keine 16-Bit-Surrogate-Tricks. Dieses Kapitel führt durch die zentrale Unterscheidung str/String, zeigt, wie sicheres Slicing in einem UTF-8-Buffer funktioniert, behandelt das format!-Makro in voller Breite, klärt das Parsing aus Strings und schließt mit Cow<str> — dem eleganten Copy-on-Write-Werkzeug für Funktionen, die manchmal allokieren müssen, oft aber nicht.

01 · Abschnitt

Was dich in diesem Kapitel erwartet

  • str vs. String — der vielleicht häufigste Stolperstein für Einsteiger. &str ist ein geborgter View auf UTF-8-Bytes; String ist ein heap-allozierter, wachsender Container. Wann brauchst du was?
  • String-Slicing und Bytes — UTF-8 hat variable Byte-Längen pro Zeichen. Slicing wie &s[0..5] funktioniert, aber nur an Zeichen-Grenzen. Was passiert, wenn man eine falsche Grenze trifft, und wie man sicher slict.
  • UTF-8 und char-Iteration — die drei Wege, einen String durchzulaufen: byteweise, charweise, graphemeweise. Welcher wann sinnvoll ist und warum „Anzahl der Zeichen" mehrdeutig sein kann.
  • Das format!-Makro — Format-Strings mit Width, Precision, Padding, Hex/Bin/Oct, named arguments und debug- vs. display-Format. Compile-Time-Validierung statt printf-Fallen.
  • Parsing und Konvertierung — Strings zu Zahlen, eigenen Typen, Datenstrukturen: parse(), der FromStr-Trait und die Stelle, an der Display und Debug ins Spiel kommen.
  • Cow<str> — der Smart-Pointer, der mal eine Referenz, mal ein owned String ist. Ideal für Funktionen wie „normalisiere diesen Text — wenn er schon sauber ist, gib ihn unverändert zurück".

Warum Rust Text anders macht

Drei Eigenheiten, die Strings in Rust prägen:

  • UTF-8 als Pflicht. Ein String ist garantiert UTF-8. Es gibt keinen Code-Path, der invalide Bytes hineinschmuggelt — die einzige Möglichkeit dazu führt durch unsafe. Praktisch heißt das: jede &str-Funktion arbeitet auf garantiert wohlgeformtem UTF-8.
  • Keine Index-Indirektion. s[i] ist ein Compile-Fehler. Hintergrund: UTF-8 hat variable Byte-Längen pro Zeichen, also könnte s[2] mitten in einem Multi-Byte-Code-Point landen. Wer das n-te Zeichen will, schreibt s.chars().nth(n) (O(n) und ehrlich).
  • Borrows trennen Lese- und Schreibwege. &str ist immutable und sehr leicht. String ist heap-alloziert und mutable. Diese Trennung ermöglicht, dass viele Funktionen nur &str als Parameter brauchen — was sowohl statisch eingebettete als auch dynamisch konstruierte Strings akzeptiert.
02 · Abschnitt

Was du nach diesem Kapitel kannst

  • Bewusst zwischen &str und String wählen — und in API-Designs den richtigen Parameter-Typ.
  • Sicher in einen UTF-8-Buffer slicen, ohne Panic.
  • Einen String byteweise, charweise oder graphemeweise iterieren.
  • format! für formatierte Ausgaben, Logging, Templates nutzen.
  • Strings in eigene Typen parsen und mit Display eigene String-Repräsentationen liefern.
  • Cow<str> einsetzen, um in API-Funktionen die Allokation auf den minimal nötigen Pfad zu beschränken.

Das nächste Kapitel behandelt Kontrollfluss: if, match, loop, while, for — alles, was nicht-lineare Ausführung erlaubt.

Weiterführende Ressourcen

Externe Quellen

/ Weiter

Zurück zu Strings & Text

Zur Übersicht