Einleitung

Ich habe dieses Tool aus einem einfachen Grund gebaut. Die manuelle Arbeit jedes Mal war schlicht zu mühsam.

CSV aus internen Systemen, aus Excel erzeugte CSV, Konfigurationsdateien aus Linux, Windows oder Datenbanken. Sobald sich die Herkunft ändert, ändern sich auch Codierung, Zeilenenden und BOM.

  • Erwartet UTF-8, tatsächlich Shift_JIS
  • Erwartet LF, tatsächlich CRLF
  • Manche Systeme brauchen BOM, andere gehen mit BOM kaputt

Diese Prüfung und Konvertierung per Augenmaß skaliert nicht. Darum habe ich ein Tool gebaut, das beliebige Quellen akzeptiert und die Ausgabe exakt auf das Zielsystem normiert.

Das eigentliche Problem ist nicht eine einzelne kaputte Datei

Wenn nur eine Datei beschädigt ist, lässt sich das meist lösen. Schwierig wird es bei 10 oder 100 Dateien gleichzeitig aus gemischten Quellen.

Noch schwieriger: Jedes Importziel hat eine andere Definition von „korrekt“.

  • System A akzeptiert nur UTF-8 ohne BOM
  • System B läuft stabil mit UTF-8 und BOM
  • System C setzt Shift_JIS voraus; UTF-8 ist lesbar, Import scheitert trotzdem

In so einer Lage hilft der Standardsatz „einfach alles UTF-8“ nicht. Man braucht einen sicheren, reproduzierbaren Ablauf passend zum Ziel.

Was dieses Tool leisten soll

Die Idee hat nur drei Prinzipien:

  1. Dateien aus jeder Herkunft akzeptieren
  2. Nach Zielanforderung konvertieren
  3. Auch im Batch die Zahl der Vorfälle nicht erhöhen

Es geht nicht um technische Show, sondern um weniger Reibung im Betrieb.

Mein tatsächlicher Ablauf

1. Zuerst die Ausgabespezifikation festlegen

Nicht mit der Eingabe starten, sondern mit der Ausgabe. Diese drei Punkte fixieren:

  • Codierung (UTF-8 / Shift_JIS usw.)
  • Zeilenende (LF / CRLF)
  • BOM (mit / ohne)

Bleibt das offen, variiert das Ergebnis mit der Person am Steuer.

2. Zielmenge in kleine Chargen teilen

Nicht sofort alles auf einmal verarbeiten. Nach System, Zeitraum oder Dateityp trennen und mit kleinen Batches beginnen.

Grund: Bei Fehlern ist ein Rollback möglich. Ein Vollvolumen-One-Shot ist nur schnell, wenn er gelingt.

3. Bedingungen fixieren und Batch-Konvertierung fahren

Im Konverter die Bedingungen je Ziel fest einstellen. Während des Laufs nichts mehr ändern. Wichtig ist Wiederholbarkeit.

4. Erfolg nicht per Sichtprüfung entscheiden

„Lässt sich öffnen, also okay“ ist oft der Beginn von Vorfällen. Mindestens prüfen:

  • Ist die Zeilenanzahl vor/nachher gleich?
  • Ist die Spaltenzahl in CSV/TSV stabil?
  • Nimmt � (Ersatzzeichen) zu?
  • Bleiben Länge und Zeichentyp in Schlüsselfeldern (ID/Code) erhalten?

Wenn das nicht passt, kein Import.

BOM ist keine Glaubensfrage, sondern Zielanforderung

Die Debatte BOM ja/nein bringt im Betrieb wenig. Es zählt nur, wie das Gegenstück Dateien verarbeitet.

  • Wenn das Ziel mit BOM stabil ist: mit BOM ausgeben
  • Wenn BOM Probleme macht: ohne BOM ausgeben

Priorität hat nicht „theoretisch korrekt“, sondern „zerstört das Ziel nicht“. So funktioniert Betrieb.

Der Wert liegt nicht in der Konvertierung selbst

Der eigentliche Wert:

  • Entscheidungen sind personenunabhängig
  • Wiederholte Prüfkosten sinken

Encoding-Vorfälle lassen sich nicht auf absolut null bringen. Aber man kann aufhören, dieselben Fehler zu wiederholen. Dafür gibt es dieses Tool: alles annehmen, passend zum Zweck stabil zurückgeben.

Fazit

Dieses Tool entstand nicht aus Idealtheorie. Es entstand, um den ständig wiederkehrenden, lästigen Encoding-Aufwand im Alltag zu eliminieren.

Dateien aus unterschiedlichen Quellen annehmen, Codierung/Zeilenende/BOM ans Ziel anpassen und konsistent ausgeben. Allein die Automatisierung dieses Flusses erleichtert den Betrieb deutlich.

Mojibake-Bekämpfung ist kein Job für reine Willenskraft. Sie muss als reproduzierbares Verfahren vorliegen, mit gleichem Ergebnis für jede Person. Erst dann ist eine sichere Batch-Rettung erreicht.