Aus Müller wird Müller: das Encoding-Problem, das keiner auf dem Schirm hat
Umlaute, die in der Automatisierung zu Zeichensalat werden, sehen harmlos aus und beschädigen trotzdem still Ihre Kundendaten. Woher der Fehler kommt und wie Sie ihn abstellen.
Es fängt harmlos an. Ein Kunde schrieb mir letzten Herbst, seine Willkommensmails gingen seit ein paar Tagen mit "Sehr geehrter Herr Müller" raus. Nicht bei allen. Nur bei den Namen mit Umlaut. Müller, Schäfer, Krüger, Weiß, alle betroffen. Meier und Schmidt kamen sauber durch. Er tippte zuerst auf einen Zufall, dann auf einen Fehler in der Mailvorlage. Es war weder das eine noch das andere. Der Fehler saß zwei Stationen vorher, in einer CSV-Datei, die seit Monaten niemand mehr angefasst hatte.
Dieser Zeichensalat hat einen Namen: Mojibake. Aus ü wird Mü, aus ß wird ß, aus € wird €. Es sieht nach einem kosmetischen Schaden aus, ist aber ein Symptom. Irgendwo auf dem Weg haben zwei Systeme unterschiedliche Annahmen darüber getroffen, wie Text in Bytes übersetzt wird. Und weil deutsche Daten voller Umlaute stecken, trifft uns das härter als den englischsprachigen Raum, wo derselbe Fehler oft monatelang unbemerkt bleibt.
Woher der Fehler kommt
Ein Computer speichert keinen Buchstaben, er speichert Zahlen. Die Übersetzungstabelle zwischen Buchstabe und Zahl heißt Zeichenkodierung. Heute ist UTF-8 der Standard, der praktisch jedes Zeichen abbildet. Daneben lebt aber noch die alte Windows-Welt mit Windows-1252 und Latin-1 weiter, und dort bekommt ein ü eine andere Nummer als in UTF-8.
Solange ein System nur seine eigenen Daten schreibt und liest, merkt niemand etwas. Der Ärger beginnt an der Grenze zwischen zwei Systemen. Ein ERP exportiert eine Datei in Windows-1252, das nächste Tool liest sie als UTF-8, und schon steht statt des einen Umlauts eine Folge aus zwei falschen Zeichen im Text. Die Bytes sind unverändert, nur die Deutung ist falsch. Das ist der ganze Mechanismus, und genau deshalb sieht das Problem so unscheinbar aus und richtet trotzdem echten Schaden an.
Wo es in Ihre Automatisierung reinrutscht
In der Praxis sehe ich drei Stellen immer wieder.
Die erste ist der CSV-Export aus einem Altsystem. Viele Warenwirtschafts- und Buchhaltungsprogramme exportieren bis heute in Windows-1252. Landet so eine Datei in Make, n8n oder einem Import-Skript, das UTF-8 erwartet, kippt jeder Umlaut.
Die zweite ist Excel. Öffnet ein Mitarbeiter eine saubere UTF-8-Datei in Excel und speichert sie wieder als CSV, macht Excel unter Windows daraus je nach Version wieder Windows-1252 oder setzt ein unsichtbares Zeichen an den Dateianfang, das sogenannte BOM. Das taucht dann als  vor der ersten Spaltenüberschrift auf und zerschießt oft genau diese Spalte.
Die dritte Stelle sind Webhooks und APIs, bei denen der Absender vergisst, die Kodierung im Header anzugeben. Der Empfänger rät dann, und er rät nicht immer richtig.
Warum es so spät auffällt
Der eigentliche Grund, warum das durchrutscht, ist das Testen. Wer eine Automatisierung baut, testet mit "Test Test" oder "Max Mustermann". Da ist kein Umlaut drin. Der Happy Path ist grün, alles wird freigeschaltet, und erst im Echtbetrieb tauchen Frau Schäfer und Herr Weiß auf. Bis das jemand bemerkt, sind vielleicht schon dreihundert Mails mit falscher Anrede raus. Oder, schlimmer, dreihundert Datensätze mit kaputten Namen liegen im CRM und werden von dort weiterverarbeitet.
Und Namen sind nur der sichtbare Teil. Straßen mit Umlaut, Städte wie Nürnberg oder Lübeck, Produktbezeichnungen, Freitextfelder aus dem Kundenservice, alles betroffen. Aus einer falschen Adresse wird eine unzustellbare Sendung, und die kostet mehr als eine peinliche Anrede.
Der Reparaturfehler, der es schlimmer macht
Wenn der Zeichensalat erst da ist, gibt es einen zweiten Fehler, der die Sache verschlimmert. Jemand sieht Müller, denkt sich nichts dabei und schickt die Datei einfach noch einmal durch eine geratene Kodierung, in der Hoffnung, dass es sich schon richten wird. Das Gegenteil passiert. Aus einem einmal falsch gedeuteten Umlaut wird beim zweiten falschen Durchlauf ein noch längeres Kauderwelsch, das sich kaum noch zurückrechnen lässt. Ich habe Datenbanken gesehen, in denen dasselbe ü über die Jahre drei verschiedene kaputte Formen angenommen hatte, je nachdem, wie oft der Datensatz durch welches Tool gelaufen war. Reparieren Sie deshalb an der Quelle, nie am Symptom. Und legen Sie vor jedem Reparaturversuch eine Kopie an, sonst zerstören Sie im Zweifel die letzte lesbare Version.
Was hilft
Die gute Nachricht: Diese Fehler sind vollständig vermeidbar, wenn Sie an den richtigen Stellen hinschauen.
Legen Sie UTF-8 als verbindlichen Standard fest, für jeden Export, jeden Import, jede Schnittstelle. Es ist die einzige Kodierung, die Sie brauchen, und jede Ausnahme davon ist eine Fehlerquelle für später.
Prüfen Sie beim CSV-Export explizit, in welcher Kodierung Ihr Altsystem schreibt. Kann es nur Windows-1252, bauen Sie den Konvertierungsschritt direkt hinter den Export, nicht drei Stationen weiter, wenn der Schaden schon durch die halbe Kette gewandert ist.
Nehmen Sie Excel aus der Kette, wo es geht. Sobald ein Mensch eine Datei in Excel öffnet und wieder speichert, haben Sie die Kontrolle über die Kodierung verloren. Übergaben direkt von Maschine zu Maschine sind hier deutlich verlässlicher.
Und testen Sie mit echten Daten. Nehmen Sie Müller, Schäfer, Weiß und ein € ins Testset auf, bevor irgendetwas live geht. Ein einziger Testdatensatz mit Umlaut und Eurozeichen deckt die meisten dieser Fehler auf, bevor der erste Kunde sie sieht.
Encoding wirkt wie ein technisches Detail, das man den Entwicklern überlässt. Tatsächlich entscheidet es darüber, ob Ihre Kundendaten sauber bleiben oder still verrotten. Und still ist hier das gefährliche Wort. Ein Absturz fällt sofort auf. Ein Müller schleicht sich rein und bleibt, bis ihn ein Kunde reklamiert.