Die Kodierungs-Apokalypse: Wenn UTF-8 nicht UTF-8 ist
Die schlimmste Datenkatastrophe, die ich je miterlebt habe, ereignete sich 2017 in einer multinationalen Einzelhandelskette. Sie konsolidierten Kundendaten aus 47 regionalen Datenbanken in 12 Ländern in einem einzigen Data Warehouse. Einfach genug, oder? Exportieren nach CSV, importieren ins Warehouse, einige Duplikationslogik ausführen und fertig. Außer dass die CSVs der französischen Division ständig Namen beschädigten. "François" wurde zu "François". "Chloé" wurde zu "Chloé". Die deutsche Division hatte ähnliche Probleme mit Umlauten. Die Daten der japanischen Division waren völlig unleserlich – nur Reihen von Fragezeichen und Ersetzungszeichen. Die zugrunde liegende Ursache? Jedes regionale Team hatte seine CSVs mit unterschiedlichen Kodierungen exportiert. Frankreich verwendete ISO-8859-1 (Latin-1). Deutschland verwendete Windows-1252. Japan verwendete Shift-JIS. Die Teams im Vereinigten Königreich und in den USA verwendeten UTF-8, aber einige hatten UTF-8 mit BOM (Byte Order Mark) und andere ohne. Ein Team in Spanien hatte es irgendwie geschafft, ihre Daten in UTF-16LE zu exportieren. Das Konsolidierungsprojekt, ursprünglich auf drei Monate angelegt, dauerte elf Monate. Wir mussten eine benutzerdefinierte Kodierungserkennungspipeline erstellen, die: 1. Versuchen würde, die Kodierung mithilfe mehrerer Bibliotheken (chardet, charset-normalizer und einer benutzerdefinierten Heuristik) zu erkennen 2. Die Erkennung validieren würde, indem sie nach typischen Zeichmustern in jeder Sprache sucht 3. Alles ohne BOM in UTF-8 konvertiert 4. Jede Konvertierung mit Vertrauenssätzen für die manuelle Überprüfung protokolliert Selbst mit dieser Pipeline hatten wir eine Fehlerquote von 3%, die eine manuelle Korrektur erforderte. Das sind 3% von 47 Millionen Kundendaten – 1,4 Millionen Namen, die von Menschen überprüft werden mussten. Die Lektion? Vertraue niemals der Kodierung einer CSV. Niemals. Selbst wenn dir jemand sagt: "Es ist definitiv UTF-8", überprüfe es. Ich habe Dateien gesehen, die behaupteten, in ihren Metadaten UTF-8 zu sein, die jedoch tatsächlich Windows-1252 mit hoch-ASCII-Zeichen waren. Ich habe UTF-8-Dateien mit zufälligen ISO-8859-1-Fragmenten gesehen, bei denen jemand von einem alten System kopiert und eingefügt hatte. Ich habe sogar eine Datei gesehen, die während des Exports die Kodierung wechselte, weil das Exportskript abstürzte und mit anderen Lokaleinstellungen neu startete. Jetzt wird jede CSV, die auf meinem Tisch landet, durch ein Kodierungsvalidierungsskript geleitet, bevor ich überhaupt einen Blick auf die Daten werfe. Es hat mir unzählige Stunden gespart und mindestens ein Dutzend größere Vorfälle verhindert.Der Whitespace, der nicht da war (außer er war)
Im Jahr 2018 wurde ich gerufen, um ein System zur finanziellen Abstimmung zu reparieren, das seit sechs Monaten versagte. Das Unternehmen war ein Zahlungsabwickler, der Milliarden von Dollar in Transaktionen bearbeitete. Ihr Abstimmungsprozess verglich Transaktionsdatensätze aus ihrer Datenbank mit CSV-Berichten von Bankpartnern. Das System meldete täglich Tausende von Abweichungen – Transaktionen, die in den Bankberichten erschienen, aber nicht in ihrer Datenbank, oder umgekehrt. Das Finanzteam gleicht diese Abweichungen manuell ab und arbeitet 60 Stunden pro Woche, um Schritt zu halten. Sie überprüften jede markierte Transaktion und fanden heraus, dass sie tatsächlich in beiden Systemen existierte. Die Transaktions-IDs stimmten perfekt überein. Aber das automatisierte System kennzeichnete sie weiterhin als Abweichungen. Ich verbrachte zwei Tage damit, den Code, die Datenbankabfragen und die CSV-Parserlogik zu analysieren. Alles sah korrekt aus. Dann tat ich etwas, das von Anfang an offensichtlich hätte sein müssen: Ich öffnete die CSV in einem Hex-Editor. Da war es. Jede Transaktions-ID in den CSV-Dateien der Bank hatte ein abschließendes Leerzeichen. In Excel nicht sichtbar. In den meisten Texteditoren nicht sichtbar. Aber dort, im Hex-Dump: `54 52 41 4E 53 31 32 33 34 35 20` statt `54 52 41 4E 53 31 32 33 34 35`. Das letzte `20` war ein Leerzeichen. Die Datenbank speicherte Transaktions-IDs ohne nachfolgende Leerzeichen. Die Vergleichslogik führte einen exakten Stringvergleich durch. "TRANS12345" ≠ "TRANS12345 ". Tausende von falschen Abweichungen, Hunderte von verschwendeten Stunden – alles wegen eines einzigen nachfolgenden Leerzeichens. Aber hier wird es schlimmer: Die nachfolgenden Leerzeichen waren inkonsistent. Einige Transaktions-IDs hatten sie, einige nicht. Einige hatten nachfolgende Leerzeichen, einige führende Leerzeichen, und einige hatten beides. Einige hatten Tabs anstelle von Leerzeichen. Eine bemerkenswerte Datei hatte eine Mischung aus Leerzeichen, Tabs und geschützten Leerzeichen (U+00A0). Die Lösung war einfach – alle Whitespace während des Imports trimmen. Aber die Lektion war tiefgreifend: Whitespace in CSVs ist niemals unbeabsichtigt, immer problematisch und häufig unsichtbar. Ich habe jetzt eine Regel: Jedes Stringfeld wird beim Import getrimmt, keine Ausnahmen. Es interessiert mich nicht, ob die Geschäftslogik besagt, dass das Feld Whitespace erhalten soll. Es interessiert mich nicht, ob jemand besteht, dass die Daten sauber sind. Trim alles. Ich habe auch gelernt auf andere unsichtbare Zeichen zu achten: Nullbreite-Leerzeichen (U+200B), Nullbreite-Nicht-Verknüpfungszeichen (U+200C), Nullbreite-Verknüpfungszeichen (U+200D) und das gefürchtete Byte-Order-Mark (U+FEFF), das manchmal in der Mitte von Dateien erscheint. Diese Zeichen sind die Geister in der Maschine, unsichtbar für Menschen, aber sehr real für Computer.Das Datumsformat, das den internationalen Handel gebrochen hat
Lassen Sie mich Ihnen von der Zeit erzählen, als ich auf ein Datumsformat stieß, das so verflucht, so grundlegend kaputt war, dass es meine Träume immer noch heimsucht. Dies war bei einem Logistikunternehmen, das Sendungen zwischen Herstellern in Asien und Einzelhändlern in Nordamerika und Europa koordinierte. Das System funktionierte so: Hersteller luden CSV-Dateien mit Versanddetails hoch, einschließlich Abholdaten, geschätzten Lieferdaten und Zollfreigabedaten. Das System analysierte diese Daten, berechnete die Transitzeiten und koordinierte mit Speditionen und Zollagenten. Alles funktionierte jahrelang gut. Dann, im März 2016, begann das System, Sendungen für Daten in der Vergangenheit zu planen. Container, die am 15. März 2016 abgeholt werden sollten, wurden für den 15. März 1916 geplant. Zollunterlagen wurden für Daten eingereicht, die noch vor der Erfindung des Containertransports lagen. Die zugrunde liegende Ursache? Excells automatische Datumsformatierung in Kombination mit regionalen Datumsformatunterschieden und einem wahrhaft spektakulären Missverständnis davon, wie Daten funktionieren. Folgendes geschah: 1. Ein Hersteller in China gab ein Datum wie "3/15/2016" (15. März 2016 im MM/DD/YYYY-Format) ein. 2. Excel interpretierte dies als Datum und speicherte es intern als Seriennummer (42444 für den 15. März 2016). 3. Beim Exportieren in CSV würde Excel es gemäß der Systemlokale formatieren. 4. Die chinesische Systemlokale verwendete das YYYY-MM-DD-Format, sodass es als "2016-03-15" exportiert wurde. 5. Unser Import-System, konfiguriert für das MM/DD/YYYY-Format, würde "2016-03-15" als "2016/03/15" (der 2016. Monat, 3. Tag, Jahr 15) analysieren. 6. Da Monat 2016 ungültig ist, würde der Parser auf "20/16/03/15" zurückfallen. 7. Durch eine Reihe zunehmend verzweifelter Versuche der Analyse würde er schließlich auf "03/15/1916" festlegen. Aber warten Sie, es wird schlimmer. Einige Hersteller verwendeten das DD/MM/YYYY-Format. Einige verwendeten YYYY-MM-DD. Einige verwendeten MM/DD/YY (zweiziffrige Jahre). Und ein Hersteller in Taiwan verwendete den Minguo-Kalender, bei dem das Jahr 105 dem Jahr 2016 n. Chr. (1912 + 105) entspricht. Wir endeten mit Daten, die von 1916 bis 2116 reichten, mit einem besonders dichten Cluster um 1970 (die Unix-Epoche), weil einige Systeme Daten als Unix-Zeitstempel exportierten und unser Parser sie als YYYYMMDD-Format interpretierte. Die Lösung erforderte: - Implementierung eines Multi-Strategie-Datenparsers, der versuchen würde, das Format zu erkennen - Hinzufügen von Validierungsregeln (Daten vor 2000 oder nach 2050 ablehnen) - Erfordern, dass Hersteller ausschließlich das ISO 8601-Format (YYYY-MM-DD) verwenden - Aufbau einer Weboberfläche für CSV-Uploads, die die analysierten Daten vor dem Import anzeigt - Erstellung einer umfassenden Test-Suite mit Daten in jedem erdenklichen Format Selbst mit all diesen Sicherheitsvorkehrungen erhalten wir immer noch gelegentlich Fehler bei der Datumserkennung. Erst letzten Monat stieß ich auf eine CSV, in der jemand "2/29/2023" eingegeben hatte (29. Februar 2023 – ein Datum, das nicht existiert, da 2023 kein Schaltjahr ist). Excel akzeptierte es glücklich, speicherte es als Seriennummer 45000 und exportierte es als "2023-02-29". Unser System importierte es, validierte, dass es im richtigen Format war, und plante eine Sendung für ein Datum, das nicht existiert."Das Problem mit Daten ist, dass jeder denkt, er versteht sie, aber niemand tatsächlich tut. Daten sind kulturelle Konstrukte, keine mathematischen. Sie haben Zeitzonen, Sommerzeit, Schaltjahre, Schaltsekunden und Kalenderreformen. Sie haben unterschiedliche Formate in verschiedenen Ländern, unterschiedliche Anfangszeitpunkte in verschiedenen Epochen und unterschiedliche Bedeutungen in unterschiedlichen Kontexten. Und CSV-Dateien, mit ihrem völligen Mangel an Metadaten, geben Ihnen keine Möglichkeit zu wissen, welche Interpretation korrekt ist."Dieses Zitat von einem Kollegen erfasst perfekt das Datumsproblem. CSVs haben keine Datentypen. Sie haben keine Schemata. Sie sind nur Text. Wenn Sie "01/02/03" in einer CSV sehen, ist das der 2. Januar 2003? Der 1. Februar 2003? Der 2. März 2001? Der 3. Februar 2001? Es gibt keine Möglichkeit zu wissen, ohne Kontext, und Kontext ist genau das, was CSVs nicht bieten.
Die Zahlen, die keine Zahlen waren
Hier ist eine Tabelle der häufigsten Probleme mit numerischen Daten, die ich erlebt habe, zusammen mit ihrer Häufigkeit und typischen Auswirkungen:| Problemtyp | Häufigkeit | Typische Auswirkungen | Beispiel |
|---|---|---|---|
| Thousandentrenner | Sehr hoch (60%) | Importfehler, Typfehler | "1.234,56" wird als String geparst |
| Währungssymbole | Hoch (45%) | Importfehler, Rechenfehler | "$1.234,56" oder "€1.234,56" |
| Unterschiede im Dezimaltrennzeichen | Hoch (40%) | Katatastrophale Rechenfehler | "1.234,56" (europäisch) vs. "1,234.56" (US) |
| Wissenschaftliche Notation | Mittel (25%) | Präzisionsverlust, Fehlinterpretation | "1,23E+05" oder "1,23456789E-10" |
| Führende Nullen | Mittel (30%) | Datenverlust, ID-Korruption | "00123" wird zu "123" |
| Prozentzeichen | Mittel (20%) | 100x Rechenfehler | "15%" wird als 15 anstelle von 0,15 gespeichert |
| Negative Zahlenformate | Niedrig (15%) | Sign Verluste, falsche Berechnungen | "(123" C
Written by the CSV-X Team Our editorial team specializes in data analysis and spreadsheet management. We research, test, and write in-depth guides to help you work smarter with the right tools. Related Tools Related Articles Data Cleaning 101: Fix Messy Data in 10 Steps — csv-x.com Excel Pivot Tables: Beginner to Advanced How to Fix CSV Encoding Issues (UTF-8, Latin-1, and the Dreaded Mojibake)Put this into practice Try Our Free Tools →🔧 Explore More Tools |