strings.ToValidUTF8 — ungültige UTF-8-Sequenzen ersetzen

Die Funktion lebt im Paket strings und hat eine sehr überschaubare Schnittstelle. Sie nimmt zwei Strings entgegen — den zu prüfenden Input und das Replacement, das anstelle jeder ungültigen UTF-8-Sequenz eingesetzt wird — und gibt einen neuen String zurück. Es wird kein Fehler zurückgegeben: ungültiges UTF-8 ist hier keine Ausnahmesituation, sondern erwartetes Eingabematerial.

Wichtig zu verstehen: die Funktion arbeitet auf Byte-Ebene und entscheidet anhand der UTF-8-Grammatik, ob eine Byte-Folge gültig ist. Gültige Sequenzen werden unverändert übernommen, ungültige Sequenzen werden durch das Replacement ersetzt — egal ob das Replacement ein leerer String, ein einzelnes Zeichen oder ein längerer Marker ist.

package main

import (
	"fmt"
	"strings"
)

func main() {
	// Signatur:
	// func ToValidUTF8(s, replacement string) string
	clean := strings.ToValidUTF8("Hallo Welt", "�")
	fmt.Println(clean)
}

Hallo Welt

Bei rein gültigem Input ist die Funktion semantisch ein No-Op: der Output ist Byte-für-Byte identisch mit dem Input. Eine Allokation kann in dieser Konstellation trotzdem entstehen — dazu später mehr.

In vielen Sprachen ist ein String per Definition eine Sequenz von gültigen Codepoints (z. B. str in Python 3 oder String in Java/Swift). In Go ist das anders: ein string ist eine unveränderliche Folge von Bytes. Das Sprachspec dokumentiert das explizit. UTF-8 ist Konvention, nicht Garantie.

Diese Designentscheidung ist pragmatisch — sie erlaubt Go, beliebige binäre Daten als String zu transportieren, ohne die Performance einer Validierung beim Erzeugen zu bezahlen. Sie hat aber Konsequenzen: sobald Strings aus unkontrollierten Quellen kommen (HTTP-Bodys, Datei-Reads, Datenbank-Spalten mit kaputtem Encoding, Inter-Prozess-Pipes), kann das, was wie Text aussieht, in Wahrheit ungültige Sequenzen enthalten.

package main

import (
	"fmt"
	"strings"
	"unicode/utf8"
)

func main() {
	// 0xFF ist in UTF-8 niemals ein gültiges Startbyte.
	kaputt := "Hallo\xffWelt"

	fmt.Println("Länge in Bytes:", len(kaputt))
	fmt.Println("Ist gültiges UTF-8?", utf8.ValidString(kaputt))

	fixed := strings.ToValidUTF8(kaputt, "�")
	fmt.Println("Bereinigt:", fixed)
	fmt.Println("Jetzt gültig?", utf8.ValidString(fixed))
}

Länge in Bytes: 11
Ist gültiges UTF-8? false
Bereinigt: Hallo�Welt
Jetzt gültig? true

Der String enthält 11 Bytes, davon ein einzelnes 0xFF — ein Byte, das UTF-8 als Startbyte nicht erlaubt. Erst nach ToValidUTF8 ist die Folge garantiert wohlgeformt.

Das zweite Argument ist beliebig. Übergibt man "", wirken sich die ungültigen Sequenzen wie ein stiller Filter aus — sie verschwinden ersatzlos. Der typische Wert ist "�", das Unicode-Replacement-Character U+FFFD (�), das genau für diesen Zweck reserviert wurde. Genauso möglich: ein längerer Marker wie "[?]", etwa für Debug-Ausgaben, in denen man die Position von Encoding-Fehlern sichtbar machen möchte.

Beachten muss man nur, dass das Replacement selbst nicht erneut geprüft wird. Wenn dort ungültiges UTF-8 hineingegeben wird — etwa ein nackter Hochstand-Byte — landet dieser ungeprüft im Output. In der Praxis kommt das selten vor, aber als Detail lohnt es sich zu wissen.

package main

import (
	"fmt"
	"strings"
)

func main() {
	in := "A\xffB\xfeC"

	fmt.Printf("löschen:    %q\n", strings.ToValidUTF8(in, ""))
	fmt.Printf("U+FFFD:     %q\n", strings.ToValidUTF8(in, "�"))
	fmt.Printf("Marker:     %q\n", strings.ToValidUTF8(in, "[?]"))
	fmt.Printf("hex-Dump:   %q\n", strings.ToValidUTF8(in, "<BAD>"))
}

löschen:    "ABC"
U+FFFD:     "A�B�C"
Marker:     "A[?]B[?]C"
hex-Dump:   "A<BAD>B<BAD>C"

Welche Variante richtig ist, hängt vom Konsumenten ab: für reine Textanzeige in einer UI ist U+FFFD die richtige Wahl (W3C-Empfehlung). Für rein technische Pipelines, in denen die Bytes selbst gar nicht angezeigt werden, ist "" oft sauberer, weil dadurch keine zusätzlichen Bytes in nachgelagerte Längen- oder Hash-Berechnungen einfließen.

