Ein paar der Ideen, die mit Numbers umgesetzt sind finde ich ja schon klasse. Doch heute habe ich versucht, eine CSV Datei meines Home-Banking Providers in eine Tabelle zu übernehmen, eigentlich eine klassische Aufgabe für jede Tabellenverarbeitung. Die Datei besteht aus einzelnen Zeilen bei denen die einzelnen Felder durch ein Semikolon voneinander getrennt sind. Wie hier in Deutschland üblich, ist das Komma natürlich als Dezimalzeichen benutzt worden. Leider sieht Numbers die Kommas und denkt sich dabei: OK, die Feldtrenner habe ich schon mal gefunden. Da hilft es leider auch nichts, wenn ich die Semiokolon durch Tabulatoren ersetze. Das Komma ist immer noch das Lieblingstrennzeichen für CSV Dateien.
OK. Dann ersetze ich halt das Dezimalkomma durch einen Dezimalpunkt und das Semikolon durch ein Komma. Dank des Automator kann ich das ja auch ganz nett automatisch durchführen lassen. Kein Problem (dachte ich).
Leider versucht Number dann beim Auswerten der Feldinhalte schlau zu sein. Da mein System auf “Deutsch” lokalisiert ist, werden die Zahlen dann natürlich entsprechend ausgewertet. Ein Punkt ist dann ein Tausender-Trennzeichen. Damit sind dann leider alle Zahlenwerte in der CSV Datei nicht mehr korrekt auszuwerten. Ich muss zugeben, dass ich exakt dieses Problem auch aus eigenen Anwendungen her kenne. Hier achten wir immer ganz genau darauf zu definieren, was der Begriff CSV Datei für uns tatsächlich bedeutet - es ist halt immer noch ein Dateiformat, das sehr stark von der Lokalisierung des Anwender-Computers abhängt. Was ich aber nicht verstehen kann ist, warum ein erfahrenes Unternehmen wie Apple so bereitwillig in eine solche Lokalisierungsfalle - die nun wirklich nicht neu ist - hineintappen kann.