Datenfehler beim CSV-Import: Ursachen und Lösung
Preise verdoppelt. Aus „café“ wurde „café“. Jedes Produkt dreifach angelegt. Geht ein Import schief, ist der erste Impuls, die Datei zu beschuldigen – doch eine „schlechte Datei“ ist fast nie die Ursache: Zwei Systeme waren sich, still und leise, uneinig darüber, was ein Komma, ein Anführungszeichen oder eine Zahl bedeutet, und nichts hat die Uneinigkeit gemeldet, bis die falschen Daten schon vor Ihnen lagen.
Sieben Arten, wie eine sauber aussehende Datei lügt
Jeder dieser Fälle kommt mit der richtigen Zeilenzahl und ohne Fehlermeldung an.
Encoding-Konflikte — eine als Windows-1252 geschriebene und als UTF-8 gelesene Datei (oder umgekehrt) macht aus „café“ „café“ und aus einem Gedankenstrich drei kryptische Zeichen. Nichts stürzt ab; die Werte sind einfach falsch, ausgerechnet in den Spalten, an denen Sie zufällig nicht vorbeischauen.
Das Trennzeichen ist eigentlich kein Komma — weite Teile Kontinentaleuropas speichern CSV mit Semikolons, weil diese Gebietsschemata das Komma als Dezimaltrennzeichen nutzen. Nehmen Sie das falsche an, bekommen Sie eine einzige riesige, ungesplittete Spalte – oder das Dezimalkomma eines Preises landet aufgeteilt in Spalten, die es gar nicht gibt.
Tabellenkalkulations-„Hilfe“ vor dem Export — Excel speichert eine als 01234 eingegebene Postleitzahl als Zahl 1234 und stellt einen 16-stelligen Barcode in wissenschaftlicher Notation dar, gerundet nach 15 Stellen. Bis die CSV geschrieben ist, existiert der ursprüngliche Wert nirgendwo mehr.
Zahlen, die zwei verschiedene Dinge bedeuten — 1.234,56 und 1,234.56 sind derselbe Betrag nach zwei regionalen Konventionen. Lesen Sie die eine unter der Annahme der anderen, wird sie trotzdem sauber geparst – als 1.23 oder als 1234560.
Kopfzeilen, die sich verschieben — ein Export fügt eine Spalte hinzu oder ordnet sie um, aus „postcode“ wird „postal_code“, und ein nach Position abgleichender Importer schreibt still Beschreibungen in Preisfelder. Nichts an einer CSV erzwingt, dass Spalte 4 zweimal dasselbe bedeutet.
Erneuter Import ohne stabilen Schlüssel — korrigieren Sie drei Zeilen, laden Sie 2.000 erneut hoch, und ein Importer ohne stabile Identität pro Datensatz erzeugt 2.000 Duplikate statt drei zu aktualisieren. Namen ändern sich; eine externe Referenz, SKU oder Bestellnummer nicht.
Zeichen, die man nicht sieht — ein geschütztes Leerzeichen, das von einer Webseite kopiert wurde, oder "Blau " mit einem nachgestellten Leerzeichen sieht identisch mit dem sauberen Wert aus und scheitert bei jedem exakten Abgleich – sodass dieselbe Kategorie zweimal angelegt wird und Duplikatsprüfungen nie anschlagen.
Vor dem Upload: die Prüfung, die das meiste davon abfängt
1
Öffnen Sie die Datei einmal als reinen Text
Bevor Sie der Vorschau eines Werkzeugs vertrauen, öffnen Sie die Datei in einem reinen Texteditor, nicht in einer Tabellenkalkulation – eine Tabellenkalkulation interpretiert die Datei in dem Moment neu, in dem sie sie öffnet, und verbirgt damit genau die Probleme, nach denen Sie suchen. Sehen Sie sich den rohen Anfang der ersten Zeile daraufhin an, ob dort etwas vor dem ersten Spaltennamen steht.
2
Prüfen Sie, ob das Trennzeichen dem entspricht, was Sie annehmen
Zählen Sie die Trennzeichen auf ein paar verschiedenen Zeilen mit bloßem Auge. Eine Datei, die in Wahrheit semikolongetrennt ist, aber als kommagetrennt angenommen wird, zeigt außerhalb der Werte selbst kein einziges Komma – eine Fünf-Sekunden-Prüfung, die eine ganze Fehlerklasse abfängt, bevor sie entsteht.
3
Testen Sie eine Zeile mit Komma, Anführungszeichen und Zeilenumbruch
Suchen oder erzeugen Sie bewusst eine Testzeile mit einem Komma innerhalb eines Textfelds, einem Anführungszeichen und einer mehrzeiligen Notiz, und prüfen Sie, ob der Importer jedes davon als ein einziges Feld behält, statt es aufzuteilen. Diese eine Zeile testet genau den Mechanismus, der bei falscher Behandlung stillschweigend alle nachfolgenden Spalten verschiebt.
4
Testen Sie einen kleinen Stapel vor der ganzen Datei
Zuerst zehn oder zwanzig Zeilen, einzeln geprüft, decken einen systematischen Zuordnungsfehler auf – eine vertauschte Spalte, eine falsche Währung, ein falsches Datumsformat –, solange es noch zehn Zeilen zu korrigieren sind und nicht zehntausend.
5
Entscheiden Sie pro Zeile, was „fertig“ heißt, nicht pro Datei
Ein einziges Bestanden oder Nicht bestanden für die ganze Datei sagt Ihnen nichts darüber, welche Zeilen zu korrigieren sind. Bestehen Sie auf einem Ergebnis je Zeile — angelegt, aktualisiert, übersprungen, fehlgeschlagen, und warum —, bevor Sie einem Import etwas Wichtiges anvertrauen.
Fast immer ein Encoding-Konflikt. Die Datei wurde in einer Zeichenkodierung geschrieben – häufig Windows-1252 oder Latin-1 – und als UTF-8 gelesen, oder umgekehrt. Speichern Sie die Quelldatei ausdrücklich erneut als UTF-8 und prüfen Sie, ob eine Byte-Order-Mark entfernt werden muss, je nachdem, was der Importer erwartet.
Tabellenkalkulationen speichern alles, was wie eine Zahl aussieht, als Zahl – und Zahlen behalten keine führenden Nullen. Das ist passiert, bevor die CSV geschrieben wurde, in dem Moment, in dem der Wert eingetippt oder automatisch formatiert wurde, und es lässt sich aus der CSV allein nicht wiederherstellen: Die Ausgangsspalte muss als Text formatiert sein, statt hinterher repariert zu werden.
Der Importer hatte keine stabile Möglichkeit, eine Zeile in der neuen Datei als „denselben Datensatz“ zu erkennen, den er bereits gespeichert hatte – höchstwahrscheinlich, weil der Abgleich über einen Namen oder eine Beschreibung lief statt über eine feste Kennung wie eine externe Referenz, eine Bestellnummer oder eine SKU. Ohne diesen stabilen Schlüssel sieht jeder Import wie ein erster Import aus.
Das ist ebenso ein Berichts- wie ein Datenproblem — ein guter Importer nennt Ihnen das Ergebnis jeder einzelnen Zeile, nicht nur das der Datei insgesamt. Wenn das Werkzeug, das Sie nutzen, nur ein einziges Bestanden/Fehlgeschlagen für den gesamten Upload liefert, werten Sie das als Hinweis, in kleinen Chargen zu testen, bis Sie Ergebnisse je Zeile sehen können.
Fast immer eine Verwechslung von Dezimal- und Tausendertrennzeichen. 1.234,56 und 1,234.56 sind beides gültige Darstellungen derselben Zahl nach unterschiedlichen regionalen Konventionen, und die eine unter der Annahme der anderen zu lesen schlägt nicht fehl – es kommt einfach ein falscher Wert heraus. Prüfen Sie, welche Konvention Ihr Export verwendet, und teilen Sie sie dem Import ausdrücklich mit, statt ihn raten zu lassen.
Vorsicht – eine CSV-Datei in einer Tabellenkalkulation zu öffnen und neu zu speichern ist genau der Schritt, der mehrere der auf dieser Seite genannten Probleme erzeugt: führende Nullen, automatische Datumsumwandlung, wissenschaftliche Notation. Wenn Sie eine Handvoll Zeilen von Hand bearbeiten müssen, ist ein reiner Texteditor sicherer als der komplette Umweg über eine Tabellenkalkulation.
Wie Olmira das löst
Olmiras Datei-Import-Connector ist genau gegen diese Liste gebaut: ein strikter RFC-4180-Parser, der in Anführungszeichen stehende Kommas und eingebettete Zeilenumbrüche verarbeitet, automatisches Entfernen eines führenden UTF-8-BOM, und überlange Dateien werden rundweg abgelehnt statt still abgeschnitten. Eine Zeile, deren Spaltenzahl nicht zur Kopfzeile passt, schlägt für sich allein fehl, ohne den Rest abzubrechen, und ein Dedupe-Schlüssel sorgt dafür, dass das erneute Ausführen derselben Datei bestehende Datensätze aktualisiert oder überspringt – je nach gewählter Regel – statt sie zu duplizieren.
Für Produkt- und Leistungskataloge fügt der CSV-Import eine Vorschau pro Zeile hinzu – einschließlich aller von der KI ausgefüllten Felder, klar gekennzeichnet – bevor auch nur eine Zeile gespeichert wird. Die vollständige Connector-Plattform, mit geplanten Abrufen und signierten Webhooks neben dem Datei-Import, finden Sie unter Integrationen.