Die zentrale Frage: wenn ToValidUTF8 auf eine ungültige Sequenz trifft — wie viele Bytes umfasst die einzelne „Sequenz", die durch ein Replacement ersetzt wird? Die Antwort liefert die sogenannte „Maximal Subpart"-Regel aus dem Unicode Standard (Abschnitt 3.9, „U+FFFD Substitution"), die auch vom W3C für HTML referenziert wird.

Vereinfacht: es wird so weit gelesen, wie die Bytes noch zu einer potenziell gültigen UTF-8-Sequenz passen könnten. Sobald das nächste Byte definitiv unmöglich ist, endet die ungültige Subsequenz dort, ein Replacement wird emittiert, und es geht beim folgenden Byte weiter. Konsequenz: ein einzelnes verirrtes Startbyte erzeugt ein Replacement, eine längere kaputte Folge ebenfalls — solange sie als „Fortsetzung dessen, was hätte sein können" interpretierbar ist.

package main

import (
	"fmt"
	"strings"
)

func main() {
	// 0xE2 ist Startbyte einer 3-Byte-Sequenz, 0x82 ist gültiges
	// Continuation-Byte — aber dann fehlt das dritte Byte und stattdessen
	// kommt 'A' (kein Continuation).
	abgeschnitten := "\xe2\x82A"

	// Zwei isolierte invalide Startbytes hintereinander.
	zwei := "\xff\xff"

	fmt.Printf("abgeschnitten: %q -> %q\n",
		abgeschnitten, strings.ToValidUTF8(abgeschnitten, "<R>"))
	fmt.Printf("zwei:          %q -> %q\n",
		zwei, strings.ToValidUTF8(zwei, "<R>"))
}

abgeschnitten: "\xe2\x82A" -> "<R>A"
zwei:          "\xff\xff" -> "<R><R>"

Im ersten Fall werden \xe2\x82 als eine ungültige Sequenz erkannt (die zwei Bytes hätten gemeinsam Teil eines gültigen Codepoints werden können, das A brach den Versuch ab). Im zweiten Fall sind beide \xff-Bytes je für sich unmöglich — also zwei separate Replacements. Dieses Verhalten ist nicht nur „eine sinnvolle Wahl", sondern die normative Vorgehensweise, auf die sich Webstandards und moderne Plattformen geeinigt haben.

Wenn man nur wissen möchte, ob ein String gültiges UTF-8 ist, ist ToValidUTF8 das falsche Werkzeug. Dafür gibt es utf8.Valid([]byte) und utf8.ValidString(string) aus dem Paket unicode/utf8 — beide geben einen bool zurück und allozieren nichts. ToValidUTF8 hingegen produziert einen sauberen String und ist damit der korrekte Schritt, wenn man weiterverarbeiten will.

Häufiges Anti-Pattern: erst utf8.ValidString prüfen, im Fehlerfall den Input ablehnen. Das ist in vielen Defense-in-Depth-Szenarien zu hart — die typische Lösung ist nicht „Eingabe verwerfen", sondern „Eingabe normalisieren". Genau dafür ist ToValidUTF8 gemacht.

package main

import (
	"fmt"
	"strings"
	"unicode/utf8"
)

func main() {
	in := "Daten\xff\xfeRest"

	if utf8.ValidString(in) {
		fmt.Println("gültig — direkt nutzen")
	} else {
		fmt.Println("ungültig — bereinigen")
		clean := strings.ToValidUTF8(in, "�")
		fmt.Printf("bereinigt: %q (gültig=%v)\n",
			clean, utf8.ValidString(clean))
	}
}

ungültig — bereinigen
bereinigt: "Daten��Rest" (gültig=true)

Faustregel: utf8.Valid* ist für Entscheidungen (annehmen, ablehnen, loggen), ToValidUTF8 ist für Transformation (sauberer Output für nachgelagerte Stufen).

Strings in Go sind unveränderlich, das Resultat von ToValidUTF8 ist also immer ein neuer Wert — die Frage ist nur, ob im Inneren tatsächlich ein neues Byte-Slice alloziert wird. Bei rein gültigem Input ist ToValidUTF8 so implementiert, dass die Funktion früh erkennt, dass nichts zu tun ist, und den Input zurückgibt, ohne einen neuen Buffer aufzubauen (das Sprachmodell garantiert das nicht hart, aber die aktuelle Implementierung verhält sich so).

Sobald die erste ungültige Sequenz gefunden wird, wird ein []byte-Buffer angelegt und der Rest dort hineingeschrieben. Für Hot-Path-Code mit hauptsächlich gültigem Input ist das günstig. Für gemischte Workloads sollte man die Allokationen messen — etwa mit testing.B und b.ReportAllocs() — bevor man optimiert.

package strv_test

import (
	"strings"
	"testing"
)

var sink string

func BenchmarkValid(b *testing.B) {
	in := strings.Repeat("Hallo Welt — ", 100)
	b.ReportAllocs()
	for i := 0; i < b.N; i++ {
		sink = strings.ToValidUTF8(in, "�")
	}
}

func BenchmarkInvalid(b *testing.B) {
	in := strings.Repeat("Hallo\xffWelt — ", 100)
	b.ReportAllocs()
	for i := 0; i < b.N; i++ {
		sink = strings.ToValidUTF8(in, "�")
	}
}

Typische Ergebnisse: null Allokationen für sauberen Input, eine einzelne Allokation für den bereinigten Buffer im Fehlerfall. Die genauen Zahlen variieren je nach Go-Version und CPU; das Muster bleibt aber stabil.

Ein typisches Szenario: ein Drittanbieter liefert per HTTP JSON-Strings, deren Encoding-Disziplin nicht zu unserer Kontrolle gehört. PostgreSQL mit UTF8-Encoding (Default) lehnt Inserts mit ungültigen Byte-Sequenzen mit invalid byte sequence for encoding "UTF8" ab — der gesamte INSERT scheitert. Statt im Hot-Path mit Errors zu jonglieren, säubert man den Wert auf dem Weg in die Datenbank.

Das ist klassische Defense in Depth: wir trauen weder dem Upstream noch dem JSON-Decoder zu, garantierten Output zu liefern. Stattdessen normalisieren wir explizit — und loggen optional, wann eine Bereinigung nötig war, um Drift bei der Upstream-Qualität zu erkennen.

package main

import (
	"fmt"
	"strings"
	"unicode/utf8"
)

type Comment struct {
	Author string
	Body   string
}

func sanitizeForDB(c Comment) (Comment, bool) {
	dirty := !utf8.ValidString(c.Author) || !utf8.ValidString(c.Body)
	c.Author = strings.ToValidUTF8(c.Author, "�")
	c.Body = strings.ToValidUTF8(c.Body, "�")
	return c, dirty
}

func main() {
	raw := Comment{
		Author: "M\xffller",                   // kaputtes ü
		Body:   "Super Produkt\xc3\x28 :)",    // ungültige 2-Byte-Sequenz
	}
	clean, wasDirty := sanitizeForDB(raw)
	fmt.Printf("dirty=%v author=%q body=%q\n",
		wasDirty, clean.Author, clean.Body)
}

dirty=true author="M�ller" body="Super Produkt�( :)"

Die Funktion liefert zusätzlich einen bool zurück, mit dem die aufrufende Schicht entscheiden kann, ob ein Metrik-Counter (encoding_repaired_total) hochgezählt werden soll. So bleibt das Problem sichtbar, ohne den Request scheitern zu lassen.

Strukturierte Logger (zerolog, slog, zap) schreiben Strings in der Regel als JSON-Felder. Wenn ein User-kontrollierter String ungültiges UTF-8 enthält, kann der Logger entweder still ersetzen, einen Marshal-Fehler produzieren oder — schlimmer — den Logging-Endpoint mit kaputten Bytes verstopfen. Vorgelagertes ToValidUTF8 ist der schnellste Weg, das Risiko aus dem Weg zu räumen.

Zweite Schutzschicht: Steuerzeichen wie \r oder \n ermöglichen Log-Injection (ein Angreifer fügt eine eigene „Zeile" in das Log ein). ToValidUTF8 selbst entfernt diese nicht — beide Schritte sollten kombiniert werden, jeder löst ein eigenes Problem.

package main

import (
	"fmt"
	"strings"
)

// safeLogField bereinigt UTF-8 und entfernt Zeilenumbrüche, die
// Log-Injection ermöglichen würden.
func safeLogField(s string) string {
	s = strings.ToValidUTF8(s, "�")
	s = strings.ReplaceAll(s, "\n", "\\n")
	s = strings.ReplaceAll(s, "\r", "\\r")
	return s
}

func main() {
	userInput := "normale Eingabe\xff\nFAKE log entry: admin login ok"
	fmt.Printf("safe=%q\n", safeLogField(userInput))
}

safe="normale Eingabe�\\nFAKE log entry: admin login ok"

Wichtig: diese Helfer gehören in eine zentrale Stelle (Logger-Wrapper, Middleware), nicht in jeden Call-Site. Sonst entstehen Lücken — und genau dort, wo eine vergessen wurde, bricht später ein Encoding ein.

Weiterführende Ressourcen

Externe Quellen

• strings.ToValidUTF8
• Go 1.13 Release Notes — strings
• unicode/utf8
• Unicode Standard §3.9 — U+FFFD Substitution of Maximal Subparts
• W3C — Encoding Standard

Verwandte Artikel

• strings-Paket — Übersicht
• strings.ToLower — Kleinschreibung
• strings.ToUpper — Großschreibung
• strings.Map — Rune-Mapping