Eine CSV-Datei vor dem Import von Windows-1251 und BOM befreien

Eine Datei kann völlig normal aussehen und trotzdem falsch codiert sein

Eine CSV-Datei, die aus älterer Buchhaltungs- oder Datenbanksoftware exportiert wurde, ist ziemlich oft gar nicht UTF-8. Windows-1251 für kyrillischen Text und Windows-1252 für westeuropäische Zeichen mit Akzenten und Umlauten sind bei Systemen, die vor Jahren gebaut wurden, noch immer übliche Ausgabeformate. Ein Tabellenprogramm zeigt eine solche Datei oft klaglos an, weil es automatisch seine eigene Vermutung über die Codierung anwendet. Die Datei sieht also normal aus – bis sie von etwas Strengerem gelesen wird, etwa einem Skript, einem Importprozess oder einem Ladeprogramm für eine Datenbank, das UTF-8 voraussetzt und statt des eigentlichen Textes eine Wand aus Zeichensalat bekommt.

Eine Markierung aus drei Bytes am Dateianfang kann einen strengen Parser zum Scheitern bringen

Die Bytereihenfolge-Markierung von UTF-8, kurz BOM (Byte Order Mark), besteht aus nur drei unsichtbaren Bytes ganz am Anfang einer Datei. Sie signalisiert, dass der folgende Text Unicode ist. Für ein Programm wie Excel, das danach sucht, ist sie hilfreich. Zum Problem wird sie, sobald das Ziel ein strenger JSON-Importer oder ein Skript ist, das nicht mit ihr rechnet. Diese zusätzlichen Bytes kleben dann am ersten Zeichen der ersten Spaltenüberschrift, und eine Spalte, die als „id“ gelesen werden soll, passt nirgends mehr zu diesem Namen, wo der übrige Code ihn erwartet. Wird die Markierung vor der Umwandlung erkannt und entfernt, statt in der Ergebnisdatei zu bleiben, entsteht diese Abweichung gar nicht erst – eine, deren Ursache sich im Nachhinein nur mühsam finden lässt.

Die richtige Codierung automatisch erkennen, ohne Auswahlmenü

Eine zuverlässige Erkennung der Codierung, wie sie „CSV in JSON“ ausführt, bevor auch nur eine Zeile gelesen wird, prüft zuerst, ob eine Bytereihenfolge-Markierung vorhanden ist. Danach versucht sie, die übrigen Bytes streng als UTF-8 zu validieren. Erst wenn diese strenge Prüfung scheitert, weicht sie auf Windows-1251 oder Windows-1252 aus, je nachdem, wie die Bytes mit hohen Werten verteilt sind. Diese Reihenfolge ist wichtig. Eine Datei, die schon UTF-8 ist, wird nie nachträglich angezweifelt und als etwas anderes fehlgelesen, und eine Datei, die kein UTF-8 ist, wird richtig erkannt, statt als UTF-8 durchgedrückt und dabei in Zeichensalat verwandelt zu werden. Dieselbe Erkennung steht auch vor „CSV in Excel“, für die Fälle, in denen das Ziel eine Tabelle ist und kein Skript.

Datentypen sind genauso wichtig wie die Zeichencodierung

Die richtige Zeichencodierung löst nur die Hälfte dessen, was bei einer CSV-in-JSON-Umwandlung schiefgeht. Die andere Hälfte ist die Entscheidung, welche Werte zu JSON-Zahlen oder booleschen Werten werden und welche reiner Text bleiben sollen. Ein Wert wie 00123, der zur Zahl 123 wird, verliert seine führende Null im Moment der Umwandlung, und zwar endgültig. Eine Kennung mit mehr als etwa fünfzehn Stellen wird gerundet, sobald sie zu einer gewöhnlichen Gleitkommazahl wird, statt Text zu bleiben. Beide sollten als Zeichenketten erhalten bleiben, denn die Umwandlung verändert hier die Daten selbst und nicht nur ihre Formatierung oder Darstellung.

Eine doppelte Spaltenüberschrift stört einen Import anders als eine falsche Codierung

JSON-Objekte können keine zwei Eigenschaften mit demselben Schlüssel enthalten. Hat eine Ausgangsdatei zwei Spalten mit zufällig derselben Überschrift – bei Exporten, die aus mehr als einem Quellsystem zusammengesetzt sind, nichts Ungewöhnliches –, müssen diese Duplikate bei der Umwandlung eindeutige Namen bekommen. Sonst überschreiben die Daten der zweiten Spalte in jedem entstehenden Objekt die der ersten, ganz ohne Warnung. Das ist eine andere Fehlerquelle als Codierung oder Datentypen, kann einen Import aber genauso unbemerkt beschädigen. Prüfen Sie deshalb, ob ein Konverter meldet, wenn das passiert, statt den Konflikt unsichtbar aufzulösen. Und wenn Sie das Ergebnis durch „JSON formatieren“ laufen lassen, sehen Sie die umbenannten Schlüssel auf einen Blick.

Schritt für Schritt: die Datei prüfen, bevor sie in den Import geht

Wandeln Sie den Export einmal in „CSV in JSON“ um, mit Trennzeichen und Codierung auf „Automatisch erkennen“, und prüfen Sie dann beide Vermutungen: Schicken Sie das Ergebnis weiter an „JSON formatieren“, einen der nächsten Schritte, die die Seite anbietet, und lesen Sie die ersten Datensätze. Verstümmeltes Kyrillisch oder kaputte Akzente und Umlaute bedeuten, dass die Codierung falsch erraten wurde; ein einziger langer Schlüssel, in dem die Trennzeichen noch stecken, bedeutet, dass das Trennzeichen falsch erraten wurde. Stellen Sie den falschen Wert von Hand ein und wandeln Sie erneut um: Das Menü für die Codierung bietet Windows-1251, Windows-1252, UTF-8 mit oder ohne BOM und UTF-16 LE, das Menü für das Trennzeichen Komma, Semikolon, Tabulator, Pipe oder ein eigenes Zeichen. Eine Datei, deren Trennzeichen oder Codierung sich überhaupt nicht deuten lässt, wird mit einer Meldung abgelehnt, statt in Unsinn umgewandelt zu werden.

Entscheiden Sie als Nächstes, welche Typen die Werte bekommen: Standardmäßig bleiben Werte mit führender Null und lange Kennungen bereits als Text erhalten, und bei einer Datei aus Codes, Telefonnummern oder Kontonummern wandelt die Einstellung „Alles als Text belassen“ unter „Werttypen“ überhaupt nichts um. Solange das Ergebnis in „JSON formatieren“ geöffnet ist, achten Sie auf zwei Spuren einer unordentlichen Quelle: Zwei Spalten, die beide id heißen, kommen als id und id_2 heraus, und eine Zeile mit mehr Feldern als die Kopfzeile trägt die überzähligen unter dem Schlüssel __extra. Beides lässt sich in der Ausgangsdatei günstiger beheben als in dem System, das sich später daran verschlucken würde. Bis zu zwanzig Dateien mit insgesamt 300 MB laufen in einem Stapel durch, ohne dass sie den Browser-Tab verlassen